NavX Quaternion Units

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.

8 Likes

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.

2 Likes

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

1 Like

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.

1 Like

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?

And the vendordep needs to be upgraded to v2024.0.1-beta-4 (not published so needs manual update on json file)

3 Likes

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

1 Like

The 2023 vendordep has been updated to 2023.0.4 with the changes. I also exposed getRotation3D() in this release.

2 Likes

GetRotation3D seems to change the positive and negative direction of the NavX (maybe intentional but was unexpected)

Hopefully this shows the weirdness that is happening. https://youtube.com/shorts/4ogKotRMiKQ?si=Dqmn0ZhxEBTOAk9F

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

1 Like