Industry Research

Appearance

MA-LIO ​

Related method pages: FAST-LIO and FAST-LIO2, GenZ-ICP and GenZ-LIO (iter 38), GEODE Degenerate LiDAR Benchmark (iter 39), MM-LINS, LIO-SAM, KISS-ICP, Continuous-Time Registration (iter 36), Removert (iter 40), TRLO Dynamic Tracking Removal LiDAR Odometry (iter 41), PIN-SLAM Neural LiDAR Mapping (iter 42), LIR-LIVO (iter 43), Semantic LiW-Odometry (iter 43), FusionPortableV2 Multi-Platform SLAM (iter 40).

Related overview pages: Robust State Estimation and Multi-Sensor Localization Fusion, Aggregated-Map Semantic Segmentation.

Related KB pages: Multi-Sensor Calibration and Observability, Lie Groups SE(3)/SO(3) and Jacobians, Sensor Calibration and Time Synchronization.

Last updated: 2026-05-24

What It Is ​

MA-LIO — "Asynchronous Multiple LiDAR-Inertial Odometry using Point-wise Inter-LiDAR Uncertainty Propagation" — is a tightly coupled LIO system that fuses an arbitrary number of heterogeneous, unsynchronized LiDARs with a single IMU. Two peer-reviewed innovations distinguish it: a per-point inter-LiDAR uncertainty propagation model, and a localization weight adapter that adjusts iKFoM/iESKF update weights on degenerate axes.

Key identifiers:

ItemDetail
arXivhttps://arxiv.org/abs/2305.16792 (submitted 2023-05-26; v2 revised 2023-11-07)
VenueIEEE Robotics and Automation Letters (RA-L), 2023
IEEE document number10138602
Estimated DOI10.1109/LRA.2023.3282722 (derived from IEEE document number; verify on IEEE Xplore before formal citation)
Codehttps://github.com/minwoo0611/MA-LIO (C++ 78%, ROS Noetic, GPL-2.0)
Demo videohttps://www.youtube.com/watch?v=M-GWxY2L_Fs

IMPORTANT — arXiv v2 is the authoritative corrected document. The IEEE RA-L published PDF (document 10138602) contains a reported typo. Any implementation referencing equations from the IEEE PDF should cross-check against arXiv 2305.16792v2 (November 2023).

Authors: Minwoo Jung (PhD candidate, first author), Sangwoo Jung, Ayoung Kim (PI). Affiliation: Robust Perception and Mobile Robotics (RPM) Lab, Department of Mechanical Engineering, Seoul National University (SNU), South Korea.

Executive Summary ​

MA-LIO addresses a practical gap in multi-LiDAR autonomous vehicles: sensors from different manufacturers complete their scans at different rates and accumulate per-point acquisition offsets of 0-100 ms relative to each other. Without hardware synchronization, naively stacking clouds from multiple LiDARs into one rigid frame produces motion blur and cross-LiDAR misalignment. MA-LIO eliminates this constraint by treating every individual point independently — deskewing it using a continuous-time IMU B-spline interpolated at its exact acquisition timestamp, and assigning it a covariance derived analytically from the current state uncertainty, the point's range, and its temporal offset from a reference time.

This per-point covariance enters the iKFoM/iESKF update as measurement noise, so far points and points acquired during high-uncertainty maneuvers are automatically down-weighted. A localization weight adapter then modulates the per-axis IMU-prior weight based on information-matrix eigenvalues, so degenerate axes — the forward direction in a tunnel, the lateral direction in a narrow corridor — lean on the IMU prior rather than on noisy measurement residuals.

MA-LIO has no learned components. It is purely geometric and probabilistic throughout, requiring no labeled training data, no GPU, and no hardware trigger between LiDARs. The reference implementation runs on ROS Noetic (C++) and has been tested on Ouster, Livox, Velodyne, and RoboSense sensors.

Core Technical Idea ​

Multi-LiDAR systems introduce two hard sub-problems simultaneously:

Temporal discrepancy. Different LiDAR models complete their scans at different rates, use different internal clocks, and accumulate per-point offsets of 0-100 ms. Without hardware sync, a naive rigid merge of clouds from two LiDARs introduces motion blur proportional to vehicle speed times temporal offset.

