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

Verify Bno055 axis map functionality in NDOF mode #396

Open
jonnew opened this issue Jan 7, 2025 · 7 comments
Open

Verify Bno055 axis map functionality in NDOF mode #396

jonnew opened this issue Jan 7, 2025 · 7 comments
Assignees
Milestone

Comments

@jonnew
Copy link
Member

jonnew commented Jan 7, 2025

There is some ambiguity as to what, exactly, the AXIS_MAP and AXIS_SIGN registers do in the context of NDOF mode for the BNO055. The datasheet claims NDOF is absolute relative to the Earth's B field and Gravity vector. So what does remapping axes do in this situation? Is there any way to make this measurement relative to a tether orientation? We need to make some measurements in different axis maps to see how data changes.

At the end of the day, what we are trying to figure out is where we need to put a selector for determining the "tether axis" for commutation. If we are "stuck" with everything being relative the B field G-vector, in some sense, this is good because its very consistent across headstages (assuming that calibration is good). However, it provides no information about how untwisting should be done.

@jonnew jonnew added this to the 0.4.3 milestone Jan 7, 2025
@jonnew
Copy link
Member Author

jonnew commented Jan 7, 2025

Results:

  • In NDOF mode, the coordinates will zero out when the remapped +X axis is pointing north and the remapped +Z axis is pointing towards the sky.

  • The axis map application is quite confusing which is what has lead to some strange behaviors. Looking at section 3.4 of the datasheet we see:

    image

    Taking the Z axis description as an example, what is meant by "Remapped Z axis value" is "What would you like to re-label the default Z axis?". So, if 0b00 was put in this position, what was the Z axis in the default axes is now called the X axis.

  • After understanding this, I realized that the descriptions here are inverted. Once I had the correct idea, and applied it, I can recover the default axis readings by rotating the headstage such that the remapped axis aligns with the default:

image

  • The action that needs to be taken is that the description of Bno055AxisMap needs to be fixed and the selected Axis map needs to be reviewed for each headstage to ensure it matches that of Headstage-64, which was assumed to be default (@aacuevas is this not true?)

@aacuevas
Copy link
Collaborator

aacuevas commented Jan 7, 2025

So, correct me if I am wrong, but I understand then, in NDOF the quaternion Z points towards the sky and X towards North, and the remap basically means "what is my default rotation state, with 0 rotation in any axis", is this right or am I understanding this wrong?

If so, since in the commutator we are still extracting the rotation around the quaternion Z-axis (i.e.: gravity) and not the device's, and further, we are extracting relative rotation (how much has turned since starting to measure) then the 0 position is not that important for the commutator (except for mathematical stuff like gimbal lock) BUT it is for other measures that might be experimentally relevant (such as gravity vector).

In headstage64, indeed, we set the axis_map_config to 00100100 (0x24) which is the default, Z->Z, Y->Y X->X

@jonnew
Copy link
Member Author

jonnew commented Jan 8, 2025

Note to self: reperform this test, but do independent yaw, pitch, roll, motions for all three situations and compare.

@jonnew
Copy link
Member Author

jonnew commented Jan 8, 2025

Here are the results as requested this morning:

image

This verifies that we must always remap axes with the tether mounting direction being aligned with Z. These measurements were taken from a calibrated BN055. One thing I did notices is that when fully calibrated its the Y axis that aligns with due North, not X. All these measurements were taken with the Default position defined as Y pointing towards due north and Z towards the sky.

@aacuevas
Copy link
Collaborator

aacuevas commented Jan 8, 2025

I find it interesting that the values of Yaw and Roll on default and remapped without changing the position are also the same, and only pitch changes (since this remap implies a pitch change), which coincides with the "remap" we are making (we are "turning" it up on pitch). YPR (and quaternion, by extension) do use an absolute system and the remap specifies the 0 position.
So conclusions are:

  • For good data consistency, we must remap when needed
  • Commutator must always turn on the Z axis (unless someone wants something extra weird)
  • Even if for some reason the remap is not done, the commutator will probably still work (yaw/heading values are unchanged), which is a nice failsafe, but we should not rely on this

@jonnew
Copy link
Member Author

jonnew commented Jan 8, 2025

  • The absolute coordinate system is parallel (Y) and orthogonal (X) to B-field and towards the sky (Z).
  • If the tether protrudes from the opposite side of wherever z ends up pointing, commutation will be backwards and fail. (this was confirmed by not flipping Z when remap called for it and commutator turns backwards, which is expected)

@aacuevas
Copy link
Collaborator

aacuevas commented Jan 8, 2025

Last point is specially important because a flat headstage with the bno on the bottom is something easy to imagine.

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

3 participants