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

[EricVanWyk]

One thing to look out for is that Gyros are temperature sensitive, and they mildly self heat. The net effect is that their zero response will drift a bit as they temperature stabilize. The cRIO measures the zero response as part of initializing the gyro.

You might find that you get a better response when the Gyro has been running before the code starts - such as when you are doing development and resetting the cRIO often. In competition you might be starting with a cold gyro, and this might result in a worse drift.


If you are getting a 1 degree / minute drift from a cold boot, stop trying to fix it. That is a great response for FRC, and you're likely to be wasting your time trying for better.

[Chris Hibner]

Originally Posted by sheleski

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

Steven

See attached image.

The equation for a high pass filter is:

Output = Input - Input_previous_sample + FilterConstant * Output_previous_sample


FilterConstant = exp(-SamplePeriod / TimeConstant)

In the attached vi, I have FilterConstant being calculated every sample, which is very inefficient if you are running the filter in a loop with a constant sample period (like TimedTasks.vi). If you are running it in a constant-time loop, replace the entire part inside the frame "Filter Constant calculation" with a simple constant.

Example filter constant calculation: if you're running in the 10 ms loop (SamplePeriod = 0.01 since 10 ms is 0.01 seconds) and you want your time constant to be 30 seconds, then the filter constant is:

FilterConstant = exp(-0.01 / 30) = 0.9996667222

Edit: I forgot to initialize one of the feedback nodes to zero. It should be zero by default, but I like to be explicit.

[Chris Hibner]

I've had a little more time to think about this. In general, I'd advise against using a high pass filter on the heading unless you put in a lot of precautionary software. There are ways to do it without the negative effects, but if you don't have a lot of understanding of all of the effects of the HPF, I'd probably do without it.

If you're really concerned about the drift, add a trim knob to your control panel. Hook an encoder up to the Cypress board and attach it to a knob. Add a lot of friction to the knob so it doesn't move if accidentally bumped. Make your final heading calculation:

Heading = Heading + TrimKnob.

If you see your robot going at an angle slightly different than what you want, slowly turn the trim knob until the angle error disappears.

[sheleski]

I want to thank everyone for the feedback on this issue. I feel I have a better understanding. I need to go back in the lab and measure the exact drift and then verify with the drive team if this to be corrected or not.

Steven