Chapter 23

多机器人与车队管理

想象你是一个仓库的运营经理。最开始只有一个搬运工，事情很简单：告诉他去哪拿货、送到哪，他自己走就行。但现在仓库扩到了 20 个搬运工，问题的性质彻底变了。两个人同时往一条窄通道走怎么办？只有一部电梯，三个人都要用怎么排队？某个人突然请假了，他手上的活谁接？这不再是“一个人怎么干活”的问题，而是“一群人怎么协调”的问题。

机器人车队管理（Fleet Management）面对的挑战完全一样。一台机器人跑通了 SLAM、Nav2、行为树，能独立完成任务 - 恭喜，你搞定了单人模式。但商业场景几乎都是多机器人的：医院里几台配送机器人、仓库里几十台 AGV、商场里一堆清洁机器人。每多加一台机器人，系统复杂度不是线性增长，而是指数级的 - 因为每台机器人之间都可能产生交互和冲突。

这一章我们聊的就是：当你的机器人从一台变成一个车队时，软件架构要怎么变。

一台到多台：哪些问题冒出来了

单机器人的世界其实挺“自我中心”的。它的 Nav2 只需要规划自己的路径，它的 costmap 只标记静态障碍物和偶尔出现的动态障碍物。但多机器人场景下，至少冒出三类新问题：

任务分配 - 20 个搬运任务进来了，分给哪台机器人？最朴素的做法是“谁离得近谁去”，但现实比这复杂得多。你得考虑每台机器人的电量、当前任务队列、路径上的拥堵情况。这本质上是一个在线调度优化问题，和外卖平台给骑手派单是同一类问题。

路径协调（Traffic Management） - 两台机器人面对面在一条窄过道里撞上了，谁让谁？如果都停下来等对方先走，那就死锁了。这不是某一台机器人能自己解决的问题 - 需要一个“上帝视角”的协调者来仲裁。

共享资源调度 - 电梯、自动门、充电桩 - 这些都是不能同时被多台机器人使用的资源。机器人 A 正在等电梯，电梯来了，但机器人 B 也在等同一部电梯 - 谁先进？这本质上是操作系统里经典的资源互斥问题，只不过资源从 CPU 时间片变成了物理世界的电梯和门。

Open-RMF：多机器人的“交通管制中心”

这个领域最主要的开源框架是 Open-RMF（Open Robotics Middleware Framework）。它由 Open Robotics（就是做 ROS 的那帮人）发起，现在归 OSRA（Open Source Robotics Alliance）管理。你可以把 Open-RMF 理解成机器人车队的“空中交通管制系统” - 它不控制每架飞机怎么飞，但它告诉每架飞机什么时候可以进入什么空域。

Open-RMF 的架构核心是几个概念：

Fleet Adapter - 这是 Open-RMF 和具体机器人之间的“翻译层”。仓库里可能同时跑着三家不同厂商的机器人，每家的 API 和导航栈都不一样。Fleet Adapter 负责把 Open-RMF 的统一指令翻译成每家机器人能听懂的命令。这个设计特别聪明 - 它意味着你不需要让所有机器人跑同一套软件，只要给每种机器人写一个 adapter 就行。实际项目中，写 fleet adapter 通常是集成工作里最耗时的部分。

Traffic Schedule - 一个全局的“交通计划表”。每台机器人把自己未来的规划路径上报给 schedule，schedule 检测是否有冲突（两条路径在同一时间经过同一区域），然后协调谁先走、谁等待、谁绕路。它的冲突检测不是简单的“两条线有没有交叉”，而是在时空维度上做检测 - 两台机器人可以经过同一个点，只要不是同一时间。

Building Systems Integration - 电梯、自动门、闸机这些“建筑基础设施”在 Open-RMF 里被抽象成标准化的接口。机器人要坐电梯？它不是自己去按按钮，而是向 Open-RMF 提交一个“我要从 1 楼到 3 楼”的请求，Open-RMF 负责和电梯控制系统对接、排队、分配。新加坡在这方面走得比较前面 - 他们的 SS 713 标准就定义了机器人和电梯/自动门之间的数据交换协议。

Task Dispatcher - 任务分配器。接收上游系统（比如仓库管理系统 WMS）发来的任务，根据机器人的状态和能力分配给合适的机器人。

云端 vs 边缘：谁管什么

多机器人系统有一个天然的架构分层：全局决策在云端（或者本地服务器），执行控制在机器人本地。这个分工不是随意选的，而是由物理规律决定的。

云端（或本地服务器）负责的事：

• 任务分配和调度优化 - 需要全局信息，对延迟不敏感（差个几百毫秒无所谓）
• 路径协调和冲突仲裁 - 需要知道所有机器人的位置和计划
• 资源排队（电梯、充电桩）- 全局状态管理
• 监控 dashboard 和报警

机器人本地负责的事：

• Nav2 实际路径跟踪和避障 - 必须实时（延迟 = 撞墙）
• 传感器数据处理和感知
• 急停和安全逻辑 - 绝对不能依赖网络
• 低层运动控制

关键原则是：任何涉及安全的决策都必须在本地做。 网络可以断、服务器可以挂，但机器人不能因为云端没响应就撞人。所以即使全局调度系统告诉机器人“往前走”，机器人本地的 Nav2 发现前方突然出现一个人，它必须自己停下来，不需要问云端的意见。

这个架构和自动驾驶很像 - 云端做路线规划和调度，但车上的感知和紧急制动完全在本地。不同的是，室内机器人的网络环境通常比路上的车好得多（WiFi vs 4G），所以云端可以承担更多实时性稍高的工作。

