Documentation
ROS 2 à travers Tailscale : pourquoi la découverte DDS échoue
Vous avez connecté deux machines ROS 2 au même réseau Tailscale, le ping passe, et pourtant « ros2 topic list » ne montre rien de l'autre côté. Ce n'est pas un bug de votre installation : DDS, l'intergiciel de ROS 2, découvre ses pairs par multicast local — et un mesh WireGuard route de l'unicast, pas du multicast. Voici pourquoi, les contournements DDS classiques et leurs limites, et l'approche « domaine de diffusion » qui rend au multicast son rôle.
Le symptôme : connectés, mais invisibles l'un pour l'autre
Le scénario est toujours le même. Deux machines — un robot sur le terrain, un poste de supervision au bureau — rejoignent le même réseau overlay. Chacune voit l’adresse de l’autre, ping répond, SSH fonctionne. Réseau opérationnel, donc.
Puis vous lancez vos nœuds ROS 2 de part et d’autre, avec le même ROS_DOMAIN_ID, et rien : ros2 topic list ne liste que les topics locaux, ros2 node list ignore les nœuds distants, aucun message ne circule. Les deux graphes ROS 2 vivent chacun dans leur bulle, comme si l’autre machine n’existait pas.
L'explication : DDS découvre par multicast, l'overlay route de l'unicast
ROS 2 ne parle pas directement réseau : il délègue à DDS, son intergiciel de publication/souscription. Et DDS trouve ses participants par le protocole standard SPDP (Simple Participant Discovery Protocol) : chaque participant annonce périodiquement sa présence sur un groupe multicast UDP bien connu du segment local. Qui entend ces annonces rejoint le graphe ; qui ne les entend pas n’existe pas.
Or un mesh WireGuard comme Tailscale est un overlay de couche 3 routé en unicast : il transporte des paquets IP d’une machine identifiée vers une autre machine identifiée. D’après sa documentation publique, la diffusion broadcast et le multicast IP n’y sont pas pris en charge nativement. Les annonces SPDP émises vers le groupe multicast partent donc sur l’interface locale… et s’arrêtent là : elles ne traversent jamais le tunnel.
Les contournements DDS classiques et leurs limites
L’écosystème DDS n’est pas démuni : puisque la découverte multicast échoue, on peut la remplacer par de la découverte unicast explicite. Toutes les variantes reviennent à la même idée : dire à chaque participant, à l’avance, où trouver les autres.
- Liste de pairs statique. La plupart des implémentations DDS acceptent une liste d’adresses de pairs à contacter en unicast (selon l’implémentation : variable d’environnement, fichier de profil XML…). Chaque machine doit connaître les adresses de toutes les autres.
- Serveur de découverte. Certaines piles proposent un serveur de découverte central que tous les participants contactent en unicast. La découverte fonctionne, mais elle n’est plus pair-à-pair : le serveur devient un composant à héberger, joindre et maintenir en vie.
Ces mécanismes sont légitimes et documentés par les éditeurs DDS. Leur limite est opérationnelle : la configuration vit machine par machine, dépend de l’implémentation DDS utilisée (et peut différer entre robots d’une même flotte), et doit être révisée chaque fois que la flotte change — un robot ajouté, une adresse modifiée, et la liste de pairs de toutes les machines est à reprendre. Ce qui était du zéro-configuration en labo devient un inventaire à tenir à jour.
L'approche domaine de diffusion : rendre au multicast son rôle
L’alternative consiste à traiter la cause plutôt que le symptôme : si la découverte échoue parce que le multicast ne traverse pas, faites-le traverser. VIGIL-MESH réplique le multicast et le broadcast IP à travers son overlay chiffré : le réseau se comporte, pour la diffusion, comme un même commutateur. Les annonces SPDP émises sur une machine atteignent les membres abonnés au groupe, où qu’ils soient — et la découverte DDS retrouve le fonctionnement qu’elle a en labo, sans liste de pairs ni serveur de découverte à maintenir.
- Zéro configuration DDS spécifique. Les abonnements multicast sont détectés automatiquement (querier IGMPv3/MLDv2 local) ; la pile DDS n’a pas besoin de savoir qu’elle n’est pas sur un LAN.
- Chiffré de bout en bout. Le multicast répliqué circule sous des clés d’émetteur que le relais réplique sans pouvoir lire.
- Borné. Un contrôle de tempête à double étage plafonne la diffusion — un point à dimensionner sur les gros graphes DDS, détaillé dans la page multicast avancé.