Why the results of factorIMU predict and insfilter predict are exactly opposite to each other？

I used the imuSensor to generate the measurement data of the imu, and then used the factorIMU to perform the predicted integration calculation of the generated data. However, I found that the result was not consistent with the expectation. So, I further compared the predict results of the insfilter with the expected ones.

For example, when the coordinate system is defined as NED, and there is a positive 1 m/s^2 acceleration in the x-axis and z-axis, when predicting the data 1 second later, the speed obtained by factorIMU is -1 m/s and -1 m/s, while the predicted data by insfilter is 1 m/s and 1 m/s.

I verified both the NED and ENU coordinate systems separately, and the phenomenon was the same.

I'm very curious as to why different results occurred. Looking forward to your reply very much.

Below is the code I used for verification. The version of Matlab is 2025b.

clear;clc;close all

FRAME_TYPE = "NED"  % NED/ENU
%% DEMO 1 Verify the relationship between the output of the IMU and the actual motion acceleration.

disp("DEMO 1")
trueAcceleration = [1 0 1];
trueAngularVelocity = [0 0 0]; 
IMU = imuSensor('ReferenceFrame',FRAME_TYPE);
[accelerometerReadings,gyroscopeReadings] = IMU(trueAcceleration,trueAngularVelocity);
accelerometerReadings
% Summing-up
% --FRAME_TYPE = NED
% trueAcceleration          AccelReading  
%     [0, 0, 0]             [0, 0, 9.8]
%     [1, 0, 1]             [-1, 0, 8.8]

% --FRAME_TYPE = ENU
% trueAcceleration          AccelReading  
%     [0, 0, 0]             [0, 0, -9.8]
%     [1, 0, 1]             [-1, 0, -10.8]

%% DEMO 2
disp("DEMO 2")
% Add an IMU factor to a factor graph
nodeID = [1,2,3,4,5,6];
sampleRate = 100; % Hz
gyroBiasNoise = 1.5e-9 * eye(3);
accelBiasNoise = diag([9.62e-9,9.62e-9,2.17e-8]);
gyroNoise = 6.93e-5 * eye(3);
accelNoise = 2.9e-6 * eye(3);

gyroReadings = repmat(gyroscopeReadings, 100,1);
accelReadings = repmat(accelerometerReadings, 100, 1);

params = factorIMUParameters( ...
    SampleRate = sampleRate, ...
    GyroscopeBiasNoise = gyroBiasNoise, ...
    AccelerometerBiasNoise = accelBiasNoise, ...
    GyroscopeNoise = gyroNoise, ...
    AccelerometerNoise = accelNoise, ...
    ReferenceFrame = FRAME_TYPE ...
    );

f = factorIMU(nodeID, gyroReadings, accelReadings, params);

G = factorGraph;
G.addFactor(f);

prevPose = [0 0 0 1 0 0 0]; % Pose + Quaternion
prevVel = [0 0 0];
prevBias = [0 0 0];
[~,predictedVel] = predict(f,prevPose,prevVel,prevBias)

%% DEMO 3
disp("DEMO 3")
filter = insfilter('ReferenceFrame',FRAME_TYPE);
filter.IMUSampleRate = sampleRate;
% Fuse a gyroscope measurement of [0.1 0.2 –0.04]  with a measurement noise covariance of diag([0.2 0.2 0.2]) .
for ii=1:100
    predict(filter,accelReadings(ii,:),gyroReadings(ii,:));
end

% Show the fused state.
insPredVelocity = filter.State(stateinfo(filter).Velocity)'

Answer 1

[Akshai Manchana]

As explained in the following imuSensor simulation assumes platform motion. Meaning the platform experiences the said linear acceleration. The acceleration experienced by IMU sensor at the same time is the opposite of platform linear acceleration. This effect is similar to what you experience while sitting in a car. When you accelerate the car forward you experience the opposite while sitting within the car. This is evident from the equations used within the following documentation.

https://www.mathworks.com/help/nav/ref/imusensor-system-object.html#mw_d780d88c-d3b3-4716-9bd9-c15924e70444

The insfilter predicts the motion of the platform where as the factorIMU predicts the motion of the imu sensor. Meaning the insfilter assumes an imaginary platform that expericences a motion in the negative direction as accelerometer measurement and predicts it's motion. Where as factorIMU just accumulates the accelerometer measurement and no platform motion assumption. When you accumulate accel readings with just gravity removed then you predict the motion of the sensor with the given accel radings. That is why they both predict opposite motions.

[mo]

Thank you very much for your detailed reply. One of the most significant differences I notice is:The insfilter predicts the motion of the platform where as the factorIMU predicts the motion of the imu sensor.

However, I still have a question: Why does the predict function in factorIMU predict motion of the IMU sensor instead of the integral of the platform?

