What frame of reference is the CG input to the IMU in Aerospace pack?

Hi there, I am working with the IMU block in simulink where I need to connect to the CG (center of gravity) input. My question is thus, is it in the fram of reference relative to my objects coordiantes (e.g. robot, drone, ect) or is it in the frame of reference of my global coordinate system, and is it dynamic, by which I mean, does it need the (e.g) the robots current location (and then of course relative the correct frame of reference)? It wasn't clear to me in the documentation, so I thought I would ask the question here. Thanks in advance.

Answer 1

[Paul]

Hi Mats,

According to IMU Location the CG input is to be provided in a coordinate frame that is fixed to the body. However, the IMU Location parameter and CG input are NOT defined in the same body-fixed axes in which the Ab and omega and omega_dot inputs are defined. According to Algorithms "The orientation of the axes used to determine the location of the accelerometer group (xacc, yacc, zacc) and center of gravity (xCG, yCG, zCG) is from the zero datum (typically the nose) to aft, to the right of the vertical centerline and above the horizontal centerline. The x-axis and z-axis of these measurement axes are opposite the body-fixed axes that produce the negative signs in the lever arms for the x-axis and z-axis." (emphasis added).

Strongly suggest developing some basic test cases for stimulating the IMU model where you know what the output should be to make sure you get all of the inputs defined correctly.

I suspect that CG is defined as an external input for applications where the CG location changes over time (relative to a fixed point on the body), such as a solid rocket burning fuel.

Looking at your diagram, I was quite surprised to see those derivative blocks on velocities to form accelerations as opposed to the accelerations being output from the 6DOF block. According to Version History, the omeg_dot and A_be outputs were removed from that block in 2025a. That seems like a very peculiar decision and I'm quite curious as to why it was made.

[Mats]

Hey Paul, thanks for the detail explantion, that cleared it up a lot.

As to your last remark, I am not sure if that is a question you're asking me, or a question for matlab. I added the derivative blocks since the inputs of the gyroscope is acceleration. i.e , and since the 6DOF block only provides the velocity, I found what I thought was the most natural way of obtaining the acceleration, as you yourself mentioned.

If it was a question for MATLAB, then I would assume they've done it that way since perhaps it is more intuitive, given that velocity dictates the direction of motion, and thus for a mass in motion, you would need that, and not accerleration, since if , then , but for accerleration , i.e. the initial velocty is lost, unless an initial datum is given. That would be my geuss as to why.

But again, thanks for the clarification, it was very helpful :) .

[Paul]

That last remark was really directed to anyone from MathWorks who might see this thread and can explain that decision.

I really hope they had a good reason because users who were using those block outputs will have a broken simulation as of 2025a. And those outputs must be computed inside the block anyway, at least I think that must be the case, so why remove them as outputs? And now users, such as yourself, must either compute those quantities algebraically, i.e., replicate that which is already done inside the block (I think), or use a Derivative block, which comes with its own potential problems as discussed on its doc page.

More importantly for you, I don't think that the derivative of Vb should be the input to the IMU as the acceleration Ab. Rather, I think to get Ab one should differentiate Ve and then transform the result from the earth frame to the body frame. Or just compute Fxyz/mass (exactly as must be done inside the block, I believe).

Wait! I just checked the R2025A Release Notes and it looks like there are two new blocks that are intended exactly for your use case: 6DOF Acceleration and 6DOF Angular Acceleration.

Now I'm really, really curious as to why MathWorks went down this path, but at least they given users those two new blocks.