具身智能实践（六）：恢复门控与路径重规划，各自解决了什么？

上一轮把“确认物体仍被抓住”和“重新规划剩余路径”一起加进了恢复策略。结果可以说明组合有效，却回答不了：究竟是证据检查避免了错误恢复，还是轨迹改变改善了动作？

这轮把两个开关拆开。最重要的结果有两条：在四对固定条件中，重规划将首次恢复目标的跳变从 50.285–97.055mm 降至 0.245–0.263mm；但四种主动恢复组合都完成了五个非掉落条件，没有观察到放置成功率提升。

这不是矛盾。是否应该恢复、恢复后发出什么目标、最终是否放好方块，是三个不同的问题。

固定版本代码 · 30回合原始证据 · 独立指标

1. 为什么需要拆开两个开关？

假设一次搬运通信中断后，方块仍在夹爪里。恢复连接时，可能发生两类错误：

• 证据错误：收到的是旧包，程序却把它当成“现在仍然抓着”。
• 目标错误：已经确认可以继续，但直接追赶旧时间表中的目标，跳过了停止期间没走完的一段路。

前者应该由恢复门控处理；后者应该由路径处理。只比较“旧策略”和“全套新策略”，会把两项改动混在一起。因此本轮采用2×2组合，再加一个不恢复的保守参照。

门控	旧时间表 wallclock	重规划 replan
收到即恢复 receipt	收到合法包就继续旧时间表	收到合法包就从当前位置重建路径
重新验收 revalidate	新证据持续成立后继续旧时间表	新证据持续成立后从当前位置重建路径

锁存停止 latched 只保留旧时间表这一格，因为它根本不会恢复，额外开关路径没有意义。这里的 wallclock 是原轨迹使用的绝对仿真时间，不是电脑的真实时钟。

2. 30回合具体控制了什么？

五种组合分别跑六个条件，共30回合；每格一次、无随机种子，不做泛化成功率估计。另有18回合E5回归，用来检查接入新实验时没有改变旧结果，不能把它们当作额外18个E6样本。

项目	固定值
场景	同一笛卡尔夹爪、方块、托盘与初始状态
物理/控制步长	2ms
观测采样	20ms
故障开始	4.8s，搬运阶段
通信间断	[4.8, 5.04)，240ms
过期门槛	包龄达到60ms
恢复确认	至少100ms连续有效捕获，间隔不超过20ms
最长停止等待	600ms，期限优先于同tick恢复
重建搬运段	1.5s，再接下降、松爪、撤离和稳定
回合终点	10.8s

六条件沿用E5：无扰动、固定40ms延迟、每第三包延迟80ms形成乱序、通信间断、间断后重送旧正常包、间断同时松爪。最后一项实际改变执行器开合，方块仍由接触与重力运动，没有改写物体位置。

仿真记录来自 Linux、Python 3.12.14、MuJoCo 3.3.7、NumPy 2.2.6；接入时在 Windows 对源码、原始记录和测试重新核验。本机审计不算新一轮物理仿真。

3. “目标跳变”不是“夹爪瞬移”

恢复判定发生在tick r 的物理步之后。因此这一行仍使用停止时保持的目标，r+1 才发出恢复后的第一个目标。

本轮记录两个距离：

J = || target[r+1] - target[r] ||₂
E = || target[r+1] - measured_hand[r] ||₂

J 回答“控制器下一步的目标突然变了多少”；E 回答“这个目标离恢复瞬间实测夹爪有多远”。两者都只取XYZ，不混入夹爪开合量。

夹爪实际位置由物理引擎和执行器跟踪决定，目标跳变不能写成机械臂瞬间移动了同样距离。日志中的手部速度也只是2ms位置差分，不是完整速度、加速度或冲击安全认证。

实现的关键分支很小：

if path_mode == "wallclock":
    return path, None

previous = np.array([*hand, float(grip)])
rest = [("transfer", 1.5, [.24, .12, .18, .033])] + base.schedule(0)[5:]
return segments(rest, tick * DT, previous), previous

重规划以实测位置起步，重设后续时间表；它不是避障算法，也不是逆运动学求解。路径几何与重新定时一起改变，后面的差异不能归结为纯几何作用。

4. 同样的门控，换一条恢复路径

下面只比较相同条件、相同门控、第一次恢复的路径差异。独立审计确认了第一次决策前的状态与控制前缀一致。

条件	门控	旧时间表 J/mm	重规划 J/mm
通信间断	收到即恢复	50.285	0.263
通信间断	重新验收	71.433	0.245
旧包重送	收到即恢复	50.285	0.263
旧包重送	重新验收	97.055	0.245

重规划与旧时间表的比值为0.25%–0.52%，四对均满足预设的“不超过一半”门槛。这是四对确定性记录的描述，没有置信区间，也不外推到其他机械臂。

两幅子图使用不同横轴范围，便于读出小数值；应对照数字，不能直接用条形长度比较比例。图与上表均来自 metrics.json。

为何重新验收配旧时间表反而跳得更远？它等待更长的有效证据窗口，旧轨迹却继续按绝对时间推进。例如旧包重送下，重新验收到5.302s才恢复，直接续旧时间表会追赶更靠后的目标。更严格的证据检查，不会自动让轨迹衔接更平顺。

这是日志绘图，不是相机观测。上排为世界坐标x，下排为最新包龄；图例中的 target 是目标，measured 是实测位置。

