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

[anpark1234]

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.

[alan412]

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.)

[anpark1234]

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.

[NoahAndrews]

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. When getting the orientation however, the native unit will be radians.

If you are using a BNO055 through the old BNO055 interface/blocks, the default angle unit for both orientation and angular velocity is radians/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/degrees/s.

Technical details (feel free to ignore)

The IMU interface always configures the BNO055's UNIT_SEL register to have the value for degrees, and does not allow reconfiguring that register. The BNO055 interface configures the UNIT_SEL register according to the value of BNO055.Parameters.angleUnit.

The reason that the IMU interface uses a native unit of radians for orientation is that it always retrieves the orientation from the sensor as a quaternion, and the math used to convert from a quaternion to a series of angles happens to use radians.