ROS 2 sur maillage sans fil : paramètres de qualité de service DDS pour les équipes de robots mobiles

Les équipes de robots mobiles communiquent souvent de manière fiable dans un laboratoire, puis développent des commandes retardées, des mises à jour de capteurs manquantes ou une récupération lente lorsque les itinéraires du maillage changent. UN Le maillage sans fil ROS 2 ajoute des fluctuations de bande passante, des pertes de paquets et des changements dans le nombre de sauts, tandis que DDS peut retransmettre ou mettre en file d'attente des données déjà obsolètes. Les paramètres de QoS permettent de contrôler la fiabilité, l'historique, la profondeur, la durabilité, le délai et la durée de vie de chaque sujet, mais des politiques d'éditeur et d'abonné incompatibles peuvent interrompre complètement la diffusion.

La clé est de savoir quels flux ont besoin de chaque échantillon, lesquels n’ont besoin que du plus récent, et comment empêcher des charges utiles volumineuses de surcharger un lien de récupération.

Commencez par le trafic, pas le menu QoS

Décidez si la fraîcheur ou l’exhaustivité compte plus

Commencez par demander ce qui se passe lorsqu’un message est perdu et ce qui se passe lorsqu’il arrive en retard. Les scans LiDAR, les images de caméra, l'odométrie, les mises à jour de localisation et la télémétrie de mouvement sont continuellement remplacés. La perte d’un échantillon peut être acceptable, tandis que sa livraison après plusieurs échantillons plus récents peut corrompre les décisions locales ou faire perdre du temps de traitement.

Les transitions de mission, les affectations de tâches, les changements de configuration, les événements de sécurité et certains transferts de cartes ont des exigences différentes. Un événement discret manquant peut laisser les robots dans des états de fonctionnement incohérents, une retransmission limitée peut donc être justifiée. Cette distinction importe plus que le seul type de charge utile : une petite commande de vitesse peut être dangereuse lorsqu'elle est obsolète, tandis qu'un grand instantané de carte peut rester utile après un certain temps.

La classification du trafic par fraîcheur et exhaustivité évite une erreur courante de maillage sans fil ROS 2 : définir chaque sujet sur FIABLE, car fiable semble plus sûr. Un DDS fiable conserve les échantillons sans accusé de réception et retransmet les données manquantes, créant ainsi une surcharge que la communication au mieux évite. Le profil de données de capteur ROS 2 standard utilise donc la fiabilité au mieux avec une file d'attente plus petite, où la livraison en temps opportun compte généralement plus que la réception de chaque lecture.

Attribuez à chaque sujet un budget de diffusion

Chaque sujet inter-robot nécessite quatre limites : l'ancienneté maximale des messages utiles, le taux de perte acceptable, la fréquence de mise à jour requise et le temps de récupération maximal après déconnexion. Ces limites transforment des attentes vagues telles que « faible latence » en exigences testables. Un flux de commandes peut nécessiter une limite d'âge mesurée en dizaines de millisecondes, tandis qu'un instantané de carte peut tolérer quelques secondes si le robot continue de fonctionner en toute sécurité avec sa copie locale.

Estimez la charge proposée à partir de la taille de la charge utile sérialisée, du taux de publication et du nombre de destinations. Comparez ensuite ce chiffre avec le débit multi-sauts mesuré plutôt qu'avec le débit de données nominal d'une radio. Laissez de la capacité pour les accusés de réception, les retransmissions, le trafic de découverte, le trafic de gestion des itinéraires et les éditeurs simultanés.

Gardez le trafic interne du robot hors du maillage partagé

Tous les sujets ROS 2 ne devraient pas dépasser les limites des robots. Les flux bruts de caméra, les nuages ​​de points complets, les données de débogage et les sorties de perception intermédiaire appartiennent souvent au robot qui les produit. La publication uniquement des détections, des suivis d'objets, des plans locaux, des nuages ​​réduits ou des modifications de cartes réduit la demande de canal partagé sans modifier le comportement du DDS.

