8.4 多机器人协同组网

8.4 多机器人协同组网

本节摘要：单机调通的导航栈，第二台机器人一加入网络就会"精神错乱"——两台都叫 robot，都发同名话题，互相吃对方的数据。本节讲清多机组网的两套隔离方案（命名空间与域）的取舍、跨组通信的桥接、以及发现流量随规模增长的应对。多机不是把代码跑两份，而是重新回答"谁是谁、谁能听见谁"。

第二台机器人是一面镜子

单机时代被忽略的假设，多机时代全部现形：话题名全局唯一（两台机器人的 /scan 撞了）、TF 树全局唯一（两套 odom 到 base_link 打架）、参数节点名唯一（param set 不知道该找谁）。多机组网的本质是给这些全局唯一的东西划定作用域。ROS2 给了两把尺子：命名空间在话题与节点名层面切分，域在物理通信层面切分。两把尺子怎么选，是本节第一个要回答的问题。

一、两套隔离方案的取舍矩阵

方案一：命名空间隔离。 同域运行，每台机器人的所有节点挂在自己的命名空间下：robot1 的雷达发 /robot1/scan，robot2 发 /robot2/scan。改动集中在 Launch（4.3 节的 namespace 参数一填，节点内代码零改动），收益是单域内跨机器人可见——协作算法能直接看到彼此的位姿与状态。

方案二：域隔离。 每台（或每组）机器人一个 ROS_DOMAIN_ID，物理层面互相不可见——1.3 节那个"域 42 残留"的故障，在多机场景里就是有意为之的隔离手段。它的收益是彻底的广播隔离：发现流量、组播数据全部不串门，单组规模大时这是性能刚需；代价是跨组通信必须显式搭桥。

两把尺子不互斥，工程上常见混合：按区域分域（东仓一个域、西仓一个域），域内用命名空间区分台数。判断题只有一道：**这两台机器人需要直接互相看见吗？**需要，同域加命名空间；不需要，分域——隔离本身就是性能与安全红利。

二、跨域桥接与协同的典型拓扑

分域之后需要跨组信息（比如调度器要看得见所有机器人），桥登场。topic bridge 是显式的点对点转译：声明源话题与目标话题，数据在域之间定向流通。它的哲学与 7.3 节的仿真桥一脉相承——只通该通的，不通默认的。

# 调度域里的桥：把两个作业域的位姿话题转进调度域
ros2 run topic_bridge relay /odom /robot_east/odom \
  --ros-args -p domain_id:=10   # 源在域10
# 目标侧另一个桥实例写入调度域（域0）
​

典型三机协同拓扑是：每台机器人一个完整的导航栈（域内自治，断网也能走），一个调度器节点（可以云上或网关上）通过桥收集各机位姿、下发目标。这个架构的抗毁性值得欣赏：网络断了，各机退化为单机模式继续工作，恢复后调度重新接管——比"中心化大脑"架构健壮得多。

图 8-3：三机混合组网拓扑

三、发现流量：规模的天花板

多机绕不开的物理事实：DDS 的发现协议是组播广播，每个参与者周期性自我介绍，也接收所有人的自我介绍。流量随台数的增长是平方级的——十台机器人意味着九十对参与者关系。规模一大，发现流量吃掉带宽、CPU 花在解析无关节点上，传感器的有效带宽被挤占。

应对手段按规模递进。几十台以内：域分组（前面的混合方案）把平方限制在组内，通常够用。再往上：配置发现服务器（discovery server 模式），参与者只与固定的服务器交换发现信息、不再互相广播——从"广场喊话"变成"花名册登记"，流量从平方回到线性。带宽预算别忘了 5.4 节的算术：每台机器人的传感器流是持续负载，组网设计先算总带宽，再决定分区方案。

💡 关键直觉：多机系统架构的最优解几乎总是"自治优先"——每台机器先是一台完整的单机，协同是锦上添花。反向设计（机器离了中心大脑就不能动）在第一次网络抖动时就会还债。

四、多机改造实录：从"第二台就乱"到"第十台如常"

组网方案讲完了，用一份多机改造实录看这些方案在真实项目里如何逐步落地——重点是每一步的决策依据，而不是命令本身。

第二步机器人入场，冲突全面爆发。 两台机器人的话题完全同名：互吃对方的扫描、TF 双广播者冲突、RViz 里两台机器人叠加成一只"合体怪"。这正是本节开头说的"全局唯一假设现形"。

第一次改造：命名空间化。 用 Launch 的 namespace 参数给每台机器人的全部节点加前缀，节点代码零改动。一轮改完，话题不再互吃，但两个新问题出现：一是部分写死绝对话题名的代码（以斜杠开头的话题名）不受命名空间约束，需要逐一改成相对名；二是 TF 的命名空间化要靠 TF 前缀参数逐帧配置，漏一帧就错一帧。这次改造的教训是命名空间化的前提是全库相对话题名纪律——绝对名是命名空间方案的暗礁。

第五台入场：发现流量开始可见。 五台同域运行，组播流量实测已占带宽的百分之一以上，且随台数陡增。此时切换到混合方案：按区域分域，域内命名空间。改造量很小（每台改一个域变量），但立刻带来两个工程红利——域内发现流量回落，且单域故障不再扩散到全域。

第十台如常的标志：新机器人入场变成一条流水线——刷镜像（8.3）、配置域与命名空间、仿真回归、入场自检（自检内容之一是确认自己的话题没与任何在网机器人重名）。多机系统的成熟度，恰恰体现在"新成员入场需要人操心多少事"上。

这份实录的元教训：多机能力要趁早建。从第一台就按相对话题名与可配置命名空间写代码，多机改造就只是一次配置；从第五台才开始建，就是一次全库手术。

本节要点回顾

• 多机的本质是划定作用域：话题名、TF、参数的作用范围都要重新审视；
• 命名空间与域的判断题：需要互相看见就同域加前缀，不需要就分域；
• 桥只通该通的：跨域信息显式声明，默认不通是特性；
• 自治优先的架构最抗毁：断网退化单机、恢复即重新接管；
• 发现流量平方级增长是规模天花板，几十台以上用发现服务器压回线性。

扩展关过了。最后一节把全册拧成一股绳：一份可以直接落地的工程化标准。