Koch v1.1 Arm Setup: Dynamixel Bus, Wiring and LeRobot

The SO-100 is the arm most LeRobot tutorials assume. The Koch v1.1 came first: a six-servo, 3D-printed, leader-follower arm built around ROBOTIS Dynamixel motors. This page covers what differs: the servo lineup, the two power rails, the operating modes LeRobot burns into motor EEPROM, and the large part of the stack that does not change.

Everything below was checked against the Koch v1.1 build repository and its wiring diagram PDF (drawn 2024-07-08 by Jess Moss for Hugging Face), the ROBOTIS e-Manual pages for the three servo models, and the LeRobot sources on main, version string 0.6.2, with the newest tagged release at v0.6.1. Where those sources disagree, and they do in one place, it is flagged.

The arm, and where it came from

The original low-cost arm is Alexander Koch's low_cost_robot from Tau Robotics, credited as such in LeRobot's class docstrings. Jess Moss rebuilt it for Hugging Face as Koch v1.1: fixed screw interferences, standardised hole sizes, no screws into plastic, a printed leader platform so the follower can reach the ground, and a replacement DC converter that removes the soldering iron and the manual voltage trim. LeRobot names both versions, so koch_follower covers each.

Dynamixel bus versus Feetech bus

Both are serial bus arms: one three-wire chain carrying power, ground and a half-duplex TTL data line, each servo answering on its own ID. That is where the similarity ends. Protocol, SDK, model numbers and control modes all differ, which is why LeRobot keeps two bus implementations.

Two rows deserve a second look. Operating-mode numbers are not comparable across the buses: the Dynamixel enum numbers position control 3 and extended position 4, while the Feetech enum starts at POSITION = 0 and uses 1, 2, 3 for velocity, PWM and step mode. And LeRobot drives both at 1 Mbps although Dynamixel servos ship at 57,600 bps with ID 1, so lerobot-setup-motors is not cosmetics: it writes ID and baud rate into EEPROM once per motor, and a motor you skip will not answer afterwards.

The XL430-W250-T is the hard constraint. Its e-Manual lists four operating modes, velocity, position, extended position and PWM, with no current control and no current-based position control. LeRobot's table agrees, giving it 1, 3, 4, 16 against 0, 1, 3, 4, 5, 16 for the XL330s. That is why the gripper is an XL330-M288 and the XL430s sit at the shoulder.

Two rails on one bus, and the mistake that ends a build

The leader is the simple one: six XL330-M077-T motors, one Waveshare driver board, one 5 V supply, daisy-chained. The repo notes that the board's data sheet asks for 9 to 12.6 V input, and that running it at 5 V anyway is harmless to the board and necessary, because the board's servo rail is what reaches the motors.

The follower is where the topology forks, and the driver board is the distribution point rather than a bystander. The 12 V supply goes into the board's power input. The board presents two three-pin servo headers carrying DATA, 12 V and GND: one runs to the two XL430 shoulder motors, the other feeds the step-down converter, whose 5 V output powers the four XL330s further out while the data line passes through. One bus, two power domains, boundary between joint 2 and joint 3.

12 V PSU
  |
  +--> Waveshare Serial Bus Servo Driver Board, PWR input
       (board data sheet asks for 9 to 12.6 V)
         |
         |-- servo header: DATA / 12 V / GND
         |     +--> XL430-W250-T   id 1  shoulder_pan    12 V
         |     +--> XL430-W250-T   id 2  shoulder_lift   12 V
         |
         +-- servo header: DATA / 12 V / GND
               +--> Voltage reducer  EP-JY-DC5
               |      IN+  12 V  ->  OUT+  5 V
               |      IN-  GND   ->  OUT-  GND
               |
               +--> DATA passes through; the 5 V output powers:
                      XL330-M288-T  id 3  elbow_flex   5 V
                      XL330-M288-T  id 4  wrist_flex   5 V
                      XL330-M288-T  id 5  wrist_roll   5 V
                      XL330-M288-T  id 6  gripper      5 V

One half-duplex TTL DATA line reaches all six motors, Protocol 2.0.
USB-C from the driver board to the host computer.
Leader arm: same board, one 5 V supply, six XL330-M077-T, no converter.

Bring-up, command by command

The commands below are the console entry points LeRobot installs on main. Anything that still calls python lerobot/scripts/control_robot.py with a --control.type flag describes an older release; that file is gone. Python 3.12 or newer is required, enforced by the package metadata.

