Quote:
Originally Posted by Greg McKaskle
Integrating the acceleration to get velocity is theoretically correct and simple, but won't yield good results unless you can handle lots of pesky details.
The biggest problem is that the accelerometer is operating in the earth's gravity field. You have a big force that just doesn't go away. You can sit still and calibrate it out, but if you tilt just a tiny bit, gravity's "down" vector starts to show up in your other orthogonal dimensions you really care about. And since you are accumulating, it adds up quick and appears that your robot has been accelerating and is now traveling across the field. My understanding is that good IMUs also contain a good inclinometer ( a specialized gyro) so that they measure the tilt and correct for it.
If this were straightforward, you'd also see tons of phone apps that not only counted steps, but told you how fast you were walking/driving and didn't need GPS and cell triangulation to know your location. Cars wouldn't measure wheel speed either. They would use the same technique.
So the concept is a good one to discuss and experiment with, but a little bit of additional analysis will show the need to cancel gravity for matches in order for this to work well enough.
Greg McKaskle
|
Just wanted to amplify Greg's point. It's complicated, so will take some focused effort and time, and understanding of the physics and related math.
The process is (a) the gravity vector has to be calculated, and to be done accurately, (b) the gyro and accelerometer data must be fused and filtered. Then (c), that vector is subtracted from calibrated accelerometer data to yield linear acceleration, (d)
rotated to be in "world" coordinates (overcoming pitch/roll effects and rotation), then (e) double-integrated to yield distance-traveled vectors in x and y axes.
In case you're interested, the navX MXP does parts (a-d). Here's a link to some
Java code that does the calculations for (b-d) [step a is done in hardware on the navX MXP] so you'll get a feel for the process. In this code (see the setQuaternion() function), the gravity vector is derived from a quaternion (a representation of the orientation of the body which has fused the gyro and accelerometer data). This is then subtracted from the calibrated accelerometer, yielding linear acceleration.
The navX MXP provides this information to the RoboRio, and there are teams
discussing on Chiefdelphi using the navX MXP and attempting to do step (e), what you are describing. The standard caveat is that this requires a double-integration (acceleration->velecity->distance) and small amounts of noise and error will quickly compound, so that actual distance that this will be accurate for is something still to be determined.
The next step after that would seem to be (f) fuse the encoder data w/the estimated distance vector, which if done well could potentially increase the quality of the estimate of the distance vector.