Comprendre le traitement des données en temps réel avec ROS2

Le Robot Operating System 2 (ROS2) est devenu le cadre standard pour la construction de systèmes robotiques de qualité de production qui nécessitent une communication déterministe et à faible latence. Le traitement des données en temps réel est essentiel dans des applications telles que la conduite autonome, la manipulation industrielle et les drones aériens, où l'absence d'une date limite peut causer une défaillance du système. ROS2 répond à ces défis par son architecture modulaire d'éditeur-abonné, appuyée par le middleware Data Distribution Service (DDS).

Architecture de base : Noeuds, sujets, services et actions

Le paradigme de communication ROS2 , repose sur quatre abstractions clés :

  • Noeuds Dans les systèmes en temps réel, chaque noeud fonctionne généralement dans son propre processus, fournissant une isolation de mémoire et permettant au concepteur de système d'attribuer des affinités CPU et des politiques de programmation par noeud.
  • Thèmes Les producteurs de données publient sur un sujet nommé, et les consommateurs s'abonnent pour recevoir des messages. Le middleware DDS gère la découverte, la sérialisation et le transport, permettant l'ajout ou la suppression de nœuds au moment de l'exécution sans reconfiguration.
  • Services Les services sont utiles pour les modifications de configuration ou les mises à jour de paramètres qui ne nécessitent pas de délais difficiles.
  • Actions étendre les services pour des objectifs de longue durée avec des retours périodiques, adaptés à des tâches comme le point de navigation, après quoi un statut intermédiaire est nécessaire.

Pour les applications en temps réel, le modèle de publication-abonnement basé sur des sujets est le choix le plus courant car il supporte la communication découplée et peut être accordé pour une livraison déterministe via les paramètres de qualité de service DDS.

Configuration ROS2 pour le traitement des données en temps réel

Installation et sélection DDS

Commencez par installer une distribution ROS2 récente, comme Bec-de-Bucle, Iron Irwiniou Roulements sur un système d'exploitation qui prend en charge l'horaire en temps réel — Linux avec un patch noyau en temps réel, QNX ou VxWorks. L'implémentation DDS par défaut (Fast DDS) fonctionne bien pour de nombreux systèmes, mais pour des exigences strictes en temps réel envisager des alternatives:

  • Cyclone DDS – Connu pour la faible latence et une grande évolutivité; utilisé dans les systèmes de production autonome de véhicules.
  • RTI Connext Pro – Un DDS commercial offrant une programmation avancée en temps réel, des fonctions de sécurité et une mémoire partagée à copie zéro.
  • DDS rapide – L'option par défaut ; les versions récentes incluent un transport de mémoire partagée avec faible jitter.

Après l'installation, configurer le domaine DDS et les paramètres par défaut de QoS pour correspondre aux exigences de synchronisation de votre application. Définissez la variable d'environnement pour isoler votre système des autres réseaux ROS2. Ajustez le fichier de configuration DDS (par exemple, pour Fast DDS ou pour Cyclone DDS) pour activer le transport de mémoire partagée et définir les priorités de thread.

Amandes en temps réel et calendrier des processus

Pour atteindre un calendrier déterministe, il faut exécuter votre boucle de contrôle robotisée avec une priorité élevée.

  1. Installez un noyau en temps réel – pour Ubuntu, utilisez . Sinon, appliquez le correctif PREEMPT RT à votre noyau.
  2. Modifier pour permettre à votre utilisateur de définir des priorités en temps réel, par exemple: .
  3. Affecter des politiques de planification en temps réel à vos nœuds ROS2 en utilisant ou l'appel . Typiquement, avec une priorité de 80–95 fonctionne bien pour les boucles de contrôle.

Pour une isolation avancée, utilisez le paramètre de démarrage du noyau pour réserver les cœurs CPU pour les tâches en temps réel, puis pincez chaque nœud dans des fils dédiés en utilisant ou . Cela empêche les interférences des processus non-temps et les interruptions.

Développement de nœuds de données en temps réel

Principes de conception des nœuds

L'écriture de nœuds en temps réel dans ROS2 nécessite une attention particulière à l'utilisation des ressources à l'intérieur des callbacks :

  • Éviter l'allocation dynamique de la mémoire utiliser des tampons pré-allotés et éviter , , ou des opérations de conteneurs STL comme qui peuvent causer une fragmentation de tas. Si l'allocation dynamique est inévitable, effectuer pendant l'initialisation des nœuds, pas dans le chemin chaud.
  • Garder les rappels courts et déterministes. Le traitement complexe devrait être déchargé vers un thread ou un exécuteur distinct, avec des callbacks relégués à l'analyse des données et à la publication de nouveaux sujets.
  • Utiliser l'exécuteur approprié. La mémoire pré-allotise pour tous les minuteurs et abonnements, fournissant une programmation de rappel prévisible. Pour les nœuds multi-threadés, appliquer avec un nombre fixe de threads. Éviter la par défaut pour les nœuds critiques dans le temps parce qu'elle ne garantit pas l'ordre déterministe.