Spatial discrepancy. Each LiDAR has a different mounting pose and a different scan pattern (360-degree spinning, limited-sector solid-state, or multi-beam with mixed coverage). Transforming a point from LiDAR-i to the reference body frame at acquisition time t_i differs from transforming it at scan-end time t_end, and the error grows with vehicle speed and angular rate.

MA-LIO's response is a point-wise uncertainty model: rather than collapsing each LiDAR's scan into a single rigid cloud, every individual point is transformed separately using the body pose interpolated at its exact acquisition timestamp via a continuous-time IMU B-spline. The uncertainty of that transformed point is then derived analytically from state covariance, range, and temporal offset. This per-point covariance flows directly into the iKFoM measurement update, making cross-LiDAR temporal discrepancy a budget entry in the uncertainty model rather than a hard alignment constraint.

Two Core Innovations ​

Innovation 1 — Per-Point Inter-LiDAR Uncertainty Propagation ​

Let T_body(t) be the body pose at time t parameterized by a continuous-time B-spline over IMU measurements. A point p_i from LiDAR L_i acquired at time t_i is projected into the reference frame as:

p_ref = T_body(t_i) * T_body_Li * p_i

where T_body_Li is the pre-calibrated extrinsic (LiDAR-i to body). The propagated uncertainty is:

Sigma_p = J_pose * Sigma_state(t_i) * J_pose^T  +  f(range_i, t_i - t_ref)
  • Sigma_state(t_i) is the state covariance at acquisition time, interpolated from the filter.
  • f(range_i, ...) is a range-dependent noise term: a point at 50 m has larger absolute positional uncertainty than one at 5 m under the same angular noise model.
  • J_pose is the Jacobian of the point transformation with respect to the state (see Lie Groups SE(3)/SO(3) and Jacobians for derivation context).

This is more physically faithful than treating all points in a multi-LiDAR scan as having identical uncertainty. It automatically discounts far points and points acquired during aggressive maneuvers when state covariance is elevated. Critically, it eliminates any strict hardware synchronization requirement: the temporal discrepancy between LiDARs becomes a principled uncertainty contribution rather than an error source that must be eliminated before fusion.

Innovation 2 — Localization Weight Adapter (Degeneracy Handling) ​

In the iESKF update step the innovation and gain are:

z = h(x) - y          (measurement residual)
K = P H^T (H P H^T + R)^{-1}

MA-LIO introduces a per-axis weight lambda that modulates the effective measurement noise R on each translational and rotational axis. The weight is derived from the eigenvalue decomposition of the local information matrix of the point-cloud measurement:

  • Low eigenvalue on a given axis signals degeneracy — the environment provides near-zero geometric constraint along that direction.
  • The localization weight for that axis is increased (the measurement is down-weighted relative to the IMU prior), preventing the filter from chasing noisy residuals.
  • In well-conditioned open areas, all eigenvalues are large, weights are uniform, and the filter trusts measurements normally.

A tunnel or long corridor constrains cross-corridor translation and yaw well, but provides near-zero information along the corridor axis. The localization weight adapter handles this without a hard mode switch or a separate degeneracy detector module, because it operates continuously inside the iESKF loop. This is conceptually related to the GEODE degeneracy metric (see GEODE Degenerate LiDAR Benchmark) and to GenZ-ICP's adaptive weighting (see GenZ-ICP and GenZ-LIO), but implemented at the iESKF update level rather than at the registration residual level.

Operator Mechanics ​

Step-by-Step Pipeline ​

Per IMU sample (100-400 Hz depending on dataset)
  |
  v
[A] IMU integration
    Propagate state + covariance forward on manifold (iKFoM prediction step)

Per LiDAR scan arrival (asynchronous; each LiDAR arrives at its own rate)
  |
  v
[B] Per-LiDAR per-point deskew via CT-IMU B-spline
    For each point p_i with acquisition time t_i:
      T_body(t_i) <- continuous-time IMU B-spline interpolation (NOT linear interp.)
      p_body = T_body(t_i) * T_body_Li * p_i
      Sigma_p = Sigma_state(t_i) propagated through Jacobian + range term

[C] Inter-LiDAR transform with point-wise covariance
    All N LiDARs' points are now in the body frame
    Each carries its own Sigma_p
    Spinning and solid-state patterns treated identically after per-point projection

[D] Point cloud preprocessing
    Voxel downsampling
    Range / intensity filtering
    NOTE: LS-C16 (RoboSense) has documented 0-20 ms per-point timestamp variance;
    authors flag this sensor as unreliable for full CT-IMU deskew benefit

