Bimanual SO-100: Running Two Arms as One System

What bimanual means once you look at the code

A single SO-100 is six Feetech STS3215 bus servos on one serial port. LeRobot's SO-100 driver writes the motor table out by hand. Read it once: every key you later see in a dataset comes from here.

# lerobot 0.6.2, src/lerobot/robots/so_follower/so_follower.py
norm_mode_body = MotorNormMode.DEGREES if config.use_degrees else MotorNormMode.RANGE_M100_100
self.bus = FeetechMotorsBus(
    port=self.config.port,
    motors={
        "shoulder_pan": Motor(1, "sts3215", norm_mode_body),
        "shoulder_lift": Motor(2, "sts3215", norm_mode_body),
        "elbow_flex": Motor(3, "sts3215", norm_mode_body),
        "wrist_flex": Motor(4, "sts3215", norm_mode_body),
        "wrist_roll": Motor(5, "sts3215", norm_mode_body),
        "gripper": Motor(6, "sts3215", MotorNormMode.RANGE_0_100),
    },
    calibration=self.calibration,
)

The bimanual class does not extend that table. It builds two complete SOFollower objects, one per port, and prefixes everything that comes out of them. The extra degrees of freedom arrive as string prefixes, not as a new kinematic model. There is no shared base frame, no cross-arm collision checking and no solver that knows the two arms are in the same room.

That last row is the design of LeRobot's BimanualMixin: connect, calibrate, configure and disconnect are delegated to both arms in sequence, and the pair reports itself connected only when both halves are. One loose cable gives you a failure, not a half-working robot. Correct behaviour, and also why the rig feels twice as fragile at the bench.

The doubled action vector

Record with a bimanual follower and every frame of your LeRobot dataset carries a 12-element action and a 12-element observation.state, left arm first, in the motor order above. The one published bimanual SO-100 dataset on the Hub, pepijn223/bimanual-so100-handover-cube, shows exactly that in its meta/info.json: 25 episodes, 13,220 frames, 30 fps, codebase_version v3.0, robot_type bi_so100_follower.

action        (12,) float32
  left_shoulder_pan.pos   left_shoulder_lift.pos  left_elbow_flex.pos
  left_wrist_flex.pos     left_wrist_roll.pos     left_gripper.pos
  right_shoulder_pan.pos  right_shoulder_lift.pos right_elbow_flex.pos
  right_wrist_flex.pos    right_wrist_roll.pos    right_gripper.pos

observation.state  (12,) float32   # same twelve names, same order
observation.images.left    (480, 640, 3)   video, av1
observation.images.right   (480, 640, 3)   video, av1
observation.images.top     (480, 640, 3)   video, av1

ALOHA, the rig every bimanual imitation-learning paper is measured against, uses two ViperX 6-DoF arms with a gripper each. The paper states the action space plainly: absolute joint positions for two robots, 7 plus 7 equals 14 dimensions, observed with four 480x640 cameras, teleoperated and recorded at 50 Hz. An SO-100 pair lands at 12 because the arm has five joints, not six, before the gripper.

Hardware: four arms, four ports, four power supplies

A conventional leader-follower bimanual rig is four arms: two followers do the work, two leaders are the input device. TheRobotStudio's parts list for one SO-100 class follower-plus-leader setup totals 12 STS3215 servos, 2 Waveshare motor control boards and 2 power supplies. Double every line.

One detail that has nothing to do with software: the two followers must sit at a fixed, repeatable distance from each other. If the left base shifts 2 cm between sessions, demonstrations before and after teach different geometries and the policy cannot tell them apart. Bolt both bases to one plate. The handover point lives in the space between them.

Ports, motor IDs and calibration

With four devices, port discovery stops being a formality. LeRobot's helper lists the serial ports, asks you to unplug one cable, lists them again and prints the difference. Run it once per arm and write the answer on the arm.