En outre, envisager d'utiliser le ROS2 exécuteur en temps réel supporté (disponible en fer et plus tard) qui respecte les priorités du thread et évite l'inversion de priorité lors de l'exécution du callback.

Mise en œuvre de politiques de qualité des services

Les politiques ROS2 QoS sont le principal outil pour faire respecter le comportement en temps réel. Les principales politiques pour le traitement des données en temps réel sont les suivantes:

  • Fiabilité: Réglé sur pour une livraison garantie des commandes critiques; utiliser pour les données de capteur où les gouttes occasionnelles sont tolérables mais la latence minimale est essentielle.
  • Durabilité: pour les données de capteur transitoire; pour les informations d'état persistant comme les données de carte.
  • Délai: Exige qu'un message soit reçu dans une durée spécifiée. Si l'éditeur ne respecte pas la date limite, le middleware alerte les abonnés. Ceci est vital pour les boucles de contrôle qui nécessitent des données à un taux fixe (par exemple, tous les 10 ms).
  • Budget de la latence: Indique au middleware le délai de bout en bout acceptable. Les implémentations DDS optimisent le transport en conséquence, par exemple en utilisant la mémoire partagée au lieu du réseau si le budget est très serré.
  • Durée de vie: Décharge automatiquement les données plus anciennes qu'un seuil, empêchant le traitement des informations obsolètes.
  • Historique: Réglez à avec la profondeur 1 ou 2 pour minimiser l'utilisation de la mémoire et réduire le temps de recherche.

Exemple d'extrait C++ pour un éditeur avec QoS en temps réel :

Pour les abonnés, définir des profils correspondants. Les paramètres QoS incompatibles entre l'éditeur et l'abonné peuvent causer des défaillances de connexion; toujours tester avec pour vérifier la compatibilité.

Essais et optimisation

Mesure de la latence et du débit

ROS2 fournit plusieurs outils pour évaluer les performances en temps réel:

  • avec le signe logs horodatages de messages pour l'analyse hors ligne de jitter.
  • (du paquet ) mesure le retard aller-retour entre deux nœuds.
  • Mesure de la latence personnalisée en utilisant des messages estampillés : publiez un message avec un horodatage synthétique et calculez le délai du côté abonné. Cela donne une granularité plus fine que les outils en ligne de commande.
  • contrôle des problèmes communs tels que les erreurs de QoS et la congestion du réseau.

Utilisation du CPU de noeud de profil avec ou pour identifier les goulets d'étranglement. Portez une attention particulière au temps d'exécution des rappels; si les rappels dépassent quelques microsecondes, déchargez le traitement vers un thread séparé ou réduisez le taux de message. Utilisez les rappels internes pour mesurer le temps d'exécution, mais veillez à ne pas introduire d'allocation dynamique à travers l'objet horloge.

Optimisation du transport des messages

Les grands flux de données – nuages point, images, données IMU à haut débit – bénéficient d'optimisations de transport:

  • Mémoire partagée à copie zéro: Activez cela lorsque vous utilisez un DDS qui prend en charge SHMEM (Fast DDS avec ], Cyclone DDS avec mémoire partagée activée, ou RTI Connext Pro avec transport de mémoire partagée).
  • Réduire les frais généraux de sérialisation: Utilisez des structures de messages plats plutôt que des types profondément imbriqués. Évitez les champs dans les messages haute fréquence; utilisez plutôt des tableaux de longueur fixe ou des identifiants entiers.
  • Régler la profondeur de l'historique DDS Avec profondeur 1, le middleware ne garde que le dernier échantillon, minimisant ainsi le temps de mémoire et de recherche.
  • Utiliser la communication intraprocédure (CPI) fonctionnalité lorsque les nœuds s'exécutent dans le même processus. Activer et définir dans votre noeud. Cela contourne entièrement DDS pour la communication de même processus, offrant la latence la plus faible possible.

Techniques avancées en temps réel

Exécuteur en temps réel et calendrier des minuteries

Le est idéal pour l'exécution de callback déterministe car il pré-alterne toute la mémoire requise et évite les décisions de programmation dynamiques. Pour les boucles de contrôle avec minuteurs périodiques, créez le minuteur avec un intervalle fixe et attachez-le à un exécuteur dédié épinglé à un noyau en temps réel:

Pour les systèmes multi-taux, utilisez des exécuteurs séparés pour chaque groupe de taux, chacun épinglé à un noyau différent. Cela empêche un callback à faible taux de bloquer un taux élevé.

Intégration avec Linux en temps réel (PREEMPT RT)