[E] iKFoM / iESKF update
    Map query: nearest neighbor in ikd-tree
    Residual computation: point-to-plane (default)
    Per-point covariance Sigma_p enters R (measurement noise matrix)
    Localization weight lambda applied per axis:
      low-eigenvalue axes get high lambda -> down-weighted toward IMU prior
    Iterated update until convergence

[F] State output
    Body pose (position + rotation on SO(3))
    Velocity, IMU biases, gravity estimate

[G] Map update
    Accepted points inserted into ikd-tree (incremental kd-tree)
    No explicit loop closure; no pose graph backend

Architecture (ASCII Block Diagram) ​

LiDAR 1    LiDAR 2    ...  LiDAR N         IMU
(async)    (async)         (async)           |
   |           |               |             |
   +-----------+---------------+             |
               |                             |
   [ROS approximate-time message filter]     |
               |                             |
   [Per-LiDAR per-point deskew] <-----------+
     T_body(t_i) from CT-IMU B-spline
               |
   [Inter-LiDAR transform + uncertainty propagation]
     p_ref = T_body(t_i) * T_body_Li * p_i
     Sigma_p = f(Sigma_state, range, t_offset)
               |
   [Point cloud preprocessing]
     voxel filter, range filter
               |
   [iKFoM / iESKF update]
     R = block-diag(Sigma_p_1, ..., Sigma_p_M)
     lambda = localization_weight(eigenvalues(H))
     x_new, P_new <- iterated KF on manifold
               |
         +-----+-----+
         |           |
    [Pose out]   [ikd-tree map update]
     SE(3)         incremental kd-tree
                   (no loop closure)

Inputs and Outputs ​

ItemDetail
Required inputsN >= 2 LiDARs (any scan pattern, any manufacturer) + 1 IMU
LiDARs testedOuster OS0-64, OS2-128; Livox Avia, Livox Tele, Livox Horizon; Velodyne HDL-32E, VLP-16; RoboSense LS-C16
IMU rate tested100 Hz (Hilti dataset) to 400 Hz (UrbanNav dataset)
Ground truth sourceSPAN CPT-7 GNSS/INS (proprietary City dataset)
Primary outputPer-step 6-DoF body pose on SE(3)
Secondary outputUnified multi-LiDAR point cloud map in ikd-tree
Output rateAsynchronous per-LiDAR scan arrival; not locked to a fixed rate
Hardware sync requiredNo
Loop closureNo
GPU requiredNo

Training ​

MA-LIO has no learned components. All processing is:

  • Analytical: uncertainty propagation via Jacobians on Lie groups.
  • Model-based: continuous-time IMU B-spline interpolation, iKFoM prediction/update.
  • Rule-based: localization weight derived from eigenvalue decomposition of the information matrix.

No neural network, no labeled data, no GPU. This is a pure geometric and probabilistic method with deterministic outputs for the same inputs.

Benchmarks ​

Datasets Used ​

DatasetLiDARsIMU rateEnvironment
Hilti SLAM Challenge 2021OS0-64 + Livox Horizon100 HzIndoor/outdoor mixed
UrbanNav (Hong Kong)HDL-32E + VLP-16 + LS-C16400 HzHigh-rise urban, tunnels
City Dataset (proprietary SNU)Livox Avia + Livox Tele + OS2-128variesCity sequences (see below)

City Dataset sequences (proprietary, SNU RPM Lab):

SequenceDurationDistanceNotable challenge
City011309 slongMany u-turns and rotations; stresses IMU preintegration and covariance propagation
City02624 smedium400 m tunnel segment; forward-motion degeneracy; localization weight adapter most impactful here
City03688 s4.3 kmDynamic objects; no loop closure until return to start; drift accumulates visibly

Comparison Methods ​

The paper compares against FAST-LIO2 (run per-LiDAR and merged post-hoc), LIO-SAM, and M-LOAM.

VERIFY FLAG: Specific ATE/RMSE numeric values from the paper's comparison tables are not available in the publicly accessible pre-print text or the GitHub README. Readers needing exact numbers must access the IEEE RA-L published PDF (IEEE Xplore document 10138602). Additionally, the IEEE PDF is reported to contain a typo; the arXiv v2 (2305.16792v2, November 2023) is the corrected version. All equation references should be verified against arXiv v2.

