第275篇多机器人系统架构——通信/协调/任务分配

郑伟强dev

65人浏览 · 2026-08-27 06:51:40

郑伟强dev · 2026-08-27 06:51:40 发布

任务调度聊完了，单机器人多任务的管理方案应该清楚了。但很多场景需要多台机器人协同工作——仓储里几十台AGV同时跑，巡检现场多台无人机分区覆盖。

多机器人系统不是把单机器人简单复制几份。它需要解决三个核心问题：通信（机器人之间怎么交换信息）、协调（怎么避免互相干扰）、任务分配（谁干什么活）。

这三个问题决定了多机器人系统的架构设计。面试问到多机器人，能把这三个维度讲清楚，就能证明你有系统级的思考能力。

一、通信架构

多机器人之间的通信有两种基本模式：

集中式——所有机器人和中央服务器通信。服务器知道所有机器人的位置和状态，统一做决策。

机器人A → 中央服务器 → 机器人B 机器人B → 中央服务器 → 机器人C

优点是全局信息完整，决策最优。缺点是服务器是单点故障——服务器挂了所有机器人都停。通信量大，服务器可能成为瓶颈。

分布式——机器人之间直接通信（P2P），没有中央服务器。每台机器人只和邻居交换信息。

机器人A ↔ 机器人B 机器人B ↔ 机器人C 机器人A ↔ 机器人C

优点是没有单点故障，扩展性好。缺点是信息不完整（每台机器人只知道邻居的状态），协调难度大。

实际项目中常用混合式——有一个中央调度器负责任务分配（集中式），机器人之间用P2P做局部协调（分布式）。

ROS2的多机器人通信基于DDS（Data 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

二、协调机制

多台机器人在同一空间运动，最大的问题是互相干扰——两台机器人走到同一条走廊的对面，谁让谁？

空间协调——用共享地图标记每台机器人的位置和占据区域。其他机器人在规划路径时把这些区域当作动态障碍物。

时间协调——给每台机器人分配时间窗口。某条走廊在t=10-20秒归机器人A用，t=20-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, key=bids.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(f'x_{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))}

约束优化的好处是能同时考虑多种约束（电量、容量、时间窗口），求出全局最优解。缺点是求解时间随问题规模增长，大规模场景可能需要启发式近似。