Simplifier l'intégration des AMR et des AGV grâce aux composants ROS 2

Les robots mobiles autonomes (AMR) et les véhicules à guidage automatique (AGV) requièrent une coordination étroite entre de multiples sous-systèmes, tels que les capteurs, les moteurs, la navigation et les processus décisionnels basés sur l'intelligence artificielle (IA). L'intégration de tous ces sous-systèmes représente un défi pour les développeurs.

Le système d'exploitation robotique Robot Operating System (ROS) offre une solution à cette complexité. ROS est un intergiciel robotique open-source qui fournit des structures de communication standardisées et un vaste écosystème de packages réutilisables. En sélectionnant des composants avec un support ROS natif, les concepteurs peuvent utiliser des modules matériels pré-construits dotés de fonctionnalités adressables par logiciel, ce qui réduit le temps de mise en service et améliore l'interopérabilité.

Cet article passe brièvement en revue les défis auxquels sont confrontés les concepteurs de robots mobiles autonomes et de véhicules à guidage automatique et la manière dont le système ROS peut les aider. Il présente ensuite le matériel compatible ROS d'Analog Devices (ADI), notamment les contrôleurs moteurs, les unités de mesure inertielles (IMU) et les capteurs temps de vol (ToF), et explique comment ces composants s'intègrent à la pile logicielle ROS pour accélérer le développement des produits.

Défi d'intégration des AMR et des AGV

Le travail d'intégration peut représenter une part importante des étapes de conception initiales d'un AMR ou d'un AGV. Au niveau matériel, les équipes doivent sélectionner les composants, concevoir les interfaces et valider l'intégrité des signaux et la synchronisation. Au niveau logiciel, elles doivent charger les pilotes, définir les flux de données et s'assurer que le système se comporte de manière prévisible en conditions réelles.

Les équipes expérimentées peuvent atteindre ces objectifs en réalisant la conception en interne, mais cela signifie souvent qu'il faut recréer des fonctionnalités disponibles sur le marché. Cet effort peut être difficile à justifier, surtout lorsque les approches traditionnelles lient les équipes à l'utilisation d'interfaces propriétaires. Lorsque les exigences évoluent, le remplacement d'un composant peut nécessiter la modification de parties importantes de la pile logicielle.

Comment le système ROS permet de relever les défis d'intégration

ROS a été créé pour résoudre ces problèmes. Malgré son nom, ROS n'est pas un système d'exploitation au sens classique du terme. Il s'agit plutôt d'une infrastructure open-source offrant un large éventail d'outils, de bibliothèques et de conventions.

Le concept clé de ROS est de structurer les applications robotiques complexes en nœuds modulaires (Figure 1). Ces processus ainsi dimensionnés effectuent des tâches spécifiques, comme la lecture de données de capteurs ou le contrôle de la vitesse d'un moteur.

