Gyro Repeatability, Expected Drift ?

[eugenebrooks]

Kevin,

You are indeed missing something. By carefully averaging
the no rotation signal, you can obtain accuracy (on average)
that is better than the ADC quantization. This improved
accuracy shows up in the resulting time integral of the gyro.

I would happily share our gyro code with you if you would
like to explore it, use it, or make some version of it generally
available. I have learned a lot about PIC interrupts studying
your code, perhaps you have one small thing to learn by
studying mine. The code, however, also uses methods to
avoid race conditions that I remember, quite well, you don't
like.

Eugene

[Kevin Watson]

Originally Posted by eugenebrooks

Kevin,

You are indeed missing something. By carefully averaging
the no rotation signal, you can obtain accuracy (on average)
that is better than the ADC quantization. This improved
accuracy shows up in the resulting time integral of the gyro.

I would happily share our gyro code with you if you would
like to explore it, use it, or make some version of it generally
available. I have learned a lot about PIC interrupts studying
your code, perhaps you have one small thing to learn by
studying mine. The code, however, also uses methods to
avoid race conditions that I remember, quite well, you don't
like.

Eugene

I certainly understand how some noise components can help improve resolution, but I just don't see how integrating gyro noise when the 'bot is known to be still can help. Yes, I realize a deadband would cause problems in applications where precise low angular rate measurements need to be taken, but that doesn't apply to many FRC 'bots.

Can you point me toward a paper or anything else that can help me understand your point? And yes, please send me any code you have that I can work with. I think we have a rate table at work and it might be fun to see if I can get some freebie time on it to take some data.

-Kevin

[eugenebrooks]

There is an old white paper posted on CD
http://www.chiefdelphi.com/media/papers/1449
as noted in the white paper, this game is relatively
standard in the signal processing business.

Assuming that you have a gyro that has inherent noise
that is larger than the quantization error, for a stationary
robot there will be a sequence of random (integer) values
returned by the ADC. What you want is the average and
this is not an integer. Obtaining this average, in suitable
precision, is the goal of sampling the gyro for a suitable
length of time while the robot is known to be still.

We represent the average in binary fixed point, a 32 bit
value in 256ths, so to speak. We then use this average
as the zero value for our time integration. It is very
straight forward to do, using the trapezoidal rule we
just shift the old value and the new value up by the right
number of bits before we subtract the average.

The resulting accuracy is good enough that the temperature
dependent drift of the gyro can become significant.
We address this by watching the drift of the integral and
re-measuring the required average when the drift becomes
larger than we want. Another approach is to read the temperature
output signal provided and compensate.

I'll package our code for this year's robot in a zip file and
put it in a place accessible to you and send you an email
when I have done that.

Originally Posted by Kevin Watson

I certainly understand how some noise components can help improve resolution, but I just don't see how integrating gyro noise when the 'bot is known to be still can help. Yes, I realize a deadband would cause problems in applications where precise low angular rate measurements need to be taken, but that doesn't apply to many FRC 'bots.

Can you point me toward a paper or anything else that can help me understand your point? And yes, please send me any code you have that I can work with. I think we have a rate table at work and it might be fun to see if I can get some freebie time on it to take some data.

-Kevin

[scottanderson]

We'd be interested in seeing this code as well. We're using the gyro code from WPILib, but it's apparently unsuitable for anything other than just driving straight. We finally just gave up on using the gyro for turns and now count gearteeth.

[de_]

Ouch. I was hoping there would be a simple answer like yes this is normal or no its defective or something !

Thanks for the suggestions on how to handle it. yes I would love to see the code too.

