There’s an article over on the WiiLi Wiki that goes into great detail describing how to translate 3D accelerometer measurements into an estimation of the position, rotation, and velocity of a device like the Wiimote. By making a few assumptions—people’s arms have a limited range of motion, most Wii play doesn’t take place in moving vehicles, etc.—it’s quite surprising what you can get away with with just the accelerometer data.
The amusingly named (but rarely used) term for the rate of change of acceleration is jerk. The jerk term for the remote shows up in the time derivative of the force recorded by the sensor, along with the rotation term that contains the angular velocity of the remote. We can extract both rotation and linear acceleration if we assume a few things:
- We know the “up” direction before the motion starts.
- Throughout the motion, the jerk on the remote perpendicular to the current direction of gravity is small.
Then we can assume the time derivative of the force component which is perpendicular to our current estimate of the up direction is caused by the user rotating the controller only. This allows us to update our estimate of the up direction for the next time step. In each time step, we can also get the linear acceleration of the remote by subtracting our estimate of from the current force sensor report. In effect we are integrating up a coupled set of ordinary differential equations. (Note, need to review the math here. Beware.)
The main problem with this technique is error accumulation in our estimate of “up.” Since it is unlikely the user can keep the controller in constant linear motion without injuring themselves, the TV, or their opponent, we can look for times when the total reported force is close to g = 1.0 to recenter . You have to be careful when doing this because it is possible and probably common for the Wiimote to report an acceleration close to g = 1.0 while it is accelerating. When this happens your acceleration vector does not actually point “up” and you will recenter to an incorrect R. This can happen anytime you are accelerating both downward and in the horizontal plane.
I keep thinking that there should be some class of flying vehicle that, when operated under fairly restrained conditions, might be able to get by with just accelerometer measurements to obtain reasonably accurate state information. You could integrate the acceleration data through very limited motions that are within some margin of error, recalibrate, and repeat. This is probably a pipe dream, but I really want a solution for a $50 6DOF IMU. :/
Accelerometer motion analysis – Link
ADVERTISEMENT
