mola_lidar_odometry

LIDAR odometry component based on the MOLA and MRPT frameworks, compatible with ROS 2.

Contents

This repository provides a C++ library mola_lidar_odometry implementing LIDAR odometry. Sensor input is provided via MOLA components, and ROS 2 example launch files are provided in ros2-launchs.

A CLI interface mola-lidar-odometry-cli is also provided for running on offline datasets.

Build and install

Refer to: https://docs.mola-slam.org/latest/#installing

Lidar Inertial Odometry (LIO) demo with Oxford Spires:

Lidar Odometry (LO) demo with KITTI:

Documentation and tutorials

See: https://docs.mola-slam.org/

ROS build farm status

Distro	Develop branch	Releases	Stable release
ROS2 Humble (u22.04)		amd64 arm64
ROS 2 Jazzy @ u24.04		amd64 arm64
ROS 2 Kilted @ u24.04		amd64 arm64
ROS 2 Rolling (u24.04)		amd64 arm64

EOL Distro	Last release
ROS2 Iron (u22.04)

Citation

The latest publication on MOLA is (ArXiV).

@article{blanco2025mola_lo,
    author = {Blanco-Claraco, Jose Luis},
    title ={{A flexible framework for accurate LiDAR odometry, map manipulation, and localization}},
    journal = {The International Journal of Robotics Research},
    volume = {44},
    number = {9},
    pages = {1553--1599},
    year = {2025},
    doi = {10.1177/02783649251316881},
    URL = { https://doi.org/10.1177/02783649251316881},
    eprint = {2407.20465},
}

License

Copyright (C) 2018-2026 Jose Luis Blanco jlblanco@ual.es, University of Almeria

This package is released under the GNU GPL v3 license as open source, with the main intention of being useful for research and evaluation purposes. Commercial licenses available upon request.

Contributions require acceptance of the Contributor License Agreement (CLA).

Changelog for package mola_lidar_odometry

2.1.0 (2026-04-29)

• FIX: show_localmap was not loaded from YAML file; expose more pipeline env vars

• Merge pull request #70 from MOLAorg/feat/multiple-scans-per-volume simple estimator params file: expose all hardcoded values as env vars

• simple estimator params file: expose all hardcoded values as env vars

• Merge pull request #69 from MOLAorg/feat/multiple-scans-per-volume feat: new option to include multiple scans per space volume

• feat: new option to include multiple scans per space volume

• feat: Add IMU & LiDAR configurable QoS (requires latest mola_bridge_ros2)

• Merge pull request #67 from Zeal-Robotics/fix/pose-timestamp-after-deskew fix: stamp published pose with deskew reference time, not raw obs stamp

• fix: stamp published pose with deskew reference time, not raw obs stamp The ICP-derived pose corresponds to the vehicle at t=0 of the deskewed cloud. With the default [FilterAdjustTimestamps: MiddleIsZero]{.title-ref}, t=0 is the middle of the scan, while [obs->timestamp]{.title-ref} (taken from the LiDAR driver header) is the start of the scan. The published [LocalizationUpdate.timestamp]{.title-ref} and the timestamp fed back into [navstate_fuse->fuse_pose()]{.title-ref} were both using [obs->timestamp]{.title-ref}, so downstream consumers (and the internal fuser) saw a pose tagged with a time roughly half a scan period (~50 ms at 10 Hz) before the moment the pose actually holds. The absolute reference time is already tracked inside `ParameterSource::localVelocityBuffer.get_reference_zero_time()[: - `Generator]{.title-ref} seeds it with [obs->timestamp]{.title-ref}

  - [FilterAdjustTimestamps]{.title-ref} shifts it by the same offset it applies to per-point timestamps

  - [FilterAbsoluteTimestamp]{.title-ref} already uses it as the absolute reference for per-point timestamps This commit reads it back after the observation pipeline runs and threads it through every pose-time use site:

  • ICP initial-guess query ([estimated_navstate]{.title-ref})
  • ICP result fusion ([fuse_pose]{.title-ref})
  • [estimated_trajectory]{.title-ref} insertion
  • [past_simplemaps_observations]{.title-ref} keyframe key

  - Published [LocalizationUpdate]{.title-ref}, map, deskewed-scan, debug-trace timestamps Sensor-cadence uses (rate stats, drop-too-close logic, debug log context, [last_obs_timestamp]{.title-ref}, per-label staleness tracking) keep the raw [obs->timestamp]{.title-ref} since they are about when the observation arrived, not when the pose holds. If [FilterAdjustTimestamps]{.title-ref} is not configured the buffer's reference equals [obs->timestamp]{.title-ref} and behavior is unchanged. There is a fallback to [obs->timestamp]{.title-ref} for safety if the buffer was never seeded.

• Merge pull request #66 from MOLAorg/better-grav-aligner-tests review: address gravity-aligner / rebaker review comments

• review: address gravity-aligner / rebaker review comments

  - Fix stale Doxygen on onNewKeyframe (window param) and computePublishResidual (drop tail_kf_id reference, document unconditional residual contract).

  - TrajectoryRebaker::rebake: slide anchor forward to lower_bound when no KF >= anchor_id exists, so corrected_poses and reported anchor_id stay consistent.

  • Remove redundant empty-input guard in two-arg rebake overload.

  - Replace composePoint+subtraction delta computation with rotateVector in TrajectoryRebaker and the test helper.

  - Extract kDefaultAxisEps single source of truth used by Params and rotationFromGravity.

  - Fix sign in test bodyGravity comment (a_body.z = +g*cos), clarify accelerometer convention.

  • Wire maxGravityErrorDeg into KnownPitchTilt_converges as a sanity check.

  - Clarify LinearDrift_recoversHorizontalPath comment that R_grav per-KF exactly cancels T_odom.R (scenario justifying the 5cm Z

File truncated at 100 lines see the full file