ALOHA and Bimanual Manipulation: What Two Arms Buy You

The task that made ALOHA famous is opening a translucent condiment cup. The right gripper tips the cup over and nudges it into the waiting left gripper, which closes and lifts; a right finger then slides under the lid and pries it open. There is no one-armed version: the thing holding cannot also be the thing prying.

That is the case for a second arm, and Zhao et al. (arXiv 2304.13705, April 2023) built the cheapest credible rig for it: two big arms, two small arms you hold, four webcams and a cage, under 20,000 USD. What follows: what the second arm buys, how the puppeteering interface works, what changed across three hardware generations, and what it costs your dataset budget.

What the second arm actually buys you

The lazy version says two arms are twice as fast. That is not it. The interesting cases are the ones a single arm cannot produce at all.

That last row matters more than the successes. ALOHA gets 96 percent on slotting a battery but 20 percent on threading velcro, degrading at every subtask: 92 percent to lift the tie, 40 percent to grasp the tail, 20 percent to insert. Two arms give you access to the task, not ease.

The puppeteering rig, and why joint-space mapping won

The part people copy is the interface, not the arms. Teleoperation happens by physically backdriving a smaller arm. The small arm is a WidowX 250, the big one a ViperX 300; they share a kinematic structure, so the small arm's joint angles go straight onto the big one. This is the leader-follower scheme; the original repository still calls the sides master and puppet in its symlinks.

The alternative was task-space mapping: track a VR controller, run IK, command the end effector pose. The paper gives concrete reasons it did not.

1. Fine manipulation lives near singularities. The ViperX has 6 degrees of freedom and no redundancy, so off-the-shelf IK fails in exactly the configurations precise tasks need.
2. The leader arm has mass. Its weight stops the operator moving too fast and damps hand vibration. A VR controller weighs nothing and shakes.
3. Less computation means less latency in a loop running at 50 Hz.
4. A 3D-printed handle and scissor mechanism gives continuous gripper control instead of a binary button.
5. Rubber band load balancing cancels part of gravity on the leader side, which is what makes sessions longer than 30 minutes tolerable.

Three hardware generations, and what you can buy in 2026

ALOHA has been revised twice in public and the commercial version renamed. Check which generation an older tutorial describes: cameras, gripper and ROS version all changed.

Two ALOHA 2 details are worth stealing even if you never buy the hardware. The leader gripper motors were swapped from XL430-W250-T to XC430-W150-T, a lower gear ratio with metal rather than plastic gears, purely to cut backdriving friction. And ALOHA's rubber bands were replaced with passive hanging retractors, benchmarked against an active system computing torques from a MuJoCo inverse dynamics model: the passive springs won, 1.38 versus 0.97 shapes inserted per minute across six operators.

Buying one in 2026 does not get you the arms in the paper. Trossen's current kits are branded Trossen AI, and both the Stationary AI and the Mobile AI ship two leader-follower WidowX AI arm pairs, where the published ALOHA paired WidowX 250 leaders with larger ViperX 300 followers. The older ALOHA Stationary and ALOHA Mobile product pages are still online alongside the new ones, so it is easy to read a spec sheet from one generation and a price from another. Prices move; the point of quoting them is the ratio.

What two arms do to your dataset

A bimanual rig does not double the data problem, it changes its shape in three places: action vector, camera count, sampling rate. ALOHA records at 50 Hz, higher than most single-arm imitation learning setups, and every timestep carries four synchronised frames. Real numbers from two ALOHA datasets in LeRobot v3.0 format on the Hub, read 24 August 2026:

# Read the real shapes of any LeRobot dataset without downloading it
import json, urllib.request

repo = "lerobot/aloha_static_battery"
url = f"https://huggingface.co/datasets/{repo}/resolve/main/meta/info.json"
info = json.load(urllib.request.urlopen(url))