Figure 1 : Les blocs fonctionnels de base de ROS incluent les packages, les nœuds, les messages et les services. (Source de l'image : Analog Devices, modifiée par Kenton Williston)

Les nœuds communiquent par le biais de deux mécanismes principaux :

• Topics : un modèle publication-souscription adapté à la diffusion continue de données, telles que les flux de capteurs
• Services : un modèle requête-réponse, idéal pour les actions peu fréquentes, telles que la configuration et l'initialisation des dispositifs

Plusieurs nœuds et leurs dépendances (y compris les topics et services associés) peuvent être combinés dans un package pour offrir des fonctionnalités plus complètes. Par exemple, Analog Devices a créé des packages de pilotes ROS pour ses modules de capteurs et d'actionneurs destinés aux AGV et AMR. Ces packages contiennent les nœuds, les définitions de messages et les fichiers de configuration nécessaires à l'intégration du matériel dans un système basé ROS.

Comment ROS simplifie la conception des AMR et des AGV

Cette architecture modulaire favorise l'interopérabilité et accélère le développement. Au niveau matériel, ROS fournit des interfaces standardisées pour des composants tels que des caméras et des contrôleurs moteurs. Cela accélère l'intégration tout en libérant les concepteurs de la dépendance aux fournisseurs et des contraintes de frais de licence.

Au niveau logiciel, ROS offre des outils et des intergiciels qui aident les concepteurs à développer, tester, déployer et maintenir des robots complexes. La version actuelle, ROS 2, offre des fonctionnalités particulièrement utiles pour les AMR et les AGV, y compris :

• Pile de navigation Nav2, prenant en charge les arbres de comportement, les zones d'exclusion, les limitations de vitesse, et plus
• Algorithmes de positionnement sophistiqués, y compris des outils de cartographie et de localisation, permettant aux AMR et aux AGV de comprendre leur environnement
• Intégration avec des outils de simulation, de visualisation et de journalisation qui facilitent à la fois le développement et le diagnostic

ROS 2 fonctionne généralement sur un ordinateur basé sur Linux, même si d'autres systèmes d'exploitation sont pris en charge. ROS 2 prend également en charge micro-ROS, une variante qui s'exécute nativement sur des microcontrôleurs (MCU) avec des systèmes d'exploitation en temps réel (RTOS), tels que Zephyr et FreeRTOS.

Commande moteur avec intégration ROS 2

Pour illustrer le potentiel de ROS 2, examinons la complexité du contrôle des entraînements. La plupart des AMR et des AGV utilisent une configuration d'entraînement différentiel, où deux séries de roues contrôlées indépendamment permettent à la fois d'avancer et de tourner. Cette architecture requiert un contrôleur moteur capable d'entraîner les deux roues simultanément tout en acceptant des commandes coordonnées du système de navigation.

Le TMCM-2611-AGV d'ADI (Figure 2) répond directement à ce besoin. Faisant partie de la gamme TMCM (Trinamic Motor Controller Module), cette carte est une plateforme de servocommande à deux axes pour les moteurs CC sans balai (BLDC) triphasés, conçue pour les applications de traction AGV et AMR. Chaque axe peut entraîner des moteurs jusqu'à 14 A RMS à 48 V, avec retour de position via des codeurs en quadrature incrémentaux ou des capteurs à effet Hall numériques.

Figure 2 : Le TMCM-2611-AGV est un contrôleur/variateur à deux axes pour moteurs BLDC triphasés. (Source de l'image : Analog Devices)

Le pilote ROS 2 adi_tmcl connecte ce matériel à l'écosystème ROS 2 principalement via des topics (Figure 3). Par exemple, une pile de navigation peut publier des commandes de vitesse pour chaque série de roues via les topics /cmd_vel_X. Le pilote adi_tmcl souscrit à ces topics, traduit les commandes en trames TMCL (Trinamic Motion Control Language) et les envoie sur le bus CAN via l'interface SocketCAN native de Linux.

Figure 3 : Le package de pilotes TMCL ROS2 intègre un ensemble robuste d'interfaces. (Source de l'image : Analog Devices)

Dans l'autre direction, le pilote adi_tmcl publie le retour moteur sur les topics /tmc_info_X, fournissant des informations sur la vitesse, la position, le couple et l'état. D'autres nœuds peuvent souscrire à ces données pour le calcul de l'odométrie, les diagnostics ou le contrôle en boucle fermée au niveau de l'application.

Ce flux bidirectionnel illustre la manière dont ROS 2 permet la conception de systèmes modulaires. L'algorithme de navigation n'a pas besoin de connaître le bus CAN ou TMCL ; il se contente de publier des messages de vitesse standard et de recevoir des retours d'informations.

Le pilote adi_tmcl utilise également des services pour des tâches telles que l'initialisation et l'accès aux paramètres. Par exemple, /tmcl_gap_all récupère toutes les valeurs des paramètres d'axe, et /tmcl_ggp_all récupère toutes les valeurs des paramètres globaux de la carte contrôleur.

Mesure inertielle pour le suivi de position

Bien que les codeurs de roue permettent à un système d'estimer la position en fonction de la course des roues, l'odométrie de roue seule est souvent insuffisante pour un suivi précis de la position. Le patinage des roues et les surfaces irrégulières peuvent entraîner des erreurs importantes au fil du temps. Cela est particulièrement problématique dans les nombreux environnements intérieurs où les signaux GPS ne sont pas fiables et ne peuvent pas fournir de corrections en continu.

Les IMU fournissent une référence de mouvement indépendante que les AMR et les AGV peuvent utiliser pour améliorer la précision de la navigation à l'estime. Un excellent exemple est la gamme ADIS16500/05/07, qui offre une détection inertielle de précision à six degrés de liberté via des gyroscopes triaxiaux et des accéléromètres triaxiaux, et ce, dans un boîtier BGA de 15 mm × 15 mm × 5 mm. L'étalonnage en usine caractérise chaque capteur en termes de sensibilité, de biais, d'alignement et de compensation de température, réduisant ainsi la charge d'intégration pour les concepteurs de systèmes.

L'ADIS16500AMLZ (Figure 4) est un exemple représentatif. Ce composant présente une plage de gyroscope de ±2000°/s, une stabilité de biais en fonctionnement du gyroscope de 8,1°/h et une marche aléatoire angulaire de 0,29°/√h. Ces spécifications contribuent à réduire la dérive au fil du temps, améliorant ainsi les performances de navigation à l'estime entre les corrections externes.

Figure 4 : L'ADIS16500AMLZ est une IMU MEMS de précision en boîtier BGA compact. (Source de l'image : Analog Devices)