Performance Characteristics (from repository narrative and abstract) ​

  • City02 (400 m tunnel) is where the localization weight adapter provides the largest measurable benefit. Without it, forward drift along the corridor axis compounds across the tunnel segment.
  • City01 (many u-turns) stresses IMU preintegration and state covariance propagation rather than degeneracy per se.
  • City03 (4.3 km with dynamics) demonstrates accumulated drift without loop closure; a pose graph backend would be needed for production-quality maps at this scale.
  • LS-C16 (RoboSense) shows 0-20 ms per-point timestamp variance. MA-LIO's uncertainty model flags this but cannot fully compensate; authors recommend avoiding this sensor in high-precision deployments.

Comparison Table ​

DimensionLIO-SAMFAST-LIO2M-LOAMMA-LIOMM-LINSGenZ-LIO
LiDAR count112+2+multi-modal1
Sync requirementhardware synchardware sync (single)hardware sync preferrednone (asynchronous)hardware sync assumedhardware sync (single)
IMU integrationfactor graph (GTSAM)iKFoM / iESKFfactor graphiKFoM / iESKFESIKFESIKF
Point uncertaintynonehomogeneousnoneper-point (range, time, state cov)none statednone
Degeneracy handlingnone explicitnonenonelocalization weight (eigenvalue)noneadaptive hybrid residual (GenZ)
Loop closureyes (pose graph)nononoyesno
Map backendfactor graph mapikd-treelocal mapikd-treefactor graph mapikd-tree variant
FOV discrepancyn/an/ahandled by overlap requirementper-point CT projectionn/an/a
Trainingnonenonenonenonenonenone
VenueIROS 2020IEEE T-RO 2022ICRA 2021IEEE RA-L 2023RA-L / IROS 2023pre-print 2026
Codeopenopenopenopen (GPL-2.0)partialpending
Drift accumulationreduced (loop)yes (no loop)yes (no loop)yes (no loop)reduced (loop)yes (no loop)
Calibration burdensingle LiDAR+IMUsingle LiDAR+IMUmulti-LiDAR+IMU + overlapmulti-LiDAR+IMU extrinsicsmulti-sensorsingle LiDAR+IMU

Key Paradigm Differences ​

MA-LIO vs FAST-LIO2 (single-LiDAR baseline): FAST-LIO2 is the direct single-LiDAR ancestor — same iKFoM/iESKF framework, same ikd-tree map. MA-LIO extends FAST-LIO2's update logic to accept N heterogeneous LiDARs with per-point covariances. FAST-LIO2 has no degeneracy weighting; MA-LIO adds the localization weight adapter. See FAST-LIO and FAST-LIO2.

MA-LIO vs M-LOAM (multi-LiDAR, synchronous): M-LOAM requires inter-LiDAR FOV overlap to estimate cross-LiDAR extrinsic covariance; MA-LIO requires no overlap and works with complementary-FOV configurations. M-LOAM is synchronous; MA-LIO is asynchronous. M-LOAM uses a factor graph backend; MA-LIO uses iKFoM.

MA-LIO vs MM-LINS (multi-modal, loop closure): MM-LINS targets camera+LiDAR+IMU fusion and requires hardware synchronization for camera shutter alignment. MM-LINS includes loop closure and a pose graph, which MA-LIO does not. Different problem scope: MM-LINS trades sensor breadth for synchronization requirements; MA-LIO trades loop closure for asynchronous flexibility. See MM-LINS.

MA-LIO vs LIO-SAM (single-LiDAR + loop closure): LIO-SAM adds loop closure and a GTSAM pose graph, significantly reducing long-term drift; MA-LIO has no loop closure. For large-scale mapping tasks, LIO-SAM or adding a loop-closure backend to MA-LIO is necessary. See LIO-SAM.

MA-LIO vs GenZ-LIO (degeneracy-aware single-LiDAR): GenZ-LIO's degeneracy handling is at the ICP residual level via continuous adaptive blending of point-to-plane and point-to-point residuals, requiring no explicit detector or mode switch. MA-LIO's is at the iESKF update level via per-axis localization weights derived from information-matrix eigenvalues. Both address degenerate environments; GenZ-LIO handles single-sensor cleanly; MA-LIO adds multi-LiDAR asynchrony. The two approaches are complementary: GenZ-LIO's residual blending philosophy could in principle be grafted onto MA-LIO's multi-LiDAR framework. See GenZ-ICP and GenZ-LIO.

