Open elodotwe opened 6 years ago
Thanks for finding this. Note that you can use the AHRS.getRawGyroZ() method to return a value w/units of degrees second for now.
However this should be fixed. The way to do so is to multiple difference by AHRS.getActualUpdateRate(), yielding the result in degrees/second; let me know if you'd like to contribute the fix for that. Otherwise we'll tackle this after the FRC build season is over.
It's been a couple years since this was opened, is there any plan to fix this in a future release?
just adding another vote to fix this. i'm sure @kauailabs is very busy; maybe just delete the method with the bug?
Contrary to the javadoc, it seems AHRS.getRate() does not return degrees per second. Experimentally, when the robot was spinning at breakneck speeds (>1 rotation per second) with a well-behaved, calibrated NavX (yaw looked correct), the getRate function was returning between 7 and 8, when I expected greater than 360.
Digging into the code, it looks like AHRS.getRate() calls ContinuousAngleTracker.getRate(), which doesn't account for the sample rate of the incoming data: https://github.com/kauailabs/navxmxp/blob/d8fa37624f03379ed0e2a8f6f458e3cecbb59247/roborio/java/navx_frc/src/com/kauailabs/navx/frc/ContinuousAngleTracker.java#L120-L133
It seems that somewhere you'd need to take into account the timestamps of the data coming in, or use the set update rate to determine the rotation rate in terms of degrees per second.
I think my sensor was set to 60Hz by default (I didn't change this), so my 7-8 observation would indicate
7*60 = 420DPS
to8*60 = 480 DPS
...plausible, I think.I'm tinkering with fixing this and might submit a pull request if I get the gumption to do so tomorrow.