Pour l'intégration ROS 2, la gamme ADIS16500/05/07 est prise en charge par le pilote imu_ros2. Le pilote exploite le sous-système Linux Industrial I/O via LibIIO. Sa sortie est compatible avec les packages de fusion de capteurs ROS 2 courants tels que robot_localization, qui implémentent des filtres de Kalman étendus pour combiner les données d'IMU et d'odométrie.

Les concepteurs intéressés par l'expérimentation avec l'IMU peuvent démarrer avec la carte d'évaluation ADIS16500/PCBZ (Figure 5). Cette carte expose l'interface SPI de l'IMU via une embase à 16 broches compatible avec les câbles plats à pas de 2 mm standard.

Figure 5 : La carte d'évaluation ADIS16500/PCBZ expose l'interface SPI via une embase à 16 broches. (Source de l'image : Analog Devices)

Détection de profondeur pour la détection d'obstacles

La détection d'obstacles est une autre fonctionnalité standard des AMR/AGV. Si le LiDAR excelle dans la détection d'obstacles à longue portée, de nombreuses applications requièrent également une détection en champ proche pour détecter les obstacles bas, les discontinuités du sol ou les objets situés en dehors du plan de balayage du LiDAR. Les caméras de profondeur ToF comblent cette lacune en fournissant des images de profondeur denses sur un large champ de vision.

Le module ToF ADTF3175BMLZ (Figure 6) répond parfaitement à ces exigences. Combinant un capteur de profondeur CMOS avec une optique d'éclairage, le module capture des images de profondeur et de luminosité active (AB) jusqu'à une résolution de 1024 × 1024 avec un champ de vision de 75° × 75°. Grâce à cette combinaison de résolution et de couverture, il est parfaitement adapté à la surveillance des zones de sécurité et à la détection au sol dans les entrepôts et les environnements de fabrication où les obstacles peuvent apparaître à différentes hauteurs.

Figure 6 : Le module ToF ADTF3175BMLZ intègre un capteur de profondeur CMOS et une optique d'éclairage. (Source de l'image : Analog Devices)

Le pilote adi_3dtof_adtf31xx facilite l'accès aux données de la caméra en publiant des images de profondeur et AB à l'aide des formats de messages ROS 2 standard. Ces sorties s'intègrent directement aux packages de perception courants pour des tâches telles que la génération de nuages de points, la détection des sols et la surveillance des bulles de sécurité. Le pilote prend également en charge un mode de lecture de fichiers, permettant le développement et le test d'algorithmes sans connexion matérielle physique.

Pour le développement et le prototypage, le kit EVAL-ADTF3175D-NXZ (Figure 7) fournit une plateforme de capteurs complète. La fonctionnalité la plus remarquable du kit est une carte basée sur Arm® fonctionnant sous Linux, qui peut héberger directement le nœud ROS 2. Alternativement, le capteur peut transmettre les données de profondeur via Ethernet à un hôte ROS 2 distinct, offrant ainsi une flexibilité pour différentes architectures système.

Figure 7 : Le kit d'évaluation EVAL-ADTF3175D-NXZ inclut un système hôte Linux basé sur Arm. (Source de l'image : Analog Devices)

La plateforme de référence Analog Devices Autonomous Mobot (ADAM) démontre comment ces composants compatibles ROS s'intègrent à des solutions supplémentaires pour la gestion des batteries, la conversion de puissance et les communications afin de former un système AMR complet.

Conclusion

La complexité de conception et de développement des AMR et des AGV peut être considérablement réduite en sélectionnant des composants compatibles ROS et en se tournant vers un fournisseur de composants de confiance comme ADI, qui propose des pilotes ROS 2 pour un large éventail de capteurs et d'actionneurs et peut s'avérer un partenaire précieux.