OpenArm: a 7DOF humanoid arm you can buy, simulate and teleoperate

What OpenArm is, and who the repository is actually for

OpenArm is described in the README as "an open-source 7DOF humanoid arm designed for physical AI research and deployment in contact-rich environments." Seven degrees of freedom puts it in the same joint-count class as a human arm rather than a tabletop manipulator, and the README ties that choice to human-scale proportions, compliance and backdrivability. The stated use cases are teleoperation, imitation learning, simulation and real-world data collection.

The audience is narrower than the phrase "open source" usually implies. This repository is not the arm's software. Its top level holds a README, a code of conduct, a contributing guide, a licence, editor config and a website directory. The engineering lives in nine sibling repositories listed in a table: openarm_hardware for CAD, openarm_description for URDF and xacro, openarm_can for motor communication, openarm_ros2 for ROS2 packages, openarm_teleop for unilateral and bilateral control, openarm_isaac_lab and openarm_mujoco for simulation, openarm_dataset for recording tools and a Python API, and dora-openarm for Dora dataflow nodes. Anyone who clones enactic/openarm expecting to find a robot driver will be disappointed; the README is an index.

That structure tells you who the project is for. A robotics lab with ROS2 experience can assemble a stack from those pieces. A software team that wants a Python object with a move method cannot, because no single repository in the table promises that.

The $6,500 bimanual price and what the OpenArm Cell standardises

The README states the price directly: "At $6,500 USD for a complete bimanual system." That figure covers two arms, not one, which matters when comparing against industrial arms sold per unit. The README also points to a purchase page at docs.openarm.dev/purchase for assembled or DIY units from "verified and certified manufacturers worldwide." The repository does not publish a bill of materials with per-part costs, so the split between the arms, the CAN interface hardware and any mounting is not visible from the README alone.

The OpenArm Cell is the part of the pitch that is easy to skip. The README describes it as "a standardized environment with unified background, lighting, and camera placement," and the argument is reproducibility: a policy trained in one lab's cell should be evaluable in another's, because the camera positions and lighting are fixed rather than improvised. That is a real methodological problem in manipulation research, where results often depend on a camera angle nobody documented. Whether the standard is adopted widely enough to matter is a separate question, and the README does not cite any external labs using it.

The image referenced in the README, website/static/img/hardware/openarm_and_cell.png, shows the arm in the cell environment. That is the only visual evidence in the repository itself; the rest of the media lives on the project homepage.

How the software stack is layered, from CAN frames to ROS2

The repository table implies a four-layer stack, and the layering is worth reading carefully because it determines what you can swap out.

At the bottom, openarm_can is described as a "CAN control library for low-level motor communication." CAN is the bus the motors speak, so this package owns the timing-sensitive part: sending setpoints and reading joint state. Above it, openarm_ros2 provides "ROS2 integration packages and nodes," which is where a joint state publisher and the usual controller plumbing would live. openarm_description supplies the URDF and xacro that both ROS2 and the simulators consume, which is why the same model can appear in a real arm and in MuJoCo without being rewritten.

Simulation branches off the same description files. openarm_mujoco holds "MuJoCo specification files and assets," while openarm_isaac_lab holds an "Isaac Lab simulation environment and training tasks," which is the reinforcement learning path. Teleoperation sits alongside: openarm_teleop offers "unilateral and bilateral control," and the topics list force feedback and bilateral teleoperation, so the bilateral mode is the one that sends contact forces back to the operator. dora-openarm is the outlier, providing Dora dataflow nodes for data collection, inference and teleop, which suggests a graph-based alternative to plain ROS2 for wiring perception to action.

Two consequences follow. First, the URDF is the contract: if a variant of the arm is missing from openarm_description, nothing above it works. Second, the CAN layer is where a real deployment will spend its debugging time, because that is the only layer touching hardware timing.

Installing OpenArm software and running a first simulation

The README does not contain install commands. It routes installation to per-component documentation: the ROS2 install page at docs.openarm.dev/api-reference/ros2/install, the CAN docs at docs.openarm.dev/api-reference/can/, and the simulation pages at docs.openarm.dev/simulation/. Start there rather than guessing package names, because the repository table gives repository names (openarm_ros2, openarm_can) and not ROS package names or distribution targets.

Because the README does not document the install steps, no commands are reproduced here. What can be said from the repository layout is the order in which the pieces depend on each other. The description package is the base, since both ROS2 and the simulators read its URDF and xacro. The CAN library is only needed once real hardware is attached. The teleoperation and dataset packages sit on top of the ROS2 integration.

