R
Member
实验室两台移动机器人连同一个 WiFi 做协同测试，一开始话题全串了：A 车的 /cmd_vel 发到了 B 车上。把隔离方案整理一下：
1. 命名空间是最直接的隔离：launch 文件里给每台车 push-ros-namespace（比如 /robot1、/robot2），话题、服务、参数全带前缀，从根上避免重名。
2. DDS 域隔离做第二层：不同机器人组设不同的 ROS_DOMAIN_ID。注意同一域内 discovery 流量会广播，机器人一多网络会变吵，域隔离能明显减少无效流量。
3. TF 树要各自独立：map -> odom -> base_link 这种 TF 链，两台车必须完全分开，不然 rviz 里两台车会叠在一起乱飘。命名空间推上去后 TF 会自动带前缀，记得检查。
4. 跨机器人通信走显式桥接：协同需要的数据（比如相对位姿）用专门的话题做桥接，别图省事把命名空间关了。桥接节点里做好数据校验，丢包时要有超时保护。
5. 实测建议：先单车跑通，再双车同网空载跑（不发控制指令），用 ros2 topic list 确认话题隔离干净了，再上协同逻辑。
我们现在是"命名空间 + 不同 DOMAIN_ID"双保险，跑得很稳。大家多机通信时 DDS 选型有讲究吗？Cyclone 和 FastDDS 在弱网下表现差得多吗？
1. 命名空间是最直接的隔离：launch 文件里给每台车 push-ros-namespace（比如 /robot1、/robot2），话题、服务、参数全带前缀，从根上避免重名。
2. DDS 域隔离做第二层：不同机器人组设不同的 ROS_DOMAIN_ID。注意同一域内 discovery 流量会广播，机器人一多网络会变吵，域隔离能明显减少无效流量。
3. TF 树要各自独立：map -> odom -> base_link 这种 TF 链，两台车必须完全分开，不然 rviz 里两台车会叠在一起乱飘。命名空间推上去后 TF 会自动带前缀，记得检查。
4. 跨机器人通信走显式桥接：协同需要的数据（比如相对位姿）用专门的话题做桥接，别图省事把命名空间关了。桥接节点里做好数据校验，丢包时要有超时保护。
5. 实测建议：先单车跑通，再双车同网空载跑（不发控制指令），用 ros2 topic list 确认话题隔离干净了，再上协同逻辑。
我们现在是"命名空间 + 不同 DOMAIN_ID"双保险，跑得很稳。大家多机通信时 DDS 选型有讲究吗？Cyclone 和 FastDDS 在弱网下表现差得多吗？