Documentation
VPN pour la robotique et ROS 2
ROS 2 et son intergiciel DDS supposent un réseau local : découverte par multicast, faible latence, échanges directs entre nœuds. À distance, c’est difficile. Un VPN mesh qui réplique le multicast IP et transporte des datagrammes de bout en bout rapproche la robotique distante d’un vrai LAN.
Le défi de ROS 2 à distance
DDS (l’intergiciel sous ROS 2) découvre ses participants par multicast UDP et privilégie les échanges directs, à faible latence. Un VPN classique en étoile casse ce modèle : pas de multicast, un détour par un concentrateur, de la latence ajoutée. Pour de la téléopération, chaque milliseconde et chaque datagramme comptent.
Comment VIGIL relie des robots
- Multicast IP répliqué à travers le mesh : la découverte DDS traverse comme sur un LAN (voir /docs/l2-multicast).
- Datagrammes non fiables de bout en bout pour la commande temps réel : pas de tête de ligne TCP sur le chemin des commandes.
- Connexion immédiate via relais aveugle puis bascule vers le chemin direct : la latence en direct est essentiellement celle de votre réseau.
- Connecteur MAVLink pour les drones et un nœud navigateur (WASM) pour piloter depuis une application no-code.
Latence et temps réel
Sur un chemin direct validé, VIGIL n’ajoute qu’une seule couche de chiffrement au trajet réseau : la latence de bout en bout est essentiellement celle de votre réseau. Les objectifs de conception (par exemple garder le chemin élu proche du meilleur chemin validé) sont des cibles, pas des mesures — voir /docs/performances.
In English
ROS 2 and its DDS middleware assume a LAN: multicast discovery, low latency, direct node-to-node exchanges. Remote operation breaks that.
VIGIL replicates IP multicast across the mesh so DDS discovery traverses like on a LAN, and carries end-to-end unreliable datagrams for real-time control.
Formal ROS 2 validation is on the roadmap; on very large DDS graphs, storm control may throttle chatty discovery, so size accordingly.