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 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?