Revision history [back]

Imagine you are in a car, and you accelerate forwards. That is +X acceleration. When you drive forwards, you feel the force pushing you backwards, even though you are accelerating forwards.

When you are in, say, a flight simulator machine, and they want to simulate forward motion, they tilt the machine backwards, so that you are facing up to the sky. You feel the force pushing you backwards, but you are "accelerating" upwards, against the gravity vector.

Taking it a step further: if you really did lay on your back, you'd feel the force of gravity pushing against you. If you then managed to fly straight up in the air from that position (+Z motion/acceleration), you'd feel an increase in force pushing against you, because you are accelerating upwards.

Now imagine we are in a standard ENU right-handed coordinate frame. +X is straight ahead, +Y is left, and +Z is straight up in the air. We have an IMU in neutral position on a table. If I push that IMU forwards along the table, it will register +X acceleration, because I am pushing it in the +X direction. If I push it left on the table, it will experience +Y acceleration, because it is moving in the +Y direction. If I move it straight up in the air, it should read +Z acceleration, because I am moving it in the +Z direction. This would be in addition to acceleration due to gravity, so if I accelerated at 1 m/s^2 straight up, my IMU should read +10.81 m/s^2. If it didn't, that would mean if I could move the IMU straight up at 9.81 m/s^2, the IMU would read 0, which is clearly not the case.

The problem is that, even though they are right-handed, a lot of IMUs report in NED frame, not ENU. r_l assumes ENU-frame, so you need to swap the signs of the Z and Y axes for all the data coming off the device if it's reading NED.