Confusion about gravity direction

[thrownit]

Hi Dear Rodralez:

I'm using NaveGo to deal with my own IMU data from UAV, during the process, I found the result was ridiculously wrong, after a careful examine, I found the gravity directions are different in my IMU data and the NaveGo code and the NaveGo simulated example data.

I used both a DJI UAV and an Xsens MTi IMU to collect the original data. Their body coordinate system are all FRD, which are supposed to be the same with NaveGo. But their data are acting differently with the NaveGo simulated example data:

↑this is the DJI UAV IMU data

↑This is the data from an Xsens MTi sensor

In both case, the body is firstly still and then moving upwards and downwards back. The upwards accelerations are negative, which meets the FRD coordinate definition well. The Z acceleration data is around -9.8,which means the gravity is -9.8 in their FRD coordinate system.

But directly providing these data to NaveGo leads to a messy result. Then I checked the simulated example data, I found the body acceleration data is like:

the Z accleration data is around +9.8, initially I thought this may be an inverted axis.But according to the simulated track, the body experienced an upward acceleration, if the axis was inverted ,the upward acceleration should be positive, however the upward acceleration is still negative with the + 9.8 gravity.

So it appears that in NaveGo the gravity is positive in the body FRD coordinate system, unlike conventional sensor's definition. Now I'm working around this problem by making:
fn_c = fn - coriolis - (g);
to
fn_c = fn - coriolis + (g);
The results get reasonable but still not perfect. So i'm wondering besides altering - (g) to + (g), is there anything else I should do to make up for the different gravity direction problem? Will this affect allan regression result?

[Rodrigo Gonzalez]

Dear thrownit, Thank you for your comments. There is some confusion about the signs of NaveGo body frame. NaveGo body frame is positive X-forward, Y-right and Z-down. So, gravity should be positive around 9.81 and upward acceleration should be negative. Then, the sign of the Euler angles is ruled by the right-hand rule [1]. This means that roll is positive when turning right, pitch is positive when the vehicle is climbing and yaw is positive clockwise. Since yaw is defined by the atan2() function, it goes from 0 to pi radians and then immediately from -pi to 0 radians, always clockwise. If you want you can display the yaw from 0 to 2pi radians or 360 degrees coding some extra function. According to my experience, sometimes you have to change the sign of the measurements of some inertial sensors from a commercial IMU. For example, if your Z accelerometer data is around -9.8, you have to multiply this vector by -1. Additionally, you may try changing the signs of the X and Y turn rates, if you are not sure about the convention signs of the IMU body frame. Kind regards. [1] https://upload.wikimedia.org/wikipedia/commons/thumb/3/34/Right-hand_grip_rule.svg/330px-Right-hand_grip_rule.svg.png

…

-- Rodrigo Gonzalez

[thrownit]

Hi Dear Rodralez:

Thank you for your explanation, actually I'm more confused about the conversion you've mentioned.

Since the commertial IMUs I used claimed using FRD coordinate system as NaveGo does, at least the accleration except gravity should be in the same direction. But if the Z accelerometer data from a commercial IMU is multiplied by -1, the acceleration except gravity will also be inverted, that will conflict with the FRD coordinate system. An upward acceleration sensed by the commercial IMU will be treated as downward acceleration.

Like these images, both MTi data and NaveGo simulated data have FRD coordinate system, and in both data, an upward acceleration is negative as shown in the red circles. the only difference is the direction of g. If multiply the Z data of MTi with -1 as instructed, the acceleration will be inverted as well

So I'm confused how to deal with this situation? Does the inverted g have any other potential effect on other data such as turn rate and Front-Right acceleration?

[Rodrigo Gonzalez]

Dear thrownit,

Since the commertial IMUs I used claimed using FRD coordinate system as NaveGo does, at least the accleration except gravity should be in the same direction. But if the Z accelerometer data from a commercial IMU is multiplied by -1, the acceleration except gravity will also be inverted, that will conflict with the FRD coordinate system. An upward acceleration sensed by the commercial IMU will be treated as downward acceleration.

I think you have a good question for your IMU technical support :-)

Like these images, both MTi data and NaveGo simulated data have FRD coordinate system, and in both data, an upward acceleration is negative as shown in the red circles. the only difference is the direction of g. If multiply the Z data of MTi with -1 as instructed, the acceleration will be inverted as well

As you may guess, a "quick and dirty" solution for your IMU Z accelerometer is to add (2 * 9.81) to your Z acc data.

So I'm confused how to deal with this situation? Does the inverted g have any other potential effect on other data such as turn rate and Front-Right acceleration?

Yes, gravity is a vector that can be decomposed in 3 directions. So, a wrong Z acc vector may affect 3D velocities and, consequently, 3D positions. Regards.

[thrownit]

Thank you for your reply. Adding (2 * 9.81) to the Z acc data seems to work. But I still have some confusion of how in different sensors the gravity may have opposite direction with vertical acceleration.

Assuming there is a simplest acceleration sensor which has a spring hanging a weighted object. An upwards acceleration of the body will make the weighted object moving downwards, that means the spring may be stretched longer. And which is simple to imagine, the gravity also have the effect to pulling the weighted object downwards. So this may make me think the gravity should be equal to an upwards acceleration, which physically it should. But in NaveGo the gravity has an opposite direction with an upwards acceleration. Because I'm new with IMUs, does actual acceleration meters such as optical fiber acceleration meters or MEMS ones can sense gravity in the opposite direction with an upwards acceleration?

Regards.

[Rodrigo Gonzalez]

Dear thrownit, Every IMU has a sign convention for its output, or in other words, the IMU manufacturer defines the signs of the IMU body frame. Z acceleration could be positive down or up, it's not a big deal. NaveGo has the same convention that most important books in the navigation field, body frame is positive X-forward, Y-right and Z-down. Your IMU may have a body frame convention where positive is X-forward, Y-left and Z-up. No problem. You only have to multiply Y and Z data by -1 to adapt your data to NaveGo convention. One more thing you have to check is how your IMU body frame was aligned with respect to the vehicle body frame. X-forward axis was pointing in the forward direction or was pointing backwards during the data logging? I hope my comments shed some light on your question. Kind regards.

…

-- Rodrigo Gonzalez

[thrownit]

Glad to have your reply.

As you said，modern IMUs may have coordinate mapping functions, but my point is, using such functions to invert the coordinate axis may invert the acceleration and the gravity at the same time. The invert operation may be like -1*(g+acc). But to make my data work with NaveGo, I did the operation like (acc-2g), witch means the gravity is separated with the acceleration. In my second reply I already have this confusion.

Like the last reply of mine said, the gravity should have the same direction with an upwards acceleration, if inverted the direction of z-axis, the upwards acceleration and gravity should receive -1 at the same time , like -1*(g+acc), but NaveGo have (acc-2g) instead, which means this is not a simple axis inversion, I'm wondering is this gravity-only inversion come from the working principle of mordern IMUs of something else?

Regards

[Rodrigo Gonzalez]

Hello Daniel, Excuse me for my late reply. It is all about sign convention for the body frame. NaveGo sign convention for body frame is positive X-forward, Y-right, and Z-down. As you pointed out, it makes no sense that an AccZ sensor shows +9.8 staying still, and a negative acceleration if the sensor goes upward. In this case, you should preprocess your sensor data in order to be consistent with NaveGo body frame. Kind regards.