PaperlayerView exact revision on arXiv

Source-linked AI summary

LOCUS: A Multi-Sensor Lidar-Centric Solution for High-Precision Odometry and 3D Mapping in Real-Time

M. Palieri, B. Morrell, A Thakur, K. Ebadi, J. Nash, A. Chatterjee, C. Kanellakis, L. Carlone, C. Guaragnella, A. Agha-mohammadi

arXiv:2012.14447v1cs.RO

TL;DR

Perceptually challenging conditions make accurate odometry difficult, and failures in fused sensor modalities can degrade or compromise odometry performance. LOCUS combines multi-stage lidar scan matching with a health-aware module for loosely integrating additional sensing modalities. LOCUS demonstrated top-class accuracy, computation time, and sensor-failure robustness; Urban Alpha 2 mean APE was 0.586 m and maximum APE was 2.599 m.

  • Problem

    Perceptually challenging conditions make accurate odometry difficult, and failures in fused sensor modalities can degrade or compromise odometry performance.

    Source: §I · p. 1

  • Method

    LOCUS combines multi-stage lidar scan matching with a health-aware module for loosely integrating additional sensing modalities.

    Source: 1) Sensor integration module · p. 3, §IV · p. 8

  • Results

    LOCUS demonstrated top-class accuracy, computation time, and sensor-failure robustness; Urban Alpha 2 mean APE was 0.586 m and maximum APE was 2.599 m.

    Source: §IV · p. 8, SUMMARY OF ACCURACY ANALYSIS RESULTS… · p. 8

  • Takeaways & Limitations

    LOCUS ran in real time on two robots exploring the Satsop power plant, as part of the CoSTAR solution that achieved first place in the Urban Circuit.

    Source: §IV · p. 8

Abstract

from arXiv · show

A reliable odometry source is a prerequisite to enable complex autonomy behaviour in next-generation robots operating in extreme environments. In this work, we present a high-precision lidar odometry system to achieve robust and real-time operation under challenging perceptual conditions. LOCUS (Lidar Odometry for Consistent operation in Uncertain Settings), provides an accurate multi-stage scan matching unit equipped with an health-aware sensor integration module for seamless fusion of additional sensing modalities. We evaluate the performance of the proposed system against state-of-the-art techniques in perceptually challenging environments, and demonstrate top-class localization accuracy along with substantial improvements in robustness to sensor failures. We then demonstrate real-time performance of LOCUS on various types of robotic mobility platforms involved in the autonomous exploration of the Satsop power plant in Elma, WA where the proposed system was a key element of the CoSTAR team's solution that won first place in the Urban Circuit of the DARPA Subterranean Challenge.

I. INTRODUCTION

Perceptually challenging environments make reliable odometry difficult, while failures in fused sensing modalities can undermine performance. LOCUS is introduced against a background of feature-, grid-, and dense-based scan matching and sensor-fusion approaches.

I. INTRODUCTION

  • LOCUS targets accurate, reliable odometry in perceptually challenging conditions where sensory failures can compromise performance.The introduction presents it as a lidar odometry system for accurate real-time operation and robustness to intermittent or faulty measurements.Source: §I · p. 1

A. Related Works

  • Feature-based methods match salient scan features, while grid-based methods match occupancy probability densities.Feature examples include planes and edges –; probability-grid matching may use Newton’s method.Source: A. Related Works · p. 2
  • Dense methods align large subsets of scan points; GICP uses local surface normals for point-to-point and point-to-plane matching, and LOCUS falls in this category.Using the full point cloud can be computationally expensive, so most approaches select a subset.Source: A. Related Works · p. 2
  • Sensor fusion can complement lidar in self-similar environments or during agile motion, with IMUs, VIO, WIO, and KIO supplying motion information.LOCUS uses loose coupling, which can provide a near-optimal prior for scan matching and reduce computation, –,,,,.Source: A. Related Works · p. 2

B. Method Highlights and Contributions

LOCUS combines adaptable, fail-safe odometry architecture with environment-specific knowledge and field evaluation. Its preprocessor corrects, merges, and filters point clouds to prepare them for matching.

B. Method Highlights and Contributions

A. Point Cloud Preprocessor

  • Motion-distortion correction adjusts lidar points for robot motion during a scan, using an available IMU or odometry source.The correction is particularly important for distant points during high-rate rotations; the selected source depends on reliable availability and calibration.Source: A. Point Cloud Preprocessor · pp. 2–3
  • For multiple lidars, the preprocessor merges corrected clouds using known sensor transforms, then voxel-grid and random filters reduce data volume and computational load.The filter stages can be tuned or activated independently; the tests use a 0.1 m voxel size and 90% random downsampling.Source: A. Point Cloud Preprocessor · p. 3

B. Scan Matching Unit

The scan-matching unit estimates robot motion through GICP scan-to-scan and scan-to-submap matching. A health-aware sensor module selects and interpolates the best available external motion estimate for scan matching.