1. 1
   Install LeRobot with the Dynamixel SDK

   The base package is thin. You need the composite extra that maps to the CLI scripts, plus the Dynamixel motor extra. SO-100 owners install the Feetech extra instead.

   bash

   conda create -y -n lerobot python=3.12
   conda activate lerobot
   
   git clone https://github.com/huggingface/lerobot.git
   cd lerobot
   pip install -e ".[core_scripts]"
   pip install -e ".[dynamixel]"

2. 2
   Find the two serial ports

   One port per arm. The script has you unplug a cable so it can diff the port list, which beats guessing between two identical usbmodem names. On Linux the device is usually /dev/ttyACM0; on a permission error, add your user to the dialout group.

   bash

   lerobot-find-port
   
   # Example output on macOS:
   #   ['/dev/tty.usbmodem575E0032081', '/dev/tty.usbmodem575E0031751']
   #   Remove the USB cable from your MotorsBus and press Enter when done.

3. 3
   Write IDs and baud rate, one motor at a time

   Every motor ships as ID 1 at 57,600 bps. The script walks the joints in reverse, gripper first, and each must be the only motor on the board when you press Enter. On a Waveshare board, both jumpers go on the B channel (USB).

   bash

   lerobot-setup-motors \
       --robot.type=koch_follower \
       --robot.port=/dev/tty.usbmodem575E0031751
   
   lerobot-setup-motors \
       --teleop.type=koch_leader \
       --teleop.port=/dev/tty.usbmodem575E0032081

4. 4
   Calibrate both arms

   Move the arm to the middle of its range, press Enter, then sweep every joint through its travel. LeRobot pins shoulder_pan and wrist_roll to 0 and 4095 rather than recording them, since those two turn freely. The calibration file is keyed by the id you pass.

   bash

   lerobot-calibrate \
       --robot.type=koch_follower \
       --robot.port=/dev/tty.usbmodem575E0031751 \
       --robot.id=my_koch_follower
   
   lerobot-calibrate \
       --teleop.type=koch_leader \
       --teleop.port=/dev/tty.usbmodem575E0032081 \
       --teleop.id=my_koch_leader

5. 5
   Teleoperate and check the mapping

   Drive the follower from the leader with the camera feeds on screen before recording. If a joint runs backwards, the calibration is wrong, not the code.

   bash

   lerobot-teleoperate \
       --robot.type=koch_follower \
       --robot.port=/dev/tty.usbmodem575E0031751 \
       --robot.id=my_koch_follower \
       --robot.cameras="{front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}" \
       --teleop.type=koch_leader \
       --teleop.port=/dev/tty.usbmodem575E0032081 \
       --teleop.id=my_koch_leader \
       --display_data=true

6. 6
   Record a dataset

   Same command shape as an SO-100. Documented defaults are 60 s per episode, 60 s reset, 50 episodes. Right arrow or n moves on, left arrow or r re-records, ESC or q stops and uploads.

   bash

   lerobot-record \
       --robot.type=koch_follower \
       --robot.port=/dev/tty.usbmodem575E0031751 \
       --robot.id=my_koch_follower \
       --robot.cameras="{front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}" \
       --teleop.type=koch_leader \
       --teleop.port=/dev/tty.usbmodem575E0032081 \
       --teleop.id=my_koch_leader \
       --dataset.repo_id=${HF_USER}/koch-pick-place \
       --dataset.num_episodes=50 \
       --dataset.episode_time_s=60 \
       --dataset.single_task="Pick up the block and drop it in the bin" \
       --display_data=true

What LeRobot writes into the motors

Reading the two classes side by side is the fastest way to understand the arm: the follower is a mixed bus, the leader uniform. Both use the same six joint names in the same order, and both normalise the gripper to 0 to 100 and the other five to -100 to 100. One asymmetry: the follower config exposes use_degrees, which switches those five to degrees for older datasets. The leader config has no such flag.

# src/lerobot/robots/koch_follower/koch_follower.py
norm_mode_body = MotorNormMode.DEGREES if config.use_degrees else MotorNormMode.RANGE_M100_100
motors={
    "shoulder_pan":  Motor(1, "xl430-w250", norm_mode_body),
    "shoulder_lift": Motor(2, "xl430-w250", norm_mode_body),
    "elbow_flex":    Motor(3, "xl330-m288", norm_mode_body),
    "wrist_flex":    Motor(4, "xl330-m288", norm_mode_body),
    "wrist_roll":    Motor(5, "xl330-m288", norm_mode_body),
    "gripper":       Motor(6, "xl330-m288", MotorNormMode.RANGE_0_100),
}