1. 1
   Find each of the four ports

   The helper asks you to unplug that arm's USB cable, then prints the port that disappeared. It errors out if zero or more than one port changed, so unplug exactly one. Run it four times and tape the result to each base.

   bash

   pip install 'lerobot[hardware]'
   
   # run this four times, once per arm, unplugging only that arm each time
   lerobot-find-port
   # -> The port of this MotorsBus is '/dev/ttyACM0'

2. 2
   Set motor IDs, one arm at a time

   Each bus needs IDs 1 to 6 written to its servos. Do it per arm with the single-arm type. bi_so_follower does implement setup_motors and runs the two arms in sequence, but the prompts are per motor and it is easy to lose track of which arm you are on.

   bash

   lerobot-setup-motors --robot.type=so100_follower --robot.port=/dev/ttyACM0   # left follower
   lerobot-setup-motors --robot.type=so100_follower --robot.port=/dev/ttyACM1   # right follower
   lerobot-setup-motors --teleop.type=so100_leader  --teleop.port=/dev/ttyACM2  # left leader
   lerobot-setup-motors --teleop.type=so100_leader  --teleop.port=/dev/ttyACM3  # right leader

3. 3
   Calibrate the pair, not the arms

   This is the step people get wrong. Calibrate through the bimanual type so the files are written under the names the class will later look for. Calibrating the four arms individually also works, as long as the ids end in _left and _right and share the bimanual prefix.

   bash

   lerobot-calibrate \
     --robot.type=bi_so_follower \
     --robot.left_arm_config.port=/dev/ttyACM0 \
     --robot.right_arm_config.port=/dev/ttyACM1 \
     --robot.id=bimanual_follower
   
   lerobot-calibrate \
     --teleop.type=bi_so_leader \
     --teleop.left_arm_config.port=/dev/ttyACM2 \
     --teleop.right_arm_config.port=/dev/ttyACM3 \
     --teleop.id=bimanual_leader

4. 4
   Verify where the files landed

   Four JSON files with the suffixes the bimanual class appends. Robots go under robots/, teleoperators under teleoperators/, and in 0.6.2 the model folder is the shared so_follower and so_leader, not a per-model one.

   bash

   ls ~/.cache/huggingface/lerobot/calibration/robots/so_follower/
   # bimanual_follower_left.json  bimanual_follower_right.json
   
   ls ~/.cache/huggingface/lerobot/calibration/teleoperators/so_leader/
   # bimanual_leader_left.json    bimanual_leader_right.json

Teleoperating both arms

Once the four calibration files exist, teleoperation is one command. Nested config fields are the only syntax difference from a single arm: --robot.left_arm_config.port instead of --robot.port.

lerobot-teleoperate \
  --robot.type=bi_so_follower \
  --robot.left_arm_config.port=/dev/ttyACM0 \
  --robot.right_arm_config.port=/dev/ttyACM1 \
  --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/ttyACM2 \
  --teleop.right_arm_config.port=/dev/ttyACM3 \
  --teleop.id=bimanual_leader \
  --display_data=true

The human factor is underrated here. One operator with two leaders can drive a handover, but coordinated two-handed motion at speed is hard to produce, and it shows up in the data as one arm waiting while the other works. Two operators, one arm each, give smoother trajectories and worse coordination. Decide before you record 50 episodes: mixing both styles teaches the policy that both are correct.

Recording a bimanual dataset