Cette étape de filtrage est particulièrement utile dans un maillage sans fil ROS 2 multi-robots, où un flux à haut débit inutile peut consommer la capacité nécessaire à plusieurs sujets de coordination. La suppression du trafic produit généralement un système plus prévisible que la tentative de protéger un lien surchargé avec des files d'attente plus longues et des tentatives supplémentaires.

Profils QoS pratiques pour les sujets courants de la flotte

Flux de capteurs et état fréquemment actualisé

Les sujets relatifs aux capteurs et aux états à haut débit nécessitent généralement l'échantillon disponible le plus récent, et non une séquence historique complète. Un profil de départ pratique est BEST_EFFORT, VOLATILE et KEEP_LAST avec une profondeur comprise entre un et cinq. La première profondeur convient aux données qui sont immédiatement remplacées, tandis qu'une file d'attente légèrement plus grande peut absorber de courts délais de planification de rappel sans créer un long retard.

LIFESPAN peut ajouter une autre protection en provoquant l'expiration des messages après leur période d'utilité. DEADLINE a un objectif différent : il exprime l'intervalle attendu entre les messages et peut déclencher un événement lorsque cette attente n'est pas respectée. Aucune des deux politiques n’augmente la capacité des liaisons, mais les deux facilitent la détection et la gestion des flux obsolètes ou interrompus.

Le profil exact doit refléter le consommateur. Un nœud local d'évitement d'obstacles peut nécessiter des analyses fréquentes avec un âge minimal, tandis qu'un tableau de bord de flotte peut accepter un taux de mise à jour plus faible. L’envoi des deux via le même maillage sans fil ROS 2 ne signifie pas qu’ils nécessitent des paramètres de fiabilité, de profondeur ou de durée de vie identiques.

Les événements de commandement et de coordination nécessitent un traitement différent

Les commandes continues et les événements de coordination discrets ne doivent pas partager un seul profil par défaut. Les flux de vitesse, de direction et de correction de formation sont actualisés à plusieurs reprises, de sorte que les anciens échantillons ne doivent pas faire la queue derrière les retransmissions. Un historique superficiel, une courte durée de vie et un délai d'expiration au niveau de l'application permettent de garantir qu'un robot s'arrête ou entre dans un mode de repli défini lorsque de nouvelles commandes disparaissent.

L'acceptation des tâches, les changements de mode de fonctionnement et les transitions de mission peuvent nécessiter une livraison FIABLE, car chaque événement change d'état partagé. Même alors, l’histoire doit rester limitée. Rejouer une longue séquence de commandes remplacées après la récupération d'un itinéraire peut être plus nuisible que de signaler l'interruption et de resynchroniser l'état actuel de la mission.

La fiabilité DDS n’est qu’un niveau de protection. Chaque robot mobile doit appliquer un comportement d'expiration de commande locale, de contraintes de mouvement et de perte de communication indépendamment du réseau. Un maillage sans fil ROS 2 peut améliorer la portée et la résilience du routage, mais il ne peut pas décider si une ancienne commande est toujours sûre.

Cartes, configuration et robots à rejoindre tardivement

Utilisez RELIABLE avec TRANSIENT_LOCAL lorsqu'un robot qui rejoint ou se reconnecte a besoin de l'état publié le plus récent. Les cartes actuelles, les barrières géographiques, les modes de fonctionnement partagés et les instantanés de configuration correspondent souvent à ce modèle. KEEP_LAST(1) est généralement plus approprié que de conserver chaque version, car seul l'instantané complet le plus récent reste pertinent sur le plan opérationnel.

KEEP_ALL doit être réservé aux données dont la séquence complète est réellement importante et dont les besoins en ressources sont connus. Le stockage Keep-All reste soumis aux limites de ressources du middleware, il ne s'agit donc pas d'une garantie illimitée. La durabilité transitoire-locale rend également l'éditeur responsable de la conservation des échantillons pour les abonnements tardifs.

