闭环控制、系统延迟与安全

非实时camera + GPU policy

→

边界validated action buffer

→

实时controller + safety

→

物理actuator + monitor

1. 一条典型部署链路

camera/state capture
   → timestamp + preprocess
   → policy client ──RPC── policy server / GPU
   → denormalize + frame transform
   → action buffer / scheduler
   → IK / WBC / low-level controller
   → actuator + safety monitor
   → logs and next observation

每一箭头都可能排队、丢包或使用不同 clock。日志必须把数据 age 和版本带到底，而不是只在 server 记录 model latency。

2. Policy 与 controller 的职责边界

Policy	Controller / safety layer
任务语义、目标对象、动作意图	轨迹插值、rate/acceleration/jerk 限制
EEF/关节 action chunk	IK、WBC、碰撞与关节限位
根据新观测重规划	高频 tracking、力限、watchdog
预测不确定性/价值	停止、退让、请求人类

安全约束不能只靠训练数据“学出来”。模型外的确定性 limit 和监控提供最后防线，也让不同 policy 的比较更安全。

3. Action buffer 的状态机

• FILLING：等待初始 chunk，机器人保持安全姿态。
• RUNNING：按 timestamp 消费 action，并异步请求下一 chunk。
• LOW：buffer 即将耗尽，可降速或提前重规划。
• STALE：新 chunk 基于过旧观测，拒绝或缩短执行。
• FAULT：网络、NaN、越界或 watchdog 触发，进入安全停止。

不要用“如果 list 空了就 hold last action”代替状态机；速度/力矩命令被无限保持可能危险。

4. 必做的动作校验

1. 数值 finite、维度和 embodiment ID 正确。
2. 反归一化后在训练统计与物理上下限内。
3. 目标 pose/关节可达，IK 有解且不越关节限位。
4. 相邻 action 的速度、加速度和 jerk 合理。
5. 预测 frame、控制 frame 和单位匹配。
6. collision、self-collision、workspace、force/torque 约束通过。

5. 不确定性与停止策略

可用 ensemble disagreement、diffusion sample variance、OOD detector、value/success predictor、视觉质量和 controller tracking error 组合风险分数。阈值应在 held-out failure 上校准。高不确定时的动作必须预先定义：减速、重新观察、退回已知姿态、请求人类，而不是让模型自由 improvisation。

6. 部署版本必须可回滚

model checkpoint、normalization stats、data schema、pre/postprocessor、controller gains、calibration 和 prompt/template 是一个原子 release。只更新权重而沿用旧 stats 会产生静默事故。每次 rollout 写入完整 version bundle，可复现并一键 rollback。

7. 故障注入比祈祷有效

• 增加 50–500 ms latency 与随机 jitter。
• 冻结/丢弃某一路 camera，或注入黑帧。
• 中断 policy server / RPC。
• 让对象滑落、被人移动、抓取失败。
• 给 state/action 一个接近限位的起点。

检查系统是否在规定时间内进入正确降级状态，并确认日志足够解释原因。

8. 四个部署预算

自测

1. 为什么不能无限 hold last action？

最后动作可能是速度/力矩命令，持续执行会造成漂移或危险接触。

2. 部署 release 为什么包含 normalization stats？

权重只在特定输入/输出变换语义下有效，stats 错会直接改变物理动作。

3. 安全层动作为何要回写？

后续诊断和学习需要区分 actor proposal 与真正执行的动作及其后果。