Lors de l'utilisation du patch du noyau PREEMPT RT, assurez-vous que les nœuds ROS2 évitent de bloquer les appels du système dans les threads en temps réel.

  • Attribution dynamique de la mémoire: Utiliser des piscines pré-allotées dans les rappels.
  • Dossiers I/O: L'enregistrement sur disque devrait se faire dans un thread séparé non-réel.
  • Débogue de style impression: Utiliser uniquement dans le développement ; ces appels peuvent bloquer sur les mutexes.
  • Inversion prioritaire: Utilisez les mutexes d'héritage prioritaires () lors de la protection des ressources partagées. Les implémentations DDS ROS2 , en général, le gèrent correctement, mais les mutexes personnalisés doivent être configurés explicitement.

Testez votre système sous la charge la plus défavorable avec des outils comme pour mesurer la latence maximale et assurez-vous qu'il reste en deçà de vos délais.

Manipulation de la criticité multi-taux et mixte

Les systèmes robotiques ont souvent des capteurs fonctionnant à des vitesses différentes – une caméra à 30 Hz, LiDAR à 10 Hz, IMU à 1 kHz. Utilisez des excutateurs séparés pour chaque groupe de taux, chacun épinglé à un noyau de processeur dédié. Assignez des priorités plus élevées aux tâches avec des délais plus serrés (p. ex., traitement IMU à la priorité 95, contrôle à 90, LiDAR à 80, enregistrement non critique à 50). cycle de vie rclcpp framework pour gérer les transitions d'état de nœud (non configuré → inactif → actif) et s'assurer que les composants en temps réel ne sont actifs que lorsque le système est prêt.

Cas d'utilisation pratique : Traitement des données LiDAR en temps réel

Considérez un robot mobile autonome qui doit traiter un balayage Velodyne LiDAR (300 000 points par seconde) et produire un nuage point filtré avec une latence maximale de 10 ms. Le pipeline consiste en:

  1. Noeud conducteur: Lit les données brutes du LiDAR via une prise Ethernet et publie les paquets bruts () au taux natif du capteur (10 Hz).
  2. Noeud filtre en temps réel: S'abonner aux paquets bruts, appliquer un filtre passe-passe (déplacement de points au-dessus de 2 mètres de hauteur), et publier des points filtrés (.
  3. Noeud de localisation: Utilise le nuage filtré pour la numérisation à 10 Hz.

Pour respecter la date limite de 10 ms :

  • Réglez la date limite de QoS à 10 ms sur les sujets bruts et filtrés.
  • Pinner les nœuds de pilote et de filtre aux cœurs de processeur dédiés avec la priorité 95 SCHED FIFO.
  • Utilisez le transport de mémoire partagée pour éviter la sérialisation de 2 Mo de données cloud point. Avec Fast DDS, définissez et configurez la taille de la file de mémoire partagée pour correspondre au débit prévu.
  • Dans le callback du filtre, utilisez des tampons pré-allotés de taille fixe. Par exemple, attribuez un avec pendant l'initialisation du nœud, puis réutilisez-le dans chaque callback avec (qui ne réaffecte pas la capacité).
  • Évitez les structures dynamiques : n'utilisez pas ; suivez plutôt le nombre de points valides avec un compteur et insérez par l'indexation du tableau.

Après le déploiement, surveillez la latence en utilisant un nœud personnalisé qui horodate chaque nuage filtré et le compare à l'horodatage du paquet original. Utilisez pour vérifier les temps aller-retour et pour détecter les prédictions inutiles. Si les délais sont encore manqués, envisagez d'augmenter la priorité du nœud filtre ou de passer à une implémentation DDS plus rapide comme Cyclone DDS avec mémoire partagée.

Conclusion

ROS2 offre un écosystème robuste pour le traitement des données robotisées en temps réel, combinant la flexibilité de l'informatique distribuée et le déterminisme requis par les systèmes autonomes modernes. Le succès dépend de la sélection de la bonne mise en œuvre DDS, de la configuration correcte des politiques QoS et de la conception de nœuds avec des contraintes en temps réel dès le départ. En utilisant des noyaux en temps réel, des horaires prioritaires et un transport à copie zéro, les développeurs peuvent construire des systèmes qui traitent des données de capteur à haut débit avec des latences prévisibles.

Pour plus de détails, consulter la documentation officielle en temps réel ROS2 (Tutoriel de programmation en temps réel ), les points de repère de performance DDS de eProsima (DDS rapide) et le projet PREEMPT RT (Wiki Linux en temps réel) . Les ROS2 Contexte en temps réel article fournit une plongée plus profonde dans la philosophie de conception derrière le support en temps réel du framework. Pour l'expérimentation pratique, le dépôt de démos ROS2 comprend des exemples en temps réel avec code exécutable.