MRPT: the Mobile Robot Programming Toolkit in C++

What MRPT is and which robotics problem it removes

MRPT is a C++ framework for mobile robotics that the README dates back to 2005 at the University of Málaga. The problem it addresses is not navigation policy or mission planning. It is the layer underneath: representing poses as SE(2) and SE(3) Lie groups, running MonteCarlo localization and Rao-Blackwellized particle filters, storing the world as occupancy grids, point maps, landmark maps or voxel maps, and drawing the result in a 3-D scene graph. Those are the parts every mobile robot project rebuilds badly at least once.

The intended reader is an engineer who wants those algorithms callable from ordinary C++ inside their own process, not behind a middleware graph. The README lists LiDAR, stereo and RGB-D cameras, IMU, GPS and Velodyne among the supported sensor inputs, and pybind11 bindings for the major modules, so the same core is reachable from Python. If your stack is a ROS 2 node graph and you never want to see a covariance matrix, this is the wrong layer of the stack to start from.

The 3.0 refactor: colcon packages, C++17, and two release lines

The README describes MRPT 3.0 as a major refactoring that modernises the build system into colcon-based modular packages, cleans up the public API, and aligns with C++17, while preserving the data structures and algorithms at the core. That last clause is the important one for anyone with existing code: the internals are meant to survive the change, the packaging and the API surface are not.

The repository confirms the split. The top level carries colcon_defaults.yaml and a modules/ directory alongside apps/, doc/, packaging/ and share/, which is the layout you would expect from a colcon workspace rather than a single monolithic CMake tree. The modules/ directory is where the modular packages live; the README also refers to the ROS 2 side as mrpt3, with distinct mrpt_core and other binary packages built per distribution.

Two release lines are visible in the recent releases: 3.1.2 in July 2026 and 2.15.21 in August 2026, with 2.15.19 in between. The 2.15.x line is still receiving releases, so it is not abandoned; it is the older packaging and API generation. Picking a line is a real decision, not a formality, and the README does not spell out a migration path between them.

Installing MRPT from ROS repositories

The README gives ROS repositories as the primary install route. For ROS 2 it installs the mrpt3 packages for your distribution, which pulls in the binary packages built for amd64 and arm64:

sudo apt install ros-$ROS_DISTRO-mrpt-*

The README also shows the ROS 1 form, `sudo apt install ros-$ROS_DISTRO-mrpt2`, and marks ROS 1 as deprecated. After the install, the packages land in your ROS 2 environment, so source your workspace setup before compiling anything against them.

That is the whole of the install documentation the README carries. There is no separate source-build recipe in it, and no plain CMake invocation. The repository top level does contain colcon_defaults.yaml and a modules/ directory, which is the layout of a colcon workspace, but the README does not spell out the build command for that layout. If you need a source build, the README points at the documentation site rather than answering it here.

The Python route is the shortest first use once the packages are present. The README states that pybind11 bindings cover all major modules. It does not list the import names, so the examples under mrpt_examples_py/ in the repository are where you find working Python calls rather than guessing at module paths.

What the toolkit does not give you

MRPT is a library, not a robot. There is no behaviour tree, no lifecycle node manager, no launch system and no message bus in the capability table. The README lists reactive navigation, path planning and PTG-based obstacle avoidance, which are algorithmic components you call; wiring them into a running robot, with its timing, its failure recovery and its process supervision, stays your job.

The second limitation is weight. A framework that ships geometry, probabilistic filters, several map representations, sensor drivers and a 3-D scene graph is a large dependency. The README does not publish a size or a minimum-footprint figure, and it does not discuss cross-compilation for constrained targets, so if you are budgeting flash on a small board, measure the actual linked result rather than trusting the module list.

The third is documentation shape. The README points to a separate documentation site for tutorials, API reference, examples and applications. The README itself is a capability table and an install note. Anything about API stability guarantees between 2.15.x and 3.1.x, or about deprecation windows, is not in the README, and you should look for it on the documentation site before you plan an upgrade.

MRPT against building on ROS 2 navigation directly

The obvious alternative for a ROS 2 user is to stay inside the ROS 2 ecosystem: use the navigation stack and the perception packages for your sensor pipeline, and write only the application-specific parts. That approach gives you the middleware, the lifecycle management and a large body of integration code for free, and it is the right call when your robot is a standard differential-drive platform with a 2-D LiDAR.

The difference in approach is where the algorithms live. With MRPT, MonteCarlo localization, the particle filters, the pose-graph optimization and the map types are in-process C++ objects you configure and step yourself, and the toolkit is usable with no middleware at all. With the ROS 2 route, those same capabilities arrive as nodes with parameters and topics, and you trade direct control of the estimator loop for integration you did not have to write.

MRPT is not outside that ecosystem. The README documents ROS 2 binary packages for Humble, Jazzy, Kilted, Lyrical and Rolling, including arm64 builds, so the two are not mutually exclusive. The practical question is whether you want the estimator as a library you own or as a node you configure.

Licence, maintenance and upgrade cost

MRPT is BSD-3-Clause, per the repository metadata and the licence badge in the README. That is a permissive licence: it allows use in closed products provided the copyright notice, the list of conditions and the disclaimer are retained, and it does not carry the source-disclosure obligation of a copyleft licence. It also means no patent grant clause, which matters if your product depends on the algorithms being free of third-party patent claims. That is a question for your own counsel, not something this article can settle.

The repository is not archived, and the last push was on 2026-09-11. Releases in the last two months cover both the 3.1 and 2.15 lines, so the project is being published to, not merely sitting still.

Upgrade cost is where the two lines diverge. The README frames 3.0 as a build-system and public-API refactor, which means code written against the older generation may need work to compile against the new one, and the README does not describe that work. If you pin to 2.15.x you keep the older API; if you pin to 3.1.x you take the C++17 requirement and the colcon packaging. Choose deliberately and record which line you are on, because the release history shows both are live and a floating dependency will move you between them.

Editorial conclusion

Adopt MRPT if you are writing C++ robotics code and want a permissively licensed library that already contains SE(2)/SE(3) geometry, occupancy and voxel maps, MonteCarlo localization, RBPF and pose-graph optimization, plus a 3-D scene graph, instead of assembling those pieces yourself. Skip it if you want an end-to-end ROS 2 application framework, a Python-first workflow, or a small dependency footprint on an embedded target; the toolkit is large and the Python bindings sit on top of the C++ core. Before committing, verify three things against the current checkout: which of the two release lines (3.1.x or 2.15.x) your project should track, that the ROS 2 distribution you target has the mrpt3 binary packages built for your architecture, and that the modules you need are covered by the pybind11 bindings if any part of your stack is Python.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. MRPT/mrpt on GitHub
3. Project website
4. README
5. Releases