ros2-multi-machine

# 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).