La compatibilité doit être vérifiée des deux côtés. Un éditeur faisant de son mieux ne peut pas satisfaire un abonné fiable, et un éditeur volatile ne peut pas satisfaire un abonnement local temporaire. Les éditeurs fiables peuvent servir les abonnés au mieux, tandis que les éditeurs locaux transitoires peuvent envoyer de nouveaux messages aux abonnés volatiles. La livraison historique conservée nécessite des paramètres locaux transitoires compatibles.

Empêchez les messages volumineux de prendre le contrôle du lien

Réduire la fragmentation avant d'ajouter des tentatives

Les images, les grilles d'occupation et les nuages ​​de points denses sont divisés en plusieurs unités de transport avant de traverser le réseau. Lorsqu'un datagramme UDP volumineux est fragmenté au niveau de la couche IP, la perte d'un fragment empêche la reconstruction du datagramme complet. Les fragments restants peuvent occuper les tampons du noyau jusqu'à leur expiration, ce qui donne l'impression que la connexion est bloquée et bloque le trafic plus récent.

La dégradation d'une charge utile importante sur les connexions sans fil ROS 2 est généralement associée à trois mécanismes connectés : une fragmentation IP excessive, un timing de retransmission inefficace et des salves de tampon congestionnées. Les modifications des paramètres DDS compatibles avec les normes peuvent réduire ces effets sans nécessiter un protocole d'application différent.

Mesurez le MTU du chemin réel sur l'ensemble du maillage sans fil ROS 2, y compris le chiffrement, les tunnels, les interfaces virtuelles et chaque segment acheminé. Lorsque la configuration du transport le permet, réduisez suffisamment la taille du message RTPS ou UDP pour éviter la fragmentation de la couche réseau. Une valeur calculée à partir d'une MTU Ethernet de 1 500 octets n'est qu'une hypothèse de départ, car les en-têtes et l'encapsulation peuvent réduire la taille utilisable.

Gardez les files d'attente d'historique plus petites que la fenêtre de récupération

Lors d'une interruption de route, un éditeur fiable peut continuer à produire des messages tandis que les accusés de réception cessent d'arriver. Les échantillons non reconnus s'accumulent dans l'historique jusqu'à ce que les limites des ressources soient atteintes. Lorsque la connectivité revient, le chemin restauré doit transporter les publications actuelles, contrôler le trafic et le retard conservé en même temps.

Choisissez la profondeur de l'historique parmi le nombre d'échantillons qui restent utiles après reconnexion. Un flux d'état à 20 Hz avec une durée utile de 250 millisecondes a rarement besoin de dizaines d'échantillons en file d'attente ; la plupart d’entre eux seraient déjà obsolètes. L'état remplaçable doit privilégier le dernier échantillon, tandis que les séquences d'événements essentiels nécessitent un plan de récupération limité.

Les grands échantillons fiables nécessitent une vérification supplémentaire : la route attendue la plus faible peut-elle drainer la file d'attente sans retarder le trafic actuel ? Un historique approfondi peut réduire la perte de données immédiate, mais il augmente également l'utilisation de la mémoire, le temps de récupération et la probabilité d'une augmentation du trafic après une panne. Un historique conservé excessif peut produire des salves de mémoire tampon qui aggravent la congestion après le retour de la connectivité.

Surveillez les rafales de retransmission

Reliable DDS utilise des échanges de battements de cœur et d’accusé de réception pour identifier les échantillons manquants et déclencher la retransmission. Des cycles de récupération peu fréquents peuvent permettre à plusieurs pertes de s'accumuler avant qu'elles ne soient renvoyées, produisant de courtes rafales qui dépassent la capacité momentanée de la liaison. Les périodes de battement de cœur, la fragmentation et les intervalles de retransmission interagissent également étroitement dans des conditions sans fil avec perte.

Testez le timing de retransmission par rapport à l'intervalle de publication de chaque sujet au lieu d'appliquer une valeur à l'ensemble du parc. Mesurez le délai de récupération, la latence de queue, la gigue, la surcharge des paquets de contrôle et la charge du processeur après chaque modification. Une signalisation de récupération plus rapide peut réduire le délai et la taille des rafales, mais un trafic de contrôle excessif peut consommer du traitement et de la bande passante.

