收到 START 后没有 COMPLETE，需要定位执行阶段，不能因为命令发出就继续下一步。
协议反馈含义由实现决定，超时可能是运动未完成、反馈丢失或状态不允许。重发前查询实际状态避免重复动作。
一、问题的范围与前提
感知、定位、规划、控制与机械执行有不同状态。坐标系、时间、单位和消息有效期决定数据能否安全使用。上层请求受理不表示下位机已完成动作，视觉目标丢失也不等于抓取或到达成功。
二、技术分析与方案取舍
START 表示任务开始，COMPLETE 表示目标动作满足完成条件，ERROR 则需要错误类别；三者不能复用一个布尔。任务携带序号和截止时间，旧 COMPLETE 不得完成新任务。超时可能发生在指令未受理、动作执行中或反馈丢失，各阶段采取不同恢复方式。
未知结果先读取实际控制器状态，再决定重试或终止，不能直接再次发送同一物理动作。终态保存后释放任务资源，但仍保留必要审计。验证早到回执、重复回执、执行中断线和恢复后旧消息，检查状态迁移是否具有唯一归属。
先做只读状态核对和受控的最小动作，再逐步组合流程。传感器外参和变换方向用实物验证，任务状态明确进入、等待、完成与异常退出。需要硬件执行时，由设备侧联锁和控制器维护确定性边界，网络或模型输出不承担全部安全保护。
三、实现与排查的顺序
- 核对反馈定义。
- 对齐实际动作。
- 检查执行条件。
- 按未知结果处理。
按这个顺序保留中间结果，可以区分输入条件、处理过程和最终输出。前一阶段的条件不成立时，先解释对应错误，再继续后面的试验；单次返回成功不足以覆盖整条链路。
最小示例
1
2
3
请求：task_id、目标、命令、期限
响应：task_id、受理/执行中/完成/故障、结果
消费：身份匹配 → 锁存 → 验证条件 → 确认
通用字段表达任务归属，不是某产品协议。接收时间和消费时间分开，重复回执按已处理身份管理。没有实际完成反馈时，不能将网络成功写成动作完成。
四、验证和结果解释
关联上层请求、通信发送、下位机反馈与实际动作。定位结果需要独立尺度或位置参考，地图图像只能提供部分证据。每轮测试按动作和运行条件保存范围，早期成功不能覆盖后来不同状态下的失败。
| 需要验证的结果 | 保留的对照 | 不能由此推出的结论 |
|---|---|---|
| 超时不推进流程 | 固定输入与配置、对应输出 | 一次成功代表所有条件成功 |
| 重复命令受控 | 中断前后状态与错误阶段 | 没有报错代表结果正确 |
| 恢复有明确确认 | 恢复后的同条件复测 | 临时恢复代表根因已经消失 |
测试目标丢失、时间过期、反馈超时和重启恢复。有效停止与异常出口先于复杂连续动作，避免旧坐标或旧回执驱动下一步。机械风险下保持受控速度与区域，文章只讨论通用方法，不公开现场动作库或生产阈值。
五、适用边界与结论
不靠延长超时掩盖机械问题，异常观察与停止在受控区域完成。
这条路径把“核对反馈定义”与“按未知结果处理”连在一起，中间保留可复查的条件。实施时优先确认“超时不推进流程”，再检查“恢复有明确确认”；两者都满足，才能在当前样本与配置范围内评价方案。设备、数据或软件版本改变以后，相关假设需要重新验证。
