Could someone explain how these units work? I am quite confused.
So a usual unit circle is 0 to 2pi. Does this circle range from -2 to 2 in a single rotation? So typically I would assume it goes from 1.999pi to 0. Does that mean this goes to 1.999 to -2? I am just really confused by these units.
Ill just tag @JamesT as hopefully Studica has a good resource on this
v2024.0.1-beta-3 supposedly has getRotation2d() and getRotation3d() functions, so you shouldn’t have to deal with quaternions directly if you don’t want to.
Those docs make no sense though. 3D rotations use unit quaternions, so the (w, x, y, z) 4-vector’s components must have values between -1 and 1, and the 4-vector’s magnitude must be 1. I also have no idea what they’re talking about with unit circles having 4pi radians, because they don’t.
That comment block has been there for more than eight years.
I looked around the code and didn’t see any reference to it being -2 to 2 or 4PI radians. I can update the comment in the next release. However, I am unsure if the data is correct then. I will start testing to verify it is between the proper unit circle 0 - 2PI. If others who are more experienced with Quaternions could help to test and verify as well, that would be appreciated.
So the reason this came to my attention is that we are using YAGSL and PathPlanner. Teleop seems to work fine, but whatever rotation is requested in pathplanner is doubled which would seem to agree that it’s -2 to 2 instead of -1 to 1
I just found this.
/* AHRSPosUpdate: Quaternions are signed int (16-bit resolution); divide by 16384 to yield +/- 2 radians */
So yeah, I will have to dig deep and determine where the range is being set. I believe it will most likely require a firmware update.
If needed we’d be willing to beta test any firmware update
I think I have it fixed. Is it possible for you to test before I push a live update?
Firmware Download: https://dev.studica.com/maven/release/firmware/navx/mxp/navx2-mxp_4.0.449.hex
And the vendordep needs to be upgraded to v2024.0.1-beta-4 (not published so needs manual update on json file)
I’m guessing that means it also requires using the WPIlib 2024 Beta and Roborio 2024 Beta Image?
That would be prefered yes. However, if you want I can update the 2023 vendordep.
That would be the quickest for us as right now we aren’t set-up on the beta
The 2023 vendordep has been updated to 2023.0.4 with the changes. I also exposed getRotation3D() in this release.
GetRotation3D seems to change the positive and negative direction of the NavX (maybe intentional but was unexpected)
More updates to come
Hopefully this shows the weirdness that is happening. https://youtube.com/shorts/4ogKotRMiKQ?si=Dqmn0ZhxEBTOAk9F
The heading is in radians between pi and negative pi
Rotation2d and Rotation3d use North-West-Up axes convention, which means a positive yaw is counterclockwise (I think that’s what your video shows?). If Rotation2d had a positive yaw as clockwise before, that was a bug in NavX’s vendordep.
I also was looking at the weirdness of jumping between 0.9 to 2 radians with extremely tiny robot rotations. The gyro widget uses a different value that doesn’t depend on the 3D rotation
I can also confirm reverting back to the non “beta” 2023 lib and firmware and multiplying the Quaternions by 0.5 fixes the issue
Hi @JamesT I don’t mean to bug you, but is there anything else you’d like us to try or do in order for you to track down this issue?
Yea, no problem. I have been trying to test internally, but I do not currently have a robot to test on.
It may sound weird, but can you test with the 2023.0.4 vendor lib and the old firmware on the navx? Then, test 2023.0.3 with new navx firmware. I am curious to see if one creates a solution and the other breaks it again when used together.
Sure can. We will try that Monday
