2026-09-03：深度终于录上了，以及为什么之前一直没有

这一天从「磁盘被写满、命令都跑不动」开始，查出深度旁路的四个缺陷， 修掉其中三个，把第四个（真正的根因）定位到 USB 2.0 带宽不够，换到 USB 3.0 后深度第一次录上。 中间还发现安全层的下限高了 8 cm，把训练示范拒掉 96.6%。 这一页是当天的完整账：做完的、发现但没修的、以及接下来谁做什么。

一、修完的

1 · 磁盘被写满（起因）

根分区被写到 0 字节，连开发环境的命令都执行不了。 根因：leader_follower_server._cmd_start 覆盖 self._depth 前不停旧的， 按两次 Start 就孤儿掉上一个录制器 —— 它跑了 13.7 小时、220,412 帧、27 GB。

• 已修：覆盖前先 stop()（leader_follower_server.py）。
• 已回收：裁掉窗口外的 220,323 帧（保留对应那 8 秒的 89 帧），回收 26.4 GB。
• 顺带删掉 42 个已确认在 Hub 上的本地副本，共 2.25 GB。

2 · 摄像头句柄泄漏

v4l2_depth.DepthCamera.open() 先 os.open() 拿 fd，再做一串会抛异常的 ioctl； 失败时只把 _cam 置 None，fd 永远不关。实测累积 34 个泄漏句柄。

• 已修：整个 body 包 try/except，失败调 self.close() 再抛。
• 已验证：monkeypatch 让第 2 个 ioctl 抛错，修复前漏 1 个 fd，修复后 fd 集合前后一致、self.fd 回到 None。

3 · 静默失败：0 帧不报

DepthRecorder 把「0 帧」当正常收尾写 meta.json，面板一个字都不说。 这是当天代价最大的缺陷 —— 9-02 一晚 102 集里 88 集丢了深度，当场无人察觉。

• 已修：_cmd_stop 现在在消息里报 depth: N frames，0 帧标红（message_kind="err"）。

4 · ★ 真正的根因：USB 2.0 带宽 ★

拓扑查出来是这样：

Jetson
 └ Realtek 双总线 hub（USB2 侧 1-2 + USB3 侧 2-1，同一个物理 hub）
    ├ 口1  iTingSbc
    ├ 口2  串口（手臂总线）
    ├ 口3  ★ 第二个 hub —— 只支持 USB 2.0 ★
    │       ├ Orbbec Gemini 335   ← 深度 + 头部 RGB，两个接口
    │       ├ 腕相机
    │       ├ 腕相机
    │       └ 键盘
    └ 口4  串口（手臂总线）

三路相机全在那个 USB 2.0 hub 后面共享 480 Mbps。深度 640×480×16bit×30fps ≈ 147 Mbps， UVC 分配不到就一直超时。换到 Jetson 机身的 USB 3 口后链路 5000 Mbps，深度立刻正常。

5 · 安全层下限高了 8 cm

teleop_safety.yaml 右臂 z_min = 0.065（08-24 换夹爪时标定） 把训练集 0826-0042 全部 40 集 16,487 帧示范拒掉 96.6%，试跑第 1 帧即中止。

• 已改：右臂 z_min → −0.11（示范最低腕高 −0.102 再留 1 cm）。
• 已验证：第 0 集 400 帧过安全层 399 OK + 1 CLIPPED；40 集 16,487 帧 0 帧被拒。

6 · 面板上四个坏了很久的按钮

tctlRun / tctlSend / REC_TASKS 等 12 个函数 + 3 个变量 声明在 start() 函数内部（文件里没有缩进，看着像顶层）， 而「重放选择器」和操作模式的按钮在外面调 → ReferenceError。 这几个按钮从来就没通过过，和当天的改动无关。用 AST 一次扫出全部，挂到 window 上修好。

顺手把这套检查固化成了技能 .claude/skills/self-debug/： HTML 标签配平、整块 JS 语法、作用域泄漏、服务端下发一致性，四类不用浏览器就能判定的错。

7 · leader-arm 录制从来不会自动上传

