远程四件事的结果：A 没过、B 把 B0 的速度理由毙了、C 有个更硬的答案、D 做完了

对应 HANDOFF-REMOTE-2026-09-04.md 的 A/B/C/D。全程没碰硬件。 每条结论都标了证据等级，联系表原图在下面，可以自己复看。

结论先行

1. A 没过验收，不进入阶段 B。逐框人工核对后，最好的一个是 「框到目标杯」5/36 = 13.9%（出框率 44.4% 是上界，不是命中率）。 失败原因有两个，同时存在：精度不行（框到 VR 手柄、桌面圆孔） ＋ 消歧没做（场上还有第二只真杯子）。
2. B：B0 的速度理由不成立，当场毙掉。顺带查出两个被传错的数 ——146 ms 是 ACT 的，不是 SmolVLA 的（SmolVLA 实测 1329 ms，10.3 倍）。
3. C2 不用权衡：OpenCV 5 删掉了 cv2.CascadeClassifier，Haar 那套现在根本跑不起来。 留 YuNet。C3 注释已改、行为没动。C4 文献首次查了，三篇带链接。
4. D 做完了，--dry 已验（10 项自检全过），并端到端过了读取端。

A · 离线跑开放词表检测

跑法：head 相机，跨 3 个数据集各抽 12 帧共 36 帧（不同批次 = 不同杯子，天然覆盖 「换一种杯子」这条验收），逐帧出联系表人工看过图。 帧固化在 05-training/detect/frames/，保证几个 python 环境比的是同一批画面。

出框率不是命中率。把每个被判成 cup 的框裁出来放大逐个看：

OWL-ViT 那 10 个真杯子里，只有 5 个是目标杯，另外 5 个是画面左上角另一只真杯子 （淡蓝绿色不透明塑料杯，离相机近）。

原始出框率与耗时

看图：三张联系表

★ 这一轮真正的发现：两个问题同时存在 ★

把 OWL-ViT 的 cup 类候选框全部打印出来核对，台面上的目标杯每一帧都被检出了， 只是排在第 2–4 名：

--- frame 0 ---                            --- frame 8242 ---
  #0 0.138 a mug   (7,52,60,103)  背景玻璃杯     #0 0.090 a mug  (303,47,381,110)  ← 目标杯
  #3 0.044 a cup   (195,65,235,122) ← 目标杯      #1 0.032 a cup  (308,48,366,86)   ← 目标杯

所以这是两个问题被混成了一个：

仍然成立的那半：把候选全部列出来时，目标杯在检查过的帧里都在候选中（排第 2–4 名）。 但「候选里有」推不出「识别没坏」。

三条实测边界条件（下一轮直接当输入用）

1. 2D 框面积不能当「最近的杯子」用。试过按框面积挑（--pick largest），没救回来： 背景那只玻璃杯离相机更近、框反而更大。 真正的「最近」得用深度旁路（640×480 16-bit PNG、毫米，要按 100–2000 mm 裁离群值）。
2. query 集合本身是个变量，而且各模型口味相反。 a drinking glass 对 GDINO 是毒 query（钓通风口），对 OWL-ViT 反而是主力 ——摘掉后 OWL-ViT 从 16/36 掉到 12/36。 换一个模型，query 集合必须重新过一遍人工看图，不能沿用。
3. 「不许写外观规则」这条的边界（澄清，不是放宽）：禁的是我们手写的外观规则。 给开放词表模型一句语言 prompt，或给干扰物一个自己的标签 （加 "a ceiling vent" 实测能把 GDINO 从钓通风口拉回来），不在禁令内 —— 那是运行时可换的输入，不是编译进代码的假设。 但它不解决「换个杯子要改 prompt」，只能当权宜。

B · 判 B0 生死

更正一：146 ms 不是 SmolVLA 的数，是 ACT 的

出处是 run_policy_trials.py:265 的注释，原文写的是 「2026-08-21 实测（ACT 51.6M，三路相机，本机 Orin）cuda 146 ms/帧」。 传到交接文档和 GOAL-DEPTH-INTEGRATION.md 时模型名被换成了 SmolVLA。 同机同法重测：

SmolVLA 是 ACT 的 10.3 倍。

更正二：「6.9 Hz vs 训练 30 Hz」这个对比对分块策略本身就不成立

SmolVLA 一次推理规划 n_action_steps = 50 步，在 30 Hz 回路上等于 1667 ms 的动作。 该问的不是「推理频率够不够 30 Hz」，而是一次推理能不能在 1667 ms 内算完：

Y 的上界：视觉 token 不是大头

做法：在预处理之后从 batch 里删 image 键，而不是把画面涂黑 ——涂黑的图照样过 vision encoder、照样产生 token，量到的会是 0，那是个假答案。 本 checkpoint empty_cameras = 0，所以删掉的键不会被补成黑图。

每多一路 +59.2 ms，三路的视觉部分合计 177.7 ms = 总耗时的 13%。 而这 177.7 ms 是 Y 的上界 —— B0 是把每路 token 从 256 压到 16，不是压到 0，真实 Y 更小。

所以 X（分割模型每帧开销）必须显著小于 177.7 ms，B0 才可能净正。 FT-Dinosaur 是个 ViT，在这块板子上不可能比 177.7 ms 小多少。不用再去下它了。

证据等级：实测。Jetson Orin Nano Super，train310 + CUDA，warmup 3 次、计时 12 次取中位。 数据 05-training/detect/bench_cameras.json，脚本 bench_smolvla_cameras.py。

C · 盘点 HRI + 修安全层那处数字错误

C2 · 留哪套人脸检测 —— 这个选择已经被环境替我们做了

实测把 face_perception.HaarFaceDetector() 在 train310 里构造一下，直接抛 AttributeError: module 'cv2' has no attribute 'CascadeClassifier'。 face_follow.py:262 调的是同一个 API，在同一环境里会死在同一个地方 （未单独跑 —— 跑它要开相机、要动舵机，属于现场的事）。

Haar 那套不是「不如 YuNet」，是「现在根本跑不起来」， 而唯一还能跑它的 lerobot 环境恰恰是 torch 没有 CUDA、不能跑策略的那个。

YuNet 实测开销（train310，8 帧热身后取中位）：640×480 18.9 ms/帧，320×240 10.0 ms/帧。 模型 227 KB，已在仓库里。

另记：conversational_ai/models/ 里还躺着一个 blaze_face_short_range.task（MediaPipe BlazeFace，229 KB）。 全仓 grep 过，没有任何代码引用它 —— 是个没接线的资产，不是第三套实现。别把它算进来，也别顺手接上去。

C3 · 安全层注释里的事实错误 —— 已改注释，行为没动

独立复核过（不是照抄交接文档）：读 xlerobot-cup-grasp-20260820-0230 的 observation.state[13]，19453 帧全部是 49.8462（min == max），不是注释写的 99.649。 按注释自己那条公式重算：

旁证：configs/head_presets.json 的 cup-grasp-v0 tilt = 2619，比 range_max 高 2 counts。 两个独立来源都说标定边界和头的实际位置只差个位数 counts。

C4 · 人机递交文献（首次查，三篇带链接）

D · 关键帧采集 —— 做完了

新增 03-software/scripts/trial_keyframes.py，接进 run_policy_trials.py。 三个设计选择都是为了绕开这一步已知的坑：

自测清单