As many of you know, the Wii remote has an accelerometer built in as one of several sensors used to enhance game play. Apple's iPhone uses an accelerometer to sense how the device is tilted; that's how it's able to change the orientation of its screen based on how you are holding it. Robots can use them to keep their balance, and Nike's shoes can count your steps with them. And that's just the beginning - there are tons of applications for this simple little device!
I recently had the 'pleasure' (if you can call it that) of working on a course assignment using a Kionix accelerometer encased in a little joystick-like cover. I'm not sure what model it was; it may have even been a demo or evaluation version our teacher was able to obtain. Anyway, this is where the love-hate thing comes in. The ideas behind what you could do with these devices are really cool, but the reality kind of hurt. It's really hard to make them work!
Our assignment had us first code up some basic calculations you can do with an accelerometer. Tilt wasn't so bad to figure out. In fact, you can determine pitch and roll, rotation around the x and y axes respectively, and tilt, the angle the z-axis makes with the vertical. What you cannot compute, however, is yaw - that's why many inertial systems also use gyroscopes.
Image from http://en.wikipedia.org/wiki/Flight_dynamicsThe second set of calculations to implement used integration equations to find location based on the rate of change of velocity (i.e., acceleration). We tried out several methods of doing this: Euler, Verlet, and Beeman equations. Through an experiment of our own design (I used the known properties of free fall in what I thought was a clever way), we comparatively evaluated the accuracy of these. Incidentally, I found that the Verlet equation (the velocity version for those keeping track) performed the best of all of them.
At this point I could tell that there were going to be some real limitations when trying to use the accelerometer in any practical application. The tilt calculations actually worked fairly well when measuring the orientation of the device when it wasn't moving. The two limitations of this are not being able to figure out yaw (as mentioned), and the fact that you can't tell the different between acceleration due to gravity, which is what allows you to compute pitch and roll, and actual movement in some direction.
The former is an annoyance only in the sense that in many of the demo applications I played with, yaw was the most natural direction to move the accelerometer to accomplish what I wanted! When I wanted to move a character in a game, for example, I always tried to use the yaw rotation for left and right movement.
The second limitation of distinguishing between movement and gravity can't be that bad if all these phone companies are able to implement their screen orientations functionalities so well. Still, I imagine things gets hairier when you want to use the same accelerometer to measure actual movement in addition to tilt orientation. Again, this is probably why so many systems use gyroscopes too.
Ok, so now onto the fun stuff. The second half of the assignment involved applying these calculations in fun and useful ways (can you sense the joy?). In the first question, we were to implement a simple gesture recognition system. In the second, we would use the accelerometer in some application of our choosing (or of our own creation), and think about how this would affect the users of the application.
I can tell you right now that although position information seems the most natural choice for most applications, the calculations alone are not good enough! Besides the annoyances of inaccuracies, consider this: If I start moving my accelerometer with increasing speed, the acceleration being read is a number strictly above zero. So far so good. Now I stop moving the device. Maybe there is some deceleration for a short while, but eventually I should get a reading of zero. Fine, makes sense. Except for one thing. Because you are relying on acceleration alone, you don't get any information that would tell you your velocity is actually zero now, too. No, a zero acceleration simply means a constant velocity, so unless your reading came at exactly that point in time that your velocity was also being calculated as zero (which is unlikely as it turns out), your velocity will keep on pumping out changes in position. Sigh.
So tilt orientation it is.
For the gesture recognition, I took inspiration from these mouse gestures that can be used in a web browser. My up/down movement came from changes in pitch, and the left/right from changes in roll. My very simple system just looked at the last gesture made after a predefined dead time, and tried to make some sense of it. I was able to use the system with better than 85% accuracy, and my husband was able to succeed at performing 50% of the dictated gestures (which actually isn't bad if you consider that he had only a minute of training first).
I implemented my own application for the last question rather than seek to integrate the accelerometer into something that already existed. I created a little matte chooser program because I used to work at Ross Video, and they have a matte chooser interface for their live video production switchers. I thought it would be interesting to see how the same type of interface would work when controlled with tilt instead of knobs. Basically, you get a colour wheel that you can control by tilting the accelerometer in various ways. This worked reasonably, but I think it could be a lot better with some more fine tuning.
Looking back, the assignment was kind of fun, despite the numerous problems I ran into (not all mentioned here). I don't know how well I did yet because I only just handed in the completed assignment.
There are many potential uses for the accelerometer even in just the software I use and write. But to be honest, I think I'll probably avoid the frustration in the future and just stick with my usual mouse or game pad, and wait for the industry to iron out the bugs for me!