对比两条路径：VR/面板录制在作业结束时起线程调 _publish_dataset； leader-arm 的 _cmd_finish 里一行上传代码都没有。 所以 9-02、9-03 两批数据全靠人工补传，操作者以为录完就传了。

• 已修：Finish 后起后台线程走 /api/dataset/publish（和 VR 同一道 verify 门）； 失败时页面明说「数据已安全落盘，只是上传失败，去面板重传，数据没丢」。下次重启 8781 生效。

二、数据与账号

三、发现了但没修的

四、深度要验收，需要做什么

深度现在能录了，但「能录」不等于「能用」。验收分两级：

第一级 · 每次录制当场看（现场，零成本）

1. 按 Stop 之后看那行消息：会写 depth: N frames。
2. 绿/正常色 + 帧数三位数 = 好。红色 depth: 0 frames = 立刻停，别再往下录。

这一条就能挡住 9-02 那种「一晚 88 集全空、第二天才发现」。

第二级 · 数据质量核对（远程，我做）

录完之后我跑这几项，全部只读：

现成工具：python 03-software/scripts/lf_depth_doctor.py（句柄数 / 线程数 / 逐集帧数 / 磁盘四项体检）。

第三级 · 对齐验证（现场 + 远程，做路线 A 之前必须过）

深度和 RGB 是两个独立的流，靠 timestamps.jsonl 的墙钟事后对齐。 这个对齐从来没被验证过。做法：现场在相机前快速挥一下手， 远程比对深度帧和 RGB 帧里手出现的时刻，量出偏移毫秒数。偏移大于一个帧间隔就得修。

五、路线 A：现在能预备什么、能直接执行什么

路线 A = 深度不进模型，在模型旁边算出杯子的 3D 坐标，用来 ①开跑前的门 ②每次试验记录杯位 ③失败诊断。不重训、不重采。 它直冲现在最大的未知：「抓不到」到底是没看见还是抓歪了 —— 今天的试验记录回答不了。

A0 · 现在就能执行的（远程，不需要任何人）

A1 · 需要现场的（现场，约 30 分钟）

1. 存一个专用的头部预置位（叫 trial）。
   这一步是整条路线的地基，漏了后面全白做。 相机装在会动的头上，所以外参是「头在某个姿态时」的值，头一动全作废。 而 run_policy_trials.py 的 head_lock 是启动时读当前位置就锁在哪 （run_policy_trials.py:531），不是固定值。 必须：标定前、每次试跑前，都先把头移到 trial 这个预置位。
   现有预置位：test / cup-grasp-v0 / sky / justforfun / justforfun2 —— 没有一个是为试跑固定的
2. 爪尖贴一个不反光的浅色记号（小块哑光胶带或小球）。反光和透明都会让深度失效。
3. 按脚本提示摆 15–20 个手臂姿态，覆盖真实工作区（前后、左右、高低都要，别挤在一小块）。 每个姿态停稳后按一下确认，脚本自动记两套坐标。
4. （可选，精度更高）打印一张棋盘格，9×6 内角点、格子 20–25 mm，贴硬板上； 打印后用尺子量一格实际边长 —— 打印机缩放会让标称值不准。

A2 · 采完之后（远程，我做）

1. 解内参（有棋盘格时）/ 解外参（刚体变换）。
2. 留出 5 个点不参与求解，用解出的变换预测它们，报残差中位数（毫米）。
3. 验收线：< 10 mm 可以开始用；> 20 mm 重采（多半是采点太集中或记号找歪）。
4. 接进试验流程：每次试跑前报一次杯子 3D 坐标，写进试验记录。

六、按优先级的待办

七、诚实边界

• 已实测：本页所有帧数、字节数、百分比、时间戳、USB 链路速率、fd 数、 安全层拒帧率、亮度/清晰度对比，都是当天在这台机器上跑出来的。
• 被证伪的：「总线复位能清掉深度假死」—— 拔插实验证明不成立，真因是带宽。
• 未验证：深度与 RGB 的时间对齐（第三级验收）； 路线 A 的标定步骤是通用做法，在这台机器上没做过，第一次必须自己量残差。
• 没查：Orbbec 的标称精度和最小工作距离；相机与机械臂基座的外参（还没量）。