实际部署时，“云端”往往不是真的公有云，而是机房里或者仓库角落的一台本地服务器。原因很现实：一是延迟更低，二是很多客户（特别是制造业和医疗）不允许数据出局域网。

仓库里 20 台 AGV 怎么不撞车

来看一个具体场景。一个中型仓库，20 台 AGV 在里面跑，每天处理几千个搬运任务。这个系统实际是怎么运转的？

地图和区域划分。 首先，整个仓库的地图会被划分成若干个 zone，每个 zone 有容量限制 - 比如一条窄通道同一时间只允许一台 AGV 通过。这些约束是预先配置好的，不是实时计算的。Traffic schedule 在分配路径时会尊重这些约束。

交通规则。 和真实道路一样，仓库里的 AGV 也有“交通规则” - 单行道（某些通道只能单向通行）、优先级路口（高优先级任务的 AGV 优先通过）、等待区（通道繁忙时在指定区域排队）。这些规则大幅简化了冲突检测的计算复杂度 - 不用每对 AGV 都做时空冲突检测，只需要管理关键瓶颈点。

典型的一个任务流程：

1. WMS 发出指令：“把 A 区货架 12 的货搬到打包台 3”
2. Task Dispatcher 评估所有空闲 AGV，选了离 A 区最近且电量充足的 AGV-07
3. AGV-07 向 Traffic Schedule 上报规划路径
4. Schedule 发现路径会经过一个单行通道，而 AGV-03 正在反方向使用这个通道
5. Schedule 让 AGV-07 在通道入口的等待区等 AGV-03 通过
6. AGV-03 通过后，AGV-07 获得通行许可，进入通道
7. AGV-07 到达货架，执行取货
8. 返程路径上需要坐货梯，向 Open-RMF 的 lift manager 提交请求，排在 AGV-15 后面
9. 轮到 AGV-07，货梯到位，AGV-07 进入，到达目标楼层
10. 完成送货，上报任务完成，进入空闲池等待下一个任务

听起来很顺畅，但每个步骤都可能出问题。

踩坑指南：多机器人系统最难调的是什么

死锁 - 多机器人的头号杀手。 两台 AGV 在十字路口对向行驶，A 占了东西向通道等待南北向通行权，B 占了南北向通道等待东西向通行权 - 经典死锁。解决方案通常是引入全局优先级（编号小的让编号大的，或者任务紧急度高的优先）加上超时检测（等太久就强制一方后退）。但死锁场景在仓库实际运营时偶尔就是会出现在你没预料到的地方 - 比如三台车在 T 字路口形成循环等待。这种 corner case 往往要在真实运营中踩到了才能发现。

通信不稳定。 仓库里有金属货架、大型设备，WiFi 信号经常不稳定。机器人和中央调度服务器的通信中断时怎么办？最保守的策略是“原地停车等重连”，但这意味着一台车断网可能把整条通道堵死。更好的做法是让机器人在断网时有“降级模式” - 能根据本地缓存的地图和交通规则继续低速行驶到最近的避让点。

异构车队的协调。 实际仓库里可能同时跑着做搬运的 AGV、做盘点的无人机、做清洁的扫地机器人。它们的速度、体型、行为模式完全不同。让一个 traffic schedule 同时管理这些差异巨大的机器人是非常有挑战的。Open-RMF 的 fleet adapter 设计就是为了应对这个问题，但写一个好的 adapter 需要对那种机器人的行为特性非常了解 - 比如 AGV 可以精确停在指定位置，但清洁机器人走的是覆盖路径，你不能让它“在 B3 等待区停车”。

电量管理。 20 台 AGV 共享 5 个充电桩，什么时候让谁去充电？太早去浪费运力，太晚去可能半路没电趴窝（趴在通道上的没电 AGV 是最糟糕的路障）。充电调度要和任务调度联动 - 预测未来 30 分钟的任务量，提前安排低电量车辆去充电。

除了 Open-RMF 还有什么

Open-RMF 是开源领域最成熟的多机器人框架，但不是唯一的选择。

InOrbit 是一个商业化的机器人运维平台，提供车队监控、远程操控、数据分析等功能，并且开源了和 Open-RMF 的 fleet adapter，可以把两者集成起来用。如果你不想从零搭建监控 dashboard，InOrbit 这类平台能省不少事。

在工业 AGV 领域，很多厂商有自己的闭源调度系统（比如 KUKA、极智嘉、快仓），这些系统通常和自家硬件深度绑定，调度效率很高，但跨厂商互操作是个大问题。Open-RMF 的价值恰恰在这里 - 它是一个厂商中立的协调层，让不同厂商的机器人能在同一个空间里和平共处。

还有一种思路是去中心化的多机器人协调 - 没有中央调度器，机器人之间直接通信协商。学术界研究很多（多智能体系统、博弈论），但工业界目前还是以中心化调度为主。原因很实际：中心化系统好调试、好监控、好追责。去中心化系统出了问题，你都不知道是哪台机器人做了错误决策。

这个模块的输出是什么

Fleet management 系统的输出是每台机器人在每个时刻应该做什么 - 具体来说是一系列的任务指令和路径许可。这些指令喂给每台机器人本地的 Nav2 和行为树去执行。

从系统架构的角度看，fleet management 处在一个承上启下的位置：它的上游是业务系统（WMS、MES、医院的 HIS），接收“把什么东西从哪搬到哪”的业务需求；它的下游是每台机器人的自主导航栈，把高层任务翻译成机器人能执行的具体行为。

如果说前面几章讲的是“怎么让一台机器人干好活”，这一章讲的是“怎么让一群机器人一起干好活”。而下一个问题就是：干好活之后，怎么让这个事情在商业上也转得动。