Aucun ajustement de synchronisation ne peut sauver un maillage sans fil ROS 2 dont la charge soutenue offerte dépasse la puissance utilisable. Lorsque le lien reste saturé, les nouvelles tentatives ajoutent du trafic à un chemin déjà surchargé.

Décidez quand modifier la charge utile à la place

Le réglage de la QoS devrait s'arrêter là où l'architecture des applications devient le problème le plus important. Réduisez la résolution de l’image, la qualité d’encodage ou la fréquence d’images lorsque les flux visuels dominent le canal. Recadrez ou sous-échantillonnez les nuages ​​de points avant la transmission et publiez des traces d'objets, des résultats de traversabilité ou des mises à jour de cartes locales lorsque les coéquipiers n'ont pas besoin d'observations brutes.

Le traitement des bords constitue souvent la solution la plus propre. Chaque robot peut conserver localement les données des capteurs à large bande passante et distribuer uniquement les informations nécessaires à la coordination. Il ne s'agit pas d'un compromis sur la fiabilité du DDS ; il s'agit d'une décision délibérée visant à adapter la demande de communication à la capacité physique du réseau mobile.

Testez le profil sur des robots en mouvement, pas seulement sur un réseau de bancs

Recréez les itinéraires et les échecs que la flotte rencontrera

Un test fixe à un saut ne peut pas représenter un maillage sans fil mobile ROS 2. La validation doit inclure l'itinéraire le plus court, le nombre maximum de sauts planifiés, les mouvements entre les positions de relais, les interférences croissantes, le trafic asymétrique, les pannes courtes, les pannes longues, la reconnexion, la connexion tardive et la publication simultanée par plusieurs robots.

Enregistrez une latence supérieure à la moyenne. Les mesures utiles incluent :

●  Fréquence de mise à jour reçue et taux de perte de messages.

●  Âge du message, latence médiane, latence de queue et gigue.

●  Temps de découverte ou de reconnexion après un changement de chemin.

●  Croissance de la file d'attente des écrivains et des lecteurs pendant une interruption.

●  Temps requis pour effacer les données utiles conservées.

●  Utilisation du processeur et de la mémoire par les éditeurs et les abonnés.

Évaluez chaque résultat par rapport au budget de livraison créé précédemment. Une rubrique de localisation peut échouer parce que sa fréquence de mise à jour tombe en dessous des exigences de contrôle, même lorsque chaque échantillon finit par arriver. À l’inverse, un transfert de carte peut réussir malgré une latence plus élevée s’il se termine dans la fenêtre de récupération autorisée.

Utiliser la télémétrie maillée pour expliquer le comportement du DDS

Les métriques ROS 2 révèlent ce que l'application expérimente, tandis que la télémétrie maillée aide à expliquer pourquoi cela s'est produit. Comparez les performances des sujets avec le nombre de sauts, les changements de topologie, la force du signal, le rapport signal/bruit, le trafic de téléchargement et de téléchargement et la synchronisation des changements de route. La corrélation des deux couches empêche les équipes de blâmer la QoS pour un changement de chemin radio ou de blâmer le maillage pour des paramètres d'éditeur et d'abonné incompatibles.

Les modules OEM/ODM WDS MIMOmesh et les unités aéroportées légères utilisent une architecture tout IP avec un routage dynamique distribué et sans centre et des modes de relais multi-sauts. Leurs fonctions de gestion de réseau fournissent des informations sur la topologie, l'intensité du champ, le SNR, le trafic, la distance des nœuds et l'état de fonctionnement que les ingénieurs peuvent comparer avec la latence, la perte et le comportement de la file d'attente de ROS 2.

Les débits de données des produits et les chiffres de retard sur un seul saut doivent rester des références de planification plutôt que des performances d'application garanties. Le comportement réel de bout en bout inclut également la profondeur du routage, l'occupation des canaux, la récupération des paquets, la sérialisation, les files d'attente du middleware et le traitement des nœuds. Dans un en déplaçant le maillage sans fil ROS 2 , la bonne puissance mesurée sur la route opérationnelle la plus faible devrait déterminer les taux de publication et les limites de l'historique.

