iOS/Android Device orientation (pitch, yaw, roll). Is it better with accelerometer or gyroscope?

Question

I've been researching for a bit now and now I have to decide which road to take.

Mine requirements: Need to know device's orientation relative to the true heading (geographic north pole, not magnetic pole). For that I must use compass and now I have to decide which other thing, accelerometer or gyroscope.

Since this is a new thing to me I've spent last few hours reading stacks and wikipedia articles and still I am confused.

I am targeting both platforms (iOS and Android) and I am developing them with Appcelerator Titanium. With Titanium I can easily get accelerometer's values (x,y,z) and trueHeading.

Since iPhone 3GS does not have gyroscope obviously I can't use it on that device. Newer iPhones and Android devices have it.

So the questions are:

1. Is accelerometer's XYZ and compas's TrueHeading data enough for me to calculate device pitch, roll and yaw? But it has to be accurate.

2. Is it more accurate to use TrueHeading from compas and use gyroscope's values instead of accelerometer's?

3. Is it clever to combine both accelerometer and gyroscope with TrueHeading?

If I take the first road I don't have to write Titanium module for fetching the gyroscope data since it gives me only accelerometer data and I can use this on 3GS iPhone also.

If I take the second road I have to write two modules (iOS and Android) to fetch me gyroscope data and I lose 3GS support.

If I take the third road I again have to write Titanium modules and I lose 3GS support.

Answer 1

First of all if you don't have a huge installed base of 3GS users but write a new app, don't care about old hardware. IMO it doesn't make sense from an economical point of view but will shrink your number of alternatives in system architecture.

What you are looking for is called sensor fusion. Doing this consequently requires some heavy math like Kalman Filters etc. The good news is that it exists on iPhone (Core Motion) and AFAIK on Andriod as well (sounds like it is in Sensor fusion implemented on Android?).

I don't know much about appcelerator aside from the name and thus cannot say anything about an easy way to use it. Anyway if not implemtented on an abstract layer, I assume appcelerator provides you with the possibility to do native API calls. Thus you should be able to embed the native API (after fiddling around some time;-).

In general it depends on your requirements. The faster you need to have an exact result the more I'd recommend real sensor fusion including all 3 sensors. If you are fine with a slower response time, a combination of compass and accelerometer will do.