OpenArm: A 7DOF Humanoid Arm Split Across Ten Repositories
A fully open-source humanoid arm for physical AI research and deployment in contact-rich environments.
At a glance
- What is it?
- OpenArm is an Apache-2.0 humanoid arm platform for contact-rich physical AI research, sold as a $6,500 bimanual system and distributed as ten separate repositories. The split is deliberate, but it means the arm is a hardware project first and a software project second.
- Who is it for?
- Adopt OpenArm if you need a backdrivable 7DOF arm for teleoperation, imitation learning or contact-rich data collection and you are willing to work through a multi-repository ROS2 stack. Do not adopt it if you want a single pip install, a mature industrial manipulator with a support contract, or a simulation-only workflow that never touches CAN hardware.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly MDX, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem OpenArm Targets: Contact-Rich Manipulation Without an Industrial Price Tag
Most affordable robot arms are position-controlled and stiff. That is fine for pick-and-place, and wrong for anything where the arm has to touch a person, a deformable object, or a surface it cannot model precisely. The README states OpenArm is built with high backdrivability and compliance, explicitly for safe human-robot interaction, and describes the target as physical AI research and deployment in contact-rich environments. Backdrivability matters here because it lets a human push the arm out of the way, and it lets a controller infer contact force from motor current rather than from a wrist sensor. The intended audience is research groups and companies doing teleoperation, imitation learning, simulation, and real-world data collection. The price point named in the README is $6,500 USD for a complete bimanual system, which is the number that makes the project interesting: it puts a two-arm setup with force feedback within reach of a university lab rather than a corporate robotics budget. OpenArm Cell, the standardized environment shown alongside the arm, is the second half of the pitch. Unified background, lighting and camera placement mean a policy trained in one lab can be evaluated under the same conditions in another, which addresses a real reproducibility problem in embodied AI papers.
Ten Repositories, One Arm: What the Split Buys and What It Costs
The top-level repository is documentation and coordination. The actual system lives in ten sibling repositories, each with its own licence file and its own documentation page. openarm_hardware holds STL, STEP and Fusion 360 assemblies. openarm_description holds URDF and xacro files for simulation. openarm_can is the low-level motor communication library. openarm_ros2 provides the ROS2 integration packages and nodes. openarm_teleop covers unilateral and bilateral control. openarm_isaac_lab and openarm_mujoco are the two supported simulators. openarm_dataset defines the dataset format plus recording tools and a Python API. dora-openarm provides Dora dataflow nodes for data collection, inference and teleop. The upside is that a simulation user never has to clone the CAN driver, and a hardware user never has to install Isaac Lab. The cost is version skew: nine of the ten repositories carry Apache-2.0, but openarm_hardware is CERN-OHL-S-2.0. That is the correct licence for open hardware and it is not a problem in itself, but it means the phrase open source means two different things depending on which directory you are standing in. Anyone planning to manufacture from the CAD needs to read the CERN-OHL-S-2.0 text, which is a strongly reciprocal licence for hardware designs, separately from the Apache-2.0 terms that cover the software.
How the Stack Is Layered: CAN at the Bottom, ROS2 in the Middle, Teleop and Learning on Top
The dependency direction is visible in the repository descriptions. openarm_can handles low-level motor communication, which in a backdrivable arm means reading joint state and commanding torque or current over a CAN bus. openarm_ros2 wraps that into ROS2 nodes so the arm appears as a standard ROS2 device. openarm_teleop sits above ROS2 and implements both unilateral and bilateral control, the latter being what makes force feedback possible: the leader and follower exchange force information rather than just position. openarm_dataset is orthogonal to the control path. It defines a dataset format, recording tools and a Python API, which is the piece that turns a teleoperation session into training data. dora-openarm overlaps with teleop and dataset but uses Dora dataflow nodes, so the same collection and inference tasks can be expressed as a dataflow graph instead of a ROS2 node graph. Two simulation targets exist rather than one: MuJoCo for the specification files and assets, Isaac Lab for training tasks. That duplication is a real maintenance surface. A change to the URDF in openarm_description has to stay consistent with the MuJoCo spec in openarm_mujoco and with whatever Isaac Lab consumes, and the README does not describe an automated check that keeps the three in sync.
Getting It Running: Install Paths Named in the Documentation
The README does not inline install commands. It points to per-repository documentation pages, and the ROS2 install page is linked as docs.openarm.dev/api-reference/ros2/install, the CAN page as docs.openarm.dev/api-reference/can, and the teleop page as docs.openarm.dev/teleop. The dataset, simulation, MuJoCo, Isaac and Dora pages follow the same pattern under docs.openarm.dev. That is the honest state of the material: the entry point is the documentation site, not a shell snippet in the README. What the README does establish is the ordering. For a real arm you need openarm_can before openarm_ros2, because the ROS2 nodes depend on the CAN library for motor communication. For teleoperation you add openarm_teleop on top of a working ROS2 bringup. For simulation without hardware, openarm_mujoco or openarm_isaac_lab plus openarm_description is the relevant pair, since the description repository is the one that carries the URDF and xacro. For data collection you add openarm_dataset or dora-openarm depending on whether you want a ROS2 graph or a Dora dataflow. There is also a purchase path documented at docs.openarm.dev/purchase, which lists manufacturers, and the README notes the arm is available assembled or as a DIY kit. I have not installed any of these packages, so I cannot report what the install actually does or how long it takes.
Where OpenArm Is the Wrong Tool
The compliance that makes OpenArm suitable for contact-rich work is the same property that makes it unsuitable for tasks needing high stiffness and repeatability. A backdrivable joint is, by construction, easier to move under load, so if your application is milling, precision insertion with tight tolerances, or anything where a disturbance force must be rejected rather than measured, a stiff industrial arm is the correct choice and OpenArm is not. The second limitation is the repository structure itself. Ten repositories with independent release cadences means adopting OpenArm is closer to adopting a distribution than adopting a library. The release history shows 0.2 in April 2025, 0.3 in May 2025, and 1.1 in October 2025. Three tagged releases in roughly six months is a fast-moving project, and the README states plainly that development is continuous and that the project is actively seeking contributors and research partners. Fast movement plus a multi-repo layout is a combination that rewards pinning versions and punishes tracking main. The third limitation is documentation depth. The README is a directory of links; the substance lives on the external site, and this material does not include the contents of those pages. Anyone evaluating OpenArm for a funded project should read the per-repository docs before treating the platform as production-ready, because the README alone does not describe failure modes, calibration procedures, or the CAN bus configuration.
Alternatives and the Actual Difference in Approach
The obvious comparison is a conventional 6DOF industrial arm driven through MoveIt 2. OpenArm lists moveit2 as a topic, so it is not an alternative to MoveIt but a consumer of it. The real difference is in the joint count and the actuation philosophy. OpenArm has 7DOF, one more than a typical industrial 6DOF arm, which gives a redundant degree of freedom for elbow placement and makes nullspace control possible. More importantly, the arm is designed for backdrivability rather than stiffness, so the control interface is torque-oriented and force feedback is available without an external force-torque sensor. A second comparison is simulation-first humanoid platforms: if your work is purely in Isaac Lab or MuJoCo and you never intend to touch hardware, OpenArm's value proposition is thinner, because you are paying the complexity of a CAN stack and a hardware repository for assets you could approximate. The counter-argument is OpenArm Cell. A standardized physical environment with fixed lighting and camera placement is something a purely synthetic benchmark cannot provide, and the README frames reproducibility across labs as a primary goal. A third comparison is the DIY arm ecosystem built on hobby servos. Those are cheaper and simpler, but they generally lack the compliance and force-feedback path that bilateral teleoperation in openarm_teleop assumes, so the comparison collapses at the point where contact matters.
Maintenance, Licensing and What to Pin
Maintenance cost for OpenArm is dominated by the repository count, not by any single component. Nine Apache-2.0 repositories and one CERN-OHL-S-2.0 repository means two licence review paths: a standard permissive review for the software, and a reciprocal hardware licence review if you intend to manufacture or modify the CAD. Apache-2.0 includes an express patent grant and requires attribution and notice retention, which is straightforward for internal research use and needs a check before redistribution. CERN-OHL-S-2.0 is a copyleft licence for hardware designs, so modifications to the CAD carry obligations that Apache-2.0 does not impose. This is not legal advice; the point is that a team treating OpenArm as uniformly Apache-2.0 is making an assumption the repository layout contradicts. On upgrades, the practical move is to pin the tagged releases rather than track main. The releases named in the material are 0.2 (April 2025), 0.3 (May 2025) and 1.1 (October 2025), and the jump in numbering from 0.3 to 1.1 suggests a stabilization step rather than an incremental patch. Because openarm_can and openarm_ros2 sit in different repositories, an upgrade to one without the other is the most likely source of breakage, and the material does not describe a compatibility matrix that would tell you which pairs are known to work together.
Editorial conclusion
Adopt OpenArm if you need a backdrivable 7DOF arm for teleoperation, imitation learning or contact-rich data collection and you are willing to work through a multi-repository ROS2 stack. Do not adopt it if you want a single pip install, a mature industrial manipulator with a support contract, or a simulation-only workflow that never touches CAN hardware. Before committing, verify two things: the exact licence of the CAD you plan to manufacture from (the hardware repository uses CERN-OHL-S-2.0, not Apache-2.0), and the release notes for 1.1 against the API in openarm_can and openarm_ros2, since the project has shipped three tagged releases in under a year.
Community notes