Integrating accelerometer output

[Jared Russell]

Hey all,

I think I want to try going with a purely inertial guidance system this year (accelerometers and gyros) instead of encoders. I don't need position information - just relative x and y velocities (along with heading).

By integrating the gyro output at about 400Hz, I get a pretty good heading calculation. It drifts by maybe a degree or two after a few minutes of driving, but that's acceptable.

My concern is with the noise handling capabilities of the accelerometer. Between the +/- 1.7G saturation of the device, nonlinearities, and possible high frequency noise, I'm having doubts about whether my integration to obtain linear velocity will be even close to accurate, even if I clean the signal up with a low pass filter.

Has anyone done this in the past? I'd like to hear your thoughts before I waste my time and end up using encoders again anyway

[Matt C]

Team 190 in 2k3 made a functional INS (Inertial Navigation System) system for a crab drive robot. I can't remember all that much about it other than it was a big challenge for the programmers, and we ran into some "drift" issues.
http://www.chiefdelphi.com/media/photos/14923

[gnormhurst]

Can you tell me how you integrate faster than 38 Hz? Do you use a timer interrupt, or do you count fast cycles and look at the gyro every so many of those?

[eugenebrooks]

Originally Posted by gnormhurst

Can you tell me how you integrate faster than 38 Hz? Do you use a timer interrupt, or do you count fast cycles and look at the gyro every so many of those?

You use a timer.
It is important that the time interval between samples is accurate.

Eugene

[Alan Anderson]

Timer interrupts, definitely. You need to keep your timing very stable in order for things to work right.

[lynca]

Originally Posted by Abwehr

Has anyone done this in the past? I'd like to hear your thoughts before I waste my time and end up using encoders again anyway

For a 15 second autonomous period , encoders will be much more reliable then dead reckoning with a accel and gyro. However over longer distances than a 15 second autonomous period, encoders will drift without a secondary sensor to update position. You could invest in a magnetic compass from spark fun and only rely on encoders for linear motion. I've had good results with a compass and encoders.

I suggest a compass from Spark Fun,

[jleibs]

So I don't know about using parts available to you guys (or your processors), but I do this pseudo-professionally these days. I was involved with the inertial nav system for the Caltech 2005 DARPA Grand Challenge, and now Northrop Grumman pays me to do related things with UAVs.

Disclaimer: if anybody remembers footage of a giant van crashing through a concrete barrier at the 2005 Grand Challenge event, that was us, so maybe I'm not the best person to take advice from

As may be gathered from my previous statement, it's not an easy task. I had enough trouble doing it with a highly accurate $20,000+ 400Hz accelerometer/gyro, that I don't want to think about trying to make it happen with your guys hardware. Granted, we were fine for a couple of minutes, and we were going over off-road terrain.

Given your guys nearly planar situation, you might be able to make it work, but expect to spend a lot of time getting it right. Certainly, feel free to message or email me if you want to discuss things in more details. I'm always happy to help in any way I can.

My big question would be as to why you don't want to use encoders?

Encoders are your best friend when you're dealing with velocity. They measure velocity directly. The fact that you are integrating accelerometer leads to inevitable error growth in your velocity (and quadratic error growth in your position), so you need SOMETHING to help zero out those errors.

If you are very much serious about pursuing this (and have a good reason for dropping the encoders), talk to me some more about advice on incorporating your control signals into your estimate. This is a poor substitute for the encoders, but by doing some calibration and taking into account commanded motor controls, I bet you could get things working reasonably well with decent bounds on your error.

[Donut]

I tried it with a vex robot prior to the 2007 season, the code is in this old post of mine:

http://www.chiefdelphi.com/forums/sh...82&postcount=5

Based on my experience the kit accelerometer would be no good for an FRC robot (at least for inertial navigation). It may be possible with a better accelerometer, or a higher resolution ADC than that of the RC, but my stuff with a vex robot was off by a few inches when traveling less than 10 feet, which would put you off by over a foot when traveling a full FRC field.