Papers
Topics
Authors
Recent
Search
2000 character limit reached

LIMOncello: LiDAR–Inertial Odometry on SGal(3)

Updated 4 July 2026
  • 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 SGal(3)\mathrm{SGal}(3) 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

SO(3)×R6,SO(3)\times\mathbb R^6,

where attitude RSO(3)\mathbf R\in SO(3) is decoupled from velocity and position, v,pR3\mathbf v,\mathbf p\in\mathbb R^3 (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

Rk+1=Rkexp([ωk]×Δt), vk+1=vk+(Rkak+g)Δt, pk+1=pk+vkΔt\begin{aligned} \mathbf R_{k+1}&=\mathbf R_k\,\exp\bigl([\boldsymbol\omega_k]_\times\,\Delta t\bigr),\ \mathbf v_{k+1}&=\mathbf v_k + \bigl(\mathbf R_k\,\mathbf a_k + \mathbf g\bigr)\,\Delta t,\ \mathbf p_{k+1}&=\mathbf p_k + \mathbf v_k\,\Delta t \end{aligned}

can drift arbitrarily in unobserved directions. LIMOncello is designed specifically to limit this effect by adopting a state evolution on SGal(3)\mathrm{SGal}(3) 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 SGal(3)\mathrm{SGal}(3) manifold

The IMU-driven state is placed on the $10$-dimensional Special Galilean group

SGal(3)\mathrm{SGal}(3)0

with SGal(3)\mathrm{SGal}(3)1, SGal(3)\mathrm{SGal}(3)2, and SGal(3)\mathrm{SGal}(3)3 a homogeneous time coordinate (Pérez-Ruiz et al., 22 Dec 2025).

The key discrete-time propagation is expressed as

SGal(3)\mathrm{SGal}(3)4

where the right-SGal(3)\mathrm{SGal}(3)5 action is

SGal(3)\mathrm{SGal}(3)6

and

SGal(3)\mathrm{SGal}(3)7

is the wedge map into SGal(3)\mathrm{SGal}(3)8.

The paper’s stated rationale is that this single matrix composition captures the coupling of SGal(3)\mathrm{SGal}(3)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 SO(3)×R6,SO(3)\times\mathbb R^6,0 are obtained by the chain rules cited in the paper.

The LiDAR update is point-to-plane. For each LiDAR point SO(3)×R6,SO(3)\times\mathbb R^6,1, the paper denotes the matched plane by normal SO(3)×R6,SO(3)\times\mathbb R^6,2 and point SO(3)×R6,SO(3)\times\mathbb R^6,3, and uses SO(3)×R6,SO(3)\times\mathbb R^6,4 to extract the spatial pose SO(3)×R6,SO(3)\times\mathbb R^6,5 from SO(3)×R6,SO(3)\times\mathbb R^6,6. The residual is

SO(3)×R6,SO(3)\times\mathbb R^6,7

Stacking all SO(3)×R6,SO(3)\times\mathbb R^6,8 residuals gives

SO(3)×R6,SO(3)\times\mathbb R^6,9

with RSO(3)\mathbf R\in SO(3)0 and Jacobian

RSO(3)\mathbf R\in SO(3)1

The iterated update solves the MAP step as

RSO(3)\mathbf R\in SO(3)2

followed by

RSO(3)\mathbf R\in SO(3)3

Here RSO(3)\mathbf R\in SO(3)4 is the right-Jacobian transporting covariances into the current tangent space, and iteration continues until RSO(3)\mathbf R\in SO(3)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 RSO(3)\mathbf R\in SO(3)6, has up to RSO(3)\mathbf R\in SO(3)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 RSO(3)\mathbf R\in SO(3)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 RSO(3)\mathbf R\in SO(3)9 rather than v,pR3\mathbf v,\mathbf p\in\mathbb R^30, 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 v,pR3\mathbf v,\mathbf p\in\mathbb R^31 ms and v,pR3\mathbf v,\mathbf p\in\mathbb R^32–v,pR3\mathbf v,\mathbf p\in\mathbb R^33 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 v,pR3\mathbf v,\mathbf p\in\mathbb R^34 until the next LiDAR scan is integrated by computing v,pR3\mathbf v,\mathbf p\in\mathbb R^35, updating the nominal state as v,pR3\mathbf v,\mathbf p\in\mathbb R^36, propagating covariance as

v,pR3\mathbf v,\mathbf p\in\mathbb R^37

and storing intermediate poses v,pR3\mathbf v,\mathbf p\in\mathbb R^38 in a buffer for deskewing.

Second, in LiDAR deskewing and downsampling, each raw point v,pR3\mathbf v,\mathbf p\in\mathbb R^39 with timestamp Rk+1=Rkexp([ωk]×Δt), vk+1=vk+(Rkak+g)Δt, pk+1=pk+vkΔt\begin{aligned} \mathbf R_{k+1}&=\mathbf R_k\,\exp\bigl([\boldsymbol\omega_k]_\times\,\Delta t\bigr),\ \mathbf v_{k+1}&=\mathbf v_k + \bigl(\mathbf R_k\,\mathbf a_k + \mathbf g\bigr)\,\Delta t,\ \mathbf p_{k+1}&=\mathbf p_k + \mathbf v_k\,\Delta t \end{aligned}0 is transformed into the world frame using interpolated pose Rk+1=Rkexp([ωk]×Δt), vk+1=vk+(Rkak+g)Δt, pk+1=pk+vkΔt\begin{aligned} \mathbf R_{k+1}&=\mathbf R_k\,\exp\bigl([\boldsymbol\omega_k]_\times\,\Delta t\bigr),\ \mathbf v_{k+1}&=\mathbf v_k + \bigl(\mathbf R_k\,\mathbf a_k + \mathbf g\bigr)\,\Delta t,\ \mathbf p_{k+1}&=\mathbf p_k + \mathbf v_k\,\Delta t \end{aligned}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 Rk+1=Rkexp([ωk]×Δt), vk+1=vk+(Rkak+g)Δt, pk+1=pk+vkΔt\begin{aligned} \mathbf R_{k+1}&=\mathbf R_k\,\exp\bigl([\boldsymbol\omega_k]_\times\,\Delta t\bigr),\ \mathbf v_{k+1}&=\mathbf v_k + \bigl(\mathbf R_k\,\mathbf a_k + \mathbf g\bigr)\,\Delta t,\ \mathbf p_{k+1}&=\mathbf p_k + \mathbf v_k\,\Delta t \end{aligned}2 and Rk+1=Rkexp([ωk]×Δt), vk+1=vk+(Rkak+g)Δt, pk+1=pk+vkΔt\begin{aligned} \mathbf R_{k+1}&=\mathbf R_k\,\exp\bigl([\boldsymbol\omega_k]_\times\,\Delta t\bigr),\ \mathbf v_{k+1}&=\mathbf v_k + \bigl(\mathbf R_k\,\mathbf a_k + \mathbf g\bigr)\,\Delta t,\ \mathbf p_{k+1}&=\mathbf p_k + \mathbf v_k\,\Delta t \end{aligned}3. For each iteration Rk+1=Rkexp([ωk]×Δt), vk+1=vk+(Rkak+g)Δt, pk+1=pk+vkΔt\begin{aligned} \mathbf R_{k+1}&=\mathbf R_k\,\exp\bigl([\boldsymbol\omega_k]_\times\,\Delta t\bigr),\ \mathbf v_{k+1}&=\mathbf v_k + \bigl(\mathbf R_k\,\mathbf a_k + \mathbf g\bigr)\,\Delta t,\ \mathbf p_{k+1}&=\mathbf p_k + \mathbf v_k\,\Delta t \end{aligned}4, the algorithm finds Rk+1=Rkexp([ωk]×Δt), vk+1=vk+(Rkak+g)Δt, pk+1=pk+vkΔt\begin{aligned} \mathbf R_{k+1}&=\mathbf R_k\,\exp\bigl([\boldsymbol\omega_k]_\times\,\Delta t\bigr),\ \mathbf v_{k+1}&=\mathbf v_k + \bigl(\mathbf R_k\,\mathbf a_k + \mathbf g\bigr)\,\Delta t,\ \mathbf p_{k+1}&=\mathbf p_k + \mathbf v_k\,\Delta t \end{aligned}5-NN neighbors in the i-Octree map for each downsampled point, fits a local plane Rk+1=Rkexp([ωk]×Δt), vk+1=vk+(Rkak+g)Δt, pk+1=pk+vkΔt\begin{aligned} \mathbf R_{k+1}&=\mathbf R_k\,\exp\bigl([\boldsymbol\omega_k]_\times\,\Delta t\bigr),\ \mathbf v_{k+1}&=\mathbf v_k + \bigl(\mathbf R_k\,\mathbf a_k + \mathbf g\bigr)\,\Delta t,\ \mathbf p_{k+1}&=\mathbf p_k + \mathbf v_k\,\Delta t \end{aligned}6, computes residuals and Jacobians, and stacks them into Rk+1=Rkexp([ωk]×Δt), vk+1=vk+(Rkak+g)Δt, pk+1=pk+vkΔt\begin{aligned} \mathbf R_{k+1}&=\mathbf R_k\,\exp\bigl([\boldsymbol\omega_k]_\times\,\Delta t\bigr),\ \mathbf v_{k+1}&=\mathbf v_k + \bigl(\mathbf R_k\,\mathbf a_k + \mathbf g\bigr)\,\Delta t,\ \mathbf p_{k+1}&=\mathbf p_k + \mathbf v_k\,\Delta t \end{aligned}7 and Rk+1=Rkexp([ωk]×Δt), vk+1=vk+(Rkak+g)Δt, pk+1=pk+vkΔt\begin{aligned} \mathbf R_{k+1}&=\mathbf R_k\,\exp\bigl([\boldsymbol\omega_k]_\times\,\Delta t\bigr),\ \mathbf v_{k+1}&=\mathbf v_k + \bigl(\mathbf R_k\,\mathbf a_k + \mathbf g\bigr)\,\Delta t,\ \mathbf p_{k+1}&=\mathbf p_k + \mathbf v_k\,\Delta t \end{aligned}8. It then forms

Rk+1=Rkexp([ωk]×Δt), vk+1=vk+(Rkak+g)Δt, pk+1=pk+vkΔt\begin{aligned} \mathbf R_{k+1}&=\mathbf R_k\,\exp\bigl([\boldsymbol\omega_k]_\times\,\Delta t\bigr),\ \mathbf v_{k+1}&=\mathbf v_k + \bigl(\mathbf R_k\,\mathbf a_k + \mathbf g\bigr)\,\Delta t,\ \mathbf p_{k+1}&=\mathbf p_k + \mathbf v_k\,\Delta t \end{aligned}9

followed by

SGal(3)\mathrm{SGal}(3)0

breaking when SGal(3)\mathrm{SGal}(3)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 SGal(3)\mathrm{SGal}(3)2, SGal(3)\mathrm{SGal}(3)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 SGal(3)\mathrm{SGal}(3)4 m tunnel with a single Livox Avia; and R-Campus, a SGal(3)\mathrm{SGal}(3)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 SGal(3)\mathrm{SGal}(3)6 m for LIMO, compared with SGal(3)\mathrm{SGal}(3)7 m for RESPLE and SGal(3)\mathrm{SGal}(3)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 SGal(3)\mathrm{SGal}(3)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 SGal(3)\mathrm{SGal}(3)0 ms mapping time and approximately SGal(3)\mathrm{SGal}(3)1 MB memory usage, versus SGal(3)\mathrm{SGal}(3)2 ms and SGal(3)\mathrm{SGal}(3)3 GB for ikd-Tree, indicate that the mapping backend is integral to the system-level result. Likewise, the choice of SGal(3)\mathrm{SGal}(3)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.

Definition Search Book Streamline Icon: https://streamlinehq.com
References (1)

Topic to Video (Beta)

No one has generated a video about this topic yet.

Whiteboard

No one has generated a whiteboard explanation for this topic yet.

Follow Topic

Get notified by email when new papers are published related to LIMOncello.