任务调度聊完了单机器人多任务的管理方案应该清楚了。但很多场景需要多台机器人协同工作——仓储里几十台AGV同时跑巡检现场多台无人机分区覆盖。多机器人系统不是把单机器人简单复制几份。它需要解决三个核心问题通信机器人之间怎么交换信息、协调怎么避免互相干扰、任务分配谁干什么活。这三个问题决定了多机器人系统的架构设计。面试问到多机器人能把这三个维度讲清楚就能证明你有系统级的思考能力。一、通信架构多机器人之间的通信有两种基本模式集中式——所有机器人和中央服务器通信。服务器知道所有机器人的位置和状态统一做决策。机器人A → 中央服务器 → 机器人B 机器人B → 中央服务器 → 机器人C优点是全局信息完整决策最优。缺点是服务器是单点故障——服务器挂了所有机器人都停。通信量大服务器可能成为瓶颈。分布式——机器人之间直接通信P2P没有中央服务器。每台机器人只和邻居交换信息。机器人A ↔ 机器人B 机器人B ↔ 机器人C 机器人A ↔ 机器人C优点是没有单点故障扩展性好。缺点是信息不完整每台机器人只知道邻居的状态协调难度大。实际项目中常用混合式——有一个中央调度器负责任务分配集中式机器人之间用P2P做局部协调分布式。ROS2的多机器人通信基于DDSData Distribution Service天然支持分布式发布/订阅。每台机器人有自己的命名空间topic名称加上命名空间前缀就能区分。# ROS2多机器人命名空间 # 机器人1的雷达数据/robot1/scan # 机器人2的雷达数据/robot2/scan # 每台机器人运行独立的Nav2实例 ros2 launch nav2_bringup navigation_launch.py \ namespace:robot1 use_sim_time:true ros2 launch nav2_bringup navigation_launch.py \ namespace:robot2 use_sim_time:true二、协调机制多台机器人在同一空间运动最大的问题是互相干扰——两台机器人走到同一条走廊的对面谁让谁空间协调——用共享地图标记每台机器人的位置和占据区域。其他机器人在规划路径时把这些区域当作动态障碍物。时间协调——给每台机器人分配时间窗口。某条走廊在t10-20秒归机器人A用t20-30秒归机器人B用。规则协调——设定交通规则。比如靠右行驶转弯让直行上坡优先。简单但有效。class MultiRobotCoordinator: def __init__(self): self.robot_positions {} self.reserved_paths {} # robot_id - path_segments def request_path(self, robot_id, path): # 检查路径是否和其他机器人的预留路径冲突 for other_id, other_path in self.reserved_paths.items(): if other_id ! robot_id: if self.check_conflict(path, other_path): return False, 路径冲突请等待 self.reserved_paths[robot_id] path return True, 路径已预留这种路径预留机制在仓储AGV系统中很常见。中央调度器管理所有路径预留机器人发送路径请求调度器检查冲突后批准或拒绝。Amazon的Kiva系统现在叫Amazon Robotics用的就是这种思路。几千台AGV在仓库里跑中央调度器管理所有路径和任务分配。每台AGV只负责执行分配到的路径遇到异常就停下来等调度器重新规划。除了路径预留还有一种更轻量的协调方式社会规则social rules。每台机器人遵循一组简单规则——靠右行驶、保持安全距离、路口减速。不需要中央调度器机器人之间通过局部感知自主协调。这种方式在机器人数量多、环境开阔的场景下效果不错。但在窄通道、交叉路口等瓶颈区域社会规则不够用还是需要中央调度或者显式的协商协议。三、任务分配多台机器人多个任务怎么分配拍卖机制——任务发布出去每台机器人根据自己的状态距离、电量、当前负载出价。出价最低的机器人中标。def auction_task(task, robots): bids {} for robot in robots: dist distance(robot.pos, task.location) battery_factor robot.battery / 100.0 bid dist / battery_factor # 距离近、电量高的出价低 bids[robot.id] bid winner min(bids, keybids.get) return winner拍卖机制的优点是分布式、可扩展。缺点是全局最优不保证——可能出现所有任务都分配给同一台机器人的情况。匈牙利算法——把所有机器人和所有任务构成一个代价矩阵用匈牙利算法求最优匹配。全局最优但需要中央计算。约束优化——把任务分配建模成约束优化问题。约束包括每台机器人最多分配N个任务、电量必须足够、时间窗口不能冲突。用求解器比如OR-Tools求解。from ortools.linear_solver import pywraplp def optimize_assignment(robots, tasks): solver pywraplp.Solver(assignment, pywraplp.Solver.CBC_MIXED_INTEGER_PROGRAMMING) # x[i][j] 1 表示机器人i分配任务j x {} for i in range(len(robots)): for j in range(len(tasks)): x[i, j] solver.BoolVar(fx_{i}_{j}) # 约束每个任务只能分配给一台机器人 for j in range(len(tasks)): solver.Add(sum(x[i, j] for i in range(len(robots))) 1) # 约束每台机器人的总工作量不超过容量 for i in range(len(robots)): solver.Add(sum(x[i, j] for j in range(len(tasks))) 3) # 目标最小化总距离 cost [] for i in range(len(robots)): for j in range(len(tasks)): d distance(robots[i].pos, tasks[j].location) cost.append(d * x[i, j]) solver.Minimize(sum(cost)) solver.Solve() return {(i, j): x[i, j].solution_value() for i in range(len(robots)) for j in range(len(tasks))}约束优化的好处是能同时考虑多种约束电量、容量、时间窗口求出全局最优解。缺点是求解时间随问题规模增长大规模场景可能需要启发式近似。四、面试高频追问Q集中式和分布式架构怎么选A小规模5台以下用集中式简单可靠。大规模几十台上用分布式或混合式避免中央服务器成为瓶颈。关键看有没有必须知道全局信息的需求。Q多机器人的命名空间怎么管理AROS2里每台机器人用独立的命名空间。所有topic、service、action都加命名空间前缀。TF树也要区分——robot1的base_link和robot2的base_link是两个不同的坐标系。Q两台机器人在窄走廊相遇怎么处理A中央调度器做路径预留。先申请到路径预留权的机器人先通过另一台在入口处等待。如果没有中央调度器用分布式协商——两台机器人交换意图按规则比如ID小的优先决定谁让。Q多机器人系统的单点故障怎么避免A集中式架构的中央服务器要做冗余——主备切换或者多副本共识。分布式架构天然没有单点故障但需要处理网络分区部分机器人失联的情况。多机器人系统架构是机器人工程师进阶的必备知识。通信、协调、任务分配三个维度都要有基本的理解。下一篇我们聊多机器人路径协调的细节。多机器人系统架构的三个核心维度通信架构集中式vs分布式、协调机制空间/时间/规则、任务分配拍卖/匈牙利/约束优化。上一篇第274篇 任务调度与编排下一篇深入聊路径协调。如果这篇文章对你有帮助欢迎点赞支持一下你的鼓励是我持续更新的动力