5. 有好包，还不等于有完整确认窗

旧字段 unsupported_resumes 只统计“恢复时包龄≥60ms，或抓取谓词为假”。它没有覆盖完整100ms确认窗的所有要求。

通信间断刚结束时，receipt 收到一份新鲜正常包就恢复，所以该计数为0；但只有一个样本，确认跨度仍是0ms。新增 missing_full_window_resumes 把这个差别单独记下来。

条件/门控	每条路径的恢复次数	旧/坏包恢复	缺完整确认窗
通信间断 / 收到即恢复	1	0	1
旧包重送 / 收到即恢复	9	8	9
通信间断 / 重新验收	1	0	0
旧包重送 / 重新验收	1	0	0

重新验收要求每个用于确认的包到达时都新鲜、捕获晚于当前停止、捕获顺序递增、相邻间隔≤20ms、跨度≥100ms，且恢复时最新包仍新鲜并支持抓取。抓取谓词仍是双侧接触、方块高度>0.12m、与夹爪中心距离<0.05m。

计数为0只说明它所定义的失败没有出现，不能代替其他前置条件。

6. 重规划为什么不能救回掉落？

在通信间断并松爪条件中，四种组合表现如下：

组合	恢复次数	旧/坏包恢复次数	最终放置
收到即恢复 + 旧时间表	6	6	未完成
收到即恢复 + 重规划	72	72	未完成
重新验收 + 旧时间表	0	0	未完成，等待到期后中止
重新验收 + 重规划	0	0	未完成，等待到期后中止

72次尤其容易被误读为“重规划让系统更危险”。实际上，继承的门控只在 transfer 阶段监测。旧时间表较快进入 lower，之后不再触发搬运阶段的停止；重规划每次恢复都重置搬运段，因此在被监测阶段暴露更久，反复触发同一循环。

所以72对6同时包含门控范围、阶段停留时间和闭环反馈的影响。它揭示一个真实缺口：只在一个阶段监测，不能代表全任务安全；但不能把差异归因于路径几何本身。

重新验收的两个组合均在600ms等待期限中止，不再恢复。这个停止符合协议，却不是“放置成功”，也不是重抓取。

7. 完整矩阵与时间代价

条件	锁存停止	收到/旧路径	收到/重规划	验收/旧路径	验收/重规划
无扰动	放置	放置	放置	放置	放置
40ms延迟	放置	放置	放置	放置	放置
乱序	放置	放置	放置	放置	放置
通信间断	中止	放置	放置	放置	放置
旧包重送	中止	放置	放置	放置	放置
间断并松爪	中止	未放置	未放置	中止	中止

“放置”按原协议验证末尾0.5s：位置在托盘范围内、高度正确、速度<0.02m/s、没有手指接触，且此前曾抬升。只是把物体移动到目标附近不算。

本轮四种主动恢复组合都完成了五个非掉落条件。因此不能宣称重规划提高了放置成功率。它还延后了部分回合：旧包重送、重新验收这对中，首次持续放置窗口的结束时刻从7.322s变成8.622s。该时间从20ms采样日志估计，不是无限精度的完成时刻。

8. 证据怎样核验，读者怎样复现？

独立审计不导入 Gate，从原始CSV、状态与接收包重算：30个完整矩阵格、180份回合文件、12份源码/协议指纹、24组锁存前缀、12组同门控路径前缀。前缀最大绝对差为0；102次恢复逐条检查，重新验收的4次实际恢复均有有效确认窗。

另18回合E5回归的离散结果与旧证据一致，状态/速度/控制最大差为约1.09×10⁻¹⁴，低于预定1×10⁻¹⁰门槛。文件一致性与假设成立分开：合法数据即使不支持假设，也应该保留。

在工程根目录，先审计现有记录；跨平台用临时副本恢复到已知哈希对应的换行，不重写原始证据：

.venv/Scripts/python -m unittest discover -s experiments/vl01_recovery_ablation -p 'test_*.py'
.venv/Scripts/python experiments/vl01_recovery_ablation/portable-audit.py evidence/recovery-ablation-20260930/e6-final

本机30项测试通过。要重新仿真，使用从未存在的目录，保留旧记录：

.venv/Scripts/python experiments/vl01_recovery_ablation/run.py --out runs/e6-my-run
.venv/Scripts/python experiments/vl01_recovery_ablation/audit.py runs/e6-my-run
.venv/Scripts/python experiments/vl01_recovery_ablation/render.py runs/e6-my-run

Linux将解释器路径换成 .venv/bin/python。control.csv 每2ms记录控制，trajectory.csv 和 states.jsonl 每20ms记录物理状态；events.json 看决定，replans.json 看重规划起点。归档提交固定整套材料；manifest仍保留原运行的基线提交与未提交状态，不将归档时间冒充运行时间。

9. 下一步应该修什么？

优先问题已经很具体：下降与释放阶段是否也需要自己的监测和恢复条件？反复恢复是否需要次数或冷却约束？ 这些应先定义协议，再用固定故障相位对照验证，而不是直接加更多机器人模型。

本轮仍是同一场景、仿真真值、同一时钟与固定故障，没有视觉、ROS2、时钟偏差、重抓取、学习策略或真机验证，完整M4/M5不因此完成。可以支持的结论是：恢复门控检查“可不可以继续”，重规划改善这组记录中的目标衔接；它们都不能单独代表任务已经安全完成。