Hi!
I was wondering how much the gyro on the romi32u4 board drifts over time. If so, is there any way I could mitigate it? Thanks!
The Romi 32u4 control board has the LSM6DS33 6 axis accel/gyro chip. The gyro is a rate gyro, meaning that it measures rotation rates about three axes rather than orientation angles.
The concept of “gyro drift” is usually associated with orientation angles. To obtain those, code to numerically integrate the rotation rates is required, along with calibration of the rate gyro to eliminate or reduce the rate measurement offsets.
So, meaningful discussion of “gyro drift” needs to take into account the code algorithm, the practical implementation of the code (e.g. accuracy of integration), the quality of gyro calibration, accuracy of the rate measurements and the temperature dependence of the rate measurements. See the sensor data sheet for the latter two.
I’m going to assume you mean that your heading angle changes at rest even after running the onboard calibration through wpilibpi. Because that’s what I get too. Mine is on the order of 0.25 deg/sec so tolerable for short routines but enough to kill any kind of useful odometry. Mine seems to be fairly constant so my next step is to see if I can expose an offset parameter to null out the drift. However, this means I’ll also have to add my own aggregator layer above the gyro such that each gyro reset starts aggregating again from zero and my new getAngle() type method will need to combine my aggregated error with the reported heading from native getAngle() method for romiGyro.
Hey! Yeah, the gyro on the Romi 32U4 does drift over time, especially if it’s sitting still. You can reduce the impact by averaging the readings when it’s stationary at startup to get a baseline offset, or use sensor fusion (like combining with an accelerometer) to correct drift over time.