Gyro Rate Bias Issue

[seg9585]

Using the ADW22307 Gyro (dual use gyro/accelerometer board), there tends to be a little rate bias. The result is that, when the gyro is kept still, the reported heading (getAngle()) tends to creep in the same direction over time.

As a point of reference, I've noticed that after 5-6 minutes the gyro reports an error in excess of 90 degrees. This is a bit concerning to me, even for a 2 minute match where we're planning to use MecanumDrive field frame.
Does anyone know why this would be happening, and what can be done about it? The FRC Java Gyro method doesn't allow a bias to be set, and using the reset() command can interfere with driving capability (you'd need to ensure the robot is pointing away from you to get a good reset)

[Joe Ross]

Originally Posted by seg9585

and using the reset() command can interfere with driving capability (you'd need to ensure the robot is pointing away from you to get a good reset)

I know that some teams use field features to line up periodically in order to reset the gyro. For example, you could reset the gyro when you go to the inbounder and press against the wall.

[Mike Bortfeldt]

Eric,

Drift is common when using a gyro and the WPILib does not have an easy way to compensate for it. As Joe mentioned, you can reset it occasionally when you are at a known heading (against a field element for example), or you could create your own compensating algorithm outside the gyro class. One thing that has helped us, is to allow the gyro a little more time to "warm up" (approx. 10 seconds) before instatiating the gyro object. This gives the gyro a few more seconds to reach temperature stability before the WPILib obtains a "zero" point. It will still drift, but perhaps not quite so quickly.

Mike

[Jared Russell]

We like to re-calibrate the gyro bias as close to the start of the match as possible. MEMS devices are highly sensitive to temperature and they self-heat as they draw current, so in the couple minutes between when you turn your robot on and when the match starts, your zero may have drifted a bit. It still isn't perfect, but it will be better than calibrating a cold gyro.

One automated way to do a reset that is commonly used in industry is a "zero velocity update" - if you know (via another source, such as wheel encoders or a button press) that your heading should not be changing, you can re-calibrate the bias on the fly and recover some of the accumulated heading error.

[Greg McKaskle]

The WPILib gyro code actually does compensate for this provided the robot is stationary when the Open is performed, and provided that the gyro temperature remains constant. It measure the baseline DC value during Open. The LV implementation averages over two seconds. This value is then used as the baseline DC voltage. The Reset operation doesn't measure the baseline again, it simply zeroes the accumulator.

Greg McKaskle