ROS 2 sur un VPN : la découverte n’est pas le chemin des données
Que la découverte trouve des pairs ne prouve pas que les charges utiles arrivent. Vérifiez le RMW, les points de terminaison annoncés et une charge de travail avant de remplacer DDS ou d’ajouter un routeur.
Deux nœuds ROS 2 aux extrémités opposées d’un VPN peuvent lister les topics de l’autre et pourtant ne pas livrer un seul message. La découverte et les données utilisateur sont des échanges distincts avec des chemins distincts, et un serveur de découverte ne relaie pas les charges utiles. Vérifier l’un et supposer l’autre, c’est ainsi que les équipes finissent par remplacer le middleware alors que le tunnel n’a simplement jamais transporté les données. La procédure ci-dessous sépare les deux résultats avant tout remplacement.
Ce que le serveur de découverte transporte réellement
Dans Fast DDS, un Discovery Server distribue des informations sur les points de terminaison : qui publie, qui s’abonne et quel QoS chacun attend. Une fois que les pairs se connaissent, les données utilisateur circulent directement entre eux plutôt que via ce serveur. Atteindre le serveur prouve que le courtier des présentations répond, rien de plus. Un VPN routé a toujours besoin d’un chemin fonctionnel dans les deux sens entre les adresses annoncées par les pairs.
Cette distinction explique aussi les défaillances partielles, où les pairs existants continuent d’échanger des données tandis que la nouvelle découverte cesse de fonctionner. Traitez-les comme deux enquêtes.
Lisez le RMW que les nœuds utilisent réellement
ROS 2 peut charger différents middlewares, et une variable exportée dans votre shell n’atteint pas les processus démarrés ailleurs. Interrogez le système en cours d’exécution plutôt que l’historique de votre terminal.
printenv RMW_IMPLEMENTATION
ros2 doctor --report | head -n 20Une variable non définie signifie généralement la valeur par défaut installée, qui peut différer entre machines d’une même expérience. Le rapport nomme aussi la distribution et le middleware utilisés, comparez-les des deux côtés du tunnel avant de supposer qu’ils correspondent. Le démon de ligne de commande de ROS met l’état en cache, redémarrez-le après avoir changé l’environnement au lieu de laisser un démon obsolète répondre pour l’ancienne configuration. Notez la distribution et le RMW des deux hôtes dans les notes de test tant que la session est ouverte.
Testez la découverte et les données comme deux résultats
Choisissez un topic inoffensif et mesurez la présentation séparément de la livraison. La commande info liste les points de terminaison et le QoS, tandis que echo prouve si un message traverse réellement le lien.
ros2 topic info /chatter --verbose
ros2 topic echo /chatter --onceL’apparition de points de terminaison dans la sortie d’info est un résultat de découverte. L’arrivée d’un message chez l’abonné est un résultat de transport, et seul le second éprouve le chemin dont l’application a besoin. Quand la découverte fonctionne et que echo expire, inspectez les adresses annoncées et la route de retour plutôt que le service de découverte. Exécutez les deux commandes depuis chaque hôte, car une route VPN asymétrique ne se révèle souvent que d’un côté.
Ne changez qu’une dépendance à la fois
Quand le chemin des données échoue, évitez de modifier le middleware, le mode de découverte et la taille des messages dans la même session, car aucun résultat ne pourra plus être attribué. Le RMW Zenoh est une alternative légitime, mais son routeur devient une dépendance supplémentaire qui doit être joignable à travers le tunnel.
export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohdSous ce RMW, le routeur porte la découverte dans la disposition par défaut de Jazzy, et la découverte multicast y est désactivée, la dépendance appartient donc à vos notes plutôt qu’à une hypothèse empruntée à un autre middleware. Gardez la charge de travail fixe pendant que vous changez un réglage, puis répétez le test echo et notez la direction, le débit de messages et les conditions du lien. Répétez la comparaison deux fois pour distinguer une réelle amélioration d’une reconnexion chanceuse. Si un changement améliore la découverte alors que la livraison reste identique, vous avez déplacé le service de présentation, pas le chemin des données.