How to train GR00T N1.7 on a Koch v1.1

Support status, stated plainly

In practical terms: expect the training half of this guide to be boring and reliable, and expect to spend your troubleshooting budget on the bus, the rails and the servo IDs. That is also why this page spends more words on the hardware than the SO-100 page does. The interesting problems on a Koch happen before the first upload.

What actually differs: the bus, the rails, the torque

Prerequisites

• A built Koch v1.1 follower, with a leader arm if you have the pair
• A Dynamixel USB interface and the correct supply for each rail, checked twice
• Unique servo IDs across the chain and one agreed baud rate
• At least one fixed camera, and a wrist camera if the build has a mount for it
• The client installed and paired. It ships the Dynamixel driver, so there is no Python environment to build
• A LeRobot v2.1 dataset of 50 or more reviewed episodes

ay-robots devices

# SERIAL PORTS
#   /dev/cu.usbserial-FT89ILSF   Koch v1.1  (6 servos responding)
#     id 1  XL430-W250   12 V rail
#     id 2  XL430-W250   12 V rail
#     id 3  XL330-M288    5 V rail
#     id 4  XL330-M288    5 V rail
#     id 5  XL330-M288    5 V rail
#     id 6  XL330-M288    5 V rail   gripper
# CAMERAS
#   0  USB 2.0 Camera   1280x720   scene

Calibrating a Dynamixel arm

Dynamixel servos store a homing offset in their own EEPROM, and a Koch built from the community instructions may already carry offsets written by the LeRobot setup scripts. Those are not the reference frame the client uses. Run the calibration through the client regardless of what the servos already believe, so that what your dataset records and what the policy later commands agree with each other.

ay-robots calibrate

# Koch v1.1 on /dev/cu.usbserial-FT89ILSF
#  torque disabled on all 6 servos
#  move the arm to the home pose, then confirm
#  sweeping joint limits ...
# calibration stored for robot "koch-bench"

Two failure modes are specific to this bus and both are quiet. A duplicated servo ID does not raise an error, it simply reports one servo where two exist, and the joint that vanished shows up much later as a dataset column that never changes. A baud rate mismatch mid-chain makes the servos past that point invisible, which looks identical to a broken cable. Confirm six responses before you calibrate, not after you have recorded.

Torque, and why hand guided recording is different here

This is the difference you will feel in your hands. Dynamixel servos hold position through a torque enable register. With torque on, the arm resists being moved. With torque off, it back-drives freely, and the XL430 joints at the shoulder will sag under the weight of everything above them the moment they release.

The consequence for your data is worth being precise about. A joint that sags while you reposition between episodes is harmless, because nothing is recording. A joint that sags during an episode is written into the dataset as an action you intended, and the policy learns to drop the shoulder at that point in the trajectory. It will reproduce it faithfully, and it will look like a model defect.

The dataset the trainer sees

Once the episodes are recorded, none of the above is visible any more. A Koch episode is six floats of state, six floats of action, one or two video streams and a task string, arranged exactly as an SO-100 episode is. GR00T N1.7 does not branch on robot_type and has no concept of which servo brand produced the numbers. This is the reassuring half of the guide: the arm is unusual, the training job is not.

{
  "codebase_version": "v2.1",
  "robot_type": "koch",
  "fps": 30,
  "total_episodes": 58,
  "features": {
    "observation.state":         { "dtype": "float32", "shape": [6] },
    "action":                    { "dtype": "float32", "shape": [6] },
    "observation.images.scene":  { "dtype": "video",   "shape": [480, 640, 3] }
  }
}

The fifty episode floor applies for the same reason it applies on every other arm: fine-tuning adapts a small set of parameters on top of a frozen backbone, and with fewer examples than that it fits your specific start positions instead of the task. On a Koch there is one extra reason to respect it. Torque related noise costs you episodes at review time, so plan to record sixty or seventy to keep fifty.

LeRobot v2.1, and the rejection you will see if you skip this

GR00T loads LeRobot v2.1 and refuses v3.0. Koch owners hit this more often than most, because this arm has been around the LeRobot community long enough that people have older recordings and mixed tooling on disk. A dataset assembled from a directory you last touched a year ago is exactly the case that fails.

The visible symptom is a job that burns two minutes of A100 time and returns FAILED with a metadata error, before any chart exists on the run page. It reads like an infrastructure problem, which is why the usual reaction is to re-upload and start again. That reproduces it exactly. Read codebase_version in meta/info.json instead, convert if it says v3.0, and upload the converted copy.

Running the fine-tune

1. 1
   Check the dataset preview before you select it

   Open the dataset and confirm it has six action columns and that none of them is flat across every episode. A flat column is the joint that a duplicated ID hid from you at recording time, and training on it wastes the whole run.

2. 2
   Select the dataset in the Training page

   Only datasets that finished processing are listed. The card shows episode count and robot type, which is your last chance to notice you picked last week’s version.

3. 3
   Choose GR00T N1.7

   It requests the A100 80 GB tier, and it is the current model of the two GR00T entries. N1.5 exists to reproduce runs from before N1.7 shipped and is not a reasonable default for a new Koch project.

4. 4
   Review the hyperparameters and leave them alone

   Batch size 32, learning rate 1e-4, 20 000 max steps, gradient accumulation 1, plus save steps. There is no seed field for GR00T. Nothing about a Dynamixel arm justifies a different starting point than a Feetech one, because the numbers reaching the model are the same shape.

5. 5
   Start the run

   The pool selects an 80 GB card on the spot market by VRAM rather than by name. Waiting in QUEUED costs nothing, so a busy market is an inconvenience and not an expense.

6. 6
   Watch loss and telemetry for the first few hundred steps

   A visible drop early means the data loaded. Flat from step one means it did not, and the run is worth cancelling immediately rather than at hour four. GPU utilization and power on the same page confirm the card is actually working.

7. 7
   Choose checkpoints for the hardware test

   Take two or three from the second half of the run. The last checkpoint is frequently not the best one, and the only way to establish which is best is on the arm.

Defaults for GR00T N1.7

Cost and duration

The A100 80 GB tier rents at 1.20 to 2.00 USD per hour, and a default 20 000 step run on fifty to a hundred fifty episodes takes 3 to 6 hours. That puts a complete Koch fine-tune at about 4 to 12 USD. The price is set by the spot market on the day, not by your arm or your dataset size.

Relative to a Koch v1.1, which costs roughly 250 to 350 euro in parts, the training runs are the cheap part of the project. The expensive resource is your recording time, which is a reason to fix the torque and ID problems before you record rather than to save two dollars on a shorter run.

Deploying the policy on the Koch

Select the checkpoint for the paired robot and start inference from the client. Restore the recording conditions exactly: camera positions, lighting, reset procedure, task sentence. At roughly 152 ms per action step the arm receives a new command six or seven times a second, which on Dynamixel servos looks like a series of short deliberate moves rather than one flowing motion.

One hardware precaution is specific to this arm. Dynamixel servos raise a hardware error flag and shut the joint down when they overload, and an early policy that drives the gripper into the table will trigger exactly that. It looks like the policy freezing mid-motion, which is also a data symptom, so check the servo state before you conclude you have an observation gap. Conservative current limits on the shoulder joints make the first evaluation session much less eventful.

Then evaluate properly: twenty attempts, the object somewhere different each time, results recorded as they happen. Physical success rate is the only number that means anything. A loss curve cannot tell you that a policy learned to compensate for a sagging shoulder that no longer sags now that torque is on during inference, and that is a genuinely Koch-shaped way to fail.

Troubleshooting

Frequently asked questions