4.6 多机器人协作规划

4.6 多机器人协作规划

本节摘要：单机器人规划是几何题，多机器人规划还要解"谁先谁后"。本节讲集中式与分布式的取舍、优先级规划的工作流程、死锁与活锁的识别解法，以及调度层与规划层的接口约定。

数字一摆，问题自己现形

仓库旺季 50 台 AMR 同时跑。若为每台独立规划——忽略其他机器人的存在——会发生什么？物流仿真给过答案：通道交口处的等待与互让使平均任务时间上升四成，每天发生数十次死锁（两车在窄通道对峙，各自都在对方的必经路上）。多机规划省下的不是"优雅"，是实打实的吞吐量。核心矛盾一句话讲完：每台机器人的最优解在别人的地图里是扰动源，50 台机器人的联合状态空间是天文数字，穷举联合规划不可能，必须在"全局协调"与"个体自主"之间找工程折中。

三种架构，三种代价

集中式：一台中央规划器掌握所有机器人状态，在联合空间直接求解。解质量最高、冲突最彻底，代价是通信时延与单点故障——中央节点挂了全场瘫痪，且机器人数上去之后计算量爆炸。适合机器人数稳定、任务节拍可控的封闭场景。

分布式：每台机器人自己规划，把其他机器人当成移动障碍（读到彼此的位置广播）。生命力最强——任何一台退出系统照常运转；代价是协调靠博弈与优先级隐式完成，冲突消解不彻底，偶发死锁。

分层混合（工业主流）：调度层（中央，管任务分配与通道占用预约，时间尺度秒到分钟）+ 规划层（每机，管自己到目标点的路径，秒尺度）+ 反应层（每机，DWA 级避撞，百毫秒尺度）。三层各管一个时间尺度，互相之间用预约与广播解耦——仓库 AMR 系统几乎全是这个架构。

图：分层混合架构与冲突消解的落点

优先级规划：便宜而实用的主力

分层架构里最常用的多机算法是优先级规划：给机器人排定优先级，从高到低逐台规划——每台把"先规划好的机器人的轨迹"当成移动障碍纳入自己的规划。它把联合问题拆成一串单机问题，计算量线性增长，效果通常够用。优先级怎么排有讲究：

• 按任务紧迫度：载货的比空载的优先，赶班次的优先；
• 按几何处境：在窄通道里的比在开阔区的优先（它让不起路）；
• 按重规划代价：路径长的先定，路径短的机动余地大，最后规划时好让路。

冲突的粒度可以更细：不是"整条路谁先走"，而是时空预约——调度层把交口格子在时间轴上切成时间窗，机器人预约"某格某秒到某秒"的占用权，后来的绕行或等待。这把冲突消解从"碰上再让"提前到"出发前预约"，吞吐量明显改善。

死锁与活锁：多机系统的两种病

死锁：互相等待，谁也不动。四台车在十字交口各占一边，都想等对方先走——系统僵死。解法按代价从低到高：死锁检测（调度层发现有环路等待）后强制最低优先级者倒车让路；预防性地把窄通道设计成单向"环线"，物理上消除对峙；必要时回炉布局——通道宽度与交口数量是多机系统最初的自由度。

活锁：两台车互相礼让，同时向同一侧挪，又同时撞到一起的方向，循环往复谁也没过去。这是"礼貌"的算法化灾难。解法是打破对称：给优先级加随机抖动，或约定"编号小者恒定右让"，让博弈有确定结局。

def resolve_conflict(a, b, t_now):
    """交口预约冲突的最小仲裁：优先级 + 抖动打破对称"""
    pa = (a.priority, a.loaded, -a.reroute_cost, a.id)
    pb = (b.priority, b.loaded, -b.reroute_cost, b.id)
    if pa == pb:                      # 完全对称：加抖动
        pa = pa + (a.rng.random(),); pb = pb + (b.rng.random(),)
    winner, loser = (a, b) if pa > pb else (b, a)
    loser.command = "yield"           # 让行者：减速、在等待区停驻
    loser.replan_after = t_now + loser.yield_time
    return winner, loser
​

⚠️ 常见坑：把通信可靠性当成理所当然。无线丢包半秒，各机地图里的"他人位置"立刻过时，反应层可能按幽灵位置急停或抢行。工业方案是位置广播带时间戳、超时即把对方按"最大速度膨胀体"保守处理——宁可绕远，不可想象对方不存在。

本节要点

• 多机规划的核心矛盾：个体最优解互为扰动，联合空间不可穷举，必须分层折中。
• 调度-规划-反应三层各管分钟、秒、百毫秒尺度，冲突在预约层就地消解是吞吐量关键。
• 优先级规划把联合问题线性化，优先级按紧迫度、几何处境、重规划代价排定。
• 死锁靠检测与单向环线根治，活锁靠打破对称化解；通信丢包要按保守膨胀兜底。

通信拓扑与去中心化的现实

第 4.6 节假设调度层中心可见一切，无线通信的现实会打破这个假设：仓库钢架对 2.4 吉赫兹信号的衰减、高峰期信道拥塞、节点漫游切换的瞬间丢包。工程上把通信降级设计进架构：机器人本地始终缓存"最近 N 秒的他人位置"，通信中断期间按"最大速度膨胀体"保守避让（4.6 节的兜底原则）；调度层对每台机器人的预约设心跳超时，超时即回收时间窗并把它标记为"待重排"。更激进的去中心化路线（机器人间直接协商，无中心节点）在学术上漂亮，工程上要解决"协商协议本身需要通信"的悖论——所以商用系统的答案几乎都是"中心可用时中心协调，中心失联时各机保守自治"的两态设计。

编队控制：另一个问题家族

多机器人还有一类任务不是"各自去各自的目标"，而是"保持队形整体移动"（编队）：数台机器人围成一排搬运超长物件、无人机群保持三角编队巡航。编队控制的核心是"队形误差"（各机相对期望位置的偏差）与"编队机动"的解耦——常用做法是虚拟结构法（把编队当刚体，各机跟踪刚体上的固连点）或领航跟随法（跟随者跟踪领航者的相对位姿）。它与第 4.6 节的路径协作正交：编队管"相对关系"，路径协作管"整体路线"，任务复杂时两层叠加。混流场景（一部分机器人编队、一部分独立作业）需要在调度层显式分组，避免独立作业者穿越编队走廊。

问题：怎么评估多机系统的调度质量

看四个统计量，按重要性排序。吞吐量（每小时完成的任务数）是终极指标；等待时间占比（机器人在等待而非行驶的时间比例）暴露调度质量，健康值通常低于一成五；死锁发生频次与解锁耗时反映鲁棒性；预约违约率（未按时到达预约时间窗的比例）暴露规划精度与通信质量。这四个量应当作为常驻看板而非验收时的一次性报告——多机系统的性能劣化往往从预约违约率悄悄爬升开始，早看板早发现。