mola_mapper_2d

2D LiDAR Graph-SLAM backend component based on the MOLA and MRPT frameworks, compatible with ROS 2.

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

Overview

This repository provides a C++ library mola_mapper_2d implementing a complete 2D LiDAR SLAM system (Simultaneous Localization and Mapping) using pose graph optimization.

The mapper uses:

• GTSAM for factor graph optimization
• mp2p_icp for scan-to-map registration and loop closure detection
• MRPT for common robotics types and utilities
• MOLA framework for system integration and component management

Sensor input is provided via MOLA observation interfaces, making it compatible with various sensor front-ends (odometry, LiDAR, etc.). ROS 2 example launch files are provided in ros2-launches.

A CLI interface mola-mapper-2d-cli is also provided for running on offline datasets.

Features

• Graph-based SLAM: Maintains a pose graph of keyframes with SE(3) constraints
• Loop Closure Detection: Automatic detection and correction of large-scale loops
• Flexible ICP Pipelines: Separate configurable pipelines for odometry and loop closure
• Keyframe Management: Intelligent keyframe selection and old-keyframe replacement
• Robust Optimization: Levenberg-Marquardt optimization with robust noise models
• Multi-Sensor Support: Handles 2D/3D LiDAR observations with flexible sensor labeling
• Session Resumption: Supports resuming SLAM sessions from saved states for multi-session mapping
• Visualization Support: Built-in 3D scene generation for debugging and visualization
• Full State Serialization: Complete state save/load for archival and analysis

Contents

The repository provides:

• Core Library: mola_mapper_2d - The main 2D SLAM backend implementation
• CLI Tool: mola-mapper-2d-cli - Command-line interface for offline processing
• Example Configurations: YAML configuration templates for different scenarios
• ROS 2 Bridges: Integration components for ROS 2 (in separate ROS-specific package)

Quick Start

Build and Install

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

# Standard MOLA installation (with ROS 2)
colcon build --packages-select mola_mapper_2d

# Or standalone (without ROS 2)
cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build
cmake --install build

Basic Usage

#include <mola_mapper_2d/Mapper2D.h>

// Create mapper instance
mola::Mapper2D mapper;

// Initialize from YAML configuration
mapper.initialize("config.yaml");

// Process observations in a loop
mapper.onObservation(observation);

// Get current estimates
auto pose = mapper.get_current_pose();
auto map = mapper.get_current_map();

// Save state for later resumption
auto state = mapper.get_state();
// ... serialize state ...

// Resume from saved state
mapper.resume_session(saved_pose);

Architecture

File truncated at 100 lines see the full file

Contributing to MOLA

Thank you for your interest in contributing to MOLA. This document outlines the process and expectations for contributing to this project. Please read it carefully before submitting any contribution.

MOLA is a modular SLAM and localization framework written in C++ with ROS 2 support. We welcome contributions from the community, provided they meet the quality and legal requirements described below.

Table of Contents

1. Contributor License Agreement
2. Code of Conduct
3. Types of Contributions
4. Getting Started
5. Development Workflow
6. Commit and Pull Request Guidelines
7. Coding Standards
8. Testing Requirements
9. Documentation
10. Review Process
11. Reporting Issues

1. Contributor License Agreement

All contributions to MOLA require acceptance of the Contributor License Agreement (CLA) prior to being merged.

MOLA is distributed under a dual licensing model:

• Open source: GNU General Public License v3 (GPL v3)
• Commercial: A separate commercial license is available for industry users who cannot comply with the terms of the GPL v3

The CLA ensures that the project maintainers hold the necessary rights to distribute your contribution under both licensing models. It does not transfer copyright ownership — you retain full ownership of your work.

When you open a Pull Request, an automated CLA assistant will verify whether you have previously accepted the agreement. If you have not, you will be prompted to do so before the PR can be reviewed or merged. Contributions submitted without CLA acceptance will not be considered.

2. Code of Conduct

All contributors are expected to adhere to the project’s Code of Conduct. We are committed to maintaining a welcoming and professional environment for everyone, regardless of background or experience level. Violations may result in removal from the project.

3. Types of Contributions

We welcome the following types of contributions:

• Bug fixes — corrections to incorrect or unexpected behavior
• Performance improvements — optimizations with measurable, documented impact
• New modules or algorithms — extensions to MOLA’s modular architecture
• Documentation improvements — corrections, clarifications, and additions to existing documentation
• Dataset integrations — support for additional SLAM benchmark or real-world datasets
• ROS 2 integrations — improvements to the ROS 2 interface, launch files, or message definitions
• Tests — new or improved unit, integration, or regression tests

If you are considering a large or architectural contribution, please open an issue for discussion before beginning work. This avoids duplication of effort and ensures alignment with the project roadmap.

4. Getting Started

Full setup instructions, dependencies, and build guides are available in the official documentation:

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

Ensure your development environment is fully configured and that all existing tests pass before making any changes.

5. Development Workflow

1. Fork the repository and create a new branch from main (or the relevant base branch).
2. Name your branch descriptively, e.g. fix/imu-integration-drift or feat/lidar-odometry-module.
3. Make your changes in focused, logically grouped commits.
4. Ensure all tests pass locally before opening a Pull Request.
5. Open a Pull Request against the main branch with a clear description of your changes.

Do not submit Pull Requests that bundle unrelated changes. Each PR should address a single concern.

6. Commit and Pull Request Guidelines

Commits

• Write commit messages in the imperative mood: Fix timestamp alignment in IMU handler, not Fixed or Fixes.
• Keep the subject line under 72 characters.
• Reference relevant issues in the commit body where applicable, e.g. Closes #123.

Pull Requests

• Provide a clear summary of the problem being solved and the approach taken.
• Include references to any related issues, discussions, or prior art.
• If the PR introduces a user-visible change, update the relevant documentation and changelog.
• Mark the PR as a draft if it is not yet ready for review.

File truncated at 100 lines see the full file