Training Pi0.5 on a Koch v1.1

What compatible means in practice

The Koch v1.1 is a five-joint arm with a gripper, built by the LeRobot community around Dynamixel XL330 and XL430 servos. This platform lists it as compatible rather than fully supported, and the distinction is precise: the data pipeline and the training backend do not know or care which servo bus produced a recording, while the hardware path is tested on Feetech arms first.

So the failure modes cluster on the bench, not in the cloud. Expect to verify device detection and calibration yourself, expect to be the person who notices if something behaves oddly, and expect the training side to be uneventful. That asymmetry has one strong implication for how you spend money, covered further down.

Two rails, and a warning that points the other way

The Koch uses 5 V and 12 V rails depending on which servo is where, and both are correct for this arm. This is the one place in the lineup where 12 V is not a mistake.

The rails also matter for a subtler reason. If a rail sags while the gripper is holding a load, the arm behaves differently under contact than it did during your demonstrations, and a policy that was trained on well-powered episodes will look like it has a timing problem when it actually has a supply problem.

The bus is different, the dataset is not

Dynamixel servos speak their own protocol over a USB serial adapter, which shows up as a port like any other. Once the client is talking to the arm, the recording it writes is an ordinary LeRobot v2.1 dataset: joint positions and gripper state in Parquet, camera streams as video, task strings in the metadata. There is no conversion step and no Koch-specific export.

ay-robots devices

# SERIAL PORTS
#   /dev/ttyUSB0    Koch v1.1  (6 servos responding)
# CAMERAS
#   0  Scene     1280x720
#   1  Wrist     1280x720

# No serial port listed at all on Linux is a permissions problem, not a wiring one:
#   sudo usermod -aG dialout $USER   then log out and back in

ay-robots calibrate

One consequence worth stating plainly: because the trainer only sees a feature schema, a Koch dataset and an SO-100 dataset look interchangeable to it and are not interchangeable in reality. Different kinematics, different servo characteristics, different zero points. Keep them in separate datasets and separate policies.

Why Pi0.5 on this arm, and why not first

Pi0.5 is a flow-matching vision-language-action model. Rather than picking actions from discretized options, it integrates a continuous path to the next action chunk, so the trajectory arrives smooth instead of being smoothed afterwards. People who bought a Koch usually bought it for careful work, and careful work is exactly where that property converts into success rate: insertion, alignment, controlled pressing, anything where the interesting part happens after contact begins.

The cost is latency: about 485 ms per action step, a little over two commands per second. On a deliberate assembly motion that is invisible. On rapid pick-and-place the arm looks like it is thinking between reaches, and no dataset improvement changes that.

Dataset requirements

• LeRobot v2.1, recorded through the client so the schema is written correctly
• Fifty kept episodes as a minimum, all from this arm and this calibration
• A single task string repeated word for word across every episode
• Consistent camera placement, because the policy reads pixels and a bumped tripod invalidates everything recorded before it
• Even, unhurried teleoperation, since the trajectory shape you record is the trajectory shape you get back

Running the training

1. 1
   Select the Koch dataset

   Open Training and pick the uploaded dataset. Use the preview to confirm the action dimension count and that both camera streams are present, which is the cheapest check you will ever run against a compatible-tier arm.

2. 2
   Choose Pi0.5 from the model list

   The entry is labeled Pi0.5. Behind it the trainer key is pi0 and the produced policy type is pi05, which is the string you will see in the checkpoint metadata and in anything you build against the API.

3. 3
   Review the parameter block

   Batch size 1, learning rate 5e-5, 30000 steps, gradient accumulation 16. Two extra fields appear for this trainer family, seed and log frequency; fill in both rather than leaving your run unreproducible.

4. 4
   Start the job

   The pool rents an 80 GB card by the hour on a spot market, choosing by VRAM rather than by GPU name. Queued time is unbilled, so a slow start costs you patience only.

5. 5
   Monitor loss and GPU telemetry

   The run page shows loss, learning rate and gradient norm together with utilization, VRAM, temperature and power draw. Use the telemetry as a liveness check and the loss as a smoke detector; neither predicts what the Koch will do.

6. 6
   Select checkpoints for evaluation

   Take a few from the second half of the run. On an arm you cannot lean on other people’s results for, on-hardware comparison between checkpoints is the only evidence you have.

Defaults for a Koch run

What the run costs

Three to six hours of A100 time at 1.20 to 2.00 USD per hour, so roughly 4 to 12 USD per run. The number is set by wall clock rather than by memory pressure: 30000 steps, sixteen accumulation passes behind each one, and a batch of a single sample means the card spends its time on sequencing rather than on capacity. An 80 GB card with headroom to spare still costs 80 GB prices.

Deploying to the Koch

Power both rails, confirm all six servos answer, put the cameras back where they were during recording, and load the checkpoint in the client with the dataset’s task string. Give the arm room, because the first policy you deploy on a compatible-tier arm is also a test of your wiring.

Evaluate with twenty attempts across varied object positions, recorded as you go, and repeat the same twenty for the second checkpoint. Watch specifically for the difference between arriving in the wrong place, which is a data or camera problem, and arriving correctly but half a second late, which is the 485 ms cadence doing what it does.

Troubleshooting

Frequently asked questions