# OMPL: sampling-based motion planning in C++ with real Python bindings

> The Open Motion Planning Library packs more than 40 sampling-based planners and over 20 state spaces into a C++ core. Since version 2.0 that core also installs from pip, which changes who can realistically use it.

**ompl/ompl** — The Open Motion Planning Library (OMPL)

- Repository: https://github.com/ompl/ompl
- Website: https://ompl.kavrakilab.org
- Stars: 2,170 · Forks: 715
- Language: C++
- License: NOASSERTION
- Published: 2026-10-08 · Updated: 2026-10-08 · Language: en
- Canonical page: https://hysenlabs.com/projects/ompl-ompl

## Forty planners over twenty state spaces, and what stays outside

The Open Motion Planning Library is a C++ library for sampling-based motion planning, the family of algorithms that searches for a path by sampling the configuration space instead of precomputing it. The README counts more than 40 such planners, naming RRT-Connect, PRM, KPIECE and RRT* among them, and states they work across more than 20 state spaces including SE(3) and plain Euclidean space.

The two repository topics, motion-planning and robotics, describe that scope honestly. OMPL is not a simulator, not a physics engine and not a collision detector. It consumes a state space you supply and hands back a path you can read. The 2.0.2 release notes from August 2026 show exactly where the line sits: the fixes cover path cost calculation for `ompl::control` planners, costs that are a joint function of control and state, constraint Jacobian dimension checks in the Python bindings, and vendored transitive dependencies in the release tarball. Every one of those is library plumbing, nothing more.

Version 2.0.0 landed on 2026-04-06 and is the release to read first if you are evaluating the project now, because it rewrote the Python bindings and made pip a supported install path. The last push to the repository was on 2026-09-25.

## Building from source with Boost, CMake and Eigen

OMPL declares three required dependencies: Boost 1.68 or higher, CMake 3.12 or higher, and Eigen 3.3 or higher. The README sends you to the installation page on ompl.kavrakilab.org for the platform-specific detail, then gives the source build, which works on Linux, macOS and MS Windows.

```bash
git submodule update --init --recursive
mkdir -p build/Release
cd build/Release
cmake ../..
make -j <num_cores> # replace <num_cores> with the number of cores on your machine
```

The `.gitmodules` entry in the repository tree explains the first line. This is not a plain clone, and forgetting the submodule step is the most common reason a fresh checkout fails to configure. The directory name `build/Release` is a convention carried over from Visual Studio projects and carries no meaning to the build.

The rest of the top level tells you what kind of project this is. There is `vcpkg.json` for the Microsoft package manager, `CMakeModules/` for custom find-modules, `omplConfig.cmake.in` so downstream CMake projects can locate it, and `package.xml` for ROS packaging. Under `.github/workflows/` sit a build badge and a format badge, so both compilation and clang-format run on pushes, alongside a `.clang-format` at the root and a `.pre-commit-config.yaml`. The `tests/` directory is part of the repository rather than a separate harness.

## The pip install path that version 2.0 introduced

Python used to be the awkward corner of OMPL. Bindings existed, they trailed the C++ API, and you built them yourself. The 2.0.0 notes say the bindings were completely rewritten, that they are enabled by default when Python is detected at configure time, and that prebuilt OMPL Python modules can now be installed with `pip install ompl`. The `py-bindings/` directory at the top of the tree is the packaging root.

```bash
git submodule update --init --recursive
pip install ./py-bindings
```

Version 2.0.1 in June 2026 tightened that story: more bindings, fixes so Python classes can derive from the corresponding C++ classes, a binary wheel for Python 3.14 alongside 3.10 through 3.13, and binary builds made portable by default when built for Debian or with scikit-build. The 2.0.1 notes also tell existing users to update if they touch FMT or ST-RRT*, which is the sort of dependency-specific warning you rarely see in a robotics library.

What the release notes do not settle is how complete the bindings are. The 2.0.1 changelog describes complete bindings for everything as currently under review, which is an admission that parity is still in flight. The useful check is therefore whether the specific planner and state space you need are exposed, not whether the import line succeeds.

## VAMP and the case for optimising the inner loop

