Why does the Gyro turn degrees continue to climb when robot at rest?


I’ve read several articles on using the gyro to try to make accurate 90 degree turns and understand the latency and turn scrub issues, but why does the sensor’s return value in degree continue to climb when at rest simply viewing the status either on the device or in the sensor view within the robotc ide?

The gyro sensor does not directly measure the angle of the robot. Instead, it measures the speed that the robot is turning at, and adds or subtracts fun the current position based on that speed.

To measure the speed, the sensor must first calibrate itself when sitting still. If the sensor is moved during this calibration, then the calibration will be off and the robot will think it is rotating, even though it is sitting still.

I don’t know exactly when the calibration process happens with the vex software, and don’t have a robot with me now to test. I suspect that this is either when first powering on the robot or when the program starts (or when the device info screen is shown).

Try to ensure that the robot is very still all the way from power on to the device info screen. That may help. Or if you want to see the effect of a miscalibrated sensor, try doing this while spinning in an office chair, then stop doing once on the device info screen.

Even when will calibrated, you won’t get a drift-free reading. I would expect a couple degrees per minute to be within normal range.

Yes but the BOT is sitting on a table and while debugging the sensor view shows the data value from the gyro sensor constantly climbing. I’ve tried


and although it resets to zero it starts climbing again.

Updated all firmware.

Is this sensor broke?

How fast does your sensor drift? Given that the sensor internally measures the rate of rotation (with finite precision) and integrates (accumulates) positive and negative speeds multiplied by the time, the actual error in absolute angle value adds up. Calibration helps to counter any consistent bias of the internal measurements, but the quantization and noise still cause the error to add up.

If your particular device drifts only by a few degrees per minute, it shouldn’t have a material impact on a programming skills match. If it drifts more and consistently, you could try to compensate the drift in software using a timer (been there, done that, but that was for MoonBots where the robot performance was multiple minutes).

Also, there is an undocumented function in RobotC to trigger the calibration and wait for its result, but I’d have to ask my students about that - they have used it, though I am not sure if it really helps.

This is reversed. You wait after calling reset. I remember kids mentioning that as time passes it drifts again. So even after reset expect it to drift if you wait long time. But after each calibration, it was best to wait at least a short time. It does not help a whole lot. If you have tried the reset with wait, and still climbs quickly, then it would be an issue with the sensor.


Edit: off topic…
@Klharless@gmail.com, it might be a good idea to change your username to not use your email address. Unless it is fake, you know that there are trolls that collect info and spam. Just a suggestion, no offense intended.