LOAM (2014, Zhang & Singh)
  -> LOAM variants -> LIO-SAM (2020, IROS)

FAST-LIO (2021, HKU MARS Lab)
  -> FAST-LIO2 (2022, IEEE T-RO) [iKFoM, ikd-tree, single LiDAR]
       |
       +-> MA-LIO (2023, SNU RPM) [multi-LiDAR, async, per-point covariance, localization weight]
       |
       +-> GenZ-LIO (2026, POSTECH CoCEL) [degeneracy residual blending, single LiDAR]

M-LOAM (2021, HKUST) [multi-LiDAR factor graph, synchronous]
  -> comparison target for MA-LIO

Continuous-time LIO / CT-ICP line
  -> CT-IMU B-spline interpolation technique reused in MA-LIO per-point deskew
     (see Continuous-Time Registration, iter 36)

Multi-LiDAR LIO line:
  M-LOAM (2021) -> MA-LIO (2023) -> MM-LINS (2023)

Degeneracy-aware LIO line:
  X-ICP -> GenZ-ICP (2025) -> GenZ-LIO (2026)
  GEODE benchmark (iter 39) evaluates methods across this line
  MA-LIO localization weight adapter: independent parallel contribution

MA-LIO sits at the intersection of three lines of work: the iKFoM/FAST-LIO2 framework (HKU MARS Lab) for tight IMU coupling; the continuous-time IMU modeling tradition for per-point deskewing; and the multi-LiDAR factor graph tradition (M-LOAM) that it replaces with an iKFoM formulation. The localization weight adapter is a novel contribution not present in any of these ancestors. For the iKFoM library specifically, MA-LIO depends on the iKFoM implementation by Yang Ren (same library used by FAST-LIO2).

Strengths ​

  1. Asynchronous multi-LiDAR without hardware sync. This is the headline contribution. Any combination of LiDARs — 360-degree spinning, limited-FOV solid-state, or mixed — can be fused without PPS or hardware trigger wiring between units. This is the largest practical advantage over M-LOAM and synchronous-fusion alternatives.

  2. Principled per-point uncertainty model. Per-point covariance is derived analytically from state uncertainty, range, and acquisition time. This is more honest than homogeneous weighting and naturally down-weights far and uncertain points without a hand-tuned threshold.

  3. Degeneracy awareness inside the update step. The localization weight adapter prevents divergence along degenerate axes (tunnels, corridors, long-wall environments) without requiring a hard mode switch or a separate degeneracy detector. It operates continuously and smoothly inside the iESKF loop.

  4. Vendor-agnostic hardware compatibility. Tested on Ouster, Livox (three models), Velodyne, and RoboSense. Any LiDAR that provides per-point timestamps should work with configuration changes only — no sensor-specific code paths are needed beyond the per-LiDAR YAML configuration and callback registration.

  5. No training required. Rule-based and analytical throughout. No labeled data needed for operation, adaptation, or domain transfer.

  6. Open code with ROS Noetic integration. C++ implementation at GitHub minwoo0611/MA-LIO. Researchers and engineers can run it on their own multi-LiDAR setups with configuration-only changes for different sensor combinations.

Failure Modes and Limitations ​

No Loop Closure or Pose Graph Backend ​

MA-LIO is a pure odometry system. Drift accumulates monotonically in long traversals. City03 (4.3 km) demonstrates this: large accumulated error by the end of the sequence. For large-scale mapping, a pose graph backend (SC-PGO, GTSAM with loop factors, or GPS-anchored factor graph) must be added. This is standard practice for any odometry-only LIO method, but MA-LIO provides no such component.

Extrinsic Calibration Sensitivity ​

Multi-LiDAR systems require accurate inter-LiDAR extrinsics (translation + rotation between each LiDAR pair). MA-LIO's uncertainty model propagates calibration uncertainty implicitly through the state covariance, but poorly calibrated extrinsics introduce a systematic bias that the model cannot distinguish from legitimate measurement noise. Accurate calibration is a prerequisite. See Multi-Sensor Calibration and Observability and Sensor Calibration and Time Synchronization.

Per-Point Timestamp Quality ​

The method depends on reliable per-point acquisition timestamps. LiDARs that do not provide per-point timestamps, or that have coarse 10+ ms timestamp bins, cannot benefit from the full continuous-time deskewing. The LS-C16 (RoboSense) has documented 0-20 ms per-point variance that the authors flag as unreliable. This is a sensor-specific limitation, not an algorithmic one. Production deployments should prefer Ouster (per-point timestamps at full spin rate) or Livox (per-point timestamps at full sample rate) over sensors with coarse timestamp resolution.

