FIRST-Tech-Challenge/FtcRobotController

imu.getRobotAngularVelocity(AngleUnit.RADIANS) returns degrees instead of radians

Closed this issue · 6 comments

It looks like imu.getRobotAngularVelocity always returns the zRotationRate (and presumably the other axes rates) in degrees regardless of the AngleUnit provided to the method. Consider the following code example:

while (opModeIsActive()) {
    driveRobotBasedOnGamepadInput();

    AngularVelocity avd = imu.getRobotAngularVelocity(AngleUnit.DEGREES);
    AngularVelocity avr = imu.getRobotAngularVelocity(AngleUnit.RADIANS);

    telemetry.addData("z ang vel (d)", "%4.2f", avd.zRotationRate);
    telemetry.addData("z ang vel (r)", "%4.2f", avr.zRotationRate);
    telemetry.update();
}

When I run this on a mecanum strafer robot, and rotate the robot left/right, the values printed for both the degrees and radians match and appear to be in degrees.

There appears to be a workaround, which is to use Math.toRadians(imu.getRobotAngularVelocity(AngleUnit.DEGREES).zRotationRate), but several libraries (including RoadRunner) use radians and would need to be updated with this workaround to operate correctly.

Thank you for reporting this issue! We have investigated and confirm that there is indeed an issue related to your report. We are looking into it now and working on the best path forward to correct it.

The issue scope currently involves all unit conversions for getting AngularVelocity from native IMU units. If you ask for a unit different than the native unit of the IMU you are using, it will not be converted. (ie, if your IMU reports natively in RADIANS then it will give you RADIANS if you ask for it in RADIANS or DEGREES. If your IMU reports natively in DEGREES then it will give you DEGREES when you ask for RADIANS or DEGREES.)

Thanks for confirming. Is there a way to programmatically determine the IMU's native units? Or, can we assume that all competition IMUs are natively degrees?

I'm asking because rbrott implemented the workaround I suggested above in road-runner, but after your description, it sounds like the workaround of just using degrees might only work for specific IMUs. The control hub I am testing with has the BHI260AP IMU, which, according to the specs, reports gyroscope measurements in degrees/s. However, it looks like the BNO55 reports either radians or degrees depending on the UNIT_SEL register.

Note: A previous version of this comment incorrectly stated that IMU orientation angles would also be affected

Both the BHI260AP and the BNO055 used through the IMU interface/blocks (also known as the Universal IMU Interface) behave the same way in this regard. When getting the angular velocity, the native unit is degrees/s.

If you are using a BNO055 through the old BNO055 interface/blocks, the default angle unit for angular velocity is radians/s. However, its more complex BNO055.Parameters class/blocks allows specifying the angleUnit, which can be used to change the native unit to degrees/s.

Fixed in 10.1

The original version of my previous comment incorrectly stated that IMU orientation angles would be affected, which is not true.

Thanks for fixing this. I just confirmed that my original code example listed above is now working as expected with v10.1. I also confirmed that the errant behavior caused by this issue in road-runner is now working as expected both in their unpatched version (0.1.13) and in their patched version (0.1.14).