How to train ACT on the Koch v1.1

What compatible support means in practice

The Koch v1.1 is listed as compatible rather than fully supported, and the distinction is worth taking literally. The reference arm of this platform is the SO-100, everything is tested there first, and the Koch works because the pipeline downstream of the driver does not care which bus produced the numbers. Recording, upload, the LeRobot v2.1 layout, the act trainer, the defaults and the deployment path are all shared.

What you should expect to verify yourself is the layer where the hardware is actually touched: port detection, servo IDs on the bus, calibration ranges and whether every joint answers. When something goes wrong on a Koch, the prior probability sits with that layer rather than with the trainer. Confirm all six actuators respond before you record fifty episodes, not after.

Why the bus never reaches the model

ACT sees joint positions and camera frames, normalized against the statistics stored with the dataset. It has no notion of Dynamixel or Feetech, no notion of servo protocol, and no notion of what a raw encoder count means. This is why a Koch dataset trains without any special handling: by the time the trainer reads it, the bus has been abstracted away into a table of numbers and a set of video files.

The corollary matters more than the fact. Because the numbers were normalized per dataset, they are not comparable across arm families. A joint value recorded on a Koch means nothing on an SO-100 and vice versa. Merging Koch and Feetech episodes into one ACT dataset produces contradictory supervision, and ACT, having no pretraining to fall back on, has no way to notice that the two halves come from different robots. One arm family per dataset, without exceptions.

Frame rate decides how long a chunk lasts

ACT predicts a chunk of future actions in one pass and executes some of them before predicting again. That is what suppresses compounding error: fewer prediction points across an episode means fewer chances for a small deviation to push the arm into a state no demonstration ever covered, and actions drawn from one plan agree with one another instead of correcting each other every frame. The chunk, though, is counted in timesteps and not in seconds, so the wall-clock length of a chunk is set by the rate you recorded at.

This is worth spelling out on a Koch specifically, because a Dynamixel setup that has not been tuned sometimes records at a lower and less steady rate than a Feetech arm on the same machine. The consequence is not a training failure, it is a policy that stays open loop for noticeably longer than you intended.

Two conclusions. Record at a steady rate and know what it is, because it changes the meaning of every chunk setting on this page. And if your Koch records below 30 fps, treat nActionSteps 100 as an aggressive setting rather than a neutral default, and start at 25 to 30 instead.

Prerequisites

• A Koch v1.1 with all six actuators responding on the Dynamixel bus, and the correct rail for each servo
• The desktop client installed and paired, so the driver and the recording path are in place
• Calibration completed on this specific arm, since Dynamixel zero points are per unit like any other servo
• A fixed scene camera, ideally plus a wrist camera
• 50 or more reviewed episodes of one task, recorded at a rate you have actually checked

ay-robots --version

# Every actuator must answer before you record anything. A joint that drops
# out mid-session poisons the episodes recorded around it.
ay-robots devices

# Per-unit calibration, exactly as on the Feetech arms
ay-robots calibrate

Recording for a from-scratch model

ACT builds its entire understanding of the task out of your episodes, so consistency beats volume by a wide margin here. It is also the part where a careful operator gains the most, and where the gain is easiest to throw away by recording two hundred episodes across three sessions with three slightly different techniques.

1. One task per dataset. ACT never reads the task string, so a second task inside the same dataset is just a set of contradictory demonstrations.
2. One approach, one grasp height, one order of operations, held for the whole dataset.
3. Object placement varies, technique does not. Placement is what generalizes; technique variation is what averages.
4. Review and discard failures, including the near-misses you would call good enough.
5. Keep sessions short. Demonstration quality falls off when you are bored, and ACT copies exactly what you show it, tiredness included.
6. Check the recorded rate on the first session rather than assuming it matches your camera settings.

Starting the run

1. 1
   Upload and inspect

   Upload the dataset, wait for processing to finish, then open the preview and step through an episode. Confirm the action dimensions match the six actuators you expect and that both camera streams are present.

2. 2
   Open Training and choose the dataset

   If your account also holds SO-100 data, check the robot type on the card. A Koch dataset and an SO-100 dataset look alike in a list and train into very different policies.

3. 3
   Pick ACT

   The form switches to the lerobot parameter set and adds the two chunk fields that only ACT exposes.

4. 4
   Set nActionSteps to match your recording rate

   Leave it at 100 if you recorded a steady 30 fps. If you recorded slower, drop it to 25 or 30 so a single prediction does not carry five seconds of blind motion.

5. 5
   Fill in a seed, leave everything else

   Batch 8, learning rate 1e-5, 100 000 steps, gradient accumulation 1, chunk size 100. The seed is what makes your second run a comparison rather than a new experiment.

6. 6
   Start it and check the first minutes

   The pool rents a 24 GB card by VRAM, not by GPU name, so the exact hardware differs per run. Watch that the loss actually starts falling before you walk away.

# The same run over the hosted MCP server, protocol version 2025-06-18.
# start_training refuses to do anything without confirm_spend, because it
# rents a GPU and bills the account.
curl -X POST https://www.ay-robots.com/api/mcp \
  -H "Authorization: Bearer $AY_ROBOTS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "start_training",
      "arguments": {
        "dataset_id": "ds_4b18aa",
        "policy_name": "koch-block-pick-act",
        "model_id": "act",
        "max_steps": 100000,
        "confirm_spend": true
      }
    }
  }'

Defaults and when to move them

Cost and duration

ACT trains on the 24 GB tier, which the pool rents from a spot market by VRAM. Budget 2 to 5 hours for the full 100 000 step schedule on 50 episodes, at 0.30 to 0.60 USD per hour, so roughly 1 to 3 USD for the run. The long step count is what makes ACT look expensive on paper and it is not: the same money buys an hour or two on the A100 tier that GR00T N1.7 and Pi0.5 require, where the rate is 1.20 to 2.00 USD per hour.

Deployment and evaluation

Inference runs locally in the client, at about 20 ms per action step. That is far inside the budget of a 30 fps control loop and it means the bottleneck on a Koch is the bus and the servo response, not the model. Set the scene back to the recorded configuration before the first attempt: cameras where they were, the same lighting, the same reset.

1. 1
   Power the arm on the correct rails

   Check the supply against the servo before the checkpoint gets anywhere near the hardware. This is the step where an unfamiliar arm costs people servos.

2. 2
   Watch the first chunk with a hand on the switch

   A chunked policy commits to seconds of motion at a time. If the opening move is wrong, cut power rather than let it finish the plan.

3. 3
   Twenty attempts with varied placement

   Write down every outcome. Twenty attempts is the smallest sample that distinguishes a real 40 percent from a lucky three in a row.

4. 4
   Compare two checkpoints and two nActionSteps values

   Four short evaluations on the same twenty positions. Checkpoint choice and replanning frequency are both worth real percentage points and neither costs GPU time.

5. 5
   Target the failure cluster

   Record fifteen to twenty new episodes of exactly the situation that fails, then retrain. Targeted data beats more data at every scale.

Troubleshooting

When to choose something other than ACT

ACT is the right pick on a Koch when the task is fixed, the scene is controlled, and you want the arm to move quickly and continuously. It is the wrong pick when the object can be anywhere, when you want to command the arm in language, or when you need behavior on objects that appear in no demonstration, because nothing in the model was trained before your dataset existed. The full fact sheet is at /policies/act, the head-to-head against the other 24 GB option at /compare/act-vs-smolvla, and the recording method that all of this depends on is at /learn/record-your-first-dataset.