← 返回报告索引
2026-09-04 · 远程待办交接

交接:下个 session 能纯远程做完的四件事

⚠ 2026-09-04 更新:这四项已经执行完了。结果见 结果页 和 流水账。本页保留作为交接记录。
下面 B 项里的 146 ms 是错的 —— 实测 SmolVLA 是 1329 ms / 50 步,146 ms 那个数是 ACT 的。

读这一份就能开工,不需要回看旧对话。 这四件全部不碰硬件、不占机器人时间,可以和现场组员并行。 现场那边的清单在 明天要干什么,两边互不阻塞。

建议顺序:A → B → C → D。如果只做一件,做 A。
A 最优先,因为后面所有动作都压在「能不能可靠找到杯子」上,而这件事我们失败过三次。

0. 先读这一段:环境事实,不知道会走弯路

事实出处 / 怎么验证
lerobot 环境的 torch 是 CPU-only torch 2.11.0+cu130,驱动 CUDA 12.6,torch.cuda.is_available() → False
跑模型要用 train310 ~/miniconda3/envs/train310/bin/python,torch 2.8.0,CUDA 可用。也是 robot_server.py:67 的 PY_POLICY
机器Jetson Orin Nano Super,7.4 GiB 内存(CPU/GPU 共用),16G swap
磁盘剩 34G / 116G硬约束。下模型前先 df -h /,满盘会让 Bash 整个失效
8770 面板已跑着。html 每请求现读,改前端不用重启
git所有 git 写命令都在 deny 列表里,提交由操作者做
量任何模型耗时都必须用 train310。 用 lerobot 会得到一个假的「跑不动」,然后据此否掉一条本来可行的路。 这是这份交接里最容易犯的错。

1. 昨夜已经做完的,别重复劳动

状态
试验记录 schema v2 + 读取端归一化(trials_io.py,334 行)✅ 三环境自检通过,对 scipy 偏差 6e-15
三个读取端收敛到一处✅
面板显示 k/n + 95% 区间 + 失败模式分布 + 子目标漏斗✅ 已上线
预注册入口(面板输入框 + CLI 参数)✅
三份 GOAL + 明日现场清单 + 概念 pitch + 市场分析✅ 已发布

试验数据管理 GOAL 的第 1、3、4 步都做完了,只剩第 2 步 —— 就是下面的 D。


A · 离线跑开放词表检测,回答「能不能可靠框住杯子」

纯远程 四件里最重要的一件

它是后面每一个动作的共同地基:倾倒、展示、递出,全都要先能稳定找到杯子。

为什么不能再手写规则

已经失败三次,每次数字都好看,每次都被看图推翻:

做法数字真相
locate_nearest检出 79%锁的是机械臂,宽度 273–344mm
locate_on_table检出 97.5%,跳动 0.9mm还是机械臂。「稳定」是因为锁住了不动的手臂
+ 剔除接触边界的连通域检出 97.6%,跳动 6.4mm,宽 86–129mm数字全合理,看图仍无法确认是杯子
操作者已定的顺序:先跑 OWL-ViT,再上业界版本(Grounding DINO + SAM)更扎实。
OWL-ViT 单模型、体积可控、直接出框,足够回答「行不行」;过了再上 Grounding DINO 拿更准的框、SAM 拿掩码。

数据在哪(本地已有,不用下载)

全部在 ~/.cache/huggingface/lerobot/,每个都是三路 RGB (head 424×240,两个 *_wrist 640×480),30 fps:

数据集集数 / 帧数用途
xlerobot-right-pick-cup-20260826-004240 / 16487换爪后的当前主数据集
xlerobot-cup-grasp-20260820-023050 / 19453现役模型就是拿它训的
xlerobot-left-pick-cup-sep3-20260903-201529 / 6507最新一批(左臂)
xlerobot-right-pick-cup-sep2-2026090*各 11–14 集还有好几批

「换一种杯子仍成立」这条验收,跨数据集跑就能覆盖 —— 不同批次的杯子不一样。

验收(事先写死,不许放宽)
· 抽 ≥30 帧人工核对,逐帧看图确认框住的是杯子,命中 ≥90%
· 至少换一种杯子仍成立
· 达不到 不进入阶段 B

★ 「人工看图核对」不许跳过。前三次失败全栽在这一步。 做法:把带框的帧拼成联系表存成图片,自己看一遍,不要只看统计量。

B · 量 token 缩减路线的净收益,判 B0 生死

纯远程 几个小时就能出结论

现状:  SmolVLA 一次推理 1329 ms,规划 50 步  (原文误作 146 ms/帧,那是 ACT 的数)
B0 想做的:  视觉 token 256 → 16
           省下  Y ms   (token 变少,语言模型那段变快)
           付出  X ms   (分割模型每帧要多跑一遍)
净收益 = Y − X
★ 先测 Y,而且不用下载任何模型 ★
这是上一轮讨论得出的关键顺序修正:如果 Y 本来就小,X 再小也翻不了盘,B0 的速度理由当场就没了。

