MOLA: a YAML-configurable LiDAR SLAM framework for ROS 2 and standalone C++

The problem MOLA solves: rebuilding a SLAM stack to change one sensor

Robotics teams that assemble a LiDAR SLAM pipeline usually end up owning a fork. The odometry front end, the inertial fusion, the loop closure and the map writer are wired together in code, so swapping a LiDAR model or adding a filter means a recompile and a regression pass. MOLA's stated goal is to move that wiring into YAML. The README describes "Fully configurable YAML pipelines - no recompilation needed to change sensors, filters, or map layers".

The target user is an engineer who already has ROS 2 on the robot and wants to choose between LiDAR Odometry (LO), LiDAR-Inertial Odometry (LIO) and geo-referenced mapping without rewriting the pipeline. The README also lists "Map-less RTK-quality outdoor georeferencing with low-cost GNSS + LiDAR + IMU" and a "Flexible accuracy" mode that ranges from fast real-time navigation to survey-grade mapping quoted at under 1 cm. Those are the project's own claims; the documentation is where the pipeline definitions live.

MOLA is not a single binary. It is a set of packages under one organisation, and this repository holds the base open-sourced ones. The top-level layout lists mola_kernel, mola_launcher, mola_yaml, mola_metric_maps, mola_viz, mola_viz_imgui, mola_relocalization, mola_traj_tools, mola_pose_list, mola_msgs, mola_bridge_ros2 and a group of dataset and log readers (mola_input_lidar_bin_dataset, mola_input_rosbag2, mola_input_rawlog, mola_input_video). That split is the design: a kernel, a launcher that reads a pipeline description, and interchangeable input and visualisation modules.

How the MOLA pipeline is assembled from modules and YAML

The architecture visible in the repository is a launcher plus modules. mola_launcher reads a pipeline description, mola_yaml provides the configuration layer, and mola_kernel holds the base interfaces that modules implement. Inputs are separate packages, so the same pipeline can be fed from a rosbag2 file, a rawlog, a LiDAR binary dataset or a video source depending on which input module is loaded.

That structure explains the ROS 2 story. mola_bridge_ros2 sits between the framework and ROS 2, while the README states the framework is "also usable from standalone pure C++". In other words the ROS 2 bridge is a module, not the foundation. A team that wants to embed MOLA in a non-ROS application can, in principle, take the kernel and the modules it needs and skip the bridge.

Output is a metric map in the project's own `.mm` format. The README describes a "Rich `.mm` metric map ecosystem: viewer, LAS/PLY/TXT export, filtering, georeferencing tools". So the data flow ends in a file that other tools can read or convert, rather than only in a live visualiser. mola_viz and mola_viz_imgui cover display, and mola_metric_maps covers the map container itself.

The trade-off is that this is a framework, not an application. You are expected to compose the pipeline. The README points to the documentation for build instructions and demos rather than giving a single run command, and it notes that "Other packages exist under the MOLAorg organization", which means the full set of capabilities is spread across repositories.

Installing MOLA on Ubuntu with ROS 2 and running the demos

The README does not print an install command. It links to the official documentation at docs.mola-slam.org/latest/ for build instructions and demos, and its build table shows binary packages published on the ROS 2 build farm for Humble (Ubuntu 22.04), Jazzy (Ubuntu 24.04), Kilted (Ubuntu 24.04), Lyrical (Ubuntu 26.04) and Rolling (Ubuntu 26.04), with Iron listed as EOL. The packages are indexed under the name mola, so the ROS 2 index is the place to look up the version for your distribution. The README gives no apt command, so use the ROS 2 installation route for your distro and confirm the version from the index entry.

What the repository does give you is the demo material. mola_demos is a top-level directory, and the README shows demo runs for LIO with the Oxford Spires dataset, LO with the GrandTour legged dataset and LO with KITTI. Those demos are the fastest way to confirm the installation works before pointing MOLA at your own sensor. The exact demo launch commands are in the documentation, not in the README.

If you build from source instead, the repository is a colcon workspace. The top-level entries include colcon_defaults.yaml and a scripts/ directory, and .gitmodules is present because some packages are pulled in as submodules. The README does not spell out the build commands, so follow the documentation for the configure and build steps. The build is C++17, and the repository carries .clang-format and .clang-tidy plus a CI job that checks clang-format, so contributions are expected to match the project's formatting. A first real use is to run one of the bundled demos against a dataset, watch the trajectory and map appear in the viewer, then edit the pipeline YAML to change an input or a filter and rerun without rebuilding.

