Gyro stability?

[sheleski]

I have this odd issue I am unable to figure out. Using the example Gyro Code I can get an angle from the Gyro, but over a few minutes of time the angle is increase by one degree roughly per minute. I have tried various gyros and A1 and A2 input and always getting the same result. What would cause the gyro to be increasing angle?

[Ether]

Originally Posted by sheleski

I have this odd issue I am unable to figure out. Using the example Gyro Code I can get an angle from the Gyro, but over a few minutes of time the angle is increase by one degree roughly per minute. I have tried various gyros and A1 and A2 input and always getting the same result. What would cause the gyro to be increasing angle?

Integration.

The gyro integrates angular velocity to get angular position. The gyro is not perfect - it may have a null bias. That null bias, when integrated, causes the angle to change over time.

[Jon236]

Ether is correct. That small drift won't affect things over the short period of time for the match. It is also helpful to use a small deadband, say +/- 5 deg, within which you assume the output to be 0. It only makes a difference if you use the D term in PID control, because you will see a big jump in the PID output at that point!

[sheleski]

So I how would I fix this issue? Someone mentioned a dead band?

[Joe Ross]

Originally Posted by sheleski

So I how would I fix this issue? Someone mentioned a dead band?

Its important to evaluate how big of an issue a one degree per minute drift is in your application. It bet for almost all FIRST robots, that is a perfectly acceptable drift rate.

[Mr_smith]

Long time ago, I fixed a problem like that with a high pass filter directly on the data from the gyro. Try that, it could work.

[Ether]

Originally Posted by Mr_smith

Long time ago, I fixed a problem like that with a high pass filter directly on the data from the gyro. Try that, it could work.

Could you please explain the theory behind that?

[Chris Hibner]

Originally Posted by Ether

Could you please explain the theory behind that?

High pass filters on inertial sensors are very common in crash sensing and rollover sensing. The time constant for the filter needs to be MUCH longer than the typical duration of a typical maneuver or event. For example, a crash usually lasts about 100 ms, so a 3-second time constant on an HPF will allow all of the data to pass through virtually unaltered, but slow drifts of the sensor bias will be removed.

For FIRST, I wouldn't expect a turning event in one direction to last much longer than 5 seconds, so a time constant of 30 seconds should work pretty well.

With all of that being said, I think 1 deg/minute is not a big deal.


Lastly: a deazone is NOT a good approach. A deadzone with normal driving can easily create 10 times the error than what you're seeing now.

[Ether]

Thanks Chris. I should have worded my question more precisely.

The high-pass filter would have to have a fairly low cutoff frequency to allow the rate information to pass through for rates typically seen in FRC robots: as you said, perhaps a 30-second time constant. I was wondering what this would do to control loops using the integrated yaw signal.

[Chris Hibner]

Originally Posted by Ether

Thanks Chris. I should have worded my question more precisely.

The high-pass filter would have to have a fairly low cutoff frequency to allow the rate information to pass through for rates typically seen in FRC robots: as you said, perhaps a 30-second time constant. I was wondering what this would do to control loops using the integrated yaw signal.

That's a good question. With a long enough time constant, it shouldn't have any effect.

The problem with high pass filters is they act like bias-learning. If you turn in one direction long enough, it "learns" a little of that time-averaged yaw rate into the bias of the integration. Then when you stop turning it thinks you're turning a little in the opposite direction even though you're not turning* (see below). If the turning of the robot averages out to zero every 1/5th of a time constant or so, then the effect of the "learning" should be zero and the HPF will not affect the integral or the control loop. If your robot is going to turn a lot more in one direction, the HPF is a bad idea (2008 is a good example of where using an HPF is not good since you're always turning left).

The important part is that the turning averages out to zero in a time period much shorter than the time constant. If you can guarantee this, the HPF will have negligible effect.

I have a lot of data saved from my autonomous simulator. If I find some time over the next day or two I can throw in a high pass filter and post some plots of the before and after.



* - Interesting sidebar for those not familiar with signal processing: The human body is filled with high-pass-filter "bias learning" characteristics. The inner ear is a good one: you spin for a while on a merry-go-round and when you stop spinning, it's hard to stand up because the "HPF" in your inner ear learned the spinning into its bias. When you stop spinning your inner ear thinks you're spinning in the opposite direction so it's difficult to walk.

Another great example is smell: ever notice that after you're near something for a long period of time, you can't smell it anymore, but if you leave the room and come back, you can smell it again. That's due to the HPF effect in your sense of smell.

Your eyes have a similar mechanism - your vision processing uses a spatial HPF (spatial as opposed to a time-based HPF). There are many illusions you can find that use black/white transitions to create interesting effects that make the image appear different than it really is.

[sheleski]

Chris,
Would you be willing to post in Labview example using a HPF and a gyro?

Steven