Wrong gravitational acceleration in IMU model (imuSemsor) in sensor fusion toolbox.

Hello dear friends,

I have been struggling with the sensor fusion toolbox lately. In short, I create a stationary model of an IMU sensor and I expect it to only capture the gravity. The problem is the direction actually!

With the IMUs we know that they capture g in the opposite direction (if the gravity is downwards, the sensor captures it upwards). Consider a stationary IMU that we are holding still; The reason that keeps it from falling, is the force that we are applying to the IMU and the IMU actually captures the acceleration caused by the applied force. So that's the reason why IMUs capture g upwards and not downwards.

But with the simple example below, we see that such thing doesn't happen with the sensor fusion toolbox.

IMU = imuSensor('accel-gyro-mag','ReferenceFrame','NED'); % Creating an IMU object
acc = [0 0 0]; % Acceleration of the IMU with respect to the NED Frame
angVel = [0 0 0]; % Angular Velocity of the IMU with respect to the NED Frame
orientation = [[1 0 0];...
               [0 1 0];...
               [0 0 1]]; % Orientation of the IMU with respect to the NED Frame
[accelReadings,gyroReadings,magReadings] = IMU(acc,angVel,orientation);
accelReadings

accelReadings = 1×3

0 0 9.8100

The IMU has no acceleration nor angular velocity with respect to the 'North-East-Down' frame and the orientation of the IMU sensor is the same as the 'NED' frame. So Its Z axis alligns with the 'Down' direction. But we know that g should be captured upwards (-down) so g should be negative (-9.81) in the Z direction of the local frame of the IMU but as can be seen above, it's positive! Can someone help me with this issue please?

Thanks in advance

[Paul]

If you look on the doc page for imuSensor under the Algorithms section for the accelerometer, it shows a block diagram of the accelerometer model. In that diagram, it shows the input to the model is called "acceleration," which is combined with "g" to form a quantity called "Total Acceleration." The diagram doesn't show whether "g" is added or subtracted. (Edit: See the Answer below for how how Total Acceleration is calculated). However, the results shown in your Question, and from the doc page example Generate Ideal IMU Data from Stationary Input, and the term "Total Acceleration," all suggest that the "acceleration" input into the model is, what I would call, the specific force and the output is a measurement of inertial acceleration.

a_i (output) = a_sf (input) + g

Unfortunately for me, and I guess you would agree, such an approach is exactly the opposite of how I would expect an acceleromter model to operate. In fact, I would leave "g" out of the model altogether and leave that up to the user to ensure that the input is specific force.

Furthermore, the doc page doesn't say what it assumes about the direction of "g." Is it always in the Down direction in the local NED frame? Can the user specify a WGS-84 model somehow? It doesn't look like it, which is another reason to let the user deal with gravity.

Interestingly enough, the imuSensor in 2019a yields the exact same result, but the doc page doesn't show the formation of a Total Acceleration.

Answer 1

[Mehdi Ejtehadi]

Dear Paul and Ryan,

Thanks for your time and consideration. I think I get the idea behind the sensor models according to the fact that this toolbox is based on the "Open Source Sensor Fusion Package". But the fact is that these models actually act like negated real IMUs. If the algorithm was changed to "acceleration - g" instead of "-acceleration + g" everything would have worked fine though.

Anyway, for those who want to get the data similar to the real IMU sensors, the arguments should be as below:

• acc: acceleration of the body on which the IMU model is mounted, with respect to the global frame and descripted in the global frame.
• angVel: angular velocity of the body on which the IMU model is mounted, with respect to the global frame and descripted in the global frame, multiplied by -1.
• orientation: Transpose of rotation matrix of the IMU with respect to the global Frame (which is orientation of the global frame in the IMU frame), multiplied by -1.

[Paul]

@Mehdi Ejtehadi

Can you clarify a few things:

acc: Doesn't acc have to be resolved in the NED frame, not the global frame?

angVel: Why does angVel need to be multiplied by -1? Shouldn't it also be resolved in the NED frame?

orientation: From the doc page, it looks like orientation is the rotation matrix that multiplies a vector resolved in the NED frame to yield that same vector resolved in the IMU frame. It sounds like you're saying that it's basically the negative of the transpose of what I've just described?

[Mehdi Ejtehadi]

Once again I remind you that the arguments that I mentioned, are for modeling a real IMU. With that in mind:

• Actually by saying global frame I mean 'NED' or 'ENU' frame. If there exists a frame between the IMU frame and the ENU/NED frame, and the kinematics of the body are measured with respect to this auxiliary frame, the measured kinematics should be transformed and expressed in NED/ENU frame (using the rotation matrix between these 2 frames). For sure there should exist some sort of relation between the auxiliary frame and the ENU/NED frame.
• Both "acc" & "angVel" are measured with respect to the global frame (ENU/NED). Then "angVel" is negated and input to the model.
• In the doc page, orientation is infered as the frame of the body with respect to the global frame (means the rotation matrix that yields IMU frame if multiplied by the global frame). But here I say that if you want to model a real IMU, you should do reverse (start from IMU frame, multiply it by a rotation matrix to yield the global frame. this rotation matrix is the forementioned "orientation")

The reason underlying all these is the algorithm used in this toolbox. The toolbox uses the formulation: "totalAcc = -acc + g" which should be: totalAcc = "acc - g" if we do not want the negated data. In order to fix this issue we should find the proper arguments that yield the real IMU data.

The details for what I said, is provided in the attached photo. Hope you don't mind my handwriting and all :D

[Paul]

Ok. Now I see where you're coming from.

Do you agree that it's functionally equivalent to have:

On input:

acc - acceleration of the IMU relative to the NED frame (assuming the NED frame is an inertial frame) resolved in the NED frame:

angVel - angular velocity of the IMU relative to the NED frame (assuming the NED frame is an inertial frame) resolved in the NED frame:

orientation - Rotation matrix that takes a vector resolved in NED to resolved in IMU:

On output:

negate the accelReadings to form the accelerometer measurement:

The gyro measurment is gyroReadings

This approach would yield:

which I think is the desired result.

[Mehdi Ejtehadi]

Yes! I think this works well either... I think the biggest misunderstanding in the docs is the "orientation"... I can see that you too have noticed it...

Anyways, Thanks a lot Paul; You have been really helpful. Wish you the best.

Mehdi

Answer 2

[Ryan Salvo]

Hi Mehdi and Paul,

The equation for total acceleration is actually listed below the block diagram in the imuSensor documentation page.

Obtain Total Acceleration

To obtain the total acceleration (totalAcc), the acceleration is preprocessed by negating and adding the gravity constant vector (g= [0; 0; 9.8] m/s2) as:

totalAcc=−acceleration+g

This convention is used to obtain an accelerometer reading of [0 0 0] when the sensor is in freefall and the sensor frame is aligned with the parent/navigation frame.

The algorithm is the same in R2019a, but the documention page was updated after that release to include the Total Acceleration equation.

Thanks,

Ryan

[Paul]

Thank you for pointing out the equattion in the Algorithms section.

The documentation would be much clearer if it said:

To obtain the total acceleration (totalAcc), the input acceleration (acc) is preprocessed by negating it and adding the gravity constant vector (g= [0; 0; 9.8] m/s2) as:

Setting aside the wording, the doc basically says the output is the negative of the input. Let's verify:

IMU = imuSensor('accel-gyro-mag','ReferenceFrame','NED'); % Creating an IMU object
acc = [1e5 1e5 1e5]; % Acceleration of the IMU with respect to the NED Frame
angVel = [0 0 0]; % Angular Velocity of the IMU with respect to the NED Frame
orientation = [[1 0 0];...
               [0 1 0];...
               [0 0 1]]; % Orientation of the IMU with respect to the NED Frame
[accelReadings,gyroReadings,magReadings] = IMU(acc,angVel,orientation);
accelReadings

accelReadings = 1×3

1.0e+05 * -1.0000 -1.0000 -0.9999

Sure enough, the output is the negative of the input! Is that documented other than in that equation (I did not check carefully)? So the user has to know to negate the output before using it downstream? Is that really desired behavior for a generic accelerometer model?

Also, the reason for doing it that way doesn't really make sense. It would be much more straightforward to simply use:

totalAcc = acceleration - g

which appears to the approach in the Aerospace Blockset (link)

This equation would also result in the (ideal) accelerometer reading [0 0 0] when in free fall (assuming that the user's implementation of the gravity model is the same as that assumed in the imuSensor, which is another weakness of this implementation), and has the advantage that the user is not obligated to worry about the polarity of the output.