Arm test, 9 Nov: π0.5 A at 16000 steps, against B

• Checkpoint: outputs/pi05_full_vial-sort-ws220_canon_base16k/checkpoints/016000 (from lerobot/pi05_base, LR 2.5e-5, 16000 steps, pinned quantiles; trained on the cluster 7 Nov). Sync, 15 actions per replan.
• Session the session log (started 00:50). 37 rollout starts for 31 moves, the same count as B’s 37. Repeats: L6→R1, L6→R3 and R1→L3 were restarted after 8–13 s; L3→R6, L2→R6 and R2→bin are the retries in the operator’s notes. L3→R3’s first try ran 39 s before the reset, and the note says “success”. If that first try failed, block 2 below is 3/4 on first tries.
• B’s rollouts and the grasp analysis: ee/ROLLOUT_ws220_B16000_8nov.md.

Rollouts, as recorded at the robot (the operator’s words), next to B

Tally, A vs B

Move by move (ranking ✓ > drop missed at the right slot > one off > wrong slot > no grasp): A is better on 16, B on 5 (1, 2, 10, 11, and 30 where A needed a retry), and 10 are the same.

The 12-take gate: A meets it, narrowly

A passes both arm criteria, with no margin, and only 7 of the 12 were actually placed. What’s left is mostly the drop, not the destination.

The destination, by digit

B’s squeeze is gone in A. Slot 6 is reached every time, and A even lands on slots 4 and 5, which never appear as destinations in training. It has learned where each number is, not 1/3/6 as three memorised moves. Slot 3 is A’s weak one (twice slot 2, both times with the vial from rack position 3 or 1).

Grasps: 1 failure in 31 (the one move that isn’t in the training data), against B’s 7. B’s L6/R6 source problem doesn’t happen in A: L6 and R6 were picked up in all 8 of those moves. (Caveat: L6→R1 and L6→R3 were restarted after 8 and 13 s. If those were failed grasps, the recordings will show it. They can be read once the session is closed.)

Held-out source slot 2: twice A went for a neighbouring vial first (L4, R3/R4). Slot 2 is never a source in training, so this tests generalisation, not the gate. B didn’t grasp L2 at all, and did R2→bin on the first try.

Probes (cluster, 9 Nov 00:43–; checkpoints 8000, 10000–16000 of both runs)

probe_go (does it leave home?): both runs pass at every checkpoint. All 9 real start frames move 72–88°, on 4 of 4 seeds. Error against the recorded demonstrations: B 2.0–3.7°, A 2.8–4.7° (A improves steadily to 16000).

probe_digits:

• DEST predicts the carry 1 s after the grasp, so the spreads are small for both. But A’s is bigger on the same frames, e.g. episode 77: A +31 / +27 / +16 vs B +11 / +9 / +7. That matches the arm.
• Is 16000 the best for B? On these probes B is flat: 8000 through 16000 give the same numbers within 1–3°. No other B checkpoint is better, and on the arm B is clearly behind A anyway.
• A’s 13000–15000 score one frame more than 16000 (2/7 vs 1/7). That’s one frame crossing the 10° line (episode 50: 33/30/22 at 13000 vs 32/29/22 at 16000): noise, not a reason to switch.

probe_shortcut (destination from the prompt or from the cameras), checkpoints 8000 and 10000–16000 (jobs 37843/37844 finished 02:00–02:03, 1 h 17–20 min each):

Flat across checkpoints for both runs, so it doesn’t pick a checkpoint either. Neither model passes the old “prompt swap ≥ 80%” line, base12k’s 19% is in the same range, and A leans less on the scene cameras than B. But this probe asks the model to change destination mid-carry: the frame is 1 s after the grasp, when the arm is already moving toward the recorded one. On the arm, with the prompt there from the start, A went where the digit said within one unchanged scene (blocks 1 and 2). The probe was built for ws100’s failure, where the scene named the destination. On the contrastive data it doesn’t separate A from B. A cleaner version would compare the three rollouts of one triplet at the start frame.

Checked from the recordings after the session (9 Nov, 01:45–02:00)

First tries. Some repeats in the log weren’t in the notes:

• L3 → R3, first try: A grasped (jaws 8.1°) and carried the vial for 28 s without ever letting go. The “success” was the second try. So the gate’s block 2 is 3/4 on first tries, and the gate on strict first tries is 8/12 right slot: one short.
• L6 → R3, first try: the gripper never closed in 11 s (hovering, B’s failure mode). R1 → L3, first try: no close within 6 s, too short to call. L6 → R1, first try: it had the vial when you reset at 6 s.
• Strict first-try count: A placed about 17–18 of 31, B 11.

Release poses: the missed drops are a last-centimetre problem. Follower joints [pan lift elbow wflex] at the moment the gripper opened, right rack:

The misses opened within 3–5° per joint of the successes at the same slot. A wasn’t aiming somewhere else. A few degrees at the wrist and elbow is ~1–2 cm at the gripper, the size of “in front of / behind the slot”. The demos’ pan per slot is the same in all three batches (within 2–3°), so the racks haven’t moved sideways. (Release style did change: the old 70 released with a flatter wrist, wflex −28 to −43, than batches 1–2, −42 to −61.)

The left_top camera moved on 4 Nov (and it’s still off)

Phase correlation of the first frames’ edges, table area only, against batch 2 (3 Nov), at 640×480.

• = picture lower / further right:

So left_top was bumped on 4 Nov between 18:31 and 18:33, during the B 4000 tests: ~12 px down and ~6 px left, about 6 px at the model’s 224×224 input. Every arm test since then ran with left_top away from where 150 of the 220 training episodes were recorded. the operator’s “moved before the 2nd batch” matches the old 70 being in another position again.

Whether it matters isn’t proven. A reaches the right slot most of the time with the camera off, so it isn’t breaking the task. But the failures left are last-centimetre drops, and that’s where the cameras guide the arm. Test: put it back (.venv/bin/python tools/cam_align.py prints the live offset and which way to move the camera until ALIGNED), then repeat the near-miss moves on A 16000 with a few controls.

Data and model

• The model: sari-abdan/vial-sort-pi05-ws220-a-16000 (Plain Bagel on the Results page)
• What it trained on: sari-abdan/vial-sort-slots-220
• The recordings of this session: rollout_pi05_016000_20261109_005026