- name
- ros2-multi-machine
- description
- Multi-host / container ROS 2 discovery — multicast vs unicast, Fast DDS Discovery Server, Cyclone peers, ROS_AUTOMATIC_DISCOVERY_RANGE, Docker host network. Use when robots do not see each other, containers isolate DDS, or WAN/multicast is blocked.
# ROS 2 Multi-Machine Discovery
Same `ROS_DOMAIN_ID` and **same RMW** on every host. Mixing FastDDS ↔ Cyclone = no graph.
## Isolation knobs
| Knob | Effect |
|------|--------|
| `ROS_DOMAIN_ID` (0–101) | Logical bus |
| `ROS_LOCALHOST_ONLY=1` | No off-host (Humble) |
| `ROS_AUTOMATIC_DISCOVERY_RANGE` (Jazzy+) | `OFF` / `LOCALHOST` / `SUBNET` / `SYSTEM_DEFAULT` |
| `ROS_STATIC_PEERS` (Jazzy+) | Unicast peer list when multicast is dead |
Default multicast discovery **fails** on many clouds, Wi-Fi AP isolation, Docker bridge, and VPNs.
## Fast DDS Discovery Server
When multicast is blocked, run one (or two) Discovery Servers; clients point at them (`FASTRTPS_DEFAULT_PROFILES_FILE` / `ROS_DISCOVERY_SERVER=10.0.0.1:11811`).
- Server must be reachable **unicast** from all robots.
- Restarting the server drops the graph until clients rediscover — treat it like DNS.
- Super-client vs client: robots that must see each other all need to know the server address.
## Cyclone
`CYCLONEDDS_URI` XML:
- `AllowMulticast=false` + `<Peers><Peer address="host"/></Peers>` for unicast
- Pin `NetworkInterface` (wrong NIC = silent empty graph)
- Docker: `network_mode: host` **or** explicit peers + `/dev/shm` for intra-host large data
## Containers
- Bridge NAT + multicast = pain. Prefer host network on Linux robots.
- Shared memory zero-copy does not cross containers unless `/dev/shm` is shared **and** RMW is configured for it.
- `ROS_LOCALHOST_ONLY=1` inside a container is a common "why can't the other pod see me".
## Debug
```bash
ros2 doctor
ros2 multicast receive # on A
ros2 multicast send # on B
getent hosts <peer>
```
If multicast test fails, do not debug QoS yet — fix discovery first (`ros2-qos-dds` is the next layer).
GitHubで見る