OpenArm teleoperation: 7-DOF bimanual arms, bilateral force feedback and native LeRobot data

OpenArm is "an open-source 7DOF humanoid arm designed for physical AI research and deployment in contact-rich environments", run by Enactic. Each arm is sized for a person of about 160 to 165 cm, built on quasi-direct-drive backdrivable motors, and rated at 4.1 kg nominal and 6.0 kg peak. A complete bimanual system is listed at $6,500 on Enactic's OpenArm GitHub as of October 2026, as a DIY build or assembled through certified manufacturers. It is built into LeRobot, single and bimanual, and its own teleoperation stack offers bilateral force feedback. Seven joints, compliance and a native data path in one open design is what sets it apart.

OpenArm 1.0, 2.0 and the leader arms

Per What's new in 2.0, the 2.0 arm keeps the 1.0 form factor, motors (DM-J4310-2EC, DM4340, DM-J8009P) and payload, and adds a redesigned gripper with an in-hand camera and replaceable fingers that reaches into confined spaces more easily. The bigger change is the leader. In 1.0, the leader was a powered OpenArm driven leader-to-follower. For 2.0, Enactic is preparing KER, a motorless leader with magnetic encoders that is worn like a backpack, weighs 1.7 kg and attaches in about 30 seconds. Its joint structure matches OpenArm 2.0 with links scaled to 70%, which Enactic says allows 1:1 mapping without retargeting. KER is not yet released.

The leader question matters more on OpenArm than on small arms, because these are human-scale arms and a bimanual session means holding two of them up for hours. Enactic positions KER for long sessions, and its encoders and bearings are there to lower the operator's physical load. Whatever leader you use, fatigue shows in the data before the operator notices it: slower approaches, more hesitation, sloppier grasps toward the end of a shift. Plan rotations and breaks into the protocol, and compare clean-episode rates across the hours of a shift rather than only across operators.

Three ways to drive an OpenArm

Building the cell around the arms

OpenArm ships as arms, not as a workstation, so the data cell is your design. The choices you make here show up in every episode:

Control loop, CAN-FD and remote operators

OpenArm talks CAN-FD to Damiao motors through a USB CAN adapter, and that adapter has no macOS driver and is untested on Windows, so the robot host runs Linux. LeRobot's follower defaults to CAN FD at a 1 Mbps nominal and 5 Mbps data bitrate, exposes per-joint `position_kp` and `position_kd` gains, and leaves `max_relative_target` at None. LeRobot's OpenArm recording example runs at 30 fps. At 30 fps a step is about 33 ms, and every remote millisecond counts twice on a bimanual 7-DOF setup, because the operator coordinates fourteen joints against a delayed picture.

Our latency guide has budgets by task type; read it before assigning distant operators to an OpenArm cell.

Data: native LeRobot, and a very large public set

Because OpenArm is built into LeRobot, `lerobot-record` writes standard LeRobot datasets with no plugin. The largest public example is lerobot/full_folding: 5,688 episodes and over 14 million frames at 30 fps, in LeRobot format v3.0, with a 16-value state and action (seven joints plus a gripper per arm) and three cameras, two 1280×720 wrist views and a 640×480 base view. It is a useful reference for camera layout and for how long, contact-rich bimanual episodes look in practice.

For corrections on a trained policy, LeRobot's human-in-the-loop collection mode defaults to `bi_openarm_follower` with `bi_openarm_mini`: the operator pauses the policy, the leader moves to match the robot, the operator takes over to recover and correct, then hands back, all inside one recorded episode. Its examples use 30 fps with an interpolation multiplier that sends extra commands per policy step while recording stays at 30 fps. We deliver OpenArm episodes as LeRobot, RLDS or HDF5; the data collection guide has the QA checklist.

Payload and precision, honestly

OpenArm's payload figures are carefully defined, and worth reading before you plan a task. Nominal payload is what an arm can hold for one minute in its worst posture, fully extended; peak is what it can move down to that posture over 3 seconds and hold for 1 second. Both include the end effector, so a 1.5 kg end effector cuts nominal payload to 2.6 kg. Precision is the open question: a GitHub issue asking for precision and repeatability documentation is still open, with a maintainer replying that they need to run experiments first. Treat OpenArm as a compliance and contact platform, not a sub-millimetre placement arm.

What a good OpenArm operator does

OpenArm or a Trossen bimanual kit?

The closest alternative for bimanual teams is Trossen's Stationary AI, an ALOHA-style cell sold complete and recorded through Trossen's LeRobot plugin. OpenArm gives you a seventh joint per arm, backdrivable compliance, optional bilateral force feedback and native LeRobot support, but you build or source the rest of the cell yourself: frame, cameras, lighting and compute. For contact-rich tasks such as folding, or assembly where the operator needs to feel contact, OpenArm is the natural fit. For repeatable tabletop manipulation where you want a turnkey cell on day one, the Trossen kit is. Our Stationary AI page covers its specs and its data format, which differs from OpenArm's in joint count and camera layout.

How RoboPilots runs OpenArm teleoperation

Your arms stay in your lab. We agree the mode with you (LeRobot unilateral, Enactic's bilateral stack for operators on a short link, or supervised HIL collection), set up the Linux robot host on your side of a VPN, and train a dedicated group of operators on your unit and your task protocol before the first recorded episode.