A reasonable first exercise, given that ordering, is to get the description files loading in a simulator before touching hardware. The MuJoCo assets are in openarm_mujoco and the Isaac Lab environment in openarm_isaac_lab; either can be used to confirm that the model loads and the joints move as expected. The README does not state which simulator is recommended for a first run, and it does not give a minimum host requirement for either.

For the real arm, the CAN documentation is the page to read before plugging anything in, since the README describes openarm_can as the low-level motor communication library and gives no wiring or interface details itself.

Force feedback, backdrivability and the limits of the pitch

High backdrivability is the property the README leans on hardest. A backdrivable arm can be pushed by hand without fighting the gearbox, which is what makes compliance and safe human-robot interaction plausible, and it is also what makes bilateral teleoperation useful: the operator feels contact through the leader arm. The topics list includes force-feedback and gravity-compensation, so gravity compensation appears to be a supported mode rather than something every user writes from scratch.

The limitation is that none of this is quantified in the repository. Payload is called "practical" without a number. Backdrivability is asserted without a measured figure. There is no published repeatability or accuracy specification in the README, and for contact-rich work those numbers decide whether a task is feasible. A lab that needs to state accuracy in a paper will have to measure it.

The second limitation is the hardware dependency itself. Every software component in the table ultimately assumes an arm on a CAN bus. Someone who only wants a simulated 7DOF arm for reinforcement learning can use the MuJoCo or Isaac Lab assets, but the README does not present the project as a simulation-only toolkit, and the value of the OpenArm Cell argument comes from matching simulation to a physical setup. If you never intend to buy hardware, the sibling repositories are still readable, but you are using a fraction of the project.

The third is maintenance surface. Nine repositories with different concerns means nine places where a ROS2 distribution change can break something. The README does not describe a compatibility matrix between the packages and ROS2 releases.

OpenArm against Franka and other research arms

The obvious alternative for contact-rich manipulation research is a Franka Emika arm, and the difference is not just price. Franka sells a closed hardware and software stack with a vendor behind it: one arm, one controller, one supported API, and torque sensing built into the joints. OpenArm inverts that. The CAD is published under CERN-OHL-S-2.0 in openarm_hardware, so the mechanical design is forkable and manufacturable by third parties, and the software is split across Apache-2.0 packages you assemble yourself. You trade a support contract for the ability to modify the arm and to buy it from more than one manufacturer.

Against a generic open-source arm such as a low-cost 6DOF hobby platform, the difference is the ecosystem rather than the mechanism. OpenArm ships a URDF, a MuJoCo model, an Isaac Lab environment, ROS2 nodes and a dataset format as separate maintained repositories. A hobby arm typically ships a serial protocol document and a Python script. That ecosystem is what makes imitation learning and teleoperation work out of the box, and it is also what makes the setup heavier.

A third comparison is simulation-only. If your work never leaves MuJoCo, a model-only project is lighter than OpenArm's nine repositories. OpenArm's counter-argument is the Cell: simulation that matches a physical standard environment is worth more than simulation that does not, provided you eventually use the physical arm.

Licensing across the nine repositories and what it means for derivatives

The licences are not uniform, and that is the detail worth checking before you plan a derivative. The top-level repository is Apache-2.0. In the table, openarm_description, openarm_can, openarm_ros2, openarm_teleop, openarm_isaac_lab, openarm_mujoco, openarm_dataset and dora-openarm are all listed as Apache-2.0. openarm_hardware is the exception: CERN-OHL-S-2.0, a strongly reciprocal hardware licence.

In practice that means software modifications can be kept proprietary under Apache-2.0 terms, while modified hardware designs carry the reciprocal obligation attached to CERN-OHL-S-2.0. If you plan to manufacture or sell a modified arm, read that licence rather than this article; the distinction between software and hardware licensing is exactly where a project like this creates obligations, and the repository itself only links to the licence text.

Upgrade cost is harder to assess from the README. The release history shows 0.2 in April 2025, 0.3 in May 2025 and 1.1 in October 2025, so the versioning moved from a 0.x line to 1.1 within about six months. The README does not publish a migration guide or a statement of what breaks between releases, so a lab pinning to a specific tag should expect to read the sibling repositories' release notes rather than a single changelog.

Editorial conclusion

OpenArm fits a lab that needs a human-scale, backdrivable 7DOF arm with published CAD, URDF and ROS2 packages, and that can absorb the cost of the hardware plus a CAN and ROS2 software stack. It is the wrong choice if you need a single pip install, a vendor support contract, or a robot that ships with a maintained end-to-end application. Before buying, confirm the current price and lead time with a manufacturer listed at docs.openarm.dev/purchase, check that the arm variant you pick has a URDF in openarm_description, and read the CAN and ROS2 install pages because those are the two places an integration will stall.

Frequently asked questions

Official sources

1. enactic/openarm on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases