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

70 views (last 30 days)
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
  1 Comment
Paul
Paul on 2 Sep 2021
Edited: Paul on 3 Sep 2021
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.

Sign in to comment.

Accepted Answer

Mehdi Ejtehadi
Mehdi Ejtehadi on 4 Sep 2021
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.
  4 Comments
Paul
Paul on 4 Sep 2021
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
Mehdi Ejtehadi on 4 Sep 2021
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

Sign in to comment.

More Answers (1)

Ryan Salvo
Ryan Salvo on 2 Sep 2021
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
  1 Comment
Paul
Paul on 2 Sep 2021
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.

Sign in to comment.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!