pengtao-tech

感知-决策-执行闭环里的工程难点

11分钟阅读

感知-决策-执行闭环里的工程难点

一句话速记

具身 Agent 的核心是 “感知（Perception）→ 决策（Decision）→ 执行（Action）” 闭环。工程难点不在算法本身，而在闭环里的 4 类问题：① 感知的多模态对齐和噪声 ② 决策延迟与实时性冲突 ③ 执行失败后的状态恢复 ④ 状态不一致——感知/决策/执行的”时间轴”会漂。核心思维：把每一环看作有延迟、有失败、有不确定性的服务，用工程方法（缓冲、超时、补偿、状态机）兜底，而不指望模型完美。

通俗解释（5 分钟版）

经典闭环图：

   ┌──────────┐    ┌──────────┐    ┌──────────┐
   │  感知    │ →  │  决策    │ →  │  执行    │
   │ (Sensor) │    │ (Plan)   │    │ (Act)    │
   └──────────┘    └──────────┘    └──────────┘
        ▲                                │
        │                                │
        └────────────────────────────────┘
                    反馈

听起来像后端的请求-响应，但具身的麻烦在每一环都漏水：

1）感知层的麻烦：

  • 摄像头拍到人，LLM/VLM 处理慢——画面已经过去 300ms
  • 多模态对不齐：摄像头 30Hz、IMU 100Hz、力传感器 1000Hz
  • 物体被遮挡、光线变了、识别模型在新场景里就掉点

2）决策层的麻烦：

  • LLM 推理 1-3 秒，机器人等不起
  • 大模型偶尔输出”幻想动作”——指挥机器人撞墙
  • 多个目标冲突：避障 vs 完成任务 vs 节能

3）执行层的麻烦：

  • 抓杯子失败：杯子滑了 / 角度偏了 / 力没控制好
  • 关节出错、电池低、电机过热、紧急停止
  • 执行了一半”目标变了”——用户改主意了

4）闭环的麻烦（最关键）：

  • 状态不一致：感知说”杯子在桌上”、决策说”去抓杯子”、执行的时候杯子被人拿走了
  • 时序漂移：感知数据是 100ms 前的，决策基于这个，执行时已经 500ms 了
  • 故障传播：感知偶尔错 → 决策错 → 执行撞坏

工程思路：把它当带延迟、带噪声、有失败的分布式系统做。

关键细节 / 数学直觉

1）四类工程难点对照表

   难点                        典型表现                     工程对策
   ─────────────────────────────────────────────────────────────
   ① 感知噪声/对齐             杯子检测漂移、模态不同步     - 滤波(Kalman/EKF)
                                                              - 时间戳对齐
                                                              - 多帧投票
   ─────────────────────────────────────────────────────────────
   ② 决策延迟/实时性冲突       LLM 慢、控制环 1ms 一次       - 分层(大脑-小脑)
                                                              - 异步规划
                                                              - skill 缓存
   ─────────────────────────────────────────────────────────────
   ③ 执行失败/状态恢复         抓不起来、电机过载            - skill 状态机
                                                              - 回滚/重试
                                                              - 安全姿态
   ─────────────────────────────────────────────────────────────
   ④ 状态不一致/时序漂移       决策依据已失效                 - 短期闭环验证
                                                              - 决策时戳
                                                              - 周期 re-plan

2）“时序漂移”的具体例子和对策

   时间线 (ms):
   ─────────────────────────────────────────
   0      : 摄像头帧拍下"杯子 A 在 (1, 2) 处"
   30     : 帧到达感知模块，VLM 处理
   330    : VLM 输出 "杯子 A 在 (1, 2)"
   350    : LLM 决策 "执行 grasp(A)"
   1850   : LLM 输出动作序列
   1900   : 控制器开始执行
   1900+  : 但杯子 A 已被人拿走（500ms 前发生）
            机器人扑空 / 抓到错误位置
   ─────────────────────────────────────────

对策：

  • 执行前再确认：grasp 之前再用快速感知（不是 VLM、用经典 CV）确认杯子还在
  • 决策时戳：每个决策附带”基于时刻 T 的感知”，过期就 reject
  • 多帧融合：连续 3 帧都看到 → 才相信目标存在
  • 预测：物体如果在动，预测它接下来位置（运动模型）

3）多模态对齐：硬件时戳 vs 软件时戳

   ❌ 错误做法：每个传感器收到时打软件时戳
       → CPU 调度抖动、网络延迟，时戳和真实时刻偏差几十 ms
   
   ✅ 正确做法：硬件 PTP 同步、传感器自带时戳
       → 摄像头帧、IMU 数据、力数据**对齐到统一时间轴**
       → 然后插值/重采样到决策频率（如 10 Hz）

具身机器人通常用 PTP（Precision Time Protocol，IEEE 1588）做毫秒级硬件同步。

4）执行失败的分类与状态机

