---
service: "Publicasta"
schema_version: "1.0"
article_id: 625
title: "OpenArm 2.0 makes reproducible physical-AI experiments the real open-source project"
language: "en"
default_language: "en"
canonical_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=en"
json_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=en"
api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/openarm_2_reproducible_physical_ai_research_stack?lang=en"
channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar"
channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles"
search_url: "https://publicasta.com/api/public/v1/search"
documentation_url: "https://publicasta.com/api-docs#reading-publicasta"
openapi_url: "https://publicasta.com/api-docs/openapi.json"
published_at: "2026-09-16T13:58:09+00:00"
updated_at: "2026-09-16T13:58:09+00:00"
translations:
  - language: "ar"
    html_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=ar"
    markdown_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=ar"
    json_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=ar"
  - language: "de"
    html_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=de"
    markdown_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=de"
    json_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=de"
  - language: "en"
    html_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=en"
    markdown_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=en"
    json_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=en"
  - language: "es"
    html_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=es"
    markdown_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=es"
    json_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=es"
  - language: "fr"
    html_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=fr"
    markdown_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=fr"
    json_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=fr"
  - language: "pl"
    html_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=pl"
    markdown_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=pl"
    json_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=pl"
  - language: "ru"
    html_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=ru"
    markdown_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=ru"
    json_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=ru"
  - language: "zh"
    html_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack?lang=zh"
    markdown_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.md?lang=zh"
    json_url: "https://publicasta.com/open_source_radar/openarm_2_reproducible_physical_ai_research_stack.json?lang=zh"
---

# OpenArm 2.0 makes reproducible physical-AI experiments the real open-source project

> OpenArm 2.0 is more than a seven-degree-of-freedom arm. Its value is the attempt to connect open hardware, ROS 2, simulation, teleoperation, datasets, and a shared evaluation cell into a workflow that other labs can actually repeat.