Changer une variable à la fois

Commencez par confirmer les noms des sujets, les types de messages et la compatibilité QoS. Testez la découverte séparément du transfert de données, car un nœud qui ne découvre jamais son homologue connaît un échec différent de celui d'un point de terminaison correspondant perdant des paquets. Les événements de qualité de service incompatible peuvent aider les applications à détecter les incohérences de stratégie plutôt que de laisser l'échec inexpliqué.

Établissez un itinéraire et un modèle de mouvement reproductibles, puis ajustez une variable par course. Modifiez indépendamment la fiabilité, la profondeur, la durabilité, la durée de vie, le taux de publication, la taille de la charge utile ou le seuil de fragmentation. Répéter le même scénario permet d'identifier si une amélioration apparente vient du changement de QoS ou d'un meilleur chemin radio.

Définissez les conditions de réussite avant le test. Les exemples incluent un âge de commande maximum, une fréquence de localisation minimale, un temps maximum pour qu'un robot se reconnectant reçoive la carte actuelle et une limite sur le temps de vidange du retard. Le profil final doit passer par l'itinéraire réaliste le plus faible, et pas seulement fournir des moyennes impressionnantes sur le banc d'essai.

 

Conclusion

Une communication fiable avec la flotte dépend de l'adéquation du comportement du DDS à l'objectif de chaque sujet. Les nouveaux flux de capteurs nécessitent généralement des files d'attente peu profondes, tandis que les événements de mission et la reconnexion des robots peuvent nécessiter une fiabilité limitée ou une durabilité locale transitoire. La fragmentation, la croissance du backlog et la mesure du goodput multi-sauts devraient façonner le profil final.

Pour les équipes qui construisent un maillage sans fil ROS 2, Shenzhen Sinosun Technology Co., Ltd. propose des modules MIMOmesh OEM/ODM et des radios aéroportées légères pour les déploiements mobiles à plusieurs sauts. Associées à des tests QoS rigoureux, ces plates-formes peuvent contribuer à réduire le trafic obsolète, à raccourcir la récupération et à maintenir la bande passante partagée concentrée sur les données utiles sur le plan opérationnel.

 

FAQ

Q : ROS 2 est-il adapté à la communication sans fil entre plusieurs robots ?

R : Oui, mais les liaisons sans fil nécessitent des paramètres QoS spécifiques à un sujet. La fiabilité, la profondeur de la file d'attente, la durabilité et le taux de charge utile doivent refléter la perte de paquets, la latence, la mobilité et la bande passante disponible.

Q : Quel paramètre de fiabilité QoS fonctionne le mieux sur un maillage sans fil ROS 2 ?

R : Faites de votre mieux pour obtenir des flux de capteurs fréquemment actualisés et une livraison fiable et limitée des commandes, des événements de mission, des cartes ou des données de configuration à ne pas manquer.

Q : Pourquoi les éditeurs et les abonnés ROS 2 ne parviennent-ils parfois pas à se connecter ?

R : Des politiques QoS incompatibles peuvent empêcher la communication. Les inadéquations courantes concernent les paramètres de fiabilité, de durabilité, de délai ou de vivacité entre le profil proposé par l'éditeur et le profil demandé par l'abonné.

Q : Comment les messages LiDAR ou caméra volumineux doivent-ils être traités sur un réseau maillé ?

R : Réduisez la taille de la charge utile, évitez la fragmentation IP, limitez les taux de publication et réduisez les files d'attente. Le traitement local ou les sorties compressées fonctionnent souvent mieux que la transmission de chaque échantillon brut du capteur.

Q : Quelle profondeur d’historique les équipes de robots mobiles doivent-elles utiliser ?

R : Choisissez la profondeur en fonction de la durée de vie du message et des besoins de récupération. Utilisez la profondeur un pour l'état remplaçable, tandis que les événements essentiels peuvent nécessiter une file d'attente plus grande mais strictement délimitée.