print(info["codebase_version"], info["fps"], "fps")
print(info["total_episodes"], "episodes,", info["total_frames"], "frames")
for key, feat in info["features"].items():
    print(f"{key:38s} {feat['dtype']:8s} {feat.get('shape')}")

Sixteen megabytes per twelve-second episode sounds harmless until you scale it. Note also that this port of the mobile dataset carries a 14-dimensional action, not the 16 the paper describes: the base velocities are not in it. Check features yourself. Conventions are in the dataset docs, and the public dataset directory shows what real recordings look like.

Recording a bimanual dataset with LeRobot

You do not need ViperX arms to try the idea. LeRobot 0.6.2 ships bi_so_follower and bi_so_leader, which compose two SO-100 class arms into one robot object. Left-arm observations get a left_ prefix, right-arm a right_ prefix, and top-level cameras stay unprefixed, so a shared overhead camera does not become left_top. The commands below come from docstrings in the current LeRobot source.

1. 1
   Find four serial ports

   Run once per arm, unplugging it when prompted. All four paths go into every command below.

   bash

   lerobot-find-port

2. 2
   Calibrate each arm

   Four arms, four calibration passes. LeRobot writes two files from the id you pass, one ending _left and one _right. Use a stable id or you recalibrate every session.

   bash

   lerobot-calibrate \
     --robot.type=bi_so_follower \
     --robot.left_arm_config.port=/dev/tty.usbmodem5A460822851 \
     --robot.right_arm_config.port=/dev/tty.usbmodem5A460814411 \
     --robot.id=bimanual_follower

3. 3
   Teleoperate before recording anything

   Drive both followers and watch the streams. If a joint moves the wrong way or a wrist camera is mirrored, fix it now. Episodes with a broken mapping get deleted.

   bash

   lerobot-teleoperate \
     --robot.type=bi_so_follower \
     --robot.left_arm_config.port=/dev/tty.usbmodem5A460822851 \
     --robot.right_arm_config.port=/dev/tty.usbmodem5A460814411 \
     --robot.id=bimanual_follower \
     --robot.left_arm_config.cameras='{ wrist: {"type": "opencv", "index_or_path": 1, "width": 640, "height": 480, "fps": 30} }' \
     --robot.right_arm_config.cameras='{ wrist: {"type": "opencv", "index_or_path": 2, "width": 640, "height": 480, "fps": 30} }' \
     --teleop.type=bi_so_leader \
     --teleop.left_arm_config.port=/dev/tty.usbmodem5A460852721 \
     --teleop.right_arm_config.port=/dev/tty.usbmodem5A460819811 \
     --teleop.id=bimanual_leader \
     --display_data=true

4. 4
   Record the handover

   Pick a task that needs both arms. The docstring uses a cube handover, the right instinct: if the task can be done one-handed, your dataset teaches the policy to ignore an arm.

   bash

   lerobot-record \
     --robot.type=bi_so_follower \
     --robot.left_arm_config.port=/dev/tty.usbmodem5A460822851 \
     --robot.right_arm_config.port=/dev/tty.usbmodem5A460814411 \
     --robot.id=bimanual_follower \
     --robot.left_arm_config.cameras='{ wrist: {"type": "opencv", "index_or_path": 1, "width": 640, "height": 480, "fps": 30}, top: {"type": "opencv", "index_or_path": 3, "width": 640, "height": 480, "fps": 30} }' \
     --robot.right_arm_config.cameras='{ wrist: {"type": "opencv", "index_or_path": 2, "width": 640, "height": 480, "fps": 30} }' \
     --teleop.type=bi_so_leader \
     --teleop.left_arm_config.port=/dev/tty.usbmodem5A460852721 \
     --teleop.right_arm_config.port=/dev/tty.usbmodem5A460819811 \
     --teleop.id=bimanual_leader \
     --dataset.repo_id=${HF_USER}/bimanual-so-handover-cube \
     --dataset.num_episodes=25 \
     --dataset.single_task="Grab and handover the red cube to the other arm" \
     --display_data=true