B. Scan Matching Unit

  • GICP scan-to-scan and scan-to-submap matching estimates the robot’s 6-DOF motion between consecutive lidar acquisitions.Source: B. Scan Matching Unit · p. 3

1) Sensor integration module:

  • Odometry sources and raw IMU measurements are transformed into the robot frame, then a health monitor selects a healthy input from a priority queue.The implementation marks an input healthy when its message rate exceeds 1 Hz; the queue ranks sources based on prior testing for the robot and similar environments.Source: 1) Sensor integration module · p. 3
  • The module buffers and interpolates the highest-priority healthy source’s pose at lidar timestamps; odometry supplies rotation and translation, while the IMU supplies rotation only.The resulting interval transform is used as the sensor-integration output.Source: 1) Sensor integration module · p. 3

2) Scan-to-scan:

In scan-to-scan matching, GICP estimates the transform between consecutive lidar scans by minimizing residual error for corresponding points. The sensor module’s estimate initializes matching when available; otherwise the system starts from identity rotation and zero translation.

2) Scan-to-scan:

  • GICP estimates the transform between consecutive lidar scans by minimizing residual error between corresponding points.Source: 2) Scan-to-scan · p. 3
  • When sensor integration succeeds, its transform estimate initializes GICP.Source: 2) Scan-to-scan · p. 3
  • If all sensors fail, GICP starts with identity rotation and zero translation, reverting the system to pure lidar odometry.Source: 2) Scan-to-scan · p. 3

3) Scan-to-submap:

LOCUS refines scan-to-scan motion by matching the current scan against a local submap. The resulting motion estimate updates the robot pose in the global frame.

3) Scan-to-submap:

  • The global map is a point cloud stored in an octree and accumulated every 1 m of translation or 30° of rotation.The octree minimum resolution is 0.001 m.Source: 3) Scan-to-submap · p. 3
  • The refined motion between consecutive lidar acquisitions updates the robot pose in the global frame.The generated odometry integrates the computed incremental transforms.Source: 3) Scan-to-submap · p. 4
  • Incremental initialization from input odometry through scan-to-scan and scan-to-map alignment improves accuracy and computational speed.A good initial estimate reduces convergence to a sub-optimal local minimum and can reduce iteration count.Source: 3) Scan-to-submap · p. 4

4) Notes on multi-threading:

LOCUS combines configurable processing and platform adaptations with flat-ground handling and staged field evaluation. The ablation study finds motion-corrected points essential, while filtering limits data volume and computation.

4) Notes on multi-threading:

  • Multithreaded GICP accelerates scan matching by parallelizing normal computation, which accounts for over 70% of process computation time.Evaluations used four threads unless otherwise stated.Source: 4) Notes on multi-threading · p. 4

C. Environment Adaptation: Flat Ground Assumption

  • The flat-ground assumption zeros Z movement, roll, and pitch in a gravity-aligned frame to limit drift and attitude error.It can be activated using prior context or an IMU monitor that detects near-zero roll and pitch over time.Source: C. Environment Adaptation: Flat Ground… · p. 4

D. Adaptation for Different Platforms

  • LOCUS exposes adjustable lidar count, filtering, GICP thread count, and initial-transform measurements to accommodate different platforms.The paper demonstrates this flexibility on two robotic platforms.Source: D. Adaptation for Different Platforms · p. 4

III. FIELD EXPERIMENTS

  • Field evaluations used three 60-minute Husky datasets with lidar, IMU, and WIO data, plus live tests across heterogeneous platforms.The datasets cover feature-poor urban spaces and repetitive mine geometries, with substantial vibration and sudden acceleration; trajectories were evaluated against DARPA-provided ground truth.Source: §III · p. 4

A. Ablation Study

  • Motion-corrected points are essential in the Urban Alpha ablation, while filtering reduces data volume and computational load.LOAM-type feature filtering can improve accuracy but uses 25% more CPU than the baseline and was not real-time on the tested system; similar trends were observed on Urban Beta.Source: A. Ablation Study · p. 4, Figure 3 · p. 5

B. Evaluation Against the State-of-the-Art

The evaluation compares open-source lidar odometry systems across alignment and sensor-integration approaches, using accuracy, robustness, and efficiency criteria. Inputs were adjusted for each algorithm, and LIO-SAM could not be run on the Urban datasets.

B. Evaluation Against the State-of-the-Art

  • The comparison spans open-source systems selected to cover different alignment and sensor-integration methods.Visual-odometry-integrating systems were not included because open-source implementations were not readily available for testing.Source: B. Evaluation Against the… · p. 5
  • Algorithms are evaluated holistically on accuracy, robustness, and efficiency.Source: B. Evaluation Against the… · p. 5
  • Each algorithm was set up for best performance with minimal parameter tuning, adjusting only inputs such as lidar count and motion-corrected points.The algorithms differed in lidar count and whether motion correction was performed internally or provided in the input.Source: B. Evaluation Against the… · p. 5
  • LIO-SAM ran only with a single lidar and could not be made to work on the Urban datasets.The authors suggest its 50 Hz Urban IMU input, below the recommended 200 Hz, may explain the failure.Source: B. Evaluation Against the… · p. 5