class SkillExecutor:
    """单个 skill 的状态机"""
    states = ["IDLE", "RUNNING", "SUCCESS", "FAILURE", "ABORTED"]
    
    def execute(self, skill, args):
        try:
            self.state = "RUNNING"
            result = skill.run(args, deadline=10.0)
            
            if result.success:
                self.state = "SUCCESS"
            else:
                self.classify_failure(result)
        
        except TimeoutError:
            self.state = "FAILURE"
            self.failure_type = "timeout"
            self.move_to_safe_pose()
        
        except SafetyViolation:
            self.state = "ABORTED"
            self.emergency_stop()
        
        return self.state, self.failure_type
    
    def classify_failure(self, result):
        """根据错误类型决定上报粒度"""
        if result.error == "object_slipped":
            self.failure_type = "retriable"
        elif result.error == "object_not_found":
            self.failure_type = "perception_stale"
        elif result.error == "plan_infeasible":
            self.failure_type = "needs_replan"
        else:
            self.failure_type = "unknown"

关键：失败要分类——不同类失败给上层不同信号（重试 vs 重新规划 vs HITL）。

5）安全护栏要”分层冗余”

   ┌─────────────────────────────────────────┐
   │  软件层：LLM 安全 prompt + skill 校验   │  慢、可绕过
   ├─────────────────────────────────────────┤
   │  控制层：力反馈、速度限幅、关节限位     │  毫秒级
   ├─────────────────────────────────────────┤
   │  硬件层：物理急停按钮、电机扭矩限制     │  微秒级、不可绕过
   └─────────────────────────────────────────┘

永远不要把安全完全交给最上层（LLM/规划器）——下层硬件层一定要有独立的、不依赖软件判断的保护。

6）感知-决策频率的合理选择

   场景                        合理频率           说明
   ─────────────────────────────────────────────────
   平衡控制                     500-1000 Hz       本能反应
   避障 / reactive control      50-100 Hz         快速调整
   skill 内部反馈控制           20-50 Hz          抓取微调
   skill 选择 / 重新规划        1-5 Hz            高层决策
   对话 / 任务理解              0.1-1 Hz          用户交互

原则：越靠近本体，频率越高、模型越简单。LLM 不能进 100Hz 以上的环。

7）闭环验证：每个 skill 都要有”成功条件”

@register_skill
def grasp(object_id):
    # 执行前条件
    assert object_visible(object_id), "object lost before grasp"
    
    # 执行
    move_to(object_pose(object_id))
    close_gripper(force=5.0)
    
    # 执行后验证（关键！）
    if gripper_force_sensor() < 1.0:
        return FAIL("nothing in gripper")
    if object_in_hand_pose() is None:
        return FAIL("object slipped")
    
    return SUCCESS

没有自检的 skill = 后续全错——上层决策永远会基于错觉规划。

8）re-plan 的触发条件设计

   触发条件                         动作
   ─────────────────────────────────────────────
   skill 失败 (retriable)           重试 1-2 次
   skill 失败 (perception_stale)    re-perceive，再决策
   skill 失败 (plan_infeasible)     LLM re-plan
   连续失败 ≥ 3                     升级 HITL
   超时 (deadline 到)               中断+回安全姿态+re-plan
   感知到环境变化                   re-plan（异步触发）

延伸追问

  • Q： 这跟自动驾驶的”感知-规划-控制”闭环差异在哪？ → 自动驾驶主要在道路上——环境结构化、约束相对固定。具身要操控——要接触物体、有不确定性更高的力学交互；同时室内场景多变（家庭/工厂）、目标更细粒度（不是车道线，是”那个红杯子”）。
  • Q： 大模型在这个闭环里替代了哪些传统模块？ → 主要替代了高层语义感知（VLM 替代了原来一堆 CV 模型 + 知识图谱）和任务规划（LLM 替代了 PDDL/HTN）。但底层控制、运动规划、安全护栏还是传统方法。
  • Q： Agent 框架（LangGraph）能直接驱动这个闭环吗？ → 能驱动”大脑层”——任务规划、skill 选择、错误处理。不能驱动小脑/本体——频率不够、抖动太大。LangGraph 节点是”调用 skill API”，skill 内部由专门控制器跑。
  • Q： 一个工程师转过来最该补的是什么？ → ① 状态机思维（skill 是状态机不是函数）② 时序意识（一切信号都有时戳）③ 分层心智（不要把所有逻辑都放 LLM）。算法本身可以慢慢学。

我的记法

  • 闭环 4 类难点：感知噪声 / 决策延迟 / 执行失败 / 状态不一致
  • 时序漂移：决策依据可能已失效——执行前再确认
  • 多模态对齐：用硬件时戳 + PTP，不是软件时戳
  • skill 失败要分类：retriable / stale / infeasible / unknown
  • 安全护栏要分层冗余：软件 → 控制 → 硬件，最低层最可靠
  • skill 必须有自检——没有 success check 的 skill 等于上层全是错觉
  • 一句话：「闭环不是算法问题、是分布式系统问题——延迟/失败/状态全要兜底」

状态

  • 已背速记
  • 能讲通俗版
  • 能答追问
  • 自己画一遍闭环图（标注延迟、失败、对齐点）

参考资料

关系图谱

反向链接