Compute Overhead from Multiple LiDARs ​

Processing N LiDARs increases point throughput by roughly N times. For three LiDARs (Avia + Tele + OS2-128), the combined point rate can exceed 500k points per second. Voxel downsampling mitigates this, but the ikd-tree update and nearest-neighbor search scale with map size and point rate. No real-time latency figures are published in the publicly accessible materials. This should be profiled on the target hardware platform before deployment.

Shared Degeneracy Across All LiDARs ​

Adding more LiDARs improves degeneracy resilience when different sensors see complementary geometry. In a perfectly featureless tunnel with uniform walls visible from all sensors simultaneously, all LiDARs see equally degenerate geometry. Wider FOV does not synthesize geometric information that is genuinely absent. The localization weight adapter correctly falls back to the IMU prior in this case, preventing divergence, but accumulated IMU-only drift during long degenerate segments is not eliminated.

Limited Public Evaluation Scope ​

The comparison in the paper is on three datasets with a modest set of baselines (FAST-LIO2, LIO-SAM, M-LOAM). No large-scale standardized multi-LiDAR benchmark equivalent to KITTI-360 or nuScenes for multi-LiDAR configurations was used. The proprietary City dataset sequences are informative (especially City02 for tunnel degeneracy) but ground-truth quality and exact ATE numbers are not in the publicly readable materials and should be treated as indicative until independently reproduced.

IEEE Version Typo ​

The IEEE RA-L published version (document 10138602) is reported to contain a typo. The corrected content is in the arXiv v2 paper and the GitHub README. Any implementation referencing equations from the IEEE PDF must cross-check against arXiv 2305.16792v2.

Domain Fit ​

DomainRelevanceKey Consideration
Airside (apron tractors, deicing trucks, baggage tugs)HighMulti-LiDAR retrofit without hardware sync; corridor degeneracy weight for taxiways
Warehouse / logistics yardMedium-HighIndoor corridors benefit from localization weight; loop closure needed for large footprints
Mining / constructionMediumSensor heterogeneity and rough terrain; calibration stability under vibration
Road AV (urban/highway)MediumSingle-LiDAR FAST-LIO2 often sufficient; MA-LIO adds value when multi-LiDAR is already in hardware
Port operationsMediumSimilar to airside; wide open areas reduce degeneracy benefit
Agriculture (open-field)Low-MediumOpen fields rarely degenerate; single-LiDAR simpler
Delivery robotsLowTypically single-LiDAR; compute budget too tight for N-LiDAR point throughput

Aggregated-Map Suitability ​

Relevance to Airside Aggregated Mapping ​

Airside operational vehicles — apron tractors, deicing trucks, baggage tugs, follow-me vehicles — commonly carry two or more LiDARs at different mounting heights and orientations to achieve 360-degree coverage around the vehicle body and to see under aircraft wings. These sensors are often from different manufacturers and are rarely synchronized at the hardware level outside OEM-integrated AVs.

MA-LIO is directly applicable to this configuration:

  • Asynchronous multi-LiDAR fusion eliminates the need for PPS or hardware trigger wiring between LiDAR units, which simplifies retrofit installation on legacy vehicles.
  • Per-point uncertainty propagation correctly handles the fact that a point from a roof-mounted Ouster and a bumper-mounted Livox acquired at slightly different vehicle attitudes have different positional confidence. The model assigns appropriate covariances without requiring manual tuning per sensor.
  • The localization weight adapter is directly relevant to taxiway and runway corridor geometry. A vehicle driving along a taxiway centerline faces the same single-axis degeneracy as the 400 m tunnel evaluated in City02.
  • Vendor-agnostic design allows mixing of existing LiDAR inventory without requiring uniform hardware, which is common in retrofit scenarios.

Complementary Role in the Pipeline ​

