The Koch v1.1: the Dynamixel arm in a Feetech world

What the Koch v1.1 is

The Koch v1.1 is a low cost five joint arm with a gripper that came out of the LeRobot community, and it is usually written as the Alexander Koch arm or simply the Koch arm. Kinematically it lands in the same place as an SO-100: six actuators, a printed structure, smart serial servos, a machine you build on a table rather than buy assembled. The parts bill is different, roughly 250 to 350 euro against 110 to 150, and the reason is the servos.

Where the SO-100 family uses Feetech STS3215 units on one chain at one voltage, the Koch uses Dynamixel XL330 and XL430 servos across 5 V and 12 V rails. That is not a footnote. It is the fact that determines the wiring, the tooling you need to set up the chain, the connectors on your bench and which of the hardware pages on this site you can follow line by line.

Specifications

Dynamixel instead of Feetech: the difference that matters

Feetech STS3215 and Dynamixel XL servos solve the same problem inside different ecosystems. Both are smart serial servos: you address a unit by id over a shared line and ask it for a position rather than feeding it a pulse width. What differs is the protocol carried on that line, the connector, the USB interface that speaks it, the register names behind torque and position, and the voltage the motor expects.

All of that difference stops at the serial port. Above it, a joint angle is a joint angle. The client records the same six values per control step, writes the same LeRobot v2.1 layout, uploads to the same place and fine-tunes the same five policies. Nothing in a dataset records which brand of servo produced the numbers, which is exactly why all four training guides exist for this arm as well as for the SO-100.

Below the serial port, almost nothing carries over from a Feetech build. Ids are written with Dynamixel tooling rather than the Feetech utility, the chain reaches the host through a Dynamixel USB interface rather than a Feetech bus adapter, and the limits you might want to inspect live in a different register map. If you built an SO-100 first, budget an evening for the parts of the process that are muscle memory on one bus and unfamiliar on the other.

People accept the higher price for build quality reasons that this platform is not in a position to referee. What can be said is what the numbers here measure and do not measure: they measure policies, and a policy cannot see the servo brand. A dataset recorded on a Koch and a dataset recorded on an SO-100 are the same kind of object to a trainer, so nothing about model choice, training cost or step count changes because of the bus.

Power: two rails, and a warning that runs both ways

A Feetech arm is one supply into one chain. A Koch is not. Which rail a given servo wants depends on the model sitting at that joint, and a Koch build mixes two families, so the wiring involves two voltages on one machine and you cannot infer either of them from the joint position.

What compatible support means in practice

The catalog marks the SO-100 and SO-101 as fully supported and the Koch v1.1 as compatible. That word is doing real work and it is worth spelling out rather than leaving to interpretation.

• Everything above the driver is identical: recording, review, LeRobot v2.1 datasets, upload, cloud training, checkpoint deployment and the MCP tools.
• All four training guides exist: /train/smolvla-on-koch-v1-1, /train/act-on-koch-v1-1, /train/groot-n1-7-on-koch-v1-1 and /train/pi0-5-on-koch-v1-1.
• New features are validated on an SO-100 first. The Koch path is the second one checked, not the first, so a fresh capability may reach you slightly later.
• Three of the six hardware fix pages are written for a Feetech chain and are scoped to the SO-100, SO-101 and LeKiwi: /fix/arm-twitches-then-sags, /fix/joint-stops-early and /fix/gripper-does-not-close. Read them for the reasoning, then translate the register names.
• The bus agnostic ones apply as written: /fix/arm-not-detected for a missing serial port, /fix/servo-not-responding for a silent unit, /fix/camera-not-detected for the cameras.

From the carton to the first movement

1. 1
   Sort the servos by model, not by joint

   Separate the XL330 units from the XL430 units before anything else and note which rail each group expects. This is the sort that prevents the expensive mistake later, when everything is assembled and the labels are hidden.

2. 2
   Write the ids with the Dynamixel tooling

   Each servo needs its id set while the connector is reachable. The Feetech utility from an SO-100 build will not do this, and neither will the ay-robots CLI. Do it first, verify it, then start assembling.

3. 3
   Follow the SO-100 build for the rhythm, not the parts

   /learn/so-100-getting-started is written for a Feetech arm, but the sequence of assemble, pair, list devices, calibrate is the same sequence here. What does not carry across is the servo tooling and the wiring, which is exactly the part above.

4. 4
   Install the client and pair this machine

   The installer from /download brings the CLI and the desktop client with the driver inside. Pair once with the code from the Robots page in the dashboard.

   bash

   curl -fsSL https://www.ay-robots.com/install.sh | sh
   ay-robots pair 4QD2-8HRM-1XV6
   ay-robots status

5. 5
   Find the port and count six servos

   The device list reports the arm, its serial port and every camera. Six units answering means the Dynamixel chain is sound, and that is the checkpoint to reach before you attach cameras or think about data.

   bash

   ay-robots devices

6. 6
   Calibrate, then send it home

   Guide the joints to the neutral pose and press Enter to store the zero, then command the home pose. The calibration reference belongs to this physical arm and has to be captured again for every arm you build.

   bash

   ay-robots calibrate
   ay-robots home

What the platform trains and runs on a Koch v1.1

The same four policy families, with the same defaults, because the defaults come from the model rather than from the arm. Nothing in the table below changes because the bus is Dynamixel.

# Record while you teleoperate. The command starts and stops the recording, it does not drive the arm.
ay-robots record --task "stack the small block on the large block" --episodes 50 --cameras wrist,top

ay-robots datasets list --local
ay-robots datasets upload block-stack --name block-stack-koch

# No training command exists. Start the run under Training in the dashboard,
# or call the start_training tool on the MCP server.

ay-robots run --model smolvla --checkpoint s3://runs/block-stack-koch/step-20000 --task "stack the small block on the large block"
ay-robots stop

Model details sit at /policies/smolvla, /policies/act, /policies/groot-n1-7 and /policies/pi0-5. If the run dies as soon as it starts, the cause is usually memory or format rather than hardware, and /fix/out-of-memory-training and /fix/dataset-rejected-v3 cover the two that account for most of it.

Against the other three arms

• SO-100 and SO-101: one Feetech chain, one 7.4 V supply, roughly 110 to 170 euro in parts, full support. They are the cheaper and better trodden route, and the SO-100 is what /live actually runs.
• LeKiwi: a Feetech arm at 7.4 V on a 12 V three wheel base, roughly 400 to 500 euro. It is the only supported machine whose action vector is wider than six values.
• Koch v1.1: the only Dynamixel arm here, the only one where a 12 V rail is correct rather than fatal, and the most expensive fixed arm on the list at roughly 250 to 350 euro.

Frequently asked questions