# src/lerobot/teleoperators/koch_leader/koch_leader.py
motors={
    "shoulder_pan":  Motor(1, "xl330-m077", MotorNormMode.RANGE_M100_100),
    ...
    "gripper":       Motor(6, "xl330-m077", MotorNormMode.RANGE_0_100),
}

That elbow PID line matters for data quality. In a LeRobot dataset, action is what the leader commanded and observation.state is where the follower actually was. A soft joint pulls those apart, and a policy trained on it learns to compensate for a lag that will not exist at inference time.

What stays exactly the same: the data pipeline

This is what people get wrong when they assume a different arm means a different training path. KochFollower and the generic SOFollower behind both so100_follower and so101_follower build their features from the same comprehension over motor names, so the tensors reaching a policy are identical in shape, ordering and key naming.

@property
def _motors_ft(self) -> dict[str, type]:
    return {f"{motor}.pos": float for motor in self.bus.motors}

# resulting action / state keys, both arms:
#   shoulder_pan.pos, shoulder_lift.pos, elbow_flex.pos,
#   wrist_flex.pos,   wrist_roll.pos,    gripper.pos

One field does change. The recorder writes robot_type from robot.name, the class attribute, not the --robot.type string you typed. A Koch recording is tagged koch_follower, while SO-100 and SO-101 recordings are both tagged so_follower, since they share one generic class. Nothing in the trainer keys off it, which is a trap: a Koch-trained policy loads and runs on an SO-100 without complaining, and it is wrong. For moving data between arms, see how to collect high-quality VLA training data.

Two ways to get from a built Koch to a working policy

lerobot-train \
  --dataset.repo_id=${HF_USER}/koch-pick-place \
  --policy.type=act \
  --output_dir=outputs/train/act_koch \
  --job_name=act_koch \
  --policy.device=cuda \
  --policy.repo_id=${HF_USER}/act_koch

lerobot-rollout \
  --strategy.type=base \
  --policy.path=${HF_USER}/act_koch \
  --robot.type=koch_follower \
  --robot.port=/dev/ttyACM0 \
  --robot.id=my_koch_follower \
  --task="Pick up the block and drop it in the bin" \
  --duration=60

Which policy to train on Koch data

The arm does not change the model choice. These are the five trainable policies, with the numbers that matter once you have 50 episodes and a deadline.

For a first Koch policy, ACT is the default answer. It has no base model at all, which is the point: it exists only after training on your task, and at 20 ms per action step it is the fastest of the five. SmolVLA is the next step up if you want a pretrained backbone and can live with 245 ms and a 30-episode floor. Start at ACT on Koch v1.1, then SmolVLA on Koch v1.1; the GR00T N1.7 and Pi0.5 guides sit alongside.

Is the Koch v1.1 the right arm for you

Where none of this helps

Four limits are worth stating plainly, because neither the arm nor the platform fixes them.

• Remote inference does not rescue a fast task. The loop is 20 to 485 ms per action step, and public-internet round trips on top turn a working policy into a hesitant one. Cloud inference suits slow pick-and-place; reactive motion needs the policy next to the servos. See inference latency.
• Better hardware does not fix bad data. If the wrist camera moved between episode 12 and 30, a 3 B parameter model learns the artefact.
• A Koch-trained policy is not an SO-100 policy. Same tensor shapes, different link geometry. Nothing errors; it just misses. See degrees of freedom.
• Extended Position mode hides assembly errors rather than preventing them. Calibration records whatever range you sweep, so a joint mounted 90 degrees off still calibrates.

Three pages to bookmark: arm not detected (a port permission or a Waveshare jumper on the wrong channel), servo not responding (a motor that missed its turn during setup and is still ID 1 at 57,600), and joint stops early (a calibration sweep that never reached the mechanical limit). None are Koch-specific, which is the point.

What the whole loop costs

The asymmetry is the useful bit. The arm is a few hundred euros once; a run is the price of a coffee. The expensive resource is recording time, so record more episodes and retrain often rather than tune hyperparameters. See pricing, /try for starting without hardware, and the dataset directory for what other recordings look like.