Three tables name the same branches three different ways

One set of branches, three naming schemes across three tables

The front page describes the same development lines three different ways, and anyone setting up CI will notice. The branch policy text says features are developed on master and that the *-devel branches correspond to released and stable versions for specific ROS distributions, then names noetic-devel as currently synced to master. The continuous integration table underneath has two columns labelled Melodic and Master, with badge links to melodic-devel and master. The ROS buildfarm table below that has four columns: Melodic Source, Melodic Debian, Noetic Source and Noetic Debian. So melodic-devel, melodic-devel on bionic and the Melodic buildfarm column are one line of development, and noetic-devel appears only in the prose and in the Noetic columns. Nothing is necessarily broken, but the tables are maintained separately and drift, so the reliable way to find whether your distribution gets a binary is to look in the buildfarm table for your distro rather than inferring from the branch names.

The version number is deliberately one ahead of package.xml

One line in the branch policy is a build-system trick worth knowing before you write anything against the version. To facilitate compile-time switching, the patch version of MOVEIT_VERSION on a development branch is incremented by 1 relative to the version in package.xml. In other words, the C++ macro and the ROS package manifest deliberately disagree by one on development branches, and code that checks MOVEIT_VERSION at compile time can tell which kind of tree it was built from. If you are porting configuration or writing conditional code, this is why a development build reports a different version from what apt shows you. Combined with the statement that bug fixes occasionally get backported, the policy describes a project where master moves and the stable branches are mostly frozen, which is the usual shape for a framework at the end of a platform's life.

The buildfarm publishes source and Debian jobs per package

The ROS buildfarm table is the most useful table for an adopter, because it is a grid of packages against distribution and build type. The package rows are moveit, moveit_core, moveit_kinematics, moveit_planners and moveit_planners_ompl among others, and the four columns pair a source job with a Debian binary job for each of two distributions. A binary job means you can apt install the package rather than build it, which removes the entire toolchain question for anyone on those distributions, and a source job means the recipe exists even where no binary is produced. The continuous integration table adds two more signals: the build farm row shows a devel build on bionic for melodic-devel and a devel build on focal for master, and the Docker row shows published images for moveit/moveit with a pull count badge for the melodic-devel column and an automated build badge for master. So there are three installation routes of increasing effort: an apt binary, a container image, or a source build.

Docker and coverage signals sit next to the CI badges

The status section is denser than it looks once you read it row by row. Formatting has its own workflow badge separate from CI, both for melodic-devel and master, which tells you style is enforced by pre-commit rather than left to review. Coverage is tracked through codecov with a token-parameterized badge URL per branch, and the repository root carries codecov.yaml along with .clang-format and .clang-tidy, so formatting and lint configuration is versioned with the code. A FOSSA status badge is present, which is the tool organizations use to track open source obligations across a dependency tree. The root also holds a CODE_OF_CONDUCT.md and a CONTRIBUTING.md, and the repository carries a .pre-commit-config.yaml. Between the formatting workflow, the tidy configuration and the coverage badge, the repository is set up for automated quality checks rather than manual review, which matters more for a framework with this many downstream users.

Docs and installs live on moveit.ai, not in the repository

The repository is deliberately thin at the top and points outward for everything a user needs. Four links cover the practical path: an overview of MoveIt, installation instructions, source code API documentation, and a page on how to get involved, all on moveit.ai. The homepage for the project is http://moveit.ai, while the logo and links still reference that older scheme rather than the moveit.picknik.ai documentation host used by the ROS 2 project. That split between where the framework is explained and where its code lives is worth knowing if you are searching for answers, because a question about configuring the setup assistant is answered in documentation hosted elsewhere, not by grepping this tree. The repository does keep the files that must be versioned with the code: the licence file, the code of conduct, the contributing guide, MIGRATION.md, and the workspace descriptor moveit.rosinstall that pulls a full workspace in one command.

The repository is a set of packages, one of them experimental

The top-level layout mirrors the buildfarm rows, which is a good sign that the package split is real rather than aspirational. There is moveit/ and moveit_core/, then moveit_kinematics/ for kinematic solvers, moveit_planners/ with the planners and a separate moveit_planners_ompl/ package, moveit_plugins/ for the pluggable pieces, moveit_ros/ for the ROS-facing layer, moveit_commander/ for the command interface, and moveit_setup_assistant/ for the configuration tool. Two entries are worth a second look. moveit_experimental/ is a separate package for work that is not yet part of the supported surface, which is a reasonable place for things that will change. And moveit_runtime/ exists here as it does in the ROS 2 repository, alongside moveit.rosinstall at the root, the descriptor file used to pull a full workspace in one command.

Where MoveIt 1 is the wrong tool

Four cases. The first is a new ROS 2 project. The README's first line points to MoveIt 2 for ROS 2 and MoveIt Pro for the commercially supported version, and starting a ROS 2 system on the ROS 1 framework means a port and the migration work that comes with it. The second is a distribution that has moved on. The buildfarm table covers Melodic and Noetic, both ROS 1 distributions, so on a newer system your only route is the source build, and the branch policy says released branches take backported bug fixes only occasionally. The third is anyone who needs vendor support. PickNik leads development and sells MoveIt Pro separately, so an unsupported deployment means the issue tracker is the fallback when a planning bug shows up on a production cell. The fourth is a project that treats the framework as a library only. MoveIt ships a setup assistant, a commander interface and a runtime component, which means there is configuration state to generate, version and migrate alongside your own code, and the newest published tag is 1.1.11 from 2023-01-09 while work continued on master through a push dated 2026-07-20, so changes are landing on a branch that has not been tagged.

Editorial conclusion

MoveIt suits a team whose robot software targets ROS 1 and needs motion planning with published binaries per distribution. It does not suit a new ROS 2 project, which should start from MoveIt 2 in the other repository rather than port this one. Before adopting, match your distribution against the buildfarm table to confirm a Debian binary exists, decide whether to track master or a synced devel branch, and remember that a development branch carries a MOVEIT_VERSION patch number one higher than package.xml declares.

Frequently asked questions

Official sources

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