[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