MOLA: A Modular C++ and ROS 2 Framework for LiDAR Odometry and SLAM

What MOLA Solves in Robotics Localization

Mobile robot navigation has two persistent problems: knowing where the robot is (localization) and building a map of the environment (mapping). SLAM, simultaneous localization and mapping, attempts both at once. Most SLAM frameworks require recompilation when you change a sensor, swap a map layer type, or adjust a processing filter. MOLA addresses this by separating the pipeline definition from the code.

A MOLA pipeline is a YAML file that specifies which sensor input module to use, which odometry algorithm to run, how to represent the map, and which optional filters to apply. Changing the sensor or the map type is a matter of editing the YAML and restarting the process. No C++ changes and no recompilation are required for those switches.

The framework targets a range of robotics deployments. The README lists capabilities from fast real-time navigation to survey-grade mapping with less than one centimeter accuracy. It also supports map-less RTK-quality outdoor georeferencing when combined with low-cost GNSS, LiDAR, and IMU hardware together. That combination is described in the feature list but the README points to the documentation site for setup details.

Supported Algorithms: LO, LIO, and Georeferencing

The README describes three main processing modes. LiDAR Odometry estimates robot pose from successive LiDAR scans alone, tracking motion by matching point clouds frame to frame. LiDAR-Inertial Odometry adds IMU data to the estimation, which improves accuracy during rapid rotations or when the LiDAR scan rate is too low to track fast motion reliably.

The third mode is outdoor georeferencing without a prior map. The README lists this as RTK-quality georeferencing using low-cost GNSS combined with LiDAR and IMU. The result is a geographically referenced map without requiring an expensive RTK base station or pre-built reference map.

The repository includes a rich metric map ecosystem. The README mentions a map viewer, export to LAS, PLY, and TXT formats, filtering tools, and georeferencing tools for the .mm metric map format. These support post-processing of maps produced during a run without requiring a separate external tool for basic operations.

Demonstration videos linked in the README cover three public datasets: Oxford Spires for LiDAR-Inertial Odometry, GrandTour legged robot dataset for LiDAR Odometry, and KITTI for LiDAR Odometry. These are standard benchmarking datasets in the robotics community, which lets teams assess expected behavior on known data.

ROS 2 Integration and Standalone C++ Usage

MOLA is distributed as ROS 2 packages and is available through the ROS 2 binary package index. The README shows build status for five active ROS 2 distributions: Humble on Ubuntu 22.04, Jazzy on Ubuntu 24.04, Kilted on Ubuntu 24.04, Lyrical on Ubuntu 26.04, and Rolling on Ubuntu 26.04. Iron is listed separately as an end-of-life distribution with a last release entry.

For each distribution, both amd64 and arm64 binary packages are listed. This means teams can install MOLA without compiling from source on supported platforms by using the standard ROS 2 package index.

MOLA also works outside ROS 2 as standalone C++. This is relevant for teams that have custom robot middleware or that need to integrate MOLA into a non-ROS application. The README mentions this capability but does not elaborate on the standalone build procedure in the main text; the documentation site at docs.mola-slam.org holds that detail.

The repository is structured as a monorepo containing multiple packages: mola, mola_bridge_ros2, mola_demos, mola_input_lidar_bin_dataset, mola_input_rawlog, mola_input_rosbag2, mola_input_video, mola_kernel, mola_launcher, mola_metric_maps, mola_msgs, mola_pose_list, mola_relocalization, mola_traj_tools, mola_viz, mola_viz_imgui, and mola_yaml.

Pipeline Configuration Through YAML

The YAML pipeline configuration is central to how MOLA is used. The README describes it as fully configurable: sensors, filters, and map layers are all changed through YAML without recompiling. This design separates the concerns of algorithm developers from those of system integrators.

The mola_yaml package in the repository handles YAML parsing and pipeline instantiation. A pipeline file specifies module types by name, and MOLA instantiates the corresponding C++ objects at runtime. The documentation site provides the pipeline reference, but the colcon_defaults.yaml file in the repository root suggests the project uses colcon as its build tool, which is standard for ROS 2 workspace management.

