Introduction
Chapter OneBy now, everyone has heard of how Android supports various sensors on the phone: the accelerometer, the compass; on newer phones, the gyroscope. But what you would never guess from the API is that using these can be pretty tricky. Here, we go beyond the basics mentioned in the API docs to see how to actually make use of the accelerometer for velocity and position measurements.
Probably the most basic info not in the API docs is: you really don't want to rely on the accelerometer alone for absolute measurements of either position or velocity. The obvious integration fails too badly. It really is quite necessary to supplement the data with one of the other sensors. Ideally, one would use the gyroscope, since the techniques of making an inertial navigation system with this combination are pretty well known. Even when dealing with such a noisy source as the MEMS devices in both iPhone and Android
Nor are the filtering procedures mentioned in the API docs adequate. They mention using a low pass filter to get the offset for gravity or for removing noise, and a high pass filter for removing constant gravity offset. But if you filter heavily enough to do any of these things, you introduce a rather annoying level of delay. A better technique is usually necessary. Even combining the two into a band pass filter designed specifically for the application is better than blindly following the API advice.
Yet there is something even more basic barely mentioned: the kind of measurement the API returns. The Android official API specs only say "SI units". What they don't explain is that the 'acceleration' returned is not relative to the reference frame one might expect, it always includes the force of gravity.
This is sometimes called "proper acceleration". This term is more accurate than just 'acceleration', and once you have the explanation below, it is easy to remember; as long as you remember that 'proper' here is in reference to General Relativity, not Special.
"Hey, wait a minute: the name is 'accelerometer' it should return acceleration. What is this 'force of gravity' doing getting mixed up with it?"
There is no shortage of answers to this question on the Internet, most of which appeal to the "Equivalence Principle" of General Relativity. But that is going too far: it is easier to understand why accelerometers do this without appealing to General Relativity at all by remembering the construction of early accelerometers: a test mass on one or more springs. The test mass is always feeling the downward force of gravity, so the spring is always stretched. The reading returned is based on Hooke's Law (F = -kx, where 'k' is Hooke's constant measuring stiffness of the spring, 'x' is displacement), so it always is the total force on the test mass, including both gravity and acceleration of the device.
Besides: strictly speaking, these explanations are overkill anyway: Einstein's equivalence principle does not say just that mechanics cannot distinguish between "fictitious forces" and gravity: it says that NO physical experiment of ANY kind can tell the difference. For the former conclusion, all one needs is d'Alembert's principle. This was well known before Einstein even formulated his Equivalence Principle.
Now true, no mobile phone uses quite this arrangement (relying solely on Hooke's Law) for measuring either the acceleration or the force due to gravity. But the output of the accelerometer was chosen by the designers based on other applications too, where users really do expect the tradition to be preserved: the output includes the force of gravity, in a form that could be called 'acceleration' only in an imaginary reference frame that is falling to the center of the Earth, but at the moment of measurement coincides with the phone.
Now that's all very nice, but what do the drivers do to the signal when they take a measurement and digitize it before returning it in the API?
Now of course, one could dig up the source code of the drivers on all the phones and read the source code to answer this question. But since it is not documented in the API, you are not guaranteed that future versions of the code will do the same thing. So best not to rely on that.
What we do know is that typical sampling frequencies are only about 50Hz, while vibrations affecting the phone could be at much higher frequencies. So without smoothing, this will introduce pretty severe aliasing. This is why they really should have at least told us, in the API documentation, what anti-aliasing filtering the hardware already does.
Few accelerometers rely on a naive application of Hooke's Law as described in the introduction, though that example is a good starting point for understanding the general characteristicse of all accelerometers. Most rely on fancier techniques. In particular, solid state techniques.
There are two basic classes of these 1) SAW (surface acoustic wave) and 2) MEMS (microelectromechanical). Most Android devices have used MEMS, so I will not discuss SAW anymore than this mention for completeness's sake.
MEMS devices in turn are divided into two classes: those that: 1) measure displacement of a test mass or 2) measure change in frequency of a vibrating element. To date, Android phones have used mostly the former, the mass either suspended on springs or by a cantilever.
Practical inertial navigation requires supplementing pure accelerometer data with some kind of other data, at least with reliable orientation data. Without orientation data, after all, we cannot even separate gravity from acceleration of the device. But with it, knowing that g=980m/S and which way is down, we can do all right. Even better though, when practical, is to include GPS data too. But this is more demanding especially on the battery.
This is a generic term for integrating accelerometer, orientation and gyroscopic data to provide corrected data for each; Sensor Fusion the proprietary name for Invensense's version of this is "MotionFusion™" now available in many Android phones running 2.3 or later. But this version requires their own hardware to support it, e.g. the DMP™ or Digital Motion Processor™.
In fact, achieving some kind of sensor fusion is the whole point of supplementing accelerometer data. The sensors 'fused' are typically accelerometer and gyroscope, though they may include GPS, too. But let's not forget: on a mobile phone, the more sensors you turn on the faster you drain the battery, especially if one of them involved a radio, as do location service using Wifi or GPS. So if you can get adequate performance using just linear accelerometers and a gyroscope, that is the way you want to go.
Both the API does and a lot of Stack Overflow articles often omit to mention: since the accelerometer (and all the sensors) return digital data, we need digital filtering, not analog. The difference is important, since both the drawbacks and the strength of analog vs. digital filtering are rather different. Ringing, for example, is rarely a problem with digital filters, since there are no elements corresponding to inductors. But digitization noise (more often called quantization noise) is unique to digital filters.
In the old days, common analog filter designs (Butterworth, Chebyshev, Bessel, Elliptic) were often just copied over to their digital counterparts. But as you get closer and closer to the Nyquist frequency, the characteristics of the digital filter diverge more and more from those of the analog. In particular, the cutoffs were never as sharp. So this procedure is not common now.
Instead, the better modern procedure is to use one of the programs referenced on a site like http://www.dspguru.com/dsp/links/digital-filter-design-software to do the design given a few key parameters such as transition band width, stop band attenuation and maximum ripple
The Kalman Filter Chapter 6
In practice even all the filtering described above is not good enough. There is just too much noise in both the accelerometer and the gyroscope. So inertial nagivation systems more often rely on a more sophisticated digital signal process technique, the Kalman Filter. This is an adaptive linear filter that tries to predict the value based on assuming a n error metric like least-mean-square, but then corrects it based on the actual data as it comes in.
Now this is a big improvement over non-adaptive filtering, but we can do even better: the non-linear "Extended Kalman Filter" has become the standard in inertial navigation applications.