RSS
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
I've done this stuff for over a decade, so here goes.
This is only a 3DOF IMU, a 6DOF IMU would at this level contain MEMS rate gyros. In this case you are only getting relatively crude 3 axis linear acceleration. If the Wii is stationary you can get the tilt but not the compass bearing.
Also keep in mind with regard to integration that acceleration is a second derivative, so after you integrate twice the cumulative error increases proportional to time squared. Since acceleration is a relative measurement the error increases indefinitely.
This is why the Wii has a sensor bar to complement the accelerometer.
For further understanding of these issues Google Kalman Filter.
Rather than considering the WiiMote as a precision IMU consider it an inner ear when you have your eyes closed.
Reply to this comment
Check this:
"Why the (gyro) rate limitations?
The angular rate sensors that we're using are limited to +/- 90 degrees per second. We've amplified them so that we can sense +/- 30 degrees per second very accurately, which should be fine for the pitch and roll axes during a stable hover. Forward flight should also not experience dynamics much faster than that. The yaw gyro may, so it should have its own scale factor."
Via: http://autopilot.sourceforge.net/faq.html#how_do_accelerometers_work
Try to buy a low resolution gyro. (+-500 degrees for seconds is to much).
Reply to this comment
Interesting. You seem to be suggesting that gyro's are not really required if some assumptions are made about the motion to be measured. A time eriod with no rotational motion or translational acceleration to find g. The jerk assumption isn't so clear. Can you show us your equations?
Reply to this comment
Shoot. I just realized I didn't link to the article. I've included it above, and there's a wealth of info there.
bruceK: right, there are a lot of assumptions that need to be made. you need to know which way is up before motion occurs, the jerk which is perpendicular to gravity needs to be small, and you need to be able to assume that the device can't be in constant linear motion.
From the article: "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."
As monopole suggested, the cumulative error increases exponentially over time. This works with someone holding wiimote, though, because you can recalculate a correct "up" value regularly when g approximates 1 for a brief moment. Any motion that could cause a false reading (ie: moving down and to the side) could only be momentary, otherwise a person's hand would be in the floor.
In terms of flying vehicles, the problem is much more difficult because it's almost impossible to make all of these assumptions.
What I was thinking is that you might be able to get by with certain types of vehicles, such as an auto-balancing, counter rotating helicopter. The heli always centers itself to a roughly balanced position, so an accelerometer might be enough to take care of sub-second motion/rotation correction. Then you can use a GPS to receive position updates every second, which allows you to recalibrate and control for drift.
Reply to this comment