Réseaux de robots : Wi-Fi, connexions filaires, 5G et l’importance de la latence
Share
Un humanoïde est un nœud mobile sur un réseau conçu, très probablement, pour des ordinateurs portables immobiles. Ce décalage est à l'origine d'environ 95 % des signalements du type « le robot se comporte bizarrement aujourd'hui » que vous effectuerez. Les contrôleurs de moteurs fonctionnent correctement. Le Jetson fonctionne correctement. Le modèle sur le serveur K-AI fonctionne correctement. Le Wi-Fi, en revanche, ne fonctionne pas correctement.
Cet article traite de la seconde moitié de I01L'image à deux cases de [nom de l'entreprise] – plus précisément, le lien au milieu. Le robot que vous avez acheté ne vaut que par le réseau sur lequel vous l'avez connecté, et ce réseau a probablement besoin d'être reconstruit avant de mériter le qualificatif « correct ».
Public cible : intégrateurs, responsables de laboratoires et équipes informatiques à qui l’on a annoncé l’arrivée d’un humanoïde le mois prochain et qui n’ont pas encore réalisé que le réseau Wi-Fi d’entreprise existant va mettre tout le monde dans l’embarras.
Pourquoi la mise en réseau des robots est un problème en soi
La plupart des réseaux Wi-Fi d'entreprise sont dimensionnés pour un usage humain : téléchargements ponctuels, appels vidéo occasionnels, longues périodes d'inactivité. Un humain n'effectue aucune de ces actions. Il génère un flux duplex continu de messages de contrôle à faible débit, des rafales intermittentes de données d'image à destination du serveur d'inférence et un flux constant de données de télémétrie. Le flux de contrôle est faible (quelques kilo-octets par seconde) mais extrêmement sensible aux variations de bande passante. Les rafales d'images sont volumineuses (de plusieurs dizaines à plusieurs centaines de mégaoctets par seconde à l'état brut) et nécessitent une bande passante importante. La télémétrie est tolérante et sans intérêt pour tous.
Ce qui rend ce problème unique :
- Le nœud se déplace. Le robot franchit la limite de couverture entre deux points d'accès, et ce déplacement entraîne une perte de paquets de 50 à 500 ms selon la configuration du réseau. L'utilisateur d'un ordinateur portable ne s'en aperçoit pas. Le système de contrôle d'équilibre du robot, en revanche, pourrait le détecter.
- RF est hostile. Un laboratoire de 30 m² avec deux ingénieurs, trois ordinateurs portables, une machine à expresso avec Wi-Fi et un four à micro-ondes constitue un environnement radiofréquence parfaitement normal qui perturbera gravement la liaison d'un robot fonctionnant à 5 GHz. L'ombre portée du robot lui-même bloque le signal de manière imprévisible lorsqu'il se déplace.
- Composés d'interférence multi-robots. Deux G1 dans la même pièce et sur le même canal ne fonctionneront pas correctement. Trois posent problème. Une flotte de huit nécessite une planification rigoureuse.
- Les protocoles au-dessus de la radio sont également fragiles. La configuration DDS par défaut de ROS 2 repose sur le multicast IP pour la découverte. Or, le Wi-Fi gère mal le multicast. Cette combinaison génère des tickets « les nœuds ne peuvent pas se voir » qui ressemblent à des bogues de robots.
Ce problème est résoluble. Aucune solution n'est trouvée par défaut.
Wi-Fi 6E : l’étage actuel
Le point de départ réaliste pour un déploiement Wi-Fi en robotique en 2026 est le Wi-Fi 6E. SSID 6 GHz dédié exclusivement aux robotsPas du Wi-Fi 6. Pas du 5 GHz « on réglera ça plus tard ». 6E, 6 GHz, SSID séparé, VLAN isolé.
La raison tient à la pureté du signal radio, et non à un débit annoncé. La bande des 6 GHz est suffisamment récente pour ne pas encore être saturée par les appareils grand public. On n'y trouve ni Bluetooth, ni interférences de four à micro-ondes, ni balises émises par une imprimante vieille de 15 ans. La radio de votre robot bénéficie ainsi d'un canal propre. Ce canal propre vaut bien plus que n'importe quelle amélioration technique.
Voici à quoi ressemble le RTT réel d'un robot Wi-Fi 6E, mesuré entre le processeur du robot et le serveur d'inférence côté câblé du point d'accès :
| État | RTT typique | Jitter |
|---|---|---|
| 6 GHz, en visibilité directe, < 10 m, SSID dédié | 3 à 6 ms | |
| 6 GHz, un mur, 15 m | 5 à 10 ms | 1 à 3 ms |
| 5 GHz partagé avec le trafic de bureau | 8 à 25 ms | 5–40 ms (pics) |
| 2.4 GHz (ne faites pas cela) | 15 à 60 ms | 10 à 200 ms |
| événement d'itinérance AP-à-AP | +50–500 ms une fois | n/a |
Une liaison 6 GHz stable offre un RTT de quelques millisecondes de manière suffisamment constante pour que les nœuds ROS 2, les clients gRPC de vLLM et la téléopération soient réactifs. Le même robot, connecté à un SSID 5 GHz partagé, présentera un décalage difficile à quantifier sans mesures.
Le Wi-Fi 7 en 2026 : un soutien limité, une promesse réelle.
La principale nouveauté du Wi-Fi 7 est le fonctionnement multi-liaisons (MLO) : la radio combine simultanément deux ou trois bandes (2.4/5/6 GHz) et agrège le débit ou réplique les paquets sur les liaisons pour une meilleure fiabilité. La réduction de la latence du Wi-Fi 7 par rapport au Wi-Fi 6E est bien réelle lorsque le MLO est activé : les fournisseurs annoncent des baisses de latence de 50 à 75 %, et des mesures en laboratoire, dans des conditions contrôlées, indiquent un temps d'aller-retour (RTT) de 1.5 à 4 ms pour le Wi-Fi 7 MLO, contre 3 à 6 ms pour le Wi-Fi 6E. Des temps d'aller-retour inférieurs à la milliseconde sont parfois annoncés à des fins marketing, mais n'ont pas été reproduits sur du matériel robotique.
Le hic, c'est que la radio robotÀ partir de mi-2026, les principales plateformes humanoïdes (Unitree G1/H1, Booster T1, EngineAI PM01/SE01) seront équipées du Wi-Fi 6 ou 6E. Aucune ne propose le Wi-Fi 7 dans sa configuration de base. Installer un point d'accès Wi-Fi 7 devant un robot Wi-Fi 6E permet d'obtenir une liaison Wi-Fi 7 et une connexion avec le robot ; c'est bien, mais vous payez pour une fonctionnalité inutilisable pour le moment.
Quand le Wi-Fi 7 commencera à avoir de l'importance pour les robots :
- Lorsque le robot sera livré avec un module Wi-Fi 7 par défaut (prévu sur les plateformes de 2027).
- Lorsque le MLO peut répliquer le flux de paquets du plan de contrôle simultanément sur les bandes 5 GHz et 6 GHz, éliminant ainsi les événements d'évanouissement sur une seule bande.
- Lorsque vous déployez une flotte suffisamment importante pour que la congestion sur une seule bande de fréquence constitue le goulot d'étranglement, quelle que soit la latence.
Pour un laboratoire mono-robot en 2026 : le Wi-Fi 6E suffit. Pour le déploiement d’une flotte prévu à partir de 2027 : spécifiez dès aujourd’hui des points d’accès Wi-Fi 7 afin d’éviter de devoir racheter le réseau dans dix-huit mois.
Placement et densité des AP
Le premier réflexe est de fixer un point d'accès au plafond, dans un coin de la pièce. Résultat : une zone morte d'un demi-mètre derrière la paillasse, où le robot perd le signal précisément pendant la démonstration prévue.
Règles empiriques qui fonctionnent :
| Zone de travail | AP nécessaires | Motif Placé |
|---|---|---|
| <30 m², un seul robot | 1 | Centre du plafond, ligne de visée vers la zone de travail |
| 30–100 m², robot unique | 1-2 | Une par zone principale, avec chevauchement aux limites |
| 100–300 m², 2–4 robots | 3-4 | Un par ~50 m², 6 GHz sur des canaux non chevauchants |
| Entrepôt ouvert, plus de 1000 m² | 6 ans et plus, prévu | Étude de site obligatoire |
La visibilité directe prime sur la puissance. Un point d'accès de 30 dBm placé derrière une baie métallique offre un signal moins bon qu'un point d'accès de 20 dBm fixé au plafond, au centre de la pièce. Les robots sont de petite taille : une antenne fixée sur le torse à 1.2 m capte un environnement radiofréquence différent de celui d'un ordinateur portable posé sur un bureau à 0.7 m, et moins bon que celui d'un téléphone à 1.5 m. Points d'accès à plus de 2.5 m, robots à moins de 1.5 m, aucun obstacle de taille humaine sur le trajet du signal.
SSID dédié à la robotique. Non négociable. Le SSID du robot possède son propre VLAN, son propre profil QoS, sa propre plage DHCP et aucun trafic utilisateur. L'intégration du robot au Wi-Fi de l'équipe de développement fonctionne pendant une semaine, après quoi un stagiaire en marketing participe à une visioconférence et le robot tombe en panne.
L'ombrage corporel — le problème de l'antenne
Le torse d'un humanoïde est une structure en acier et en plastique d'environ 30 cm de large. L'antenne radio est généralement située à l'intérieur de la plaque pectorale, souvent dans le dos ou sur le côté. Lorsque le robot tourne le dos au point d'accès, son corps fait office de cage de Faraday partielle.
La perte de signal est généralement de 6 à 15 dB, selon l'emplacement de l'antenne et la présence de métal sur le torse. Cela suffit à faire basculer une liaison instable de « fonctionne bien » à « coupure toutes les quelques secondes », simplement par rotation. Les quadrupèdes sont moins affectés car leur corps est plus bas et plus plat, et l'antenne est généralement placée sur le bord du châssis, offrant une vue dégagée sur le ciel.
Ce qui aide :
- Antenne sur la tête ou les épaules, pas sur la poitrine. Certains humanoïdes destinés à la recherche permettent de déplacer ou d'ajouter une antenne externe. La plupart des modèles grand public ne le permettent pas. Renseignez-vous avant l'achat pour savoir si la fiabilité radiofréquence est une exigence de déploiement.
- Deux AP avec diversité. Avec des points d'accès situés sur des murs opposés, le robot se trouve « devant » l'un d'eux, quelle que soit son orientation. La fonction de déplacement des points d'accès gère le changement de point d'accès – maladroitement, certes, mais mieux que l'absence totale de signal.
- Antennes plus basses du côté du point d'accès. Si vos points d'accès sont fixés au plafond à 3 m et que l'antenne du robot est à 1.0 m, l'angle d'élévation est suffisamment prononcé pour que le torse bloque une grande partie du signal. Les points d'accès fixés au mur à 2 m bénéficient d'un trajet plus plat et plus facile.
Le lien : comment les équipes sérieuses se développent
Toute équipe de robotique sérieuse utilise un câble d'alimentation. La plupart n'en parlent jamais car cela nuit à l'esthétique des démonstrations « regardez, sans fil ». Quiconque effectue un véritable travail d'intégration branche le robot.
La connexion se fait via un câble USB-C, un câble Ethernet M12 X-code, ou, pour les unités de recherche, via un câble spiralé transportant l'alimentation et les données. La bande passante est de 1 Gbit/s ou plus ; la latence est de… aller-retour en moins d'une milliseconde, souvent en moins de 200 µs. C'est deux ordres de grandeur mieux que la meilleure connexion Wi-Fi.
L'intérêt du partage de connexion pendant le développement n'est pas lié à la bande passante, mais à l'élimination des variables. En cas de connexion Wi-Fi instable, impossible de déterminer si le problème vient de votre nœud ROS 2, du modèle ou de la qualité de l'air. Branchez-vous directement sur le réseau : plus besoin de connexion. Le débogage devient alors beaucoup plus simple.
| Lien | RTT typique | Jitter | Bande passante | Quand l’utiliser |
|---|---|---|---|---|
| Ethernet USB-C (1 GbE) | 0.2 à 0.5 ms | <100 µs | 1 Gbps | Développement, intégration, démonstrations fiables |
| Code X M12 (compatible 10 GbE) | 0.2 à 0.5 ms | <100 µs | jusqu'à 10 Gbps | Travail avec des capteurs à large bande passante, vidéo brute |
| Cordon ombilical enroulé (fournisseur) | 0.2 à 1 ms | <500 µs | 1 Gbps | Longues séances, puissance pendant le développement |
| Wi-Fi 6E, idéal | 3 à 6 ms | 1–2 Gbit/s efficace. | Opération sans fil | |
| Wi-Fi 7 MLO, idéal | 1.5 à 4 ms | 2–4 Gbit/s efficace. | 2027+ sans fil |
Les Unitree G1 EDU et Booster T1 sont livrés avec des configurations de connexion filaire fiables. La connexion filaire du H1 est plus délicate. Les PM01 et SE01 prennent en charge la connexion filaire pour le développement via USB-C ou Ethernet. Les quadrupèdes (Go2) sont rarement connectés filairement car leur utilisation se fait principalement en extérieur ; toutefois, si vous effectuez des travaux de réalité augmentée en intérieur, vous pourriez souhaiter le faire.
Réseaux privés 5G : quand est-ce que ça vaut le coup ?
La 5G privée — votre propre réseau cellulaire sous licence ou à spectre partagé sur site — est entrée dans le domaine des « produits concrets » en 2025 et sera déployée à grande échelle dès 2026. La technologie fonctionne.
Quand la 5G privée a du sens :
- Grands sites extérieurs. Installations de plusieurs hectares, mines, grandes exploitations agricoles, ports. Le déploiement de cellules Wi-Fi à grande échelle est impossible dans ces zones ; le nombre de points d’accès et les efforts de recensement dépassent le coût d’un seul réseau 5G à petites cellules.
- Campus multi-bâtiments. Lorsque le robot doit se déplacer entre l'intérieur et l'extérieur, ou entre bâtiments, l'itinérance Wi-Fi devient problématique. La 5G gère la mobilité nativement.
- Déploiements axés sur la mobilité. Robots d'inspection parcourant des kilomètres, robots mobiles autonomes dans de grands entrepôts, tout ce qui nécessite que la liaison radio suive l'unité à travers le territoire.
- Flotte mixte comprenant d'autres actifs 5G. Si le site dispose déjà d'un réseau 5G privé pour les chariots élévateurs, les AGV ou les réseaux de capteurs, l'ajout de robots représente un coût supplémentaire et non un nouveau projet.
Quand c'est excessif :
- Un seul laboratoire, un seul bâtiment, un à quatre robots. Le Wi-Fi 6E remplit cette fonction pour 3 000 à 8 000 € de points d'accès. La 5G privée, quant à elle, coûte entre 60 000 et 200 000 € en petites cellules, en EPC/5GC, en licences de spectre et en collaboration avec un fournisseur. Ce rapport est déséquilibré.
- Environnements de développement purs. Le partage de connexion et le Wi-Fi vous offrent tous les avantages de la 5G, sans rien de plus à gérer.
- Vous n'avez pas d'équipe réseau. La 5G privée n'est pas un système « à installer et à oublier ». Il s'agit d'un système de production supplémentaire à exploiter, à surveiller et à mettre à jour.
Le budget de latence : quelles charges de travail peuvent supporter quoi
| Charge de travail | RTT tolérable | Fréquence tolérable du P99 | Implications pour le transport |
|---|---|---|---|
| Commande locale du moteur (500 Hz–1 kHz) | n/a — local | n/a | À bord, jamais en réseau |
| Réflexe de réaction à l'obstacle | Local, jamais réseau | ||
| Manipulation en boucle fermée (retour de force) | Partage de connexion ou Wi-Fi 7 MLO | ||
| Planification de la prise en main axée sur la vision | 20 à 50 ms | Wi-Fi 6E acceptable | |
| Description de la scène VLM | 100 à 500 ms | Wi-Fi 6E ou 5G | |
| Dialogue LLM | 500 à 2000 ms | Tout fonctionne, même le WAN | |
| Télémétrie, surveillance, mises à jour du modèle | secondes | sans bornes | Tout, y compris les téléphones portables |
La tendance est claire : les tâches en boucle fermée s’effectuent en local ou via un câble, la perception et la réflexion peuvent utiliser le Wi-Fi, et la conversation un réseau étendu (WAN). L’erreur architecturale consiste à placer du code adjacent à la boucle moteur sur un chemin susceptible de subir des fluctuations du réseau. L’autre erreur est de payer pour un transport de 5 ms alors que la latence du modèle est de 400 ms ; vous avez ainsi économisé 30 ms sur un total de 430 ms. Il faut optimiser le terme dominant.
Le modèle « toujours un pied dans les nuages »
Même dans une configuration sur site, le robot est rarement totalement isolé du réseau. Voici quelques éléments qui nécessitent légitimement une connexion WAN :
- Télémétrie vers votre propre infrastructure de surveillance (Prometheus / Grafana / Datadog). Utile, faible consommation de bande passante, compatible avec tous les temps de latence.
- Mises à jour du modèle et du micrologiciel. Mise à jour des poids VLM, des images de conteneurs et des correctifs du système d'exploitation. Opération par à-coups, pouvant être effectuée la nuit.
- Données cartographiques et environnementales. Plan d'étage, synchronisation du nuage de points, sauvegarde de la mémoire de la scène.
- Solution de repli pour les opérations téléopérées à distance. Parfois ; sous réserve d'un examen de sécurité.
Le modèle est Priorité au trafic sur site pour le chemin chaud, pare-feu de sortie WAN pour le chemin froid. Le robot n'a jamais besoin d'une adresse WAN entrante. Le serveur non plus. Uniquement des connexions sortantes, vers les destinations autorisées, TLS, sans exception.
Multicast, mDNS, DDS : et pourquoi le Wi-Fi les rend problématiques
ROS 2 est fourni avec DDS comme intergiciel par défaut. DDS utilise la multidiffusion IP pour la découverte des participants. Le Wi-Fi gère la multidiffusion en transmettant au débit commun le plus bas à tous les clients du BSSID, ce qui :
- Gaspillage de temps d'antenne.
- Il semblerait qu'il y ait une inondation du firmware du point d'accès.
- Souvent, cette fonctionnalité est bloquée par les points d'accès d'entreprise dont la suppression du multicast est activée.
Le résultat est que « mes nœuds ROS 2 peuvent communiquer entre eux via Ethernet, mais pas via Wi-Fi » — un problème bien connu et parfaitement évitable. La perte de paquets Wi-Fi mesurée pour le trafic multicast ROS 2 se situe entre 1 et 3 %, même sur des liaisons performantes ; elle est nulle sur Ethernet. Deux robots ROS 2 connectés au même réseau Wi-Fi peuvent générer des tempêtes de découverte qui déstabilisent le point d'accès.
Les solutions, par ordre de préférence :
- Utilisez le serveur de découverte Fast-DDS. Lancez un serveur de découverte (généralement sur le serveur d'inférence ou une VM dédiée), orientez tous les nœuds ROS 2 vers celui-ci via unicast, et la découverte devient un flux client-serveur normal que le Wi-Fi gère parfaitement.
- Configuration statique des pairs via un profil XML. Intégrer en dur l'adresse IP de l'autre côté. Solution fragile, mais fonctionnelle pour une paire fixe.
- Activez l'écoute IGMP et la conversion multicast-vers-unicast sur le point d'accès. Aruba, Ruckus, Cisco Meraki et les dernières versions du firmware UniFi prennent tous en charge cette fonctionnalité. Signalez-le à l'ingénieur réseau ; il suffit de cocher deux cases.
- Implémentation du commutateur RMW. Certains utilisateurs passent de Cyclone DDS à Fast-DDS ou à Zenoh-bridge précisément pour éviter la complexité de la découverte multicast. C'est une solution de dernier recours ; cela représente un coût d'intégration.
QoS, DSCP et priorisation
Le SSID du robot possède son propre VLAN ; ce VLAN dispose de son propre profil QoS. L'étape suivante consiste à s'assurer que le réseau considère le trafic du robot comme prioritaire par rapport à la synchronisation Dropbox de l'équipe marketing.
Modèle standard :
- Le trafic de contrôle des robots est marqué DSCP comme EF (transfert accéléré, DSCP 46). Le flux du plan de contrôle est petit et critique en termes de latence ; EF est la classe de référence pour cela.
- Flux d'images marqués AF41 (DSCP 34). Vidéo en temps réel, débit élevé, priorité inférieure à celle du contrôle.
- Télémétrie et récupération de modèles marquées par défaut (DSCP 0). Aucun traitement de faveur.
- Le mappage AP WMM doit respecter le marquage. La plupart des points d'accès d'entreprise (Aruba, Cisco Meraki, Ruckus) le font automatiquement lorsque la confiance DSCP est activée. UniFi nécessite une configuration explicite dans les versions récentes du firmware.
Architecture réseau concrète pour un laboratoire de robotique
Une configuration fonctionnelle pour un laboratoire de 1 à 4 robots, calibrée selon les normes en vigueur. I01 réalité matérielle :
QoS, surveillance IGMP
Réseau du laboratoire de référence : robots → points d’accès dédiés 6 GHz → commutateur 10 GbE → serveur K-AI. Pare-feu de sortie uniquement.
Pour 1 à 4 robots dans une même pièce, le coût des équipements réseau varie entre 4 000 et 12 000 € selon le fournisseur. Ruckus et Aruba offrent les meilleures performances RF dans les environnements denses ou difficiles. Cisco Meraki privilégie la simplicité, mais engendre des coûts récurrents plus élevés. UniFi est le plus abordable et convient parfaitement à une utilisation en laboratoire.
Modes de défaillance, plus ou moins dans l'ordre où ils se produisent
- L'itinérance des points d'accès interrompt le flux. Le robot franchit la limite d'une cellule, la connexion est interrompue pendant 100 à 400 ms, le socket ROS 2 se rétablit, mais une interruption du flux de contrôle apparaît dans les journaux. Pour atténuer ce problème, il est recommandé d'utiliser des cellules qui se chevauchent, le roaming rapide 802.11k/v/r et de ne pas dépendre du réseau pour le contrôle en boucle fermée.
- Interférences entre plusieurs robots sur les canaux partagés. Trois G1 utilisant le même canal 6 GHz interfèrent entre eux. Prévoyez des canaux de 80 MHz non chevauchants dans la bande 6 GHz (sept en Europe, davantage aux États-Unis).
- Structure du bâtiment. Les murs en béton armé atténuent le signal de 20 à 30 dB. Les portes en acier des salles serveurs l'atténuent de 40 dB. Effectuez systématiquement une étude de site RF avant d'installer des points d'accès.
- Expiration du bail DHCP en cours de tâche. Session robot de longue durée, échec du renouvellement DHCP, changement d'adresse IP, interruption des sockets. Réservations DHCP statiques pour le robot. Toujours.
- Modes d'économie d'énergie. L'économie d'énergie Wi-Fi sur la radio du robot augmente la latence pour préserver l'autonomie de la batterie. Désactivez-la explicitement. L'autonomie de la batterie dépend de celle-ci ; ne la sacrifiez pas au profit d'une latence accrue.
- Incompatibilité MTU. Le kit de développement logiciel du fournisseur de robots utilise une MTU de 1 500 Mo, votre infrastructure en utilise 9 000 Mo ; une fragmentation se produit et les performances chutent silencieusement. Assurez-vous que la MTU de bout en bout corresponde.
Le point de vue honnête
La phrase la plus utile de cet article : 95 % des « problèmes de robots » signalés au cours du premier mois de déploiement sont des problèmes de configuration Wi-Fi. Le robot fonctionne correctement. Le modèle fonctionne correctement. Le Wi-Fi, en revanche, ne fonctionne pas correctement : le SSID est partagé avec le bureau, il n’y a pas de VLAN dédié, le multicast est omniprésent, les points d’accès sont mal placés et l’intégrateur s’attarde sur le mauvais problème depuis trois semaines.
Embauchez le spécialiste réseau au plus tôt. Rémunérez-le mieux que prévu. Un ingénieur réseau senior capable de concevoir un plan Wi-Fi 6E, de configurer la QoS de bout en bout et d'optimiser la découverte DDS vaut autant qu'un roboticien senior sur ce projet et est beaucoup plus difficile à trouver.
Que faire ensuite ? – Liste de vérification pour la configuration du réseau
Avant l'arrivée du robot :
- Parcourez le site. Identifiez la zone de travail, les points de montage des points d'accès, le cheminement des câbles et les sources évidentes d'interférences radiofréquences. Procédez par étapes.
- Spécifiez les points d'accès Wi-Fi 6E, au moins un par 50 m² de zone de travail, en visibilité directe avec l'endroit où se trouvera le robot.
- Définir un SSID dédié à la robotique sur son propre VLAN, 6 GHz uniquement, itinérance rapide activée, filtre de diffusion activé, multidiffusion vers monodiffusion activée.
- Planifiez la partie câblée. Liaison 10 GbE entre le point d'accès et le commutateur du serveur d'inférence. Aucun lien 1 GbE n'est présent sur le chemin critique.
- Réserver de manière statique l'adresse IP du robot et celle du serveur. Aucune surprise concernant le DHCP.
- Configurer la confiance DSCP Sur le commutateur et le point d'accès. Marquer le plan de contrôle EF, vidéo AF41.
- Configurer le serveur de découverte Fast-DDS avant l'expédition du robot, pas après.
Le jour où le robot arrive :
- Attachez d'abord. Branchez le robot via USB-C / M12 et vérifiez que le chemin d'inférence fonctionne sur le câble avant d'ajouter la radio.
-
Effectuer un test RTT de référence (
pinget une petite boucle d'écho gRPC) via le câble. Notez les chiffres. Ils correspondent à votre étage. - Passez au Wi-Fi 6E. Comparez le RTT. S'il est supérieur à 3 fois la valeur de référence du câble, la radio n'est pas correctement configurée.
- Faites marcher le robot. Errance, ombres portées, zones mortes. Repérez les endroits dangereux avant qu'ils ne vous nuisent.
Le premier mois :
- Regardez P99 RTT, ce n'est pas méchant. Alarme sur les épines de la queue.
- Effectuer un nouveau relevé après toute modification du bâtiment. Nouveau rack, nouveau mur, nouveau voisin du dessus avec son propre réseau Wi-Fi 7 mesh — tout cela peut modifier votre niveau de référence RF.
- Conservez le kit de connexion au laboratoire. En cas de problème, commencez par brancher l'appareil. Éliminez la radio comme cause possible avant d'incriminer le modèle.
Ceci fait partie du Kentino Wiki, une série de référence sur l'intelligence artificielle, la robotique et les systèmes qui les connectent. Commentaires et corrections bienvenus. info@kentino.com.