xlerobot-act-cup-grasp-right

ACT — right-arm cup grasp (XLeRobot)

Trained with LeRobot ACT on Suyang99/xlerobot-cup-grasp-20260820-0230.

A previous version of this card read step 200001211111. That was an upload-script bug (tr -dc '0-9' concatenated every digit in training_step.json), not a real step count. Fixed.

Training did not converge — it was cut off while still improving

Read this before comparing the checkpoint against anything.

The curve is healthy — monotone, no divergence, no oscillation, gradient norm down 95%. But over the last 5 000 steps the mean loss still fell 13.2% (0.1750 → 0.1519). A converged run is flat there. This checkpoint stopped where it was still learning.

The reason is the step budget: batch_size = 2 × 20 000 steps = 40 000 samples over a 19 453-frame dataset — 2.06 epochs total. ACT is normally trained far longer.

No validation was run

eval_freq was None, so every number above is training loss. Nothing here measures overfitting or generalisation, and loss: 0.138 must not be read as "the policy learned the task". The project's own guidance is explicit that training loss is not an acceptance criterion.

The generalisation evidence that does exist comes from the sibling SmolVLA run (Suyang99/xlerobot-smolvla-cup-grasp-right), which was given a held-out cup position: unseen-position loss 0.2300 vs trained-position 0.2348 (0.98×). That is offline replay of recorded observations, not a closed-loop rollout.

KLD collapsed

kl_weight = 10.0, yet KLD fell from 1.122 to 0.004. The CVAE latent is effectively unused and the model has degenerated to deterministic chunk regression. Not unusual for ACT on a small single-task dataset, but worth knowing before treating the latent as meaningful.

Checkpoint availability

Ten checkpoints were written during training (every 2 000 steps). Eight no longer exist — they were deleted from the Jetson under disk pressure and never uploaded. Only these two survive:

hf download Suyang99/xlerobot-act-cup-grasp-right \
  --revision a920f833 --local-dir ./act_step4000

(huggingface-cli is deprecated and on recent versions prints help and exits 0 without downloading anything — use hf, or snapshot_download(..., revision="a920f833") from Python.)

Important: the left arm is parked in this data

Dimensions 0–5 (the left arm) hold a single constant across every frame — the recording ran with arms: 1.0, so the left arm never followed the operator. This policy therefore cannot drive the left arm, and it will not transfer to a left-arm version of the task. A bimanual task needs its own recording with arms: 0.0.

Hardware caveat

The gripper is being replaced (Fin-Ray blade 68 mm → 90 mm). Once that lands, the arm's dynamics change and this checkpoint's real-world behaviour has to be re-measured.

Not yet run on a robot

As of 2026-08-21 this checkpoint has never driven the physical arm. Any policy-to-motor path must go through the project's safety wrapper first (NaN/inf rejection, per-joint absolute and per-step clamps, Cartesian envelope rejection, base zeroing, head lock).