SmolVLA 吃三路相机。用 1 路 / 2 路 / 3 路各跑一遍推理计时, 就能量出「每多一张图的 token 值多少毫秒」,给 Y 定上界。 零下载、零磁盘、不碰手臂。先做这个,再决定值不值得为 X 去下 FT-Dinosaur。
结果含义该怎么做
X > Y(净负)分割模型比省下的还贵B0 在这块板子上毙掉
X ≈ Y(净零)速度上不赚不亏只剩「结构先验帮泛化」一个理由,和 B1/B2 重新比
X < Y(净正)又快又有结构先验B0 升为优先,顺带缓解 6.9 Hz vs 30 Hz
引用纪律:Oat-VLA 论文报真机 59% vs 41%。用我们自己的 Clopper-Pearson 算它给的原始计数: 29/49 vs 20/49,区间重叠,Fisher p = 0.106,不显著。 引用它的 token 缩减和收敛速度,别引用它的真机成功率。

C · 盘点已有的 HRI 代码 + 修一处安全层数字错误

纯远程 产出是一份清单和一个决定

这套东西三周前就写好了(2026-08-14 提交,main 和 china-console 都有):

文件行数做什么
face_perception.py265感知适配器 → FaceObservation(检测 + 表情,不做身份识别)
face_follow.py330头部跟随一张主脸,直驱舵机 7/8
face_display.py168ESP32-S3 + OLED 表情脸
test_face_emotion.py113冒烟测试
DEMONSTRATION-INTERFACES.md325示范接口决策文档

再写一套是重复劳动。先读,再列缺口。

内容
C1通读上面五个文件,出「已有 / 缺 / 冲突」清单
C2决定留哪套人脸检测:Haar(scripts/)还是 YuNet(conversational_ai/)。现在两套并存,别加第三套
C3★ 修下面那处数字错误 ★
C4查文献:人机递交(human-robot handover)。我们没查过。至少三篇带链接

C3 是这一项里最要紧的

policy_safety.py:239 的 HEAD_LOCK_NOTE 断言该数据集 head_motor_2 = 99.649,据此算出 3181 counts、超出标定 564 counts。

实测:19453 帧全部是 49.846。用它自己的公式重算:

head_2counts对 range_max = 2617
99.649(注释写的)3181.5超出 +564.5
49.846(实测)2615.0在范围内,差 2 counts
后果:正因为推出「超出 564 counts 却没卡住」,那段注释得出「标定描述不了头在哪」, 于是第 4 步的绝对钳位直接跳过 HEAD_DIMS。前提不成立,这个跳过就没了依据。
· 现在无害:头被钉死在启动位置,不动。
· 动头之后有害:观众互动方案要让头在展示阶段跟脸,那时安全层对头部没有绝对边界。

旁证:head_presets.json 里 cup-grasp-v0 的 tilt = 2619, 比 range_max 高 2 counts。和数据算出的 2615 相互印证 —— 标定边界和头的实际位置几乎重合,只差个位数 counts。
改之前先问操作者。这一处只是注释里的事实错误,改注释不改行为是安全的; 但要不要把 HEAD_DIMS 的钳位加回来,那是行为变更,必须操作者拍板。

D · 关键帧采集(试验数据管理 GOAL 只剩这一步)

纯远程 把已完成的 90% 补齐最后一块

试跑时在三个时刻各存一张头相机图,存到 05-training/trials/keyframes/: 开跑前(初始条件)→ 闭爪瞬间 → 结束时。

写进结果文件的 keyframes: {init, closure, end} —— schema v2 里这个字段已经预留好了,trials_io.py 也已经能读,现在只是永远是 null。

为什么要做:出自 MRISA(Graphics Interface 2025)的结论 —— 大家实际在用的分析视图是带轨迹的关键帧 + 时间轴。 轨迹我们已经有了(traces/*.npz,17 维,质量很好),关键帧是缺的那一半。
坑:run_policy_trials.py 会驱动真手臂, 改之前 pgrep -f run_policy_trials 确认没人在跑; 面板模式走 wait_for_panel() 轮询,不要在那条路径上插 input(),会把面板挂死; 存图别挡住控制循环 —— 30 Hz 回路里同步写盘会掉帧。改完用 --dry 跑一次验证。

顺带:这次实测出来的深度事实

不许做的

  1. 不碰硬件。这四件全部离线。要动手臂的事在 明天清单里,归现场。
  2. 不改安全层的行为。C3 那处改注释可以,改钳位行为要先问。
  3. 不写第三套人脸检测。先在现有两套里选一套。
  4. 不跑 git 写命令。全在 deny 列表里。
  5. 结论必须标证据等级:实测 / 未测 / 跑了但被挡住。
  6. 感知方案必须过人工看图核对才允许写进结论。数字好看但锁错目标,已经发生三次。
2026-09-04 · 仓库内同一份:HANDOFF-REMOTE-2026-09-04.md · 背景: 深度整合 GOAL(A、B)· 观众互动 GOAL(C)· 试验数据管理 GOAL(D)· 现场清单