Where MOLA is the wrong tool

MOLA is a poor fit if you want a single command that maps a room with no configuration. The README frames the project around configurable pipelines and points to documentation for demos; it does not present a zero-configuration entry point. Expect to read the pipeline definitions and understand which modules you are loading.

The ROS 2 support matrix is another boundary. The README lists Humble, Jazzy, Kilted, Lyrical and Rolling, and marks Iron as EOL. If your robot runs an older ROS 2 distribution, or ROS 1, this repository's build table does not cover you. Standalone C++ use is advertised, but the README does not document a standalone build path, so that route depends on the documentation.

Licensing is the constraint that rules MOLA out for some products. The README shows a GPL-3.0 badge, while the repository metadata reports the licence as NOASSERTION and a LICENSE file sits at the top level. The README also links a "Plans & Pricing" page under the documentation site. If your product cannot ship GPL-3.0 code, or if you need to know exactly what the pricing page covers before you build on MOLA, that is a question for the project, not something this article can settle.

Finally, the README's accuracy claims (survey-grade under 1 cm, RTK-quality georeferencing) are stated without the conditions under which they hold. Sensor, calibration and environment decide whether you get near them. Treat them as targets to validate on your own data.

MOLA compared with LIO-SAM and FAST-LIO style packages

The obvious alternative is a single-package LiDAR-inertial odometry implementation of the LIO-SAM or FAST-LIO family. Those projects typically ship as one ROS package with a fixed pipeline: a front end, an IMU preintegration step and a pose graph, tuned through a parameter file but not decomposed into swappable modules. If you want one well-known configuration and you are happy with its sensor assumptions, that is less to learn than MOLA's module set.

The difference in approach is where the configuration boundary sits. In a single-package LIO, changing the input source or the map representation usually means editing that package. In MOLA, the input is its own package (mola_input_rosbag2, mola_input_rawlog, mola_input_lidar_bin_dataset, mola_input_video) and the map is its own package (mola_metric_maps), selected by the pipeline that mola_launcher reads. The README's claim that sensors, filters and map layers change without recompilation is the direct consequence of that split.

MOLA also goes further on output. The `.mm` map ecosystem with LAS/PLY/TXT export and georeferencing tools is a deliverable in its own right, not just an internal state. A single-package odometry node usually leaves you to write that export yourself. Whether that matters depends on whether your project ends at a live trajectory or at a map file someone else has to consume.

Maintenance, releases and licence cost

The repository is not archived, and the last push was on 2026-09-14. The build matrix is the maintenance signal that matters here: binary builds are shown for Humble, Jazzy, Kilted, Lyrical and Rolling across amd64 and arm64, with per-package status tables for mola and its sibling packages. That is a lot of distributions to keep green, and the EOL row for Iron shows the project does drop them. No releases were retrieved for this repository, so the practical upgrade unit is the ROS 2 package version shown in the index, tied to your distribution.

Upgrade cost is mostly the cost of moving ROS 2 distributions. Because pipelines are YAML and modules are separate packages, a distro bump should not force a pipeline rewrite, but it can change which module versions are available. Pin your distribution and test the pipeline against your dataset after each bump.

On licensing, the README displays GPL-3.0 and the repository reports NOASSERTION. Those two signals do not agree, and the LICENSE file at the top level is the text that governs. GPL-3.0 has obligations that matter for closed-source products, and the documentation site has a pricing page, which suggests commercial terms exist alongside the open-source licence. Read the LICENSE file and the pricing page before you build a product on this code. This is not legal advice; if the answer decides your architecture, ask someone qualified.

Editorial conclusion

Adopt MOLA if you already run a ROS 2 distribution listed in its build table and want LiDAR odometry, LIO or metric-map tooling whose sensors, filters and map layers are set in YAML. Do not adopt it if you need a permissive licence, since the README shows a GPL-3.0 badge and the repository's LICENSE file is the authoritative text. Before committing, verify that your distro appears in the binary-build table and read the pricing page linked from the README.

Frequently asked questions

Official sources

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