VAMP, Vector-Accelerated Motion Planning from the Kavraki Lab, is listed as an optional dependency but is enabled by default. The README credits it with SIMD-accelerated planning for millisecond planning times in both Python and C++. The 2.0.0 notes describe it as a high-performance backend for collision checking and motion validation, and one of the five paper badges on the README points at the ICRA 2024 VAMP paper.

This is the part worth understanding about how OMPL is put together. Sampling planners spend most of their time asking one narrow question repeatedly: is this state in collision, and is this segment free? When that inner loop gets faster, every planner stacked on top of it gets faster without its logic changing at all. Vectorising the inner loop is a cleaner gain than retuning search parameters, and it is the reason the VAMP paper sits in the README's badge row rather than in a footnote.

The other optional dependencies sit further from the hot path and are worth knowing for what they enable. Flann 1.9.2 handles nearest neighbour queries, which PRM-style planners need for their roadmap construction. Spot is used for constructing finite automata from LTL formulae, which is how the library handles LTL planning. yaml-cpp reads and writes YAML world descriptions in the PlanarManipulator demos, and Doxygen is only needed if you want a local copy of the documentation instead of the published site.

## Custom planners in Python, custom state spaces in C++ only

The README states its extensibility position precisely, in a way most libraries do not: custom planners can be written in Python and C++, while custom state spaces are C++ only. That asymmetry has teeth. A planner is an algorithm written against a space you already have, so writing one in Python costs you little. A state space is the object that defines the configuration, the bounds, the distance metric and the interpolation, and those types sit closest to the C++ core.

So the decision point is concrete. If your problem is that RRT* converges too slowly on your robot, you can prototype the replacement planner in Python and keep the build simple. If your problem is that your robot is not described by anything in the existing catalogue, you are writing C++ regardless of how comfortable you are in Python.

The `demos/` directory is where to look for what working example code looks like. PlanarManipulator is the demo the README ties to yaml-cpp, which tells you the demo suite spans more than the single-link case the tutorials usually show. The `scripts/` and `external/` directories at the top level sit alongside them, and `src/` holds the library proper.

## The README is an index, not a manual

At roughly sixty lines the README is a well-organised index rather than documentation. Detailed installation instructions, including the paths that differ per platform, live on the OMPL installation page. Algorithm pages, state space pages and the tutorials are generated from the `doc/` directory and published under ompl.kavrakilab.org/core.

One thing the README never mentions is a licence. The repository carries a LICENSE file at its top level, and GitHub reports no licence identifier it recognises for the project. That is precisely the kind of detail worth opening yourself before a product depends on it, because no documentation page is going to answer it for you and the answer is not inferable from the code.

There is also no benchmark table on the README. The five badges point at the original OMPL design paper in Robotics and Automation Magazine, an ICRA paper on the Python bindings, a benchmarking paper in the same journal, an IJRR paper on constrained path planning, and the VAMP paper. If you need numbers rather than adjectives, those are where the measured comparisons live, and the benchmarking paper is the one to read before you quote anyone else's timing as your own.

## Conclusion

OMPL fits when you need a proven sampling planner over a configuration space and are willing to write the state space, the bounds and the validity checking yourself. It does not fit when you want a robot stack that runs from a config file, because no amount of OMPL supplies the model of your robot. Start with the pip path if you only need to try planners, and drop to a source build with the submodule step intact the moment you need to add a state space in C++. Before either, open the LICENSE file yourself, since the README names no licence and that decision is yours to make.

## FAQ

### What does OMPL stand for?

The Open Motion Planning Library. It is a C++ library of sampling-based motion planners, and the README counts more than 40 of them working across more than 20 state spaces.

### Is OMPL free to use?

The README names no licence. The repository ships a LICENSE file at its top level and GitHub reports no licence identifier it recognises for the project, so read that file directly before relying on it.

### Does OMPL need ROS 2 to plan a path?

No. The required dependency list is Boost, CMake and Eigen, with no ROS package among them. People search for the pairing because ROS motion planning stacks such as MoveIt use OMPL as their planner backend.

## Sources

- [Issues](https://github.com/ompl/ompl/issues)
- [ompl/ompl on GitHub](https://github.com/ompl/ompl)
- [Project website](https://ompl.kavrakilab.org)
- [README](https://github.com/ompl/ompl/blob/main/README.md)
- [Releases](https://github.com/ompl/ompl/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ompl-ompl