Accelerating iPhones

I’m pleased to be able to say my application to be a registered iPhone developer was finally approved, and hence I am now able to run test native applications on my own iPhone. Although the simulator provided with XCode allows you to test many types of applications, one thing it won’t do is simulate feedback from the built-in accelerometers. Hence my grand ideas of developing a suite of applications based on the use of accelerometer data had to be put on hold until now, given that I couldn’t determine whether the accelerometers would be capable of the accuracy and consistency I would need to make my apps work.

So the first thing I did was load up the sample Accelerometer Graph application and then modify it to display the acceleration (m/s^2), speed (m/s) and distance traveled (m) along each axis, in order to observe its behaviour and experiment with it.

The accelerometers return data in units of g, so need to be multiplied by 9.81 to convert to m/s^2. The interval duration may be varied as desired, but I experimented with both 1/40th and 1/100th of a second.

The speed is then incremented with each time interval by the acceleration x interval duration.

The distance traveled is incremented with each time interval by the speed x interval duration.

My initial observation was that it was all wildly inaccurate. When the iPhone is moved and then returned to its initial location, the acceleration should increase and then decrease, and correspondingly the speed and distance. The acceleration demonstrably returned to zero, but there was usually a residual speed shown after returning to rest, indicating that there were accumulating errors along the way.

An initial factor in causing this appears to be the granularity of the measurements of acceleration returned (ie. the resolution). The accelerometer readings returned appeared to come in quanta of about 0.18m/s^2 (ie. about 0.018g). This is a fairly large gap, and results in a large cumulative error very quickly.

Further investigation led to the observation that errors became especially large when the iPhone was not kept perfectly level whilst being moved horizontally, and eventually I realised that this was because the high-pass filter only acted slowly to filter out gravity effects – and even very small degree of tilting was leading to large cumulative errors before the filter managed to adjust for the gravity bias.

The crux of the issue is that the accelerometers actually measure force rather than acceleration per se. Hence they are affected by gravity, which is not relevant to the measurement of the device’s motion, and this can necessarily only be filtered out over a period of time rather than instantly, which therefore makes it impossible to derive accurate motion information.

So the the force of gravity and any actual acceleration of the device are not individually distinguishable by the accelerometers. The device may detect, for example, that it has a force on it 10% more than gravity, but whether this means that it is accelerating at 0.1g vertically away from the earth, or alternatively perhaps is accelerating 0.14g at 45% from vertical (which results in a total vector magnitude of 1.1g) along with a slight rotation of the device, simply cannot be distinguished.

So what exactly are the accelerometers “good for”, so to speak? The most obvious usage is as an orienting mechanism – finding which direction is up (or down). This involves working on the assumption that the device is not experiencing any acceleration (or if it is then it is small in comparison with gravity, and of limited duration), and that the forces it measure therefore indicative of the direction of gravity. And this is precisely how the iPhone “knows” when to rotate its browser, photos, keyboard etc.

Also, if one were to adopt the alternative assumption that the device had a fixed orientation (eg. attached to a stable moving platform), then the effect of gravity could be eliminated, and speed and distance traveled should then be derivable. However, it seems rather unlikely that any practical scenario would allow for sufficient stability to make this accurate enough to be of any use.

A third possibility here, although admittedly with somewhat limited applicability, is that it would be possible to reliably detect an absence of force ie. the state of free-fall. This might help someone make a great app for astronauts, but for us earth-bound individuals who don’t like the idea of dropping (or throwing upwards and then catching) our iPhones it is probably only going to be of use either in a gaming scenario or as a novelty.

Unable to resist the novelty myself,and in the interest of science of course, as proof of concept I did create an app which waits for and captures free-fall events. When this happens, the screen goes red, the vibrator is triggered, and a wav file is played – in this case with a message pleading for the user not the drop my iPhone. Quite fun and amusing, if I might say so myself, but sadly a far cry from being able to measure distances moved with any accuracy.

Advertisement