MA-LIO is the online LIO and degeneracy-aware front-end layer. It complements the following iter-series methods in the aggregated-map pipeline:

  • GEODE Degenerate LiDAR Benchmark (iter 39): provides the evaluation framework for degenerate-environment performance. MA-LIO's City02 tunnel performance should be re-evaluated using GEODE-style degeneracy metrics for fair comparison against other methods.
  • GenZ-ICP and GenZ-LIO (iter 38): addresses degeneracy via residual blending for a single LiDAR. For airside vehicles with multiple LiDARs, MA-LIO's asynchronous multi-LiDAR handling fills the gap that GenZ-LIO does not address. The two are complementary: GenZ-LIO's residual blending philosophy could in principle be integrated into MA-LIO's multi-LiDAR iKFoM framework.
  • Removert (iter 40) and TRLO (iter 41): offline post-pass dynamic removal tools that operate on the map produced by the online front-end. The pipeline is: MA-LIO online front-end -> saved point cloud sessions -> Removert/TRLO post-pass -> aggregated static map.
  • FusionPortableV2 (iter 40): multi-platform dataset that could provide additional public evaluation ground truth for multi-LiDAR configurations.

Limitations for Production Aggregated Mapping ​

  • Drift accumulation without loop closure makes MA-LIO unsuitable as a standalone system for large-area apron mapping (typical apron footprint 0.5-5 km²). A session-level loop closure backend (SC-PGO, GPS-anchored factor graph) must be added.
  • Calibration quality between LiDARs mounted on operational vehicles (vibration, thermal expansion during deicing operations) needs active monitoring or online refinement — static calibration degrades over time.
  • Compute budget must be validated for the target platform. The Orin AGX is the recommended platform for LIO-class workloads; three-LiDAR MA-LIO has not been publicly profiled on Orin.
  • For large-scale airside surveys, the full pipeline is: MA-LIO (online front-end) + session-level loop closure backend + Removert or DUFOMap (offline static extraction post-pass) -> aggregated semantic map ready for segmentation (see Aggregated-Map Semantic Segmentation).

Implementation Notes ​

Software Dependencies ​

  • iKFoM library (Yang Ren): the core iterated Kalman filter on manifold. MA-LIO extends this library's update step with per-point covariances and the localization weight.
  • ikd-tree: incremental k-d tree from the FAST-LIO2 ecosystem. Same data structure as FAST-LIO and FAST-LIO2.
  • Livox ROS driver: required for Livox solid-state LiDARs.
  • ROS Noetic (Ubuntu 20.04): reference environment. ROS 2 port is not provided in the public repository.
  • License: GPL-2.0. Product teams must evaluate licensing implications before embedding in commercial systems.

Hardware Stack Suggestions (Airside Retrofit) ​

  • 2-3 LiDARs: one Ouster OS1-128 or OS2-128 (360-degree spinning) on roof; one or two Livox Mid-360 or Livox Avia (solid-state, forward/rear coverage) at bumper level.
  • IMU: internal Ouster IMU (6-DoF, 100-200 Hz) or external VectorNav VN-100 (200-800 Hz). Higher IMU rate improves CT-IMU B-spline interpolation quality and deskew accuracy.
  • Compute: NVIDIA Jetson AGX Orin (recommended platform for LIO-class workloads per project CLAUDE.md). Real-time performance on Orin with three LiDARs is unconfirmed in public benchmarks and must be profiled.

ROS Integration Sketch ​

bash
# Dependencies
sudo apt install ros-noetic-livox-ros-driver

# Build
mkdir -p catkin_ws/src && cd catkin_ws/src
git clone https://github.com/minwoo0611/MA-LIO
cd .. && catkin_make

# Launch (2-LiDAR example)
roslaunch ma_lio mapping_two_lidar.launch

Configuration Points for Multi-LiDAR Adaptation ​

Per the GitHub README, five code elements must be adapted when changing LiDAR count or sensor types:

  1. YAML configuration file (extrinsics, sensor parameters per LiDAR).
  2. ROS message filter sync policy (approximate-time sync, queue size calibration).
  3. Synchronizer initialization (subscriber count must match LiDAR count).
  4. Callback function (per-LiDAR scan handler registration).
  5. iKFoM state manifold definition (extrinsic calibration states added per additional LiDAR).

Calibration Pipeline ​

Inter-LiDAR extrinsic calibration should use a dedicated tool before running MA-LIO. Candidate tools: motion-based calibration (MLIDAR_calibration), direct_visual_lidar_calibration (if cameras are present), or targetless LiDAR-LiDAR calibration using mutual information. See Multi-Sensor Calibration and Observability and Sensor Calibration and Time Synchronization.

Sources ​

Public research notes collected from public sources.

Copyright © 2026 kvynlim