How to train SmolVLA on a Koch v1.1

What compatible actually means here

The SO-100 is this platform reference arm, which means every feature is built and tested on one before it ships. The Koch v1.1 is listed as compatible. That word is doing real work and it is worth unpacking, because it does not mean the same thing at every layer of the stack.

The practical consequence is narrow and specific: everything from the uploaded dataset onward behaves exactly as documented for the SO-100, and everything before the uploaded dataset deserves an explicit check. That is where the extra steps in this guide sit.

Voltage, which is the opposite trap from the SO-100

The reason this matters for training and not just for hardware is that a brownout mid-episode does not always announce itself. A servo that sags under load produces a demonstration where the recorded action and the achieved pose diverge, and that episode goes into your dataset looking exactly like a good one. If you are unsure about the supply, find out before you record 30 episodes, not after the policy fails to reach.

Validate the recording path before you commit

On an SO-100 you can reasonably record 30 episodes and then look at them. On a compatible arm, spend fifteen minutes proving the pipeline first. Three episodes and a careful look at the dataset preview will surface a bus or calibration problem that would otherwise be baked into an entire evening of work.

ay-robots devices
# The Koch should enumerate six actuators on the Dynamixel bus.
# A partial count is wiring or a duplicate servo ID, never a software setting.

ay-robots calibrate
# Sweep every joint and watch the reported range. A joint that stops early
# here will stop early in every episode you record afterwards.

1. 1
   Enumerate the bus

   Confirm all six actuators answer. Dynamixel servos are addressed by ID, and two servos sharing an ID is a classic Koch assembly mistake that presents as a missing joint rather than as an error.

2. 2
   Calibrate and read the ranges

   Watch the range each joint reports during the sweep. Compare left and right limits against what the arm can physically do. A range that is obviously short means a mechanical stop or a horn mounted a spline off, and it will silently clip every demonstration.

3. 3
   Set conservative torque limits before teleoperating

   The XL330 units in the wrist and gripper are small. A grasp that stalls against a rigid object with the limit wide open is how they overheat. Lower is also better for your data, because a compliant grasp is more repeatable than a forced one.

4. 4
   Record three throwaway episodes

   One task, real motion, then upload them as a scratch dataset and step through the preview. You are checking that the joint traces look smooth, that both camera streams are present, and that the gripper channel actually changes when you close it.

5. 5
   Only now record the real thirty

   With the path proven, the rest is the standard loop: consistent task string, varied object placement, review and discard failures. /so-100/data-collection describes that loop and every word of it applies to a Koch.

Dynamixel data is not Feetech data

A LeRobot dataset stores per-feature normalization statistics computed over the episodes it contains. As long as one dataset holds one arm type, this is invisible and works. Mix Koch episodes and SO-100 episodes into a single dataset and it stops working, because the joint columns no longer describe one action space. This is a stronger objection than the usual advice about mixing two units of the same model, where at least the units agree on what a joint value means.

The other Dynamixel difference that reaches your data is tracking behavior. The XL series follows a commanded position with a different lag and a different holding stiffness than an STS3215 does, so the gap between the action you recorded and the pose the arm actually reached is not the same size as on a Feetech arm. Demonstration advice tuned on an SO-100, in particular how fast you can move and still be precise, needs recalibrating by eye. Move slower than feels necessary for the first ten episodes and watch the playback.

The training run

From here on there is nothing Koch-specific left. Open Training, pick the dataset, pick SmolVLA, name the policy, press Start. The job sees a LeRobot v2.1 dataset and does not know or care which bus produced it.

Seed and log frequency are lerobot family parameters, shared with ACT and Pi0.5. Neither GR00T entry point offers a seed, so the reproducibility you get here does not follow you up the ladder.

A full run is 2 to 5 hours at 0.30 to 0.60 USD per hour on the 24 GB tier, roughly 1 to 3 USD. On an arm where you are still learning what good demonstrations feel like, that price is the point. Two runs on two versions of a dataset cost less than one A100 hour, and the second run tells you whether the change you made to your technique actually helped.

Language conditioning and the task string

SmolVLA attends to the sentence attached to each episode, so the same discipline applies here as anywhere: one task, one sentence, pasted rather than retyped. The Koch-specific version of the warning is that people arriving from another arm tend to carry a task string across and edit it, ending up with two variants split across one dataset.

Used deliberately, the same mechanism is what lets a single 60 episode Koch dataset hold two jobs, thirty episodes each, that you select between at inference by changing the string. That is worth setting up while the scene is fresh, since both tasks need the same camera positions to share a policy.

Deployment and evaluation

Load the checkpoint, restore the camera positions from your notes, pass the recorded task string, and keep a hand near the power. SmolVLA runs at about 245 ms per action step, so the arm moves in discrete increments and there is time to reach for the switch, which is more reassurance than a 20 ms ACT policy gives you.

• Twenty attempts with varied object placement, each outcome written down as it happens.
• Two or three checkpoints from the back half of the run, compared under the same protocol.
• Watch the gripper specifically. It is the joint whose behavior differs most between Dynamixel and Feetech arms, and the one most likely to disagree with advice written for an SO-100.
• A separate pass with a reworded instruction, to measure rather than assume language robustness.

Troubleshooting on a Dynamixel arm

Where to go after this run

If the SmolVLA policy makes task-shaped attempts, your Koch pipeline is sound and the dataset carries signal. That is exactly the condition under which spending A100 hours is rational. GR00T N1.7 wants 50 or more episodes, an 80 GB card at 1.20 to 2.00 USD per hour, and a v2.1 dataset, which is what you already have. /train/groot-n1-7-on-koch-v1-1 is that run, and /policies/groot-n1-7 has the details.

If instead the policy does nothing recognizable, do not escalate the model. Escalate the data check. A larger model trained on demonstrations that disagree with each other produces the same failure with a bigger invoice. /policies/smolvla explains where this model ceiling actually sits, and /compare/act-vs-smolvla covers the other option on the cheap tier.