IMUFactor: body_T_sensor with a large lever arm

[Brice Rebsamen]

Hello

Even though the IMU factor accepts a transform between the sensor (the
IMU) and the body (where we do the state estimation), this becomes
less accurate as the lever arm becomes large. This is because an
accurate transformation of the acceleration measurements from one
frame to another (on the same rigid body) requires rotational
accelerations, which are typically not measured by the IMU.

For maximum accuracy, what we did was to estimate the pose/vel state
of our mobile at the IMU, and transform all our other measurements
(e.g. from the GPS) to the IMU's frame. And then transform the
estimated state back to body frame for pose consumers.

However, now we'd like to incorporate a secondary IMU, for redundancy,
which is unfortunately located a bit far from the primary one (about
1m), meaning that this lever arm issue is becoming non-insignificant
(from our experiments so far, barring any mistake we may have made).

So I was thinking that the IMU factor would handle this better if
instead of applying the body_T_sensor transform on the IMU
measurements before preintegration, it was applying it to the
estimated state during error evaluation. i.e. for the pose part
something like this: `(pose_i * body_T_sensor) * preint_ij = (pose_j *
body_T_sensor)`. And for velocity `transform(vel_i, body_T_sensor,
omega_i, omega_bias_i) + preint_vel_ij = transform(vel_j,
body_T_sensor, omega_j, omega_bias_j)` where this `transform` function
transforms the velocity from one frame to the other... In other words,
the IMU factors would form a graph that estimates the pose/vel state
of the IMU, and that graph would be connected to the main graph, which
estimates the pose/vel state of the body using other sensors, via a
rigid transform link...

So my questions are:
1- why isn't the IMU factor designed this way? i.e. was this ever
considered but then not pursued because of some maths issue that I am
not seeing? (I haven't yet spent the time to figure the maths
properly). In other words, does this seem doable (without having to
rewrite the whole preintegration paper), or doomed to fail?
2- Is there an alternative way to add multiple IMUs to the same graph?
3- Am I over-estimating this lever arm effect? In our experiments,
adding a new IMU to the graph works well when it is close to the first
one (a few cms), but fails when it's about 1m away. But it's always
possible that we have over issues (bugs) at play in our experiment...

Regards
Brice Rebsamen

[Michał Nowicki]

Hi,

We once had a spare IMU and failed to make significant gains, so I am happy to share my findings.

2. We were looking at Sandipan Das works with Maurice Fallon (https://arxiv.org/pdf/2210.01154, https://arxiv.org/pdf/2302.14735) that create a single virtual IMU based on multiple IMUs and then do a single IMU preintegration in the IMU frame as you currently do. We may have had too small a arm to see improvements but we were also worried that the IMU biases are estimated just once for the virtual IMU . We saw no clear way of estimating separate biases per each IMU in this approach.

There is also great work by MIMC-VINS (https://arxiv.org/pdf/2006.15699), which effectively tracks the state of each IMU to enable online calibration and shows that these multi-IMU gains should be expected.

3. We had the same experience in sim. A few cm is ok, but meters are not ok. We concluded that it was all about missing rotational velocity that starts to impact when moving between coordinate systems. Happy to be proved wrong here.

1. It looks doable I would worry that estimating separate rotational velocities for each IMU could disrupt some transformations of velocities/covariances leading to some noise correlation. You never know until you try.

Best,
Michal Nowicki

[Suresh Kannan]

Hi Bruce, would you be able to share your learnings on this issue of the ImuFactor and a large lever arm. I suspect it would mean the preintegration manufacturer would have to be extended. Is this true?

[Suresh Kannan]

The autocorrected word  "manufacturer" in my previous message should really mean, do you think the ImuFactor would have be extended to include a large lever arm, or can it be composed using existing factors somehow.

---

From: gtsam...@googlegroups.com <gtsam...@googlegroups.com> on behalf of Suresh Kannan <kan...@nodein.com>
Sent: Tuesday, May 27, 2025 3:13 PM
To: gtsam users <gtsam...@googlegroups.com>
Subject: [GTSAM] Re: IMUFactor: body_T_sensor with a large lever arm

 

--
You received this message because you are subscribed to a topic in the Google Groups "gtsam users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gtsam-users/nG_B_-5VDxA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gtsam-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/gtsam-users/35608a88-abd8-4a6a-abdc-84389cb9a13cn%40googlegroups.com.