Recording uses the same nested syntax plus a dataset block, and a wider install extra: the record script asks for pip install 'lerobot[core_scripts]', not the hardware extra alone. The command below is verbatim from the lerobot-record docstring, the closest thing upstream has to bimanual SO-100 documentation: there is no bimanual page in the LeRobot docs tree. The dataset docs and the SO-100 setup guide both cover the single-arm path only.

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},
    front: {"type": "opencv", "index_or_path": 4, "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 \
  --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" \
  --dataset.streaming_encoding=true \
  --dataset.encoder_threads=2

Camera naming is where the prefixes stop being uniform, and both public examples get bitten by it. BiSOFollower prefixes every camera declared on left_arm_config.cameras or right_arm_config.cameras with the side, and leaves top-level --robot.cameras alone. The upstream command above puts top under the left arm, so it writes left_top. Seeed's guide names the per-arm cameras left_wrist and right_wrist, so it writes left_left_wrist. A real collision between the two levels does raise a ValueError rather than shadowing silently.

Plan for throwing episodes away. Seeed's double-arm walkthrough records 50 episodes of a cube handover with a 30 second episode budget and a 10 second reset window, a sane starting shape for a two-arm task. Delete the bad ones rather than letting them teach: lerobot-edit-dataset rewrites the dataset in place and keeps the old copy next to it.

# drop episode index 24 (the 25th) from a recorded bimanual dataset
lerobot-edit-dataset \
  --repo_id=${HF_USER}/bimanual-so-handover-cube \
  --operation.type=delete_episodes \
  --operation.episode_indices="[24]"

# the original is kept at <dataset>_old until you remove it yourself

Which policies accept a doubled action vector

This is the question that decides whether the rig is worth building. The honest answer: three of the five trainable policies take 12 dimensions with no change at all, and the GR00T family takes a configuration file you write yourself.

The padding numbers are not guesses. In lerobot 0.6.2 both SmolVLA and Pi0.5 declare max_state_dim: int = 32 and max_action_dim: int = 32, and pad state and action to that width. A bimanual SO-100 uses 12 of the 32. That headroom is why those architectures needed no redesign when people pointed them at two-arm rigs. Nor is two-arm SO-100 data exotic to SmolVLA: the community dataset list in its paper's appendix already includes two-arm recordings such as ZCM5115/so100_2Arm3cameras_movebox.

ACT is not merely compatible with bimanual data, it was written for it. ACT is the policy from the ALOHA paper, trained on those 14-dimensional demonstrations, and it has no max_action_dim at all: the shapes come from the dataset features. Its action chunking defaults are still chunk_size 100 and n_action_steps 100, the values AY-Robots sends alongside a 100,000 step ceiling; Seeed's double-arm guide trains those same defaults for 60,000 steps. For the shortest path from a bimanual dataset to a moving robot, ACT on SO-100 is it: about 80 M parameters, 20 ms per action step, an RTX 4090 tier GPU and no base checkpoint to fight with.

GR00T is the one that needs work

GR00T does not read a flat vector, it reads named slices. NVIDIA's shipped SO-100 example splits the six channels into a single_arm key over indices 0 to 5 and a gripper key over 5 to 6, with one ActionConfig per key: relative for the arm, absolute for the gripper. For two arms you write four slices instead of two. NVIDIA ships no bimanual SO-100 config, so both files below are yours to write.

// meta/modality.json for a 12-channel bimanual SO-100 dataset.
// This is what you write; NVIDIA ships only the single-arm version
// at examples/SO100/modality.json, with single_arm 0-5 and gripper 5-6.
{
  "state": {
    "left_arm":      {"start": 0,  "end": 5},
    "left_gripper":  {"start": 5,  "end": 6},
    "right_arm":     {"start": 6,  "end": 11},
    "right_gripper": {"start": 11, "end": 12}
  },
  "action": {
    "left_arm":      {"start": 0,  "end": 5},
    "left_gripper":  {"start": 5,  "end": 6},
    "right_arm":     {"start": 6,  "end": 11},
    "right_gripper": {"start": 11, "end": 12}
  },
  "video": {
    "top":         {"original_key": "observation.images.top"},
    "left_wrist":  {"original_key": "observation.images.left_wrist"},
    "right_wrist": {"original_key": "observation.images.right_wrist"}
  },
  "annotation": {
    "human.task_description": {"original_key": "task_index"}
  }
}

The matching Python config registers those keys under NEW_EMBODIMENT, which Isaac-GR00T's embodiment tag enum documents as the finetuning tag for custom robots. One ActionConfig per modality key, in the same order: NVIDIA warns that a mismatch is applied silently, so a misordered list hands a gripper the relative representation meant for an arm and nothing complains. Background on embodiment tags is in the VLA overview.

# Extends examples/SO100/so100_config.py from Isaac-GR00T to two arms.
from gr00t.configs.data.embodiment_configs import register_modality_config
from gr00t.data.embodiment_tags import EmbodimentTag
from gr00t.data.types import (
    ActionConfig, ActionFormat, ActionRepresentation, ActionType, ModalityConfig,
)

KEYS = ["left_arm", "left_gripper", "right_arm", "right_gripper"]

bi_so100_config = {
    "video": ModalityConfig(delta_indices=[0],
                            modality_keys=["top", "left_wrist", "right_wrist"]),
    "state": ModalityConfig(delta_indices=[0], modality_keys=KEYS),
    "action": ModalityConfig(
        delta_indices=list(range(0, 16)),      # 16-step horizon, as in the SO-100 example
        modality_keys=KEYS,
        action_configs=[
            ActionConfig(rep=ActionRepresentation.RELATIVE, type=ActionType.NON_EEF,
                         format=ActionFormat.DEFAULT),   # left_arm
            ActionConfig(rep=ActionRepresentation.ABSOLUTE, type=ActionType.NON_EEF,
                         format=ActionFormat.DEFAULT),   # left_gripper
            ActionConfig(rep=ActionRepresentation.RELATIVE, type=ActionType.NON_EEF,
                         format=ActionFormat.DEFAULT),   # right_arm
            ActionConfig(rep=ActionRepresentation.ABSOLUTE, type=ActionType.NON_EEF,
                         format=ActionFormat.DEFAULT),   # right_gripper
        ],
    ),
    "language": ModalityConfig(delta_indices=[0],
                               modality_keys=["annotation.human.task_description"]),
}

register_modality_config(bi_so100_config, embodiment_tag=EmbodimentTag.NEW_EMBODIMENT)

Two routes to a trained bimanual policy

Compute cost does not change when you add the second arm. The same tiers apply: about 4 to 12 USD for a 3 to 6 hour run on the A100 or H100 tier that GR00T N1.7, GR00T N1.5 and Pi0.5 need, and about 1 to 3 USD for a 2 to 5 hour run on the RTX 4090 tier SmolVLA and ACT use. The breakdown is on the pricing page. What doubles is the hardware bill and the recording time.

What actually goes wrong

• Ports swap after a reboot. /dev/ttyACM0 is assigned in enumeration order, so the left arm becomes the right arm and everything you record is mirrored. Pin the devices with udev rules by serial number. See arm not detected.
• A recalibration prompt on every launch. The calibration ids do not carry the bimanual prefix, or you are looking in the old per-model folder. Both covered above.
• Camera keys come out doubled. left_left_wrist in the dataset means you named the per-arm camera left_wrist. Rename and re-record, or the modality config will not match.
• One arm sags on connect. Torque is disabled during calibration, and with four arms the odds that one is not in its rest position go up. Arm twitches then sags covers it.
• The policy moves one arm and parks the other. Usually the data: long idle stretches for one arm teach the policy that idling is correct. The bimanual version of the problem in collecting high-quality VLA training data.
• Joint indices scrambled in a GR00T run. The modality.json ranges do not match the left-then-right order the recorder wrote. Training converges on nonsense without raising an error.

The honest limits

Two things are worth saying plainly before you spend a weekend on this. First, latency. The control loop runs at 20 ms per action step for ACT up to 485 ms for Pi0.5, and inference latency has to sit next to the servos for anything fast. Public-internet round trips turn a working policy into a hesitant one, and two grippers in contact with the same object punish hesitation harder than one arm reaching for a static cube. Remote inference is viable for slow pick-and-place, not for a fast handover.

Second, this platform has no bimanual product. The five vision-language-action models on the training matrix are listed against four single arms, the browser teleoperation workflow drives one arm, and the arm at /live is a single SO-100. What transfers is everything downstream of the dataset: GPU rental, trainer defaults and a served checkpoint. A 12-channel LeRobot dataset is still a LeRobot dataset. If you wanted to click a button and get a two-armed robot, that is not on offer here.