5. 5
   Train ACT on it

   State and action are now 12-dimensional, six motors per SO-100 arm. ACT reads the shapes from the dataset. What it needs from you is episodes.

   bash

   lerobot-train \
     --dataset.repo_id=${HF_USER}/bimanual-so-handover-cube \
     --policy.type=act \
     --output_dir=outputs/train/act_bimanual \
     --job_name=act_bimanual \
     --policy.device=cuda

How many demonstrations two arms actually need

The number everyone quotes is 50: fifty demonstrations, 10 minutes of data, 80 to 90 percent success. Real, and the best case from the easiest tasks. The picture across three papers is more useful.

Read the top and bottom together. Fifty demonstrations buys a well-posed, short-horizon task with a fixed object and fixed lighting. Tying a shoelace took over five thousand demonstrations from 35 operators across 10 robots in 2 buildings over 8 months, and still lands at 40 percent. Our data collection guide applies with more force here: a handover episode has two ways to go wrong.

Do it yourself, or do it here

source /opt/ros/humble/setup.bash
source ~/interbotix_ws/install/setup.bash

# Bring up all arms and cameras
ros2 launch aloha aloha_bringup.launch.py

# Teleoperate both sides
python3 ~/interbotix_ws/src/aloha/scripts/dual_side_teleop.py

# Record one episode, optionally with leader gravity compensation
python3 ~/interbotix_ws/src/aloha/scripts/record_episodes.py \
  --task_name my_task --episode_idx 0 --gravity_compensation

# Or loop it
./scripts/auto_record.sh my_task 50

ACT: what the paper says and what the code does

ACT is the second half of ALOHA and travels further than the hardware. The idea is action chunking: instead of one action per observation, the policy predicts the next k target joint positions and executes them as a unit, dividing the effective horizon by k. The ablation is the strongest number in the paper: success rises from 1 percent at k = 1 to 44 percent at k = 100, then tapers at k = 200 and 400. The LeRobot implementation deviates from the paper in two documented places.

The decoder row is not a typo. LeRobot's config points at issue 25 on the original ACT repository: the reference declares 7 decoder layers, but the action head reads only the first decoder output, so LeRobot sets 1 to match real behaviour. The ensembling row matters too: the paper measured a 3.3 percent gain, and LeRobot leaves it off because it requires n_action_steps of 1, which multiplies your inference latency by the chunk size. If a tutorial promises paper-matching results, check whether it turned ensembling on.

That latency column is why ACT is still relevant three years on. A 50 Hz loop is a 20 ms budget per step. ACT fits it; a 485 ms model does not. ACT against SmolVLA is the closest comparison, and the arena has 332 benchmark results across 85 models, each linked to its source.

Where this does not transfer

Four honest limits, because bimanual attracts more enthusiasm than it deserves at the hobby end.

• Remote inference will not work for this. ALOHA's loop is 50 Hz. Public-internet round trips add tens to hundreds of milliseconds and turn a working policy into a hesitant one. Cloud inference suits slow pick-and-place, not a mid-air handover.
• A bimanual policy is not two single-arm policies. The action space is joint, cameras are shared, and the interesting behaviour lives in the correlation between arms. Two independent policies give you two arms that ignore each other.
• The SO-100 is not a ViperX. A ViperX has 750 g payload, 1 mm repeatability and 5 to 8 mm accuracy, and the ALOHA authors themselves call the hardware imprecise. An SO-100 pair will do a cube handover, not velcro threading.
• This platform is single-arm. Teleoperation, recording, training and inference all target one arm. For bimanual, LeRobot's bi_so_follower is the path, and you run it yourself.

None of that argues against trying, only for choosing the task honestly first. If it needs a handover, build two arms. If not, the SO-100 setup guide and the first-policy tutorial get you a working single-arm fine-tune cheaply, and a policy that only works in one setup is a known failure mode, not a hardware problem.

Questions people actually ask