For example, in the example at https://ww2.mathworks.cn/help/nav/ug/factor-graph-based-pedestrian-localization-imu-gps.html, I noticed that the integral of the IMU is updated to the new node state. The node states describes the pose of the platform, so if their meanings are different, why the predict results of predictedPose and predictedVel can be directly assigned to nodeState(at step 5)?

 % 2. Create an IMU factor. 
    fIMU = factorIMU(currNodeIDs,imuFs, ...
        imuNoise.Gyroscop
eBiasNoise, ...
        imuNoise.AccelerometerBiasNoise, ...
        imuNoise.GyroscopeNoise, ...
        imuNoise.AccelerometerNoise, ...
        sensorData{ii}.GyroReadings,sensorData{ii}.AccelReadings);

    % 3. Create a GPS factor. 
    fGPS = factorGPS(currNodeIDs(t0IndexPose),HDOP=sensorData{ii}.HDoP, ...
        VDOP=sensorData{ii}.VDoP, ...
        ReferenceLocation=lla0, ...
        Location=sensorData{ii}.GPSReading);

    % 4. Add the factors to the graph. 
    addFactor(G,fIMU);
    addFactor(G,fGPS);

    % 5. Set initial node states using previous state estimates and a state prediction from the IMU measurements.
    [predictedPose,predictedVel] = predict(fIMU,prevPose,prevVel,prevBias);
    nodeState(G,currNodeIDs(t1IndexPose),predictedPose);
    nodeState(G,currNodeIDs(t1IndexVel),predictedVel);
    nodeState(G,currNodeIDs(t1IndexBias),prevBias);

[Akshai Manchana]

The short answer for this question is that factor graph system is designed to work with muli-sensor systems like LIDAR, Camera, IMU and GPS. The system expects motion of sensor system (with one sensor as base sensor).

INS system always imagines the poses to be in navigation reference frame like ENU/NED. That's not true for factor graph system. The pose reference frame can even be initial camrea or LIDAR where gravity rotation is usually unknown before we optimize factor graph.

Also, we felt that assuming platfom motion silently is more restricting (simple integration of accel readings won't result in predicted motion). However, at this point we feel it's users responsibility to invert the accelerometer measurements if they are fully aware of the situation.

We can certainly enhance our tool to let users explicitly mention that platform is accelerated instead of IMU-sensor in which case we can use relevant equations to mimic ins-filters under the hood if that is an important use-case.

With imu factor the connected pose and velocity nodes are no longer expected to hold the platform pose and velocity anymore. They are IMU sensor poses and velocities.

[Paul]

@Akshai Manchana

I don't understand the distinction between linear acceleration of the platform and the linear acceleration of the IMU.

Suppose I put an IMU in the passenger seat of my car with the +x-axis of the IMU (as indicated by the vendor) pointing toward the windshield, and then I step on the gas pedal (transmission in drive). Are you suggesting that the IMU will output a negative acceleration even though the car is accelerating forward (in the direction of the IMU +x-axis)?

[Akshai Manchana]

Hi Paul,

You are correct. The imuSensor and insfilter are configured to work with the assumption that IMU captures negative of acceleration that causes actual motion (platform motion).

factorIMU doesn't silently consider that. Instead like other sensor fusion and SLAM frameworks it considers computing sensor motion from acceleration measurements without any silent assumptions. We expect the customers to transform acceleration in any other case.

[Paul]

"We expect the customers to transform acceleration in any other case."

That is very unfortunate.

The design decision to have the accelReadings output of the @doc:imusensor have polarity opposite the input (among other aspects of @doc:imusensor) causes quite a bit of confusion (as seen in this thread and others easily found on Answers) without any benefit.

Maybe different communities of practice use different conventions for an accelerometer model?

Interestingly, the documented input to factorIMU is called "AccelerometerReadings" whereas for predict the documented input is called "accelReadings", which also happens to be (not coincidentally?) the name of the output from @doc:imusensor. Those inputs with different names might be a (very, very) subtle indication that they're not the same thing, even though they are both described as "Accelerometer readings" on the respective doc pages.

[Akshai Manchana]

Hi Paul,

I do agree that imuSensor returning opposite polarity measurements is slightly confusing. Which is one of the reasons in motivating us to take a different decision for factorIMU apart from majority of SLAM community using what factorIMU does. Having said this, what imuSensor does is not wrong either. It's all about the use-case. In imuSensor and insfilter the worksflows focus on most requent simulation scenario and IMU-GPS state estimation workflows. In their usecases the current default behaviors fit best. We will plan on improving the doc to make the behavior more visible than simply hiding it in the equations and enhance our tools to support more behaviors choosable as per use-case than restricting the default.

[Paul]

Another choosable behavior for the @doc:imusensor should be to allow the user to specify that the algorithm not add (or subtract as the case may be) g to the acceleration input to from totalAcc. That way the user can use whatever gravity model is appropriate and deal with it themselves rather than be locked in to the model assumed by imusensor, as can be done with the three axis accelerometer model in the Aerospace Blockset.