多机通信就像一群人用对讲机在各自频道里对话。每个机器人是一个"人"，话题是"频道"，节点发现就是"先喊一声看看谁在"。单机ROS2开发时，所有节点跑在一个进程空间里，共享内存就能交换数据。一旦扩展到多机，网络延迟、节点发现、时钟对齐这些新问题就会立刻冒出来。
| 对比维度 | 单机通信 | 多机通信 |
|---|---|---|
| 节点发现 | 本地进程发现（共享内存） | 网络发现（DDS Discovery协议） |
| 数据传输 | 共享内存 / 回环接口 | UDP多播 / TCP点对点 |
| 时钟基准 | 系统时钟统一 | 需NTP/PTP协议同步 |
| 可靠性保障 | 进程级隔离，丢包率极低 | 网络丢包、乱序、延迟抖动 |
| 配置复杂度 | 零配置 | 需设置网络拓扑、发现超时等参数 |
多机ROS2系统在架构上沿用单机的节点-话题-服务模型，但底层通信从进程内共享内存切换为网络协议栈。这种切换对开发者透明（API不变），但带来的延迟和可靠性差异必须纳入系统设计。
多机通信的第一选择是UDP多播。DDS默认使用多播地址做节点发现，每个节点加入同一个多播组，就能收到其他节点的"广播"消息。我踩过一个坑：某次调试时，两台机器人明明连在同一个交换机下，节点就是互相发现不了。排查了半天，发现是交换机的IGMP Snooping功能把多播包过滤掉了——关掉这个功能，或把ROS2的发现协议改为TCP单播模式立刻解决。
节点发现是多机通信的"握手"阶段。DDS的Discovery协议分为两个层次：SPDP（Simple Participant Discovery Protocol）发现参与者（即进程级别的DDS实体），SEDP（Simple Endpoint Discovery Protocol）发现端点到端点（话题发布者/订阅者）。整个流程可以用下图概括：
实际开发中，大部分团队使用默认的Discovery配置就能跑通。但如果你遇到"节点间歇性消失"的报错，大概率是网络环境中存在防火墙或NAT设备，拦截了多播报文。一个可靠的替代方案是设置ROS_DISCOVERY_SERVER环境变量，让节点通过一个中心服务器做发现，绕过多播限制。
SPDP/SEDP就像两个人在大厅里互相喊话："我叫小明，我在找关于'位置'的话题"——先确认谁在（SPDP），再确认各自聊什么（SEDP），最后才拉群开聊。如果大厅里太吵（网络混乱），就需要一个前台（Discovery Server）来登记信息。
时间同步是多机系统的"隐形支柱"。两个机器人各自采集传感器数据，如果系统时钟差了几毫秒，融合出来的位姿就会偏移。生活类比：多人合奏时，每个人按照自己的手表演奏，曲子永远合不上拍——必须统一校准。
ROS2使用Time和Clock类封装时间操作。在多机场景中，每个节点可以通过订阅/clock话题获得全局时间基准。一个常见的实践是：
Clock回调获取同步后的时间戳，确保数据的时间基准一致我在项目中踩过一个坑：两台机器人各自运行NTP客户端，但它们同步的是不同的NTP服务器，导致系统时钟仍有50ms偏差。后来统一指定同一个NTP服务器，偏差降到2ms以内。
tcpdump抓包确认报文是否到达目标网卡。多机系统的数据同步比单机复杂得多。ROS2提供了三种主要同步手段，适用于不同场景：
ApproximateTime策略消息过滤器（message_filters）的ApproximateTime同步器是我最常用的工具。它不要求各话题严格同时到达，而是采用"最近邻匹配"策略，在时间窗口内找到最接近的时间戳组合。实际开发中，我会把时间窗口设为50-100ms（根据网络延迟调整），既能保证数据关联的准确性，又不会因为等待而降低输出频率。
在调试多机同步问题时，一个高效的做法是先在单机上用多进程模拟多机场景。启动两个独立的ROS2进程（通过ROS_LOCALHOST_ONLY=1限制本地通信），就可以模拟网络延迟和发现流程。这个技巧能让你在开发阶段就把同步问题暴露出来，而不是到现场才手忙脚乱。
多机通信绕不开网络丢包和延迟抖动。DDS的QoS策略提供了细粒度的可靠性控制：
RELIABILITY：设置为RELIABLE时，接收方会确认每个数据包，丢失则重传。适合关键控制指令。DURABILITY：设置为TRANSIENT_LOCAL时，新加入的节点可以收到历史数据。适合"晚到者"需要补全状态的场景。DEADLINE：设置消息最大间隔，超时触发回调。适合需要监控"节点是否存活"的场景。一个典型配置组合是：控制话题用RELIABLE + TRANSIENT_LOCAL，传感器数据流用BEST_EFFORT + VOLATILE（允许丢包，追求低延迟）。
在两台同一局域网内的机器上完成以下实验：
chatter话题），观察能否互相发现。ros2 node list和tcpdump对比验证。ROS_DISCOVERY_SERVER环境变量，重启节点，确认多播发现被中心服务替代。message_filters.ApproximateTime同步两个机器各自发布的pose话题，调整时间窗口参数观察输出频率变化。RELIABLE可靠性策略？A. 摄像头图像流 B. 机器人急停指令 C. 激光雷达点云数据