1) Accuracy Evaluation:

LOCUS matches or outperforms state-of-the-art methods in position accuracy across the evaluated datasets, with map-error trends broadly similar. Robustness tests show it can continue odometry through sensor failures using available inputs.

1) Accuracy Evaluation:

  • LOCUS is equal to or better than state-of-the-art methods in position accuracy across all datasets.FGA improves LOCUS performance but is not essential; LIO-Mapping has similarly low error but averages 1 s per scan.Source: 1) Accuracy Evaluation · p. 5
  • LIO-SAM performs best in the Tunnel dataset, while Cartographer and ALOAM perform relatively well in Urban environments.The passage attributes the latter pattern to the effectiveness of edge-and-plane features and grid methods in human-made environments.Source: 1) Accuracy Evaluation · p. 5
  • BLAM performs adequately in Urban datasets but poorly in the Safety Research dataset, where self-similarity and low lidar observability are present.The authors suggest LOCUS’s WIO integration is important under those conditions.Source: 1) Accuracy Evaluation · p. 5
  • Map-error RMSE shows trends similar to position error, with negligible differences in algorithm ordering.Map error is computed against the DARPA map after ICP alignment to account for possible calibration misalignments.Source: 1) Accuracy Evaluation · pp. 5–6

2) Robustness Evaluation:

  • After WIO and IMU streams stop, LOCUS cascades from WIO integration to IMU integration and then pure lidar odometry; some competitors stop running.The simulated stream failure occurs after 1200 s; losing WIO alone affects Cartographer and LOCUS.Source: 2) Robustness Evaluation · p. 6
  • During a simulated 10 s lidar gap, LOCUS uses WIO to provide an initial transform when lidar returns, unlike methods that stop or drift on IMU alone.Source: 2) Robustness Evaluation · p. 6

3) Efficiency Evaluation:

LOCUS is evaluated for per-scan processing time and real-time operation, then demonstrated on competition robots with platform-specific tuning. Its configurations account for differences in sensors and computing capability.

3) Efficiency Evaluation:

  • LOCUS delivers the best accuracy with real-time performance, but requires the largest CPU load; ALOAM and BLAM also maintain real-time processing.ALOAM and LIO-SAM can stay real-time only at a lower lidar scan rate; FLOAM and LIO-Mapping do not appear feasible for real-time operation.Source: 3) Efficiency Evaluation · p. 6

C. Real-Time Operation Across Different Platforms

  • LOCUS was demonstrated during four Urban Circuit competition runs: two in Alpha and two in Beta.The field operation covered different robotic platforms.Source: C. Real-Time Operation Across… · p. 6

1) Hardware and Tuning:

  • LOCUS was deployed on Husky and Spot, with parameters tuned for accurate, robust real-time operation across their different hardware and computing capabilities.Husky carries an AMD Ryzen 9 3900X; Spot uses an Intel NUC7i7DN and has VIO and KIO available, with VIO selected as more accurate in the authors' tests.Source: 1) Hardware and Tuning · p. 6

2) Performance:

LOCUS is assessed for accuracy and robustness on competition runs and sensor-failure tests. Live operation on Husky and Spot was accurate, and Spot's VIO-supported initial transform let it perform well despite dropped scans.

2) Performance:

  • Spot dropped 2 lidar scans per second because of its less powerful onboard computer, yet its VIO initial transform enabled fewer scans to be processed while still performing well.Scans were received at 10 Hz without buffering, so dropped scans indicate processing exceeded 0.1 s.Source: 2) Performance · p. 6
  • Fig. 4 plots APE for methods on the test datasets and shows only the six best algorithms for each dataset.The accompanying table is identified as Table II, but no values are supplied here.Source: Figure 4 · p. 7, Table II · p. 7

SUMMARY OF ACCURACY ANALYSIS RESULTS ON ALPHA, BETA AND SAFETY RESEARCH DATASETS

D. Discussion

LOCUS uses loosely coupled additional sensing modalities to support accurate, resilient odometry in challenging conditions. The authors report top-class accuracy and computation time, superior robustness to sensor failures at greater CPU load, and field-proven operation on two robots in the winning CoSTAR team solution.

D. Discussion

  • Loose sensor coupling makes LOCUS robust to sensor failures and can outperform tightly coupled approaches when extrinsic sensor calibration is not ideal.The system uses additional sensing modalities to seed GICP, supporting registration with more points than feature-based methods at reasonable computational cost.Source: D. Discussion · p. 8

IV. CONCLUSIONS

  • LOCUS shows top-class accuracy and computation time and superior robustness to sensor failures, but with greater CPU load.Its architecture is adaptable to heterogeneous platforms and optimized for real-time operation.Source: §IV · p. 8
  • LOCUS operated in real time on two robots during autonomous exploration of the Satsop power plant as part of CoSTAR's first-place Urban Circuit solution.The paper describes LOCUS as a key component of the team solution.Source: §IV · p. 8
Loading 2012.14447v1…