Gyro Repeatability, Expected Drift ?

[rdaugherty]

Team 435 can do a full lap plus in automode using the KoP gryo for both the turns and maintaining alignment while driving straight. We are using a modified version of Kevin's code. (QuickADC and only reading the gryo once every 26ms.)

Last year we were unsuccessful with using the gryo, the robot's momentum would carry it past the 90 turn and we were never able to get a consistent turn amount.

[Joe Ross]

What sample rate are you running at?

In 2005, we ran many tests with sample rates from 200hz to 12800 hz. While we have since lost the raw data from the tests, the results were that we saw improvements in performance up to 1600hz and beyond that there were no noticeable improvements. We have since always used 1600hz and get results that are repeatable to within the accuracy of our measurement method.

[Chris Hibner]

Dr. Brooks' marklars are wise and true

One of the best thing that you can do to help reduce the drift is use a very large average during disabled mode to get the sensor bias, and don't throw out resolution when you're done with the average.

I think I posted a similar example in a different thread within the last couple months, but here is an example of what you want to do.

- assume you want to use a 32-bit variable for your integral.

- Let's assume we want to use a 64 sample average to get the sensor bias. Use the following code to calculate your bias (do this code ONLY in disabled mode).

        
tempAngRate = Get_Analog_Value(angRate);
angRateBias = (angRateBias - angRateArray[angRateBiasCounter]) + tempAngRate;
angRateArray[angRateBiasCounter] = tempAngRate;
angRateBiasCounter++;
if (angRateBiasCounter > 63)
{
    angRateBiasCounter = 0;
}

- Once disable mode is over, the above angularRateBias value contains the bias of the sensor. Just note that it is a 64 sample SUM, but you can think of it as the average * 64. At this point you DO NOT want to divide by 64, since you would then be throwing out the "decimal portion". Just multiply you A/D sample by 64 to bring it up to the same resolution of the bias value. See the following code:

angRateValue = Get_Analog_Value(angRate);
robotHeading += (s32)angRateValue*(s32)64 - angRateBias

Now you have a nice integral with 6 bits worth of fractional-resolution. If you want your fractional portion to be 7 bits, use 128 samples in the average, etc.

[eugenebrooks]

We do our averaging to get the bias in the pit where we can be sure
that the robot is not disturbed while the data is being taken. The
resulting number is then hard coded.

I will be heading to SanJose this evening, but I can post
snippets of the code I use from there and will be happy to do so.


[quote=Chris Hibner;717147]

One of the best thing that you can do to help reduce the drift is use a very large average during disabled mode to get the sensor bias, and don't throw out resolution when you're done with the average.

[\QUOTE]

[Chris Hibner]

Originally Posted by eugenebrooks

We do our averaging to get the bias in the pit where we can be sure
that the robot is not disturbed while the data is being taken. The
resulting number is then hard coded.

We do ours immediately before every match by using the disabled_mode flag. In other words, we're running a moving average right up until they enable the robots. Since everyone is required to be off the field for the last few seconds before the match start, you're pretty much guaranteed to get have the robot undisturbed and still, and you get the bias as close to what you're going to have in the match.

The code is more or less:

static char runBais = 1;
if (disabled_mode && runBias)
{
    // run moving-average bias code
}
else
{
    // the bias has now been captured and is held
    // don't let the bias run again if the robot is disabled for a short period of time
    runBias = 0;
    // run integral code
}

[eugenebrooks]

Not a bad way to go, but we average for about 15 seconds at 150hz.

We do check the drift of the integrated gyro in the pit and
redo the average whenever it starts drifting too much.

Eugene

Originally Posted by Chris Hibner

We do ours immediately before every match by using the disabled_mode flag. In other words, we're running a moving average right up until they enable the robots. Since everyone is required to be off the field for the last few seconds before the match start, you're pretty much guaranteed to get have the robot undisturbed and still, and you get the bias as close to what you're going to have in the match.

The code is more or less:

static char runBais = 1;
if (disabled_mode && runBias)
{
    // run moving-average bias code
}
else
{
    // the bias has now been captured and is held
    // don't let the bias run again if the robot is disabled for a short period of time
    runBias = 0;
    // run integral code
}

[Kevin Watson]

Originally Posted by eugenebrooks

Not a bad way to go, but we average for about 15 seconds at 150hz.

If you look at the output of the gyro using a scope or spectrum analyzer, you'll notice some significant fourier noise products above your 75Hz Nyquist frequency. This noise is aliased back into your 75Hz bandwidth, and certainly isn't Gaussian in nature. You might want to up your sampling frequency to the ~1600Hz sweet spot.

-Kevin

[eugenebrooks]

Kevin,

Our gyro is set for a 40hz bandwidth, as I recall, and
it is working absolutey great. If I had a problem I
would borrow a scope and sort it out.

The first thing I would do to improve things would be
to add temperature compensation, and then power supply
voltage compensation, but these improvements do not appear
to be required for our use.

Eugene

Originally Posted by Kevin Watson

If you look at the output of the gyro using a scope or spectrum analyzer, you'll notice some significant fourier noise products above your 75Hz Nyquist frequency. This noise is aliased back into your 75Hz bandwidth, and certainly isn't Gaussian in nature. You might want to up your sampling frequency to the ~1600Hz sweet spot.

-Kevin

[Qbranch]

Our gyro works great... and never ceases to amaze me that it functions at all.

I mean... think about it for a minute. It's a little teeny piece of silicon, and who knows what else, and it knows its spinning. Amazing!

Gotta hand it to those Analog Devices guys...

And thanks to Kevin for speeding all of our development schedules along!

...

Hope you guys like the new and improved 1024 hybrid mode this week. Should be quite a show.

That, and... I think we've finally got enough complicated (messy) homebrew circuitry to make the display stop blanking out all the time now...

If any of you are at BMR and would like to discuss Hybrid mode, I'll be happy to discuss ideas/concepts with you. Just ask anyone on 1024 for "Q" and I'm sure they'll direct you.

-q

[eugenebrooks]

Originally Posted by rdaugherty

Team 435 can do a full lap plus in automode using the KoP gryo for both the turns and maintaining alignment while driving straight. We are using a modified version of Kevin's code. (QuickADC and only reading the gryo once every 26ms.)

Last year we were unsuccessful with using the gryo, the robot's momentum would carry it past the 90 turn and we were never able to get a consistent turn amount.

If you carefully tune the gyro, with no deadband, and use it as a
compass; you can feed the error in the heading back into the
motor power. It keeps the robot on track when it gets bumped,
and it automatically corrects for overshoot in turns.

Eugene