数据录完了、也公开了，四个 checkpoint 训完了、也发布了，策略现在能驱动实机手臂。74 次记分试验里成功 7 次。验收线是 10 次里成功 8 次 —— 而且训练时用的那副夹爪，今天上午已经换掉了。
整条链路是通的 —— 录制、上传、云端训练、下载、带安全层在实机上执行，全部走得通。没解决的是抓取本身。而且今天换了夹爪，四个已发布 checkpoint 背后那 50 集数据已经和现在的机器人对不上了；下一步该做的是重录一批新数据，而不是拿旧数据再训一次。
登记表是靠真的把每个数据集加载一遍生成的，不是看文件名：37 个结构可用，30 个不可用（只作为「试过什么」的记录保留）。「可用」指能加载，不代表抓取成功。
| 批次 | 集数 | 帧数 | 用途 |
|---|---|---|---|
cup-grasp-20260820-0230 |
50 | 19,453 | 所有已发布 checkpoint 的冻结训练集。五个杯位。Hub 上为私有（HTTP 401）。 |
right-pick-cup-20260824-1055 |
19 | 5,422 | 今天上午换爪之后录的。重录批次的开头。 |
right-pick-cup-20260824-0344 / -0714 |
2 + 2 | 1,981 | 换爪前后夜里录的两个小批。 |
| 更早的 34 批 | 60 | 54,451 | 08-16 至 08-20 的 soak 测试和探索性录制。 |
所有已发布模型都是在同一份 50 集数据上微调的。三个 SmolVLA 跑法之间唯一变量是 batch size —— 本机 Jetson 只塞得下 batch 2，这也是后来转去租 A100 的原因。
| 训练 | 在哪训 | Batch | 保留的 checkpoint |
|---|---|---|---|
smolvla_20260820-1502 |
本机（Jetson） | 2 | 16000 · 18000 · last |
a100-6000 |
租用 A100 | 64 | 6000 |
b8-u20k |
租用 A100 | 8 | 20000 |
act_20260820-0429 |
本机（Jetson） | — | 4000 · 20000 |
Suyang99/xlerobot-smolvla-cup-grasp-right 24 次下载Suyang99/xlerobot-act-cup-grasp-right 15 次下载Suyang99/xlerobot-smolvla-20260820-step16000 9 次下载Suyang99/xlerobot-act-20260820-step20000 10 次下载做过一次位置级留出评估：训练时排除一个杯位，再在该位上评分 —— 未见位置 loss 0.2300，已训位置 0.2348，比值 0.98x。这个数只能这样读：拿录好的观测去比录好的示范动作。模型自己的错误不会改变下一帧。它不是 rollout，也没有预测出下面的实机结果。
下面每一次都是经安全包装层真正发出电机指令的。「作废」指这次不算 —— 安全层连续 15 帧拒绝，或操作者中止 —— 不计入成功率。
这张表说清了两件事。云端 checkpoint 虽然 batch size 健康得多，实机上并没有赢过 Jetson 那个憋屈的跑法 —— 算力买不来这个抓取。以及 Jetson 侧其实只飞过一个 checkpoint：checkpoints/last 是指向 016000 的符号链接，所以记在「last」和「016000」名下的是同一份权重。018000 存在，但从没试过。
机器人面板的「实机试验」区读的是同一批 JSON，但只列 20 个 run 文件（磁盘上有 31 个）。所以它给出的分模型合计比上面的小 —— 上面数的是全部历史。两个都对，只是回答的问题不同。
提交 c6cec86 抬高了腕部下限并写入了新测的爪长：右臂 z_min 0.02 → 0.065，左臂 0.01 → 0.061，并由 measure_table.py 写入 gripper_len_m: 0.1179。10:55 录的那 19 集是新硬件上的第一批数据。
这一条在试验日志里看得见，而且是目前整个项目最尖锐的单一信号。到 2026-08-24 03:33 为止，安全层拒绝的帧大约是 0%。从 08:07 起变成三分之一 —— 最近两次是 34.0% 和 32.5% —— 并有两次直接中止，原因是「right wrist height +0.0634 m outside [0.065, 0.35]」和「+0.0494 m outside [0.065, 0.35]」。
直白说：这些 checkpoint 学的是下降到一个现在被下限禁止的高度。安全层没做错 —— 是策略在瞄准旧的桌面。再拿这些 checkpoint 试机，量的是「新下限」和「旧训练数据」之间的分歧，不是策略好坏。
00:50 到 01:22 之间，录制的手臂映射严重错乱 —— 前伸变转向、上下变画弧。根因是在两条控制路共用的上游加了一次坐标变换，而两个消费者对坐标的预期不同。01:22 已完全还原，与 08-17 那次卡顿不是同一个问题。
配置里已经是实测的 0.1179 m，但 clamp_report.py:36 和 robot_server.py:4091 仍写死 0.159，操作指南文案 robot_server.py:2036 与 :2308 还在教 0.159 配 z_min +0.02。凡是靠这些常数反推桌面高度的地方，现在报的都是一张不存在的桌子。
值得操作者核一下：旧的一组反推桌面在 −0.139，新的一组在 −0.053，差 8.6 cm。要么桌子挪过，要么这两个数里有一个得在下次试机前重测。
爪长一变，学到的「关节角 → 接触点」映射整体平移。这是运动学问题不是视觉问题，在旧批次上再堆数据补不回来。上面那 33% 的拒绝率，就是这个错位在动作上的表现。四个已发布 checkpoint 现在都是历史参考。新旧夹爪的数据绝不能混在一次训练里。
OK / CLIPPED / HELD 和拒绝原因只打在终端里。SAFETY.md §6 第 6 点要求把原因推到面板。2026-08-16 那次撞臂，部分原因就是操作者看不到反馈，所以这条排在试验看板之前。
此后已经训了两个 A100 跑法并在实机上测过。index.html 的 Now 区块该改成「换爪后的重录批次」。
分支 fix/gpu-inference-and-tunnel-auth-20260821 上的 record.py、robot_server.py 和四个面板页 —— 约 970 行新增，装着今天的录制与面板改动。
measure_table.py --pivot，然后把那三处写死的 0.159 改成从配置里读。