Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
anpark1234 opened this issue Sep 19, 2024 · 6 comments

Comments

@anpark1234
Copy link

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
Copy link

alan412 commented Sep 19, 2024

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

rbrott added a commit to acmerobotics/road-runner-quickstart that referenced this issue Sep 19, 2024
@anpark1234
Copy link
Author

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
Copy link
Member

NoahAndrews commented Sep 19, 2024

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.

@alan412
Copy link

alan412 commented Sep 20, 2024

Fixed in 10.1

@NoahAndrews
Copy link
Member

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

@anpark1234
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants