[Question] Orientation of MPU9250 and MPU9150 axis about rtimulib2 HOT 2 OPEN

Around a year ago, we had the same doubt and sent a mail to the original author asking for this.

He kindly responded:

Hi there! While it is true that the axes of the gyro and accelerometer are aligned, the problem is that the gyro rotation directions are inverted from what I want for the rest of the calculations. So what you are seeing in the code is first the gyro rates having their signs changed. However, they also use a right hand rule for axes and RTIMULib uses a left hand rule so the X axis has to be reversed. That's why you see the gyro Y and Z values being negated but not the X value - the X value has been negated twice. The sense of the accelerometer is correct but it also needs the right hand to left hand conversion, hence the X value is negated.

Hope that makes sense!

Richard.

The key thing is that the gyro data are ANGLE RATES and are required in left-hand rule which are conventionally CLOCKWISE (contrary to the chip's right-hand standard). So a new left-hand axis needs to be decided, and it just invert the X axis as you noted in the accelerometer axis. That requires to negate angles rates of Y and Z, but not X, while only negates X axis in the accelerometer.

This leads to:

The compass remained kind of a mystery for us, but we did ask him about that and, while he was a bit hesitant, we got:

...
If you look at lines 633 to 635 of that file you can see the magnetometer
outputs being adjusted to match the IMU as the raw IMU and magnetometer data are in different
frames. All of the drivers output data in the standard AxisRotation 0 frame.
...

So we understand that, to take the compass MPU9250-Right-Hand-NED (RH) to the same RTIMULib-MPU9250-Left-Hand (LH) as the gyro/accel it should:
LH_X = -RH_Y
LH_Y = RH_X
LH_Z = -RH_Z

But he doesn't do that, he ends up with a right-hand axis again. I disagree with your interpretation of the resulting axis @SivertHavso, as I understand it is rotating 90 degrees in the opposite direction that you drawn.

At that point we just commented the lines in our internal repo and move on with our lives.

What is mind-blowing to me is that the default AxisRotation (explained in RTIMU.h) is in right-hand, as It is stated that "Standard configuration is X pointing at north, Y pointing east and Z pointing down", which is right-hand NED. That greatly differs from the gyro+accel left-hand axis delivered by the MPU9250 driver.
Also, as I understand, changing AxisRotation, would lead to a right-hand matrix transformation being applied to left-hand raw data in the RTIMU::handleGyroBias() function.

I don't know if any of this happens with any other IMU chip/driver, but we set the AxisRotation as 0, so identity matrix would be used and performed data reinterpretation at a later point in our code and didn't use any fusion capabilities.

I would be really nice to document and state requirements for the drivers on which coordinate system they should deliver the samples, what is left-hand / right-hand and how data should be expected. Some examples on how to use the AxisRotation would be nice also.

Hope this helps.

from rtimulib2.