A robot arm is easy to photograph and difficult to reproduce. Two laboratories can buy nominally identical hardware, run the same policy, and still collect data under different camera positions, lighting, calibration routines, controller settings, and task definitions. When the result improves, it becomes hard to tell whether the model got better or the experiment simply changed around it.

 ![A generic collaborative robot arm in a standardized research evaluation cell with cameras and calibration objects.](https://publicasta.com/storage/projects/10/pages/625/2026/09/e99395d4-f3a9-45ec-876e-344b3e9b036c.webp)

 That is the problem OpenArm 2.0 is trying to address. Enactic’s project is presented as an open-source seven-degree-of-freedom humanoid arm, but the important change is broader than the mechanism. The 2.0 lineup combines the arm with an evaluation cell, a data format, simulation environments, ROS 2 packages, teleoperation workflows, and an eventual passive teaching device. The aim is to make physical-AI experiments portable between machines and, eventually, between labs.

 The project has attracted attention because the hardware is unusually accessible by research-robotics standards: the project advertises a complete bimanual system at $6,500, with assembled and DIY paths. That price matters, but it is not the strongest reason to pay attention. The more consequential idea is that a robot should be treated as a reproducible software-and-data platform, not as a one-off research fixture.

 OpenArm is still under active development. Its own documentation flags unstable hardware bridges, ongoing MoveIt 2 work, and an unreleased KER leader device. The sensible question is therefore not whether it is ready to replace every laboratory platform. It is whether the open stack is already useful for a particular class of researcher—and whether its limitations are visible enough to manage.

 ## What OpenArm 2.0 actually adds

 OpenArm 1.0 established the basic proposition: a human-scale arm with public hardware designs, software, and documentation. The 2.0 release keeps the core mechanical envelope while reorganizing the project around a workflow. Enactic’s [2.0 overview](https://docs.openarm.dev/overview/whats-new-in-2.0/) describes three connected pieces: the OpenArm 2.0 arm, the OpenArm Cell, and OpenArm KER. The last of those is not released yet, so it should be understood as a planned component rather than something buyers can use today.

 The arm remains a seven-degree-of-freedom design mounted on a MISUMI-frame base. The published specifications list a nominal payload of 4.1 kilograms and a peak payload of 6.0 kilograms, including the end effector. Those figures are useful for understanding the intended research envelope, but they are not a promise that every payload is safe in every posture or motion. The documentation defines the nominal figure under a worst-posture, one-minute condition and distinguishes it from a short-duration peak load. A gripper, camera, tool, or custom fixture consumes part of that budget.

 The OpenArm Cell is the more important addition for reproducibility. It provides a standardized environment with consistent background, lighting, and camera placement. That sounds mundane until a team tries to compare demonstrations recorded months apart. A change in a ceiling camera’s height can alter the apparent size of an object. A different light can change reflections on a cup or the contrast around a cable. A new table surface can turn a learned grasp into a benchmark-specific trick.

 A cell does not solve every source of variation, but it creates a common reference. The [project site](https://enactic.ai/) describes the cell as a way to support automatic evaluation and compare robot policies across iterations. This is a more useful promise than the usual claim that open hardware will democratize robotics. Lowering the cost of a platform helps more people obtain it; standardizing the experiment helps them learn from one another.

 The third component, KER, is designed as a passive, motorless teaching device. Enactic says the zero-actuator design is light enough to wear or mount near the operator and is intended to reduce fatigue during long teleoperation sessions. It is also explicitly not available yet. That distinction matters because the current data-collection story depends on the tools already released: VR/WebXR teleoperation, simulation, and direct control of the physical arm.

 ## The software stack is the real product

 The repository is divided into pieces that map to recognizable research jobs. The main project links to hardware CAD, a robot description, a CAN control library, ROS 2 integration, teleoperation nodes, simulation environments, a dataset library, and connections to Dora, a dataflow framework. The [software guide](https://docs.openarm.dev/api-reference/) describes the stack as a set of components for robot description, high-frequency motor control, CAN configuration, ROS 2 middleware, and independent Python processes for control, recording, and inference.

 That modularity is valuable because robotics teams rarely agree on one complete framework. A group may want ROS 2 for controllers and MoveIt 2 for planning, MuJoCo for dynamics experiments, a custom policy server for inference, and a separate storage format for demonstrations. OpenArm does not force all of those interests into a single monolithic application. Instead, it exposes interfaces that can be replaced or extended.

 The trade-off is that the user inherits integration work. “Open” does not mean “one command and finished.” The installation guide is built around Ubuntu and recommends ROS 2 Humble, while Jazzy support is described as work in progress and potentially unstable. The ROS 2 package requires controller and hardware-interface dependencies. Real hardware requires CAN interfaces and the appropriate low-level library. A team without ROS experience will spend time learning middleware before it reaches the experiment it cares about.

 The [ROS 2 control documentation](https://docs.openarm.dev/api-reference/ros2/control/) makes the boundary clear. The package can expose position, velocity, and torque commands and can run against mock hardware, which is helpful for testing. But the same page warns that hardware-bridging components are being updated, that the gripper bridge is particularly active, and that MoveIt 2 integration is under development. Those warnings are not a footnote; they define the difference between a promising research platform and a mature production robot.

 A practical evaluation should begin with the fake-hardware path. If a team cannot launch the robot description, inspect joint states, and run a simulated control loop, purchasing the arm will not remove the software problem. It will add motors, power electronics, calibration, mechanical limits, and safety procedures to it.

 ## Simulation is useful before the robot arrives

 OpenArm’s MuJoCo support gives the project a stronger entry point than a hardware-only kit. The [simulation guide](https://docs.openarm.dev/simulation/mujoco/) provides MJCF files for the arm and bimanual configuration and explains how to load them into MuJoCo’s simulator. The project uses torque control in simulation, which is closer to the control problem a research team must solve than a simple animation of joint angles.

 The documentation also describes the simulation as a place to test the data-collection workflow. With WebXR, a researcher can use VR controllers to operate a MuJoCo version of the arm, record episodes, inspect the resulting data, and convert it to a training format without owning the physical hardware. The [WebXR tutorial](https://docs.openarm.dev/tutorial/data-collection-webxr/) includes a complete path through a local data-collection interface, a browser-based VR controller, success and failure labels, and an OpenArmDataset output directory.

 That ordering changes how a lab can de-risk a project. A team can first ask whether an operator can perform the task reliably. It can test whether the task representation records the observations it needs. It can build a policy-training pipeline and determine whether the inference interface is fast enough. Only then does it need to confront the cost and safety requirements of the real arm.

 Simulation will not reveal everything. Contact dynamics, cable drag, motor temperature, backlash, sensor noise, object variability, and emergency-stop behavior can invalidate a policy that looks good in MuJoCo. The guide itself says the ROS 2 bridge for realistic hardware mocking was still to come after the earlier release. Simulation should therefore be treated as an integration and iteration tool, not as evidence that a physical deployment will work.

 There is another practical wrinkle: WebXR requires HTTPS. The tutorial asks the operator to generate a certificate, open a local page, and accept a self-signed certificate on the VR device. This is manageable for a lab, but it is exactly the sort of detail that disappears from a launch announcement and consumes an afternoon during setup. The documentation’s value is that it exposes the detail before the experiment.

 ## The dataset layer addresses a neglected problem

 Robotics projects often publish a model and a short demonstration video while leaving the data pipeline implicit. That makes it difficult to reproduce an experiment even when the hardware is available. OpenArm’s dataset work is an attempt to make the episode itself a first-class artifact.

 The [dataset documentation](https://docs.openarm.dev/dataset/) describes a directory structure containing episodes, action and state data, camera streams, metadata, and task information. The API is designed around a directory on disk rather than a database service. Metadata is read up front, while the rest of the data can be accessed as needed. This is a sensible shape for large recordings: teams can move a dataset with ordinary files, inspect its metadata, and process only the cameras or episodes required for a given job.

 The API reference documents changes in the 0.3.0 dataset layout. State data is split into position, velocity, and torque tables for each arm side, while older layouts may expose only position data. The library also includes a conversion path to LeRobot v2.1 through both Python and a command-line entry point. That bridge matters because a project-specific format is only useful if researchers can take their data into the broader ecosystem.

 The format does not magically make a dataset comparable. Researchers still need to record camera calibration, robot version, gripper configuration, object identity, task instructions, operator details, timing, failed attempts, and environmental conditions. A consistent file layout is the floor, not the ceiling. The advantage is that OpenArm gives those fields somewhere to live and provides an API rather than asking every lab to invent its own conventions.

 The success and failure controls in the WebXR tutorial are also significant. Learning systems are sensitive to what counts as a successful episode. If one team stops recording after a nearly successful grasp and another labels only completed placements as success, their datasets are not interchangeable even if the robots and cameras match. Explicit episode marking will not eliminate subjective labeling, but it makes the decision visible and machine-readable.

 ## Inference is separated from the robot runtime

 OpenArm’s inference workflow draws a useful boundary between policy code and robot control. The [inference guide](https://docs.openarm.dev/tutorial/inference/) describes a policy server that receives an observation bundle containing camera data and joint positions, runs a model, and returns a chunk of joint-position actions. The runtime is organized as a Dora dataflow, while the model-specific code lives behind a local socket contract.

 That separation has several benefits. A policy author can adapt a model without rewriting the hardware transport. A team can replace the model server while keeping the observation and action plumbing stable. A failure in the model process can be handled as a process-level event rather than being entangled with every motor-control function. It also makes the interface easier to inspect: inputs, outputs, timestamps, and action dimensions can be tested independently.

 The boundary is not a complete safety system. Returning a valid JSON action chunk does not make an action safe. The controller still needs limits, watchdog behavior, collision handling, a physical emergency stop, and an operator who can intervene. A model that performs well in an offline replay may produce unsafe commands when a camera is occluded or a joint state is delayed. The open stack makes it possible to review these layers, but the responsibility remains with the integrator.

 This is where OpenArm’s compliance and backdrivability claims should be interpreted carefully. They describe mechanical properties intended to support contact-rich work and safer interaction. They do not remove the need for a risk assessment, guarded testing, conservative velocities, or a clear operating envelope. A robot that can be moved by a person is not automatically safe around every person, object, or control policy.

 ## Who should try it now

 OpenArm 2.0 is a plausible fit for researchers who want to study imitation learning, teleoperation, bimanual manipulation, robot learning from demonstrations, or policy evaluation in a controlled cell. It is also interesting for engineers building tooling around physical-AI datasets, simulation-to-real transfer, ROS 2 control, and local inference. The ability to begin in MuJoCo and move toward hardware gives these groups a concrete development path.

 It may be especially useful for small academic labs and independent researchers who cannot justify a proprietary research platform but can build a system around public CAD, commodity components, and open middleware. The DIY option also changes the relationship between the researcher and the machine. A team can inspect the bill of materials, adapt fixtures, understand the control path, and contribute improvements upstream. That is a better learning environment than a sealed robot whose failure mode is “contact the vendor.”

 It is less suitable for a group that needs a turnkey production cell, a long-term support contract, validated industrial safety certification, or guaranteed compatibility with a fixed commercial automation stack. It is also a poor first robotics project for someone who has no interest in Linux, ROS 2, electromechanical debugging, or dataset engineering. The low purchase price relative to research robots does not make the total cost low. The lab still needs computers, power and communication hardware, tooling, cameras, VR equipment if using WebXR, spare parts, fixtures, and time.

 A sensible first project would be narrow: one object, one workspace, one gripper configuration, and a small number of operator demonstrations. The goal should be to measure the entire loop—recording, labeling, training, inference, recovery—not to produce a spectacular demo. If the team can reproduce its own result after changing machines or rebuilding the workspace, it has learned something important about the platform.

 ## What to inspect before buying

 The first inspection should be licensing. The main repository lists a mix of licenses across the project: the hardware repository uses CERN-OHL-S-2.0, while several software repositories use Apache-2.0. The [OpenArm repository](https://github.com/enactic/OpenArm) links each major component and identifies its license. A lab planning to modify CAD, redistribute a build, bundle firmware, or publish a commercial derivative should read the license for each component instead of treating “fully open source” as one universal legal category.

 The second inspection should be version alignment. OpenArm has v1.0 and v2.0 models, multiple repositories, submodules, ROS 2 distributions, and evolving documentation. A tutorial may work for one arm revision and require adjustments for another. Pinning repository commits, recording the ROS distribution, and keeping a machine-readable bill of materials are basic reproducibility practices. They are particularly important for a physical platform, where a small mechanical change can alter calibration and control behavior.

 The third inspection should be the gap between a mock system and a real one. Run the fake-hardware launch files. Load the MJCF. Collect a small dataset. Convert it to the intended training format. Implement a policy server that emits actions but does not move a motor. Then read the real-hardware instructions and identify every component that is still ambiguous: CAN adapters, motor configuration, gripper behavior, calibration, limits, startup sequence, and recovery from communication loss.

 The fourth inspection should be maintainership. GitHub shows active repositories and recent work across the OpenArm organization, but activity is not the same as support maturity. Look at open issues, release notes, the contribution guide, breaking changes, test coverage, and how hardware regressions are communicated. A robot platform is a dependency with physical consequences. If an update changes a controller parameter, the result may be more than a failed build.

 The [release history](https://github.com/enactic/OpenArm/releases) shows the project developing through incremental hardware and software revisions, including changes to the casing, gripper, ROS 2 packages, payload-related components, and simulation files. That is normal for a young platform. It also means a buyer should budget for maintenance and should not assume that a repository snapshot is equivalent to a supported product release.

 ## Alternatives and the question OpenArm leaves open

 Researchers do have alternatives, but they usually optimize for a different constraint. Commercial arms can provide mature support and industrial integration. Established academic platforms may offer a larger body of published work, known calibration procedures, or a more settled data ecosystem. Low-cost educational manipulators reduce the barrier to entry, although they may not offer the payload, compliance, or bimanual workflow OpenArm targets. Simulation-only platforms avoid hardware cost but cannot answer questions about real contact and sensing.

 OpenArm’s distinctive choice is to put hardware, simulation, data collection, and evaluation in one open project. That creates an opportunity for shared benchmarks, but only if the community resists the temptation to publish isolated demos. The useful unit of progress is not merely a new policy running on one robot. It is a task, dataset, environment description, evaluation script, and versioned software stack that another group can run and challenge.

 The project also exposes a broader tension in open robotics. Making CAD public does not automatically create a community. Community forms when the parts are documented, affordable enough to obtain, stable enough to use, and structured enough to compare. OpenArm’s 2.0 work on the Cell and Dataset is aimed at that middle layer between an open design and a functioning research ecosystem.

 That layer will take time. The KER device is not yet released. The hardware bridge and gripper integration are still marked as active work. Jazzy support is not presented as fully settled. Physical safety, supply availability, assembly quality, and calibration will vary between builds. The project’s openness makes these risks easier to investigate, not automatically smaller.

 ## The practical verdict

 OpenArm 2.0 is worth trying if the experiment you want to run is about learning from physical interaction and you are willing to own the integration. Its strongest contribution is not the claim of a humanoid form factor or the headline price. It is the attempt to connect the pieces that usually remain disconnected: an inspectable robot, a simulation model, a teleoperation interface, a structured dataset, a policy boundary, and a repeatable evaluation environment.

 For a researcher, the best starting point is the software path. Use the fake hardware, inspect the robot description, run the MuJoCo model, collect WebXR demonstrations, and examine the OpenArmDataset output. Check how much of the intended task survives conversion to the training framework. Only after that should the lab decide whether the physical arm and cell answer a question that simulation cannot.

 For a buyer, the advice is equally concrete: pin versions, read the licenses, plan for safety engineering, and treat the current documentation warnings as part of the product specification. OpenArm is not a turnkey industrial robot. It is a public, evolving research stack whose value will be measured by how well other teams can reproduce, modify, and extend the work.

 That is a demanding standard, but it is the right one. Physical AI will not become more credible because another robot produces a polished video. It becomes more credible when the same experiment can be inspected, repeated, failed safely, and improved by people who did not build the original machine.