KOP Gyro steadily decreasing

[brennonbrimhall]

We were fooling around with a gyro, but as we print gyro.getAngle, we've noticed the angle steadily increasing as the robot sits. We've had this problem before in previous years, but we can't remember what we did to mitigate the issue. Any suggestions?

[Team3266Spencer]

Reset the gyro as often as possible in the code. The gyro we use for targeting we reset right before we move the robot so there's less time for error to develop.

[MagiChau]

The gyro naturally accumulates error due to drift. The getAngle() it sends back is an accumulation in rate of change of angle. Error accumulates every time the gyro finds this. I agree with resetting the gyro as much as possible. There is a good white paper on gyros as well that you should read if you haven't in the following link.

http://team358.org/files/programming...rFRCRobots.pdf

[Joe Ross]

what rate does it drift? a few degrees in 15 seconds is a reasonable rate for an FRC gyro.

[Greg McKaskle]

As mentioned, gyros are not perfect or magic. They are a sensor circuit and are affected by a number of real-world issues such as electrical noise, temperature, and operating procedures.

Electrical noise: The heart of the sensor is an element that affects the voltage of the circuit proportional to rotational movement. Electrical noise and power dips on the input circuit look like rotation.

Temperature: The sensor's gain changes with temperature. When you boot the robot, it calibrates. If the temperature changes substantially, the sensor's assumptions are off and it will increase drift. The data sheet should indicate the amount of the temperature effect.

Procedures: It is important that the robot be steady when the program boots because it is measuring for a few seconds to identify what voltage correlates to a rotation of 0. If the robot is moving at this point, the assumptions are wrong and the gyro will spin at the opposite of that "zero" rate.

Another procedural issue is that the gyro has an upper limit on rotation. If you exceed this limit, it under-reports the rotation and throws off your idea of where the robot is pointing.

With all of these issues handled correction, it will drift, but for short periods of time, like during auto, or when aiming, you can use it for relative turning measurements.

Greg McKaskle

[brennonbrimhall]

Thanks for the responses, guys.

Originally Posted by Team3266Spencer

Reset the gyro as often as possible in the code.

Originally Posted by MagiChau

I agree with resetting the gyro as much as possible.

As in every cycle of test/auto/teleopPeriodic()? I thought that resetting set your current point as the new reference frame.

By the way, MagiChau, thanks for the whitepaper. It is exceptionally informative.

Originally Posted by Greg McKaskle

As mentioned, gyros are not perfect or magic. They are a sensor circuit and are affected by a number of real-world issues such as electrical noise, temperature, and operating procedures.

I understand. My concern was that the drift was exceptionally steady, which I assumed meant a problem outside of the sensor.

[Ether]

Originally Posted by brennonbrimhall

I thought that resetting set your current point as the new reference frame.

Yes. So you set the current point as your new reference... when the current point is your desired zero.

[brennonbrimhall]

Originally Posted by Ether

Yes. So you set the current point as your new reference... when the current point is your desired zero.

Hence my confusion. To reset every iteration of testPeriodic(), autoPeriodic(), or teleopPeriodic() would reset my current frame of reference every 20ms. When would you suggest resetting the gyro, so that the drift is minimized, but the reference is functionally unchanged?

[Ether]

Originally Posted by brennonbrimhall

Hence my confusion. To reset every iteration of testPeriodic(), autoPeriodic(), or teleopPeriodic() would reset my current frame of reference every 20ms.

Spencer said to reset it "as often as possible", not every 20ms.

When would you suggest resetting the gyro, so that the drift is minimized, but the reference is functionally unchanged?

It depends on the application. For example, if you're using it to measure the heading of the robot, you could have a reset button on the joystick that the driver could push whenever the robot is pointing straight downfield.

[brennonbrimhall]

Originally Posted by Ether

For example, if you're using it to measure the heading of the robot, you could have a reset button on the joystick that the driver could push whenever the robot is pointing straight downfield.

Thanks for the suggestions. Ether, for the purposes of autonomous driving, would you just ignore the sensor drift because of the short time span?

[Ether]

Originally Posted by brennonbrimhall

for the purposes of autonomous driving, would you just ignore the sensor drift because of the short time span?

Most likely. If you have access to more than one gyro, you could test them and pick the one with the least drift.

[Ether]

Originally Posted by brennonbrimhall

By the way, MagiChau, thanks for the whitepaper. It is exceptionally informative.

Be aware that the paper was written years before the introduction of the cRIO and its FPGA. The FPGA handles all the integration of the yaw rate signal from the gyro. You don't have to write all that code shown in the paper.