A Post-Processing Smoothing Trick Cuts LiDAR Odometry Jitter by Up to 70% Without Touching the Estimator

Cubic spline interpolation over a sliding window of SGal(3) poses tames short-horizon oscillation in LiDAR-inertial odometry — a bolt-on fix validated across 17 sequences on three public benchmarks.

Imagine you're watching a GPS dot on your phone navigate a winding road. The dot knows roughly where you are, but it jitters — hopping a meter left, then right, then back — even though your car is moving smoothly. Now imagine a second layer that watches the last few GPS fixes, fits a smooth curve through them, and reads off a position slightly behind the newest fix. The curve can't hallucinate future positions because it only interpolates within what it's already seen. That's CT-SGAL-LIO in a sentence: a causal smoothing layer that sits on top of an existing LiDAR-inertial odometry (LIO) estimator and irons out short-horizon jitter without altering the estimator's internals. The committed claim: you can bolt a continuous-time cubic trajectory refinement onto the discrete SGal(3) posterior of a LiDAR-inertial estimator, evaluate it at a small fixed lag so it's interpolation not extrapolation, and dramatically improve relative trajectory error (RTE) without sacrificing global accuracy. This is not a new estimator — it's a post-processing wrapper that treats any SGal(3)-based LIO as a black box. The baseline here is the authors' own prior work — SGal(3)-based discrete LIO — which itself operates on richer state manifolds than the SE(3) world most competitors live in. Against this self-baseline, improvements are substantial: RTE drops by up to 70% on GRAND-TOUR sequences, 9.9–51.1% across all seven GEODE sequences, and posterior jumps shrink by 85.4% on a 19.5-minute campus run with only 4.7 mm drift penalty. The catch is that the comparison is entirely internal. No head-to-head numbers are given against the leading external competitors — FAST-LIO2, Faster-LIO, or Point-LIO — on relative trajectory metrics. The paper implicitly inherits whatever global accuracy its SGal(3) base achieves, but the smoothing claim is validated only as a delta over that base. Architecturally, this belongs to the continuous-time trajectory estimation family — specifically B-spline or polynomial fitting over Lie-group manifolds — but stripped to its minimal useful form. Rather than jointly optimizing raw LiDAR scans and IMU data in continuous time (the CLINS / CT-ICP approach, which adds latency and fragility during aggressive motion), the authors fit a cubic over a bounded window of already-corrected posterior poses and query at a fixed lag. The key structural choice is that the query point always lies inside the observation window, guaranteeing interpolation. This makes the module lightweight and causal — no lookahead, no re-optimization of the underlying filter. Integrity is mixed. The three benchmarks — GRAND-TOUR, MCD, and GEODE — are public and community-recognized, which is good. All 17 sequences are reported, not cherry-picked subsets. But validation is entirely self-referential: the improvement is measured against the authors' own discrete estimator, not against the field's strongest relative-accuracy competitors. There's no ablation separating the cubic fit from simpler alternatives (linear interpolation, moving average), and no analysis of failure modes under different lag values or window sizes. Code is promised but not yet released. The milestone to watch is whether this smoothing module generalizes beyond SGal(3) estimators to the broader LIO ecosystem — FAST-LIO2 and its descendants — and whether it holds up on sequences with sustained aggressive motion where the fixed-lag assumption might break down. The practical threshold is sub-centimeter RTE at 100+ Hz on a drone doing aggressive indoor flight, which would make this relevant for real-time planning and control, not just mapping. The obvious experiment not run: applying CT-SGAL-LIO's refinement layer to FAST-LIO2 or Point-LIO and reporting comparative RTE. The authors certainly have access to these codebases. The most charitable read is that they're saving this for a follow-up or that the SGal(3) manifold structure is load-bearing for the cubic fit and doesn't trivially port to SE(3) estimators. The less charitable read is that the improvement might shrink or vanish on estimators with already-smoother posteriors.