LIMOncello: LiDAR–Inertial Odometry on SGal(3)
- LIMOncello is a LiDAR–IMU odometry system that models 6-DoF motion on the 10D SGal(3) manifold, enabling coherent and drift-limited state propagation.
- It integrates an IKFoM-based filtering formulation with an iterated error-state Kalman filter update and point-to-plane LiDAR constraints to enhance accuracy.
- Its dynamic i-Octree mapping backend enables rapid, memory-efficient map updates, outperforming conventional incremental kd-trees for real-time applications.
Searching arXiv for the specified paper and closely related LiDAR–inertial odometry references. First, I’ll look up LIMOncello by arXiv id, then retrieve a few related references such as FAST-LIO2 and IKFoM for contextual citations. LIMOncello, abbreviated in the paper as LIMO, is a tightly coupled LiDAR–Inertial Odometry system that models $6$-DoF motion on the manifold within an iterated error-state Kalman filter backend. Its core design combines three elements: an IMU-driven state on the $10$-dimensional Special Galilean group, an IKFoM-based filtering formulation on manifolds, and a lightweight incremental i-Octree mapping backend. The system is presented as an approach for achieving competitive accuracy together with improved robustness in geometrically sparse environments, while maintaining real-time performance with stable memory growth; an extensible open-source implementation is released at the repository stated in the paper (Pérez-Ruiz et al., 22 Dec 2025).
1. Definition and problem setting
LIMOncello is situated within tightly coupled LiDAR–IMU odometry, where inertial prediction and LiDAR geometric constraints are estimated in a unified backend rather than in loosely staged modules. The paper contrasts this with the common representation of pose and velocity on the compound manifold
where attitude is decoupled from velocity and position, (Pérez-Ruiz et al., 22 Dec 2025).
The stated motivation is low-observability behavior. Under nearly constant velocity and degenerate LiDAR returns, the uncoupled discretization
can drift arbitrarily in unobserved directions. LIMOncello is designed specifically to limit this effect by adopting a state evolution on rather than on a decoupled product space.
A central point is therefore that the method is not defined only by its sensor combination, but by its manifold choice and by the way that choice is integrated into the filter and map update pipeline. This suggests that the contribution is as much geometric and numerical as it is algorithmic.
2. State representation on the manifold
The IMU-driven state is placed on the $10$-dimensional Special Galilean group
0
with 1, 2, and 3 a homogeneous time coordinate (Pérez-Ruiz et al., 22 Dec 2025).
The key discrete-time propagation is expressed as
4
where the right-5 action is
6
and
7
is the wedge map into 8.
The paper’s stated rationale is that this single matrix composition captures the coupling of 9 in a coherent and numerically stable way, and that uncertainty in “when” propagates directly into “where” via the Galilean symmetry. In this formulation, rotational, translational, and temporal effects are not handled as separate updates stitched together afterward; they are embedded in one group action. A plausible implication is that the method targets consistency in the propagation model itself rather than relying only on stronger measurement corrections to suppress drift.
3. IKFoM backend and manifold filtering formulation
LIMOncello builds on the IKFoM framework to filter on manifolds. The state vector is
$10$0
with dimension count
$10$1
This state contains the Galilean motion state, LiDAR-to-IMU extrinsics in $10$2, gyroscope and accelerometer biases, and gravity constrained to $10$3 (Pérez-Ruiz et al., 22 Dec 2025).
Between LiDAR frames, IMU samples $10$4 are integrated under zero-order hold. Nominal propagation is written in unified $10$5–boxplus notation:
$10$6
with increment function
$10$7
Covariance propagation follows
$10$8
where $10$9 and 0 are obtained by the chain rules cited in the paper.
The LiDAR update is point-to-plane. For each LiDAR point 1, the paper denotes the matched plane by normal 2 and point 3, and uses 4 to extract the spatial pose 5 from 6. The residual is
7
Stacking all 8 residuals gives
9
with 0 and Jacobian
1
The iterated update solves the MAP step as
2
followed by
3
Here 4 is the right-Jacobian transporting covariances into the current tangent space, and iteration continues until 5 or a fixed number of steps. In encyclopedic terms, LIMOncello is therefore a manifold IESKF whose update equations are specialized to a Galilean motion state and LiDAR point-to-plane constraints.
4. Incremental i-Octree mapping backend
LIMOncello replaces the usual incremental k-d tree, specifically the ikd-Tree style map structure, with a dynamic octree (Pérez-Ruiz et al., 22 Dec 2025). Each node represents an axis-aligned cubic cell in 6, has up to 7 children, and leaves contain a small point buffer. Child indexing uses Morton codes (Z-order), which the paper identifies as enabling very fast node-address computations.
Insertion proceeds by pushing each point down the tree. If a leaf exceeds a point-count or spatial extent threshold, it is split into 8 children; no reallocation of existing points is done, and no global rebalancing is ever performed. The stated purpose is to avoid the expensive “redistribute-all” step associated with kd-trees. Nearest-neighbor queries use a standard best-first search over octree bounding boxes, with Morton codes accelerating neighbour-cell order. Because the branch factor is 9 rather than 0, the tree is shallow, so search depth is small and bounding-box tests are cheap.
The paper explicitly attributes two practical effects to this design: speed and memory efficiency. The summary comparison reported for mapping is as follows.
| Metric | ikd-Tree | LIMO i-Octree |
|---|---|---|
| Average time | 248 ms | 14.6 ms |
| Memory usage | 10.7 GB | ~120 MB |
An “original i-Octree” baseline is also reported at 1 ms and 2–3 MB. The broader interpretation offered in the paper is that the i-Octree achieves faster updates and substantially lower memory usage than incremental kd-tree style structures without relying on locality-restricted search heuristics. This is significant because the mapping structure is not treated as an auxiliary optimization; it is part of the system’s claim to real-time operation with stable memory growth.
5. End-to-end processing pipeline
The paper gives a four-stage per-frame algorithmic flow for LIMOncello (Pérez-Ruiz et al., 22 Dec 2025).
First, during IMU propagation, each IMU sample 4 until the next LiDAR scan is integrated by computing 5, updating the nominal state as 6, propagating covariance as
7
and storing intermediate poses 8 in a buffer for deskewing.
Second, in LiDAR deskewing and downsampling, each raw point 9 with timestamp 0 is transformed into the world frame using interpolated pose 1. The point cloud is then downsampled voxel by voxel via the i-Octree’s splitting rule.
Third, an iterated IESKF update is performed. The error state and covariance are initialized as 2 and 3. For each iteration 4, the algorithm finds 5-NN neighbors in the i-Octree map for each downsampled point, fits a local plane 6, computes residuals and Jacobians, and stacks them into 7 and 8. It then forms
9
followed by
0
breaking when 1.
Fourth, in map insertion, the newly deskewed LiDAR points are inserted into the i-Octree, in parallel if desired. The output is the updated 2, 3, and map. These four steps repeat on each incoming LiDAR frame. In system terms, the pipeline couples continuous inertial propagation, temporally corrected LiDAR geometry, iterative scan-to-map estimation, and persistent map growth in a single recurring loop.
6. Experimental evaluation, comparative behavior, and interpretation
The reported evaluation covers multiple real-world datasets: Grand-Tour sequences “#Arc_1”, “#Con_1”, “#Con_3”, “#HAUS_1”, and “#Trim_1” with Hesai XT32 plus Novatel CPT7; MCD NTU campus day sequences 01, 02, 10 and night sequences 04, 08, 13 with Livox Mid70 plus VN100; the City Datasets sequence “City02,” described as a 4 m tunnel with a single Livox Avia; and R-Campus, a 5 km bipedal-robot run with Livox Avia (Pérez-Ruiz et al., 22 Dec 2025).
The metrics are Absolute pose error (APE) RMSE over interpolated ground-truth timestamps using evo, failure rate defined by divergence, tunnel end-to-end stability, end-to-end drift on R-Campus, and per-frame mapping time and memory usage. Within this protocol, the paper reports that on Grand-Tour and MCD, LIMO matches or slightly trails the best methods, identified as FAST-LIO2 and RESPLE/I-LIO, in feature-rich scenes, with zero failures. On the City02 tunnel sequence, only LIMO traverses the tunnel stably, while others diverge or undergo unrecoverable drift. On R-Campus, reported end-to-end drift is 6 m for LIMO, compared with 7 m for RESPLE and 8 m for FAST-LIO2.
These results support a specific reading of the system’s performance profile. LIMOncello is not presented as uniformly dominant in all accuracy metrics and all environments; rather, it is presented as competitive in feature-rich scenes and more robust in geometrically sparse or low-observability regimes. That distinction is important because it clarifies the paper’s contribution: the main claim is not that the system always yields the smallest APE, but that the combination of 9 propagation, manifold IESKF, and i-Octree mapping helps limit drift and preserve stability when geometric constraints become weak.
A related misconception would be to treat the i-Octree only as an implementation convenience. The reported 0 ms mapping time and approximately 1 MB memory usage, versus 2 ms and 3 GB for ikd-Tree, indicate that the mapping backend is integral to the system-level result. Likewise, the choice of 4 is not framed as mere mathematical reformulation; it is explicitly tied to coherent discrete-time propagation and drift limitation in low-observability conditions. Taken together, the paper positions LIMOncello as a LiDAR–inertial odometry architecture in which geometric state representation, estimator structure, and map data structure are mutually reinforcing components rather than separable optimizations.