Being a brand new user of gyros (haven't even had the time to figure out what technology they are based on, obviously not a spinning top), I'm obviously trying to run up the learning curve as fast as possible.

I'm hoping the lack of repeatability may not be a show stopper for the 15 seconds. But I am concerned the rate of the First gyro may be too slow. Its probably too late for us to get a 300 deg/sec one.

Are many teams able to do relative extreme navigating using the gyro (and perhaps the gear tooth for straight travel) ? By extreme, I mean, at least one 90 degree turn or better still three 90s (ie one loop around the course) ?

Kevin, is it possible for you to give a 20 word description of this deadband, its magnitude and how it comes in to play for repeatability ?

Thanks

[scottanderson]

Our robot is capable of doing repeatable 90deg turns just using the gear teeth sensors. It's not perfect, and it depends on traction, but we couldn't get the gyro to behave reliably. We were consistently getting 3 lines, and had the IR worked at a greater distance we could have hit 4.

[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]

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

[Kevin Watson]

Originally Posted by de_

Ouch. I was hoping there would be a simple answer like yes this is normal or no its defective or something!

Well, let me just say the KOP isn't very good and that you'd be better off using a ADXRS300 for this application.

Originally Posted by de_

I'm hoping the lack of repeatability may not be a show stopper for the 15 seconds. But I am concerned the rate of the First gyro may be too slow. Its probably too late for us to get a 300 deg/sec one.

You could probably overnight one from SparkFun.

Originally Posted by de_

Are many teams able to do relative extreme navigating using the gyro (and perhaps the gear tooth for straight travel) ? By extreme, I mean, at least one 90 degree turn or better still three 90s (ie one loop around the course) ?

Yes, quite a few. Team 1024 sent me this link to a match at Chicago where they do 1.5 laps in autonomous.

Originally Posted by de_

Kevin, is it possible for you to give a 20 word description of this deadband, its magnitude and how it comes in to play for repeatability?

This is the code we're talking about:

// get the latest measured gyro rate
temp_gyro_rate = (int)Get_ADC_Result(GYRO_CHANNEL) - gyro_bias;
 
// update reported gyro rate and angle only if 
// measured gyro rate lies outside the deadband
if(temp_gyro_rate <-GYRO_DEADBAND || temp_gyro_rate > GYRO_DEADBAND)
{
// process gyro data
}
else
{
gyro_rate =0;
}

If the turning rate is very, very small (i.e., less than a degree per second) the data is thrown away and not used in the rate or angle calculations. This can improve the angle estimation because we're not including (actually, integrating) the measurement noise while the 'bot is not rotating. How do I know the 'bot isn't rotating? Well, I think it's a safe bet that most, if not all, FRC 'bots are incapable of rotating at these rates. This has no effect on repeatability (someone else mentioned that these gyros may have a problem where the sensitivity may be different between rotating CW versus CCW, which may be what you're seeing). Using my code and a pretty good Silicon Sensing Systems' CRS03-02 gyro, my Vex 'bot can drive the edge of a 4' x 4' square for twenty minutes and not deviate more than a few degrees over that period <grin>.

Now, Eugene is suggesting (I believe) that I don't need a deadband if I use a higher resolution bias value in my calculations and he may be right. I'm already oversampling the signal, so I don't know if I can really do much better without using a better ADC.

Eugene is also using trapizoidal integration, which works great at lower sampling rates, but doesn't help much (I suspect) at the high rates I sample the gyro at. I have a version that uses trapazoidal integration, but I haven't taken the time to do much testing (I wiil though).

Sorry, it's a few more than twenty words <grin>.

-Kevin

Edit: Okay I just read Chris' posting and I believe we're on the same page now. I'm already oversampling the gyro output to reduce the effects of gaussian noise sources and to gain resolution through interpolation, which is what Chris discusses in his posting. For the bias calculation, I use a circular buffer to store the last sixty-four Gyro rate updates (each update contains the average of many gyro samples) and when Stop_Gyro_Bias_Calc( ) is called (presumably just as autonomous period starts), I add up those sixty-four samples and use that value for the bias. The difference is that I don't retain all of those ~18-bits for use in my calculations. I only retain what theoretically makes sense. Classic textbook oversampling and decimation theory states that for every extra bit of resolution, a signal must be sampled four times and the results added together (this is the oversampling part) and then divided by two (the decimation part). This is exactly what I do in my code.

Now is it possible that I may be discarding valid data when I do the decimation? My understanding of the theory says no, but there could be some aspect of the theory that I don't fully understand. Either way it'll be fun to try it out to see if I can wring a little more performance out of the FRC gyro.

-Kevin

Another edit: I Googled and found an excellent application note that discusses the theory behind my code. It's for Atmel AVR microcontrollers, but it's also applicable to the PIC in the FRC robot controller.

-Kevin