IMU Axis Conventions

[dlktdr]

The current axis convention from the IMU is using is Y+ faces forward, X+ to the right and Z+ faces up. X+ on the Nano 33 faces the USB port, Z+ is away from the chips. This is not a standard convention. Propose switching to NED.

https://en.wikipedia.org/wiki/Axes_conventions

To prevent too much confusion when updating, the firmware should add saving the current version into flash going forward. Default to zero if not found. If version less < xx, apply necessary rotations to make the output NED.

[dlktdr]

Second note: all rotations should be switched to quaternions, to prevent possible gimbal lock situations. A Euler->Quaternion converter can be shown in the GUI, but internally everything is quaternions.

[gcmcnutt]

ok, for the first step, let's consider a new orientation -- how about this:

• assume the board is a vehicle oriented like this:
  • with the board flat (flat on the table, components up)
  • and with the usb connector facing forward
• then +x is 'forward', and roll right should be 'increase in ppm'
• then +y is 'left' and tilt down should 'increase in ppm'
• and +z is 'up', and pan left should 'increase in ppm'

then for orientation, an example:

if we install the board on the right side of DJI with connector facing back we would translate like this:

• X -90 -- this rolls device with components facing DJI first
• Y +170 -- this then flips the device around for the mount. note this isn't perfectly 180 as the side of the headset is slightly inward panned
• Z 0 -- device is still horizontal

@dlktdr can you check my math here?

[dlktdr]

With that reference frame which is ENU, here is what I come up with. All assuming we keep the same order of operations x-> y-> z

Red X
Green Y
Blue Z

Initial Orientation

After a X -90

After Y +170

I'm not sure but I don't think this was your intention?

[gcmcnutt]

Ok, I see the difference -- in my case, I performed the xyz rotation according to the board axis, not a global axis. If this should be performed according to global, then does this look like the rotation?
x +90
y +180
z +10

[dlktdr]

Ahh.. Yes those rotation values make sense.

[dlktdr]

Been thinking about this, and after a bit of discussion on discord. I think we should keep with the current sensor orientation and labelling of the tilt, roll, pan outputs. As long as the frame stays right handed which is a must from IMU sensor, the board rotation option will take care of all mounting possibilities after that.

Both NED and ENU standards have the X axis pointing forward. As it's currently setup in the code/labelling Y points forward. If we follow the standard convention ENU or NED of a tilt/pitch is a rotation in X, then the standard Euler is only going to have a range of +/-90, which isn't ideal as @kobelev-tech brought up.

So I think the ideal situation is keep the current right handed orientation from the sensors, and the current labelling that Tilt is a rotation in X, Roll is a Rotation in Y and pan a Rotation in Z.

Might not be a standard, but can make a drawing and have something to reference if required. Also no code changes or new videos required :)

Eventually remove that pesky board orientation and have it rotate the IMU output with a few snapshots during calibration. e.g. Hold Level, push button, Look Up push button, Look Down, push button. From which we can determine the world frame from, Or (Hold Level, Look Left, Look Right) This is actually completed in Pauls code #124, just needs to be implemented in the GUI and tested.

[gcmcnutt]

sounds good -- we can make a little 3d render on that -- perhaps a separate alignment tab -- that moves with the settings -- then no additional manual needed. let's close this one and we can open another on improved board alignment setter or something similar.