Documentation

Connecter une flotte de robots à distance : ROS 2, AGV et AMR

Une flotte de robots se déploie rarement sur un réseau accueillant : AMR chez des clients derrière le CGNAT d’un opérateur 4G, AGV sur un Wi-Fi industriel cloisonné, drones sur des sites sans informatique. Connecter un robot à distance — le superviser, le mettre à jour, récupérer sa télémétrie — devient alors un projet en soi. VIGIL-MESH place chaque robot dans le même réseau local logique que vos postes d’ingénierie : ROS 2 se découvre entre sites, la console montre la flotte en temps réel, et un terminal SSH s’ouvre dans le navigateur.

Le terrain : des robots injoignables par construction

Un robot en production n’est presque jamais joignable depuis l’extérieur. Il est derrière la 4G d’un opérateur — donc en CGNAT, sans adresse publique —, sur le Wi-Fi industriel cloisonné d’une usine, ou sur le réseau d’un client où personne n’ouvrira de port pour vous.

L’AMR chez le client

Livré avec son routeur 4G, il vit en CGNAT : aucune connexion entrante possible — la redirection de port n’existe même pas —, et l’IT du client ne touchera pas à son pare-feu.

L’AGV dans l’usine

Le Wi-Fi industriel est cloisonné en VLAN, filtré ou coupé d’Internet ; l’équipe robotique n’a pas la main sur le réseau de l’usine.

Le drone, l’engin de chantier

Sites temporaires, liaisons 4G/5G ou Starlink, zéro infrastructure informatique sur place — et pourtant de la télémétrie et de la vidéo à faire remonter.

ROS 2 et DDS ont besoin de multicast : le mesh le transporte

DDS, l’intergiciel de ROS 2, découvre ses participants par multicast UDP : sans multicast, pas de découverte, et sans découverte, pas de graphe. C’est ce qui rend ROS 2 multi-sites si pénible avec un VPN classique — le multicast ne traverse pas. VIGIL-MESH réplique le multicast IP à travers le mesh : la découverte DDS fonctionne entre sites comme sur un LAN, et les nœuds ROS 2 du siège voient les topics du robot déployé à l’autre bout du pays.

Le fonctionnement détaillé du multicast dans le mesh (groupes, périmètre, contrôle de tempête) est décrit dans Multicast avancé.
L’approche complète pour la robotique — datagrammes de bout en bout, priorités temps réel, MAVLink — est sur la page Robotique et ROS 2.

Gérer la flotte : enrôler en usine, superviser, intervenir

Une flotte ne se gère pas robot par robot à la main. L’enrôlement par clé s’intègre à la production : la clé est posée dans l’image disque en usine, et chaque robot rejoint le réseau à son premier démarrage connecté — sans opération sur site.

Assistant d’enrôlement de la console : génération d’une clé d’enrôlement à intégrer à l’image disque des robots. — L’assistant d’enrôlement génère la clé que l’usine intègre à l’image : le robot rejoint le réseau à son premier démarrage.

Topologie en temps réel dans la console : quels robots sont en ligne, depuis quel site, par quel chemin.
Télémétrie et vidéo en temps réel : datagrammes de bout en bout, sans tête de ligne TCP sur le chemin des flux.
Mise à jour et débogage par terminal SSH dans le navigateur, sans VPN ni bastion — voir Terminal SSH dans le navigateur.
ACL par identité : l’équipe support joint chaque robot, le robot ne joint que ce dont il a besoin, et le réseau du client final reste hors de portée.
L’agent tourne sur NVIDIA Jetson, Linux, Windows et Android ; le poste de supervision peut n’être qu’un navigateur (WASM).

Terminal SSH de la console : connexion à une machine du réseau depuis le navigateur. — Un terminal SSH s’ouvre sur le robot depuis la console — pour lire un log, relancer un nœud ROS 2 ou pousser une mise à jour.

Cas concret : l’AMR déployé chez le client est injoignable

L’AMR est livré chez le client avec son routeur 4G. L’opérateur mobile fait du CGNAT : pas d’adresse publique, aucune connexion entrante possible — la redirection de port n’existe même pas. Côté client, l’IT ne vous ouvrira ni port ni VPN sur son réseau.

Résultat : au premier incident, il faut envoyer un technicien sur site pour un problème qui se réglerait en dix minutes de SSH — et la flotte grandit plus vite que l’équipe support.

Téléopération : ce qu’il faut savoir

Pour la téléopération, le mesh établit un chemin direct dès que possible et n’ajoute qu’une couche de chiffrement au trajet réseau ; tant que le chemin direct n’est pas établi, le trafic passe par une vigie aveugle. Les datagrammes temps réel sont strictement prioritaires sur les flux de service.

Questions fréquentes

Faut-il une carte SIM avec adresse IP publique pour chaque robot ?

Non. Le robot établit toutes ses connexions en sortie : une SIM 4G grand public en CGNAT suffit. C’est précisément le cas que le mesh est conçu pour traverser.

La découverte ROS 2 fonctionne-t-elle vraiment entre deux sites ?

Le multicast IP est répliqué à travers le mesh, donc la découverte DDS traverse comme sur un LAN. La validation ROS 2 formelle est sur la feuille de route — nous ne la revendiquons pas encore comme démontrée.

Quelle latence pour téléopérer ?

Nous ne promettons pas de chiffre : sur chemin direct, le mesh ajoute une couche de chiffrement au trajet réseau, et la latence réelle dépend surtout du lien radio du robot (4G, Wi-Fi industriel). Mesurez sur votre lien avant tout usage critique.

Comment enrôler cinquante robots sans cliquer cinquante fois ?

Avec une clé d’enrôlement intégrée à l’image disque en usine : chaque robot rejoint le réseau à son premier démarrage connecté. La clé est gérée depuis la console, et l’arrivée de chaque machine y est visible.

Quelles plateformes côté robot ?

Linux et NVIDIA Jetson côté robot ; Windows, Android et le navigateur (WASM) côté supervision. Le poste de téléopération peut n’être qu’un onglet de navigateur.

Lire ensuiteRobotique et ROS 2 →