imuSensor - why is the acceleration negated, when calculating the total acceleration?

The IMU-Sensor simulates an acclerometer, magnetometer and gyroscope. As inputs the sensor needs acceleration, angular velocity and orientation. I don´t

understand why the input acceleration is negated.

https://www.mathworks.com/help/fusion/ref/imusensor-system-object.html

[Jan Kappen]

I'm struggling here, too.

Any source I'm looking at says "a positive acceleration in the x-axis in the NED reference frame returns a positive acceleration in the accelerometer's body frame if the frames were aligned before movement". Why is that not the case here?

I tested it with a real IMU (XSENS MTi-30, quite expensive). Accelerating towards the sensors x-body axis results in a positive acceleration.

Are the MathWorks models wrong?

[Paul]

"Accelerating towards the sensors x-body axis results in a positive acceleration."

As would be the case with any real accelerometer I would think.

Unfortunately, Mathworks has adopted the opposite convention, which I can only charitably assume is the convention used by some communities of practice. I believe this choice has ripple effects on other functions/objects in the toolbox that use the outputs of imusensor (or the standalone accelerometer), i.e., the AccelReadings, as inputs, such as imufilter. By this, I mean that if one wants to use imufilter with one's own IMU model, one better account for the sign conventions of the accelReadings input to that filter. At least I think that's the case.

Interestingly enough, the Aerospace Blockset has a three-axis accelerometer model that works the way we expect, i.e., opposite of imusensor wrt polarity of the accelerometer outputs.

The imusensor has been discussed on other threads here on Answers, which might or might not be of interest. They should be easy to find.

[Jan Kappen]

Thanks Paul, this really drives me crazy. So is the solution to just negate all acc readings to compare it with other sensor conventions, or do we need to do special stuff like only negating the first two elements of the body acceleration and similar?

Why in hell has MathWorks chosen that convention? I was hoping, given such a relatively new product, that everything fits well to common standards :(

Edit, here are some great threads:

• Wrong gravitational acceleration in IMU model (imuSemsor) in sensor fusion toolbox. - MATLAB Answers - MATLAB Central
• How should I modify my real-time IMU data for usage in insfilterAsync/insfilterMARG object(s)? - MATLAB Answers - MATLAB Central

Thanks!

[Paul]

From my comment in the first thread you linked, I think you'd negate all three components of accelReadings to make them match what with other sensor conventions (including Mathworks own Aerospace Blockset).

From that first thread, and a few others, I agree that the imusensor model is .... confusing.

Answer 1

[Adam Danz]

Acceleration due to gravity is always negative. For example, if a falling object is affected only by gravity, its acceleration is -9.81m/s^2.

The sign of acceleration indicates the direction of acceleration for some reference frame. For example, if you're driving forward and you define forward as positive, then negative acceleration is the same as deceleration. The acceleration is being applied to the backward direction.

[Sebastian Bilkey]

thank you for your answer. your response does not really answer my question, but I already find the response somewhere else.

[Adam Danz]

@Sebastian Bilkey, please share what you've found so future visitors of this thread can benefit from your question. You can add it as a new answer.

[Morten Nissov]

I think he's asking why the following produces a negative number

>> imu = imusensor('accel-gyro');
>> imu([1,0,0], zeros(1,3))

ans =

   -1.0000         0    9.8100
   

Going from your explanation, and the accel begin in NED frame, I interpret the "true acceleration" being positive in the x axis as corresponding to the vehicle accelerating forward, as such I can't quite see why the measurement should be negative?

Especially considering "negative acceleration is the same as deceleration"

[Paul]

"Acceleration due to gravity is always negative."

Acceleration is a vector and the signs of the components of that vector depend on the choice of coordinate frame in which that vector is resolved. The linked doc page in the question actually shows this under the discussion of the RF input, where one can specify either ENU or NED as the coordinate frame of choice, which affects the sign of the z-component of the gravitational acceleration vector.

[Adam Danz]

Thanks Paul. I've looked into this problem deeper and now I have a better understanding of the issue. I will see if I can get any clarity (I did not work for MathWorks when I added that answer in 2020).

[Suleyman]

Hi @Adam Danz, just wanted to know if there was any progress on this front, thanks!