The OpenMANIPULATOR repository is a stack of ROS 2 packages, not one node

One repository, many ROS 2 packages, split by function

The open_manipulator repository presents itself as the official ROS 2 package collection for the ROBOTIS OpenMANIPULATOR platform, and the top level listing shows exactly that shape. Instead of a single package directory, you get open_manipulator for the core interfaces and tools, open_manipulator_description for the robot model, open_manipulator_bringup for startup configuration, open_manipulator_moveit_config for motion planning setup, open_manipulator_collision for collision related resources, open_manipulator_gui for a graphical front end, open_manipulator_teleop for teleoperation, open_manipulator_playground for experimental work, and a ros2_controller directory for the controller layer. A file named open_manipulator_ci.repos sits alongside them, which by naming convention is the kind of file used to pin dependency repositories for continuous integration. Reading the directory names tells you the shape of the stack even though the README never explains it. This is a vendor integration repository, not a tutorial, and a reader coming in expecting a working example will not find one here.

The README is a directory of links rather than a build guide

It helps to say what the README does not contain, because that shapes what you can expect. There is no installation section, no source build command, no launch file example and no list of dependencies. What it does contain is a set of pointers. Documentation for the OMY platform is linked from ai.robotis.com, and documentation for the OpenMANIPULATOR-X sits on the ROBOTIS eManual. A separate link points to the Physical AI Tools repository, and another to the Simulation Models repository for exploring the platforms in simulation. Tutorial videos are hosted on the ROBOTIS Open Source Team channel, and datasets and pre-trained models for the open source platforms are published on Hugging Face under the ROBOTIS organisation. Docker images for running the ROS packages together with the Physical AI tools are published to a registry, with the tags listed on Docker Hub. So the repository assumes you already know how to work with ROS 2 packages and will follow one of these pointers depending on whether your problem is documentation, simulation, data or deployment.

The package topics hint at a simulation and hardware path in parallel

The topic tags attached to the repository list moveit, gazebo, dynamixel, arduino, turtlebot, turtlebot3 and ros, alongside the manipulator and package tags. Read carefully, these are keyword labels rather than a feature list, but they do describe the intended span of the ecosystem. MoveIt appears as both a topic and as a directory in the form of open_manipulator_moveit_config, which is where motion planning setup lives, and the ros2_controller directory names the controller layer that a ROS 2 system needs to drive joint interfaces. Gazebo appears in the topics while the README points to a separate Simulation Models repository, so the simulation path lives next door rather than inside this tree. The dynamixel and arduino tags point to the servo and microcontroller ecosystem the hardware sits in, and the turtlebot tags suggest the mobile base that some configurations pair with the arm. None of this tells you which of those are exercised by any given launch file, and the README does not say.

Physical AI work is the stated purpose, with LeRobot named directly

The README states that the packages provide the interfaces and tools to control the robot, integrate with its sensors, and develop physical AI applications, and it names frameworks like LeRobot in that list. That is the clearest signal about who this is for. A researcher collecting demonstrations to train a manipulation policy does not want a hand written ROS 2 driver; they want a driver that exposes joints, gripper state and camera data in a form a learning stack can consume. Publishing pre-trained models and datasets on Hugging Face alongside the packages reinforces that reading, and the separate Physical AI Tools repository suggests the training side lives in its own project rather than being mixed into the driver code. The separation is sensible, but it also means that adopting the physical AI path means depending on at least two repositories, and the README does not describe how their versions are kept in step.

Docker is the documented route for running packages and tools together

For anyone who does not want to resolve a ROS 2 workspace by hand, the README points to published Docker images for running the ROS packages and the Physical AI tools with the OpenMANIPULATOR, with the tag list on Docker Hub. That is a practical answer to the missing install section: the container is the distribution channel, and the repository itself assumes you will obtain a working environment from there or from your own ROS 2 setup. The images are relevant for two distinct use cases. A developer on a laptop can use a container to run the same package versions without polluting a local workspace, and a deployment can pin an image tag so that a manipulator behaves the same way on the test bench and in the field. The README does not list the image tags, the base distributions, the CUDA versions, or the robot model each image expects, so the tag list on the registry is the only place to check that.

Two platforms are documented in parallel, OMY and OpenMANIPULATOR-X

The documentation links split cleanly by platform. One path leads to the OMY documentation on ai.robotis.com, the other to the OpenMANIPULATOR-X overview in the ROBOTIS eManual, and the repository description names both AI Manipulator and Open Manipulator. For a reader, this split is the first decision to make, because the packages in this tree are described as the official packages for the OpenMANIPULATOR platform while the OMY documentation is hosted on a separate site, which suggests the two systems are supported through different combinations of packages and documentation. The distinction matters in practice: configuration files, joint names and controller setup are hardware specific, and picking the wrong documentation path sends you looking for parameters that do not exist. The README offers no migration notes between the two, and no compatibility table, so the documentation site for your own arm is the place to establish what the packages in this repository are expected to drive.

Apache-2.0 and a release train that tracks the hardware

The licence is Apache-2.0, with the terms in the LICENSE file, which is a permissive grant carrying the usual notice and patent conditions, and this is a vendor repository for a vendor's own platform. The release record is dense and recent: version 5.1.4 was published on 2026-10-19, 5.1.3 on 2026-09-28 and 5.1.2 on 2026-09-15, and the last push was on 2026-10-20. This is a project that ships on a schedule tied to the hardware rather than a hobby, and that has consequences for upgrade planning. Patch level changes to the packages can arrive every one or two weeks, and because the repository also contains a repository index file for continuous integration, those releases are what pin the versions of the surrounding ROS ecosystem for your build. There are no GitHub releases older than the current series listed here, and the repository does not publish a changelog, so the practical way to see what changed between two versions is to diff the package trees directly.

Editorial conclusion

open_manipulator is the right starting point for a team that owns an OpenMANIPULATOR or an OMY and wants the vendor's own ROS 2 interfaces, description files and MoveIt configuration rather than a hand rolled stack, and for teams that plan to train policies with LeRobot because the repository positions itself explicitly for physical AI work. It is the wrong choice if you want a self contained tutorial, since the README contains no install commands, no build steps and no example launch file, and it offers nothing to a team with no robot and no interest in the vendor's hardware. Verify three things before you commit to the packages: which of the two documented platforms, OMY or OpenMANIPULATOR-X, matches the arm in front of you, which ROS 2 distribution the pinned repositories in open_manipulator_ci.repos resolve to, and whether the Docker images at the published registry match your GPU and network environment. The project is Apache-2.0 licensed and the last push was on 2026-10-20, so the packages move with the hardware releases.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. ROBOTIS-GIT/open_manipulator on GitHub