Linear Acceleration input to the IMU Block in Simulink

Referenced documents: https://uk.mathworks.com/help/nav/ref/imu.html

Hi, I have a UAV model in Simulink and would like to add some noise to the model outputs. I'm trying to simulate IMU sensors using the 'IMU' block. I configured it in NED orientation. My model also assumes NED orientation.

The issue is that I don't understand the block's help:

• "Do not include the gravitational acceleration in this input since the sensor models gravitational acceleration by default."

After reading this, I was planning to get the Body-Frame accel from the EOM, substract the Body-Frame gravity and connect that to the block. But then I read this in the block's help:

• "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 assuming an NED frame) as: totalAcc=−acceleration+g. The acceleration term is negated to obtain zero total acceleration readings when the accelerometer is in a free fall. The acceleration term is also known as the specific force".

So if I substract the gravity from the body frame total accel, I think what happens internally is:

(EOM_accel - g) --> processed as totalAcc=−acceleration+g --> output = -(EOM_accel - g)+g = 2g - EOM_accel, which is not correct.

Then I thought about passing (-EOM_accel + 2g) so that, after processing, the block delivers (EOM_accel-g), which is the the specific force that an accelerometer delivers, isn't it? i.e. -g when the UAV hovers, 0 in free fall.

But this doesn't feel right. What am I getting wrong?

Thanks!

[Paul]

Please provide a link to the doc page for the specific block in question.

[Ubersich]

done! https://uk.mathworks.com/help/nav/ref/imu.html

Answer 1

[Paul]

Hi Ubersich,

You're not getting anything wrong, only suffering from poorly written documentation and a block algorithm that's probably not what you (and others) expect.

See link 1, link 2, and link 3 for additional discussion. I think different toolboxes use the same underlying model.

In short, IIRC:

1. The input to that block should should be the inertial acceleration at the IMU, i.e., you don't subtract the gravity vector to form the specific force on input. The block will internally subtract the gravity vector.

2. You are stuck with the gravity model assumed by the block.

3. The inertial acceleration input to the block should be resolved in the NED (or ENU) frame, not the IMU frame.

4. The accel output of the block will be a measurement of the negative of the specific force.

I strongly suggest running some basic test cases where you know what the block output should be to make sure the inputs are correct and how to process the outputs. It's confusing as you (and others based on the links above) have found.

You many want to have a look at the Three-Axis IMU in the Aerospace Blockset, which I assume uses a Three Axis Accelerometer. The Three-Axis Accelerometer seems to operate the way you'd expect. I don't know if the Three-Axis IMU implements the same error sources as the model you're looking at from the Navigation toolbox.

[Ubersich]

Hi Paul,

Your answer has exceeded my expectations, thank you.

What I've done so far (Attached a screenshot for anyone's reference):

1. I've had a go with your proposal for not subtracting the gravity (as the block does indeed perform this operation), plus fixing the sign of the output. Finally, to close the control loop, I've had to add back the Body-Frame gravity to the block output, but only the z-component. With this, I think I got the results I expected...
2. Then I thought this would be equivalent to try the initial approach of correcting the IMU block input, but in this case I've only substracted the gravity z-component only. This is not very realistic since the block is spitting a total acceleration instead of the specific force, but I'll have to live with that...
3. I've tried the 'Three-axis Accelerometer' block and yeah it is more intuitive, so it can save people some headache. The thing is that the IMU looks compact so it is appealing.
4. In the screenshot, the body-frame accel is plotted in yellow, the input to the IMU block is in red, and the output of the IMU block in blue.

Please if someone reads this, have a thought before assuming what I posted here is correct, since I'm not sure!

[Paul]

1) I think you have to add back all three components of the gravity vector resolved in the body frame if you want a measurement of the inertial acceleration vector resolved in the body frame (as opposed to just its component along the z-axis of the body frame).

inertialaccelreadings = -accelreadings + transpose(orientation)*g where orientation is the input to the block and g is the gravity vector used inside the block.

2) I don't fully understand this. Not sure why you have to live with whatever this is because it seems like (1) is the way to go.