This approach has a practical implication for teams evaluating MOLA: the interface between the YAML configuration and the C++ implementation is where most integration work happens. A team that needs a sensor type or a map format not already supported by the existing input and metric map packages will need to write a new C++ module conforming to the MOLA plugin interface. The README does not document that interface directly; it points to the wiki and documentation site.

Where MOLA Is the Wrong Choice

MOLA is specialized for LiDAR-based localization and mapping. Teams working with camera-only perception pipelines, or with radar or ultrasonic sensors as primary range sensors, will not find direct support in the existing package set. The README lists LiDAR inputs specifically in the feature summary.

The documentation strategy is important to understand before starting. Build instructions, demos, and the API reference are all at docs.mola-slam.org rather than in the repository. A team evaluating MOLA from the repository alone will have an incomplete picture of the setup procedure. If that documentation site were unavailable, reproducing a working setup from the repository alone would require significant reverse engineering.

The licensing situation is worth noting. The GitHub metadata reports the license as NOASSERTION, meaning the license file exists but its type was not automatically identified. Teams with legal requirements around open-source license compliance will need to read the LICENSE file directly rather than relying on the repository metadata.

The pricing page linked in the README header (docs.mola-slam.org/latest/pricing.html) suggests the project has commercial licensing or support tiers. The open-source repository provides the base packages, but teams should check that page before assuming all capabilities are available under the open-source terms.

Comparing MOLA to Cartographer

Google's Cartographer is the closest widely-used alternative for LiDAR SLAM in robotics. Cartographer supports both 2D and 3D SLAM, uses a pose graph optimization approach, and has ROS and ROS 2 integration. The key architectural difference is how configuration works.

Cartographer uses Lua configuration files rather than YAML, and its configuration parameters are tied closely to the probabilistic occupancy grid approach at its core. Changing sensor parameters in Cartographer requires careful tuning of scanning period, range, and submap configuration. The algorithm is not designed to swap between different map representation types.

MOLA's YAML pipeline model is designed for that kind of modularity. Swapping from one map type to another is a YAML edit rather than an algorithm-level change. The trade-off is that MOLA's modular pipeline requires understanding which modules exist and how to chain them, whereas Cartographer has a single well-documented configuration surface.

For teams that need survey-grade georeferencing with GNSS fusion, the README describes MOLA capabilities that Cartographer does not document as a built-in feature.

Maintenance Status and License Considerations

The last push to the repository was on 2026-09-26, and the repository is not archived. Binary packages are tracked across five active ROS 2 distributions with both architecture variants, which indicates ongoing maintenance as those distributions evolve.

The repository license shows as NOASSERTION in the GitHub metadata. This means that automated license detection did not identify the license type from the LICENSE file. Teams building products on MOLA need to read the LICENSE file directly before shipping. The README does not reproduce license text.

The documentation site at docs.mola-slam.org includes a pricing page, which is linked in the README header alongside the documentation and solutions pages. This is consistent with a dual-license or open-core model. The repository provides the base open-source packages under the MOLAorg organization on GitHub, but the specific terms of use for the commercial tier are on the documentation site rather than in the repository.

Editorial conclusion

MOLA is a practical choice for robotics teams that need LiDAR-based localization or mapping and want to configure pipelines in YAML without modifying C++ source. It supports ROS 2 Humble through Rolling and also works as standalone C++. Teams working on production robot deployments should note that the license is not confirmed in the repository metadata, so verifying the actual LICENSE file before shipping is necessary. Teams outside robotics or without LiDAR hardware have no use case here. The documentation lives at docs.mola-slam.org rather than in the repository, and the README states it is the authoritative reference for build instructions, demos, and the API.

Frequently asked questions

Official sources

1. Issues
2. MOLAorg/mola on GitHub
3. Project website
4. README