企业官网建设流程全解析

面试翻车现场

面试一家做多机器人协作的公司，面试官问："你有过多机ROS2通信的经验吗？两台机器人之间怎么共享数据？"

我说用DDS自动发现，同一网络下的Node自动通信。他追问："网络延迟大的时候怎么办？不同子网怎么通信？你怎么保证多机之间的时间同步？"

这几个问题我答得不好。我只知道ROS2的多机通信"理论上"靠DDS自动搞定，但实际部署中会遇到很多网络层面的问题。面试官说："多机通信是分布式机器人系统的核心，不能只停留在理论层面。"

DDS的自动发现机制

ROS2的多机通信建立在DDS的自动发现机制上。同一个域（Domain）内的所有Node会自动发现对方，建立通信连接。你不需要手动配置"谁和谁通信"，只要话题名和消息类型匹配，DDS就会自动连接。

域的概念很重要。域ID（ROS_DOMAIN_ID）决定了哪些Node在同一个通信域内。默认域ID是0。如果你有两台机器人，不想让它们互相干扰，可以给它们设不同的域ID。

发现过程是这样的：每个Node启动时会向网络广播自己的存在（通过SPDP协议），同时监听其他Node的广播。发现对方后，通过SEDP协议协商具体的端点匹配。这个过程对用户完全透明。

默认情况下，DDS用UDP组播做发现。这意味着同一个广播域内的机器人都能互相发现。如果机器人在不同子网，需要配置组播转发或者用发现服务器。

网络配置实战

实际部署多机系统时，网络配置是最容易出问题的环节。

最简单的场景：两台机器人在同一个局域网，用交换机连接。这种情况下，DDS自动发现直接就能工作，不需要额外配置。你只需要确保两台机器的ROS_DOMAIN_ID相同，RMW_IMPLEMENTATION相同（比如都用rmw_fastrtps_cpp）。

中等难度的场景：两台机器人在不同子网。比如一台在192.168.1.x网段，另一台在192.168.2.x网段。UDP组播不能跨子网，所以自动发现会失败。解决办法有两种：一是配置路由器的组播转发（IGMP snooping），二是用DDS的发现服务器（Discovery Server）。

发现服务器是DDS提供的一种集中式发现机制。一台机器运行发现服务器，其他机器作为客户端连接它。这样即使在不同子网，只要都能访问发现服务器，就能互相发现。配置方式是设置环境变量ROS_DISCOVERY_SERVER。

我分享一个实际踩坑的经历。有一次我们做三台机器人的协作实验，三台机器在不同子网，用了发现服务器方案。配置好后发现机器人A能发现B，B能发现C，但A发现不了C。排查了半天，最后发现是发现服务器只在一台机器上跑，而FastDDS的发现服务器需要所有客户端都配置正确的服务器地址。我们在每台机器上都设了ROS_DISCOVERY_SERVER="192.168.1.100;11811"，问题就解决了。另外，发现服务器的端口号（默认11811）要确保在所有机器的防火墙中都放行。建议部署前先在一台机器上跑fastdds discovery -i 0测试发现服务器是否正常工作，再逐步接入客户端。

最难的场景：机器人通过WiFi连接，网络不稳定。WiFi的延迟波动大、偶尔断连，DDS在这种环境下表现不太好。建议用有线连接，或者用专门的mesh网络方案。如果必须用WiFi，选择QoS配置为Best Effort，减少重传带来的延迟。

时间同步

多机系统中，时间同步是个大问题。每台机器有自己的系统时钟，如果时钟不同步，消息的时间戳就没有可比性。

最基础的方案是用NTP（Network Time Protocol）同步所有机器的系统时钟。局域网内的NTP同步精度可以达到毫秒级，对大多数机器人应用来说够用了。配置很简单：一台机器做NTP服务器，其他机器做NTP客户端。

更高精度的方案是用PTP（Precision Time Protocol，IEEE 1588）。PTP通过硬件时间戳可以达到微秒级精度，但需要网卡和交换机都支持PTP。工业场景中对时间精度要求高的应用（比如多传感器融合）会用到。

还有一种思路是不依赖全局时钟同步，而是用逻辑时间。每台机器用自己的时间戳，在数据融合时通过TF2的时间缓存机制来对齐。这种方式对网络要求低，但实现起来更复杂。

我参与的一个多机器人项目中，用的是NTP加TF2的组合方案。每台机器人通过NTP同步系统时钟，精度在几毫秒以内。机器人之间共享位姿数据时，用TF2的lookup_transform查询对应时刻的变换。实际测试下来，定位数据的对齐误差在可接受范围内。如果NTP同步出了问题（比如网络断了），系统会报警并切换到保守模式——每台机器人只在自己的工作区域内活动，不进入共享区域。这种容错设计在生产环境中很重要。

数据分发策略

多机通信时，不是所有数据都需要广播给所有机器。你需要设计数据分发策略。

第一种策略是话题隔离。不同机器人的传感器数据用不同的话题前缀，比如/robot1/lidar和/robot2/lidar。每台机器只订阅自己需要的数据。这种方式简单直接，但话题多了以后管理起来比较麻烦。而且要注意带宽问题——如果10台机器人同时广播原始点云数据，网络带宽会很快被打满。实际中通常只在机器人之间传输处理后的结果（比如目标位置、路径规划），不传原始传感器数据。

第二种策略是用命名空间。ROS2支持给Node设命名空间，/robot1/cmd_vel和/robot2/cmd_vel是两个独立的话题。这种方式更规范，也方便管理。

第三种策略是自定义DDS配置。你可以修改DDS的QoS策略，控制数据的传输范围、持久性、可靠性等。比如机器人的状态信息用Reliable QoS确保送达，传感器数据用Best Effort减少带宽占用。

常见问题排查

多机通信出问题时，排查思路是这样的。

第一步，检查网络连通性。ping一下对方机器，看网络通不通。如果不通，检查IP配置、子网掩码、网关。

第二步，检查DDS发现。用ros2 topic list看能不能看到对方机器的话题。如果看不到，可能是域ID不同、防火墙阻挡了组播、或者不同子网没有配置路由。

第三步，检查防火墙。Ubuntu默认的ufw可能会阻挡DDS的组播端口。临时关掉防火墙试试：sudo ufw disable。生产环境中应该配置精确的防火墙规则，只放行DDS需要的端口。

第四步，检查DDS实现。两台机器必须用同一种DDS实现（比如都用FastDDS或都用CycloneDDS）。如果一个用FastDDS一个用CycloneDDS，可能发现不了对方。建议团队统一用一种DDS实现，CycloneDDS在稳定性和性能上口碑不错，很多生产项目都在用。

安全考虑

多机系统的安全问题不能忽视。如果通信被窃听或篡改，后果可能很严重。

ROS2提供了SROS2（Secure ROS2）来加密和认证通信。SROS2基于DDS的安全规范，支持身份认证、数据加密、访问控制。配置比较复杂，需要生成证书、分发密钥、配置权限策略。

实际项目中，如果机器人都在受信任的内网中，一般不开启SROS2，因为加密会增加延迟和CPU开销。但如果机器人通过公网通信，或者在不安全的环境中运行，SROS2是必须的。

多机部署检查清单

上线一套多机系统前，建议逐项检查以下内容。

网络层面：确认所有机器的IP配置正确，子网掩码一致，防火墙规则已配置。用ping和iperf测试网络延迟和带宽。DDS发现：用ros2 topic list在每台机器上确认能看到所有必要的话题。时间同步：用chronyc tracking或ntpq -p检查NTP同步状态，确保各机器时钟偏差在可接受范围内。域ID和环境变量：确认所有机器的ROS_DOMAIN_ID、RMW_IMPLEMENTATION一致。QoS配置：检查关键话题的QoS设置，确保跨机器通信的可靠性符合要求。

建议在项目中维护一份部署脚本，自动化这些检查和配置过程。每次上线新环境跑一遍脚本，避免手动配置遗漏。

面试中怎么聊

面试官问多机通信，你可以说："ROS2多机通信基于DDS自动发现，同域内Node自动建立连接。实际部署要注意网络配置——同局域网直接通信，不同子网用发现服务器，WiFi环境注意延迟波动。时间同步用NTP或PTP。数据分发用命名空间隔离和QoS策略控制。多机系统的核心挑战是网络可靠性和时间同步精度。"

上一篇：第133篇 ROS2生命周期节点——状态机管理的标准化方案

下一篇预告：第135篇 ros2_control框架——机器人硬件抽象的标准方案