Intégration INS-ROS2 pour les plateformes robotiques autonomes de nouvelle génération

Pourquoi l'intégration INS-ROS2 est-elle nécessaire pour les robots autonomes ?

Les robots autonomes ont besoin d'informations continues et fiables de position, de vitesse et d'attitude pour se localiser, planifier leur trajectoire et se commander. Le GNSS seul ne peut pas toujours garantir une navigation ininterrompue, à cause des masquages de signal, des interférences ou des environnements sans GNSS.

L'intégration d'un INS à ROS2 permet aux robots de :

1. Obtenir une estimation continue de la position, de la vitesse et de l'attitude

2. Maintenir la navigation pendant les interruptions temporaires du GNSS

3. Effectuer une navigation à l'estime dans des conditions sans GNSS

4. Fusionner les données de l'INS avec celles du GNSS, du LiDAR, des caméras et de l'odométrie

5. Fournir des données de navigation à cadence élevée à la pile d'autonomie et de commande ROS2
   

Le Pollux 3 associe un très faible C-SWaP à une navigation haute performance, ce qui le rend particulièrement adapté aux plateformes robotiques autonomes compactes.

Principales capacités :

1. Conception ultra-miniature, légère et à faible consommation (faible SWaP)

2. Haute précision d'attitude et de cap

3. Estimation précise de la position et de la vitesse

4. Navigation à l'estime fiable dans des conditions sans GNSS

5. Sortie de navigation à 200 Hz, données IMU jusqu'à 1000 Hz

6. Pilote ROS2 dédié pour simplifier l'intégration

7. GNSS multiconstellation intégré et fusion de capteurs fondée sur un EKF

8. Conçu pour les UAV, les UGV et la robotique

9. Chaîne d'approvisionnement maîtrisée

10. Qualifié MIL / IP65 le cas échéant
    

En somme, ROS2 fournit le cadre d'autonomie, tandis que le Pollux 3 apporte l'ossature de navigation fiable des plateformes robotiques autonomes.

Pourquoi la précision de navigation compte en robotique autonome

Les systèmes autonomes modernes s'appuient sur plusieurs capteurs pour se localiser et percevoir leur environnement. Les caméras, les LiDAR et les codeurs de roues ont chacun leurs limites.

Un système de navigation inertielle comble ces lacunes en estimant en continu :

1. La position

2. La vitesse

3. L'orientation

4. La vitesse angulaire

5. L'accélération

Lorsque le GNSS est disponible, le Pollux 3 fusionne le positionnement par satellite et les mesures inertielles grâce à des algorithmes avancés de fusion de capteurs, afin de fournir des données de navigation fluides et fiables, même pendant les interruptions temporaires du GNSS.

Les robots peuvent ainsi conserver une localisation stable dans des environnements dynamiques et difficiles.

Pilote ROS2 du Pollux 3

Le pilote ROS2 du Pollux 3 est conçu comme un nœud à cycle de vie géré et un composant composable. Il publie des topics ROS2 conformes aux normes REP-103, REP-105 et REP-145 , ce qui assure la compatibilité avec les paquets ROS2 courants sans middleware spécifique. En plus des topics ROS2 standard, le pilote expose aussi les flux de données brutes d'Aeron pour les utilisateurs avancés et le diagnostic.

Principales fonctionnalités

Le pilote ROS2 offre :

1. Intégration d'un INS assisté par GNSS

2. Architecture à nœud à cycle de vie

3. Composants ROS2 composables

4. Conformité REP-103, REP-105 et REP-145

5. Topics ROS2 standard et bruts

6. Qualité de service (QoS) configurable

7. Diagnostic intégré et surveillance de l'état

8. Services d'étalonnage de l'appareil

9. Prise en charge des TF statiques et dynamiques

10. Communication série robuste avec reconnexion automatique

11. Données d'assistance externes via un nœud ROS2 pour prendre en charge l'assistance embarquée.

Ces fonctionnalités permettent aux développeurs d'intégrer efficacement le Pollux 3 dans des systèmes robotiques autonomes tout en conservant un flux de données et un diagnostic fiables.

Compatible avec les principaux frameworks de navigation ROS2

Le pilote ROS2 du Pollux 3 est conçu pour s'intégrer aux frameworks de navigation ROS2 les plus utilisés, notamment :

1. robot_localization

2. Nav2

3. navsat_transform_node

Comme le pilote respecte les normes REP de ROS2, les développeurs peuvent utiliser ces frameworks sans couche d'interface supplémentaire, ce qui réduit le temps et la complexité d'intégration.

Comment intégrer un système de navigation inertielle (INS) à ROS2 pour des robots autonomes ?

Les développeurs peuvent intégrer rapidement le Pollux 3 dans un espace de travail ROS2 grâce à la structure de dépôt fournie, au flux de travail de sparse checkout et au processus de compilation colcon. Le paquet prend en charge les distributions ROS2 Humble et Jazzy et inclut des paquets de démonstration pour la visualisation sous RViz et Gazebo.

Applications concrètes : le Pollux 3 est idéal pour :

1. La navigation d'UAV

2. Les véhicules terrestres autonomes (UGV)

3. Les robots mobiles autonomes (AMR)

4. Les robots d'entrepôt

5. Les robots miniers

6. Les robots de défense

7. Les robots agricoles

8. Les robots de livraison

9. Les robots d'inspection
   
   

Pourquoi les ingénieurs en robotique choisissent le Pollux 3

Le Pollux 3 associe une navigation inertielle haute performance à une intégration ROS2 transparente, ce qui permet aux équipes d'ingénierie d'accélérer leur développement tout en conservant la précision de navigation.

Au lieu de consacrer de précieuses ressources d'ingénierie à une intégration de capteurs sur mesure, les développeurs peuvent déployer une solution de navigation prête pour la production, compatible avec l'ensemble de l'écosystème ROS2.

Que vous construisiez des robots autonomes, des UAV, des UGV ou des systèmes d'automatisation industrielle, le Pollux 3 offre la performance, la fiabilité et la flexibilité qu'exigent les plateformes autonomes de nouvelle génération.

Prêt à accélérer votre développement ROS2 ?

Découvrez comment le Pollux 3 peut simplifier l'intégration de la navigation dans votre application de robotique autonome.

Prochaines étapes :

1. Demandez une démonstration en direct du produit.

2. Téléchargez la fiche technique du Pollux 3.

3. Accédez à la documentation du pilote ROS2.

4. Contactez l'équipe d'ingénierie d'Aeron Systems pour obtenir une assistance à l'intégration.

Aeron Pollux 3 : guide d'intégration ROS2

Le paquet aeron_pollux_driver intègre le système de navigation inertielle PLX3 à ROS2 comme un composant à part entière : topics de capteurs conformes aux normes, nœud à cycle de vie géré, diagnostic intégré et accès aux paquets bruts pour les utilisateurs avancés. Ce guide vous mène de la boîte encore fermée à un PLX3 qui alimente votre pile de navigation. Pour la référence exhaustive des paramètres, topics et services, consultez le guide de l'utilisateur complet dans le dépôt.

Ce que vous obtenez : des topics standard sensor_msgs/ nav_msgs prêts pour robot_localization, Nav2 et RViz ; l'ensemble des paquets bruts du PLX3 republiés en unités natives pour l'enregistrement et les estimateurs personnalisés ; une diffusion de TF statiques pilotée par paramètres pour l' IMU et l'antenne GNSS ; des services d'exécution pour l'étalonnage et la commande de l'appareil ; et huit tâches de diagnostic sur /diagnostics.

1. Installation du matériel

Le PLX3 transmet ses données en RS232/UART. Raccordez-le à votre hôte via un convertisseur RS232-USB : il apparaîtra comme un périphérique série, typiquement /dev/ttyUSB0. Deux étapes à effectuer une seule fois sur l'hôte évitent les échecs les plus courants au premier lancement :

Autorisations du port série. Ajoutez votre utilisateur au groupe dialout , puis déconnectez-vous et reconnectez-vous :

sudo usermod -aG dialout $USER

Un nom de périphérique stable. /dev/ttyUSB* La numérotation peut changer d'un redémarrage à l'autre. Figez un nom fixe soit avec la règle udev fournie par le paquet (elle crée un lien symbolique depuis votre convertisseur vers /dev/aeron_pollux , idéal pour un robot déployé), soit avec le chemin natif du noyau /dev/serial/by-id/... (sans sudo, fonctionne sous WSL2). La règle udev doit correspondre aux identifiants USB du convertisseur, puisque le PLX3 se trouve derrière lui. Consultez le guide de l'utilisateur §1.1 pour les commandes exactes.

2. Installation

ARN_DRIVERS est un monodépôt ; un sparse checkout ne récupère donc que le paquet PLX3 plutôt que tous les pilotes Aeron :

cd ~/ros2_ws/src 

git clone --filter=blob:none --sparse https://github.com/aeron-systems/ARN_DRIVERS.git

cd ARN_DRIVERS

git sparse-checkout set ROS2/pollux3/v01.00/aeron_pollux_driver

colcon parcourt récursivement src/ pour trouver le paquet, aucun lien symbolique n'est donc nécessaire. Résolvez ensuite les dépendances et compilez depuis la racine de l'espace de travail :

cd ~/ros2_ws 

sudo rosdep init      #first time on this machine only (harmless warning if already done)

rosdep update

rosdep install --from-paths src -y --ignore-src
 
colcon build --packages-up-to aeron_pollux_driver

source install/setup.bash

Pour mettre à jour plus tard, git pull dans ARN_DRIVERS actualise uniquement le paquet récupéré.

3. Démarrage rapide

#Launch (auto-configures+auto-activates)
 
ros2 launch aeron_pollux_driver aeron_driver.launch.py \
    
device_path:=/dev/aeron_pollux baud_rate:=921600 

#Watch data and confirm health 

ros2 topic echo /imu/data 

ros2 topic echo /navsat/fix 

ros2 topic echo /diagnostics 

ros2 run rqt_runtime_monitor rqt_runtime_monitor

Si le port n'existe pas ou si la vitesse de transmission est incorrecte, le nœud reste non configuré et indique pourquoi dans les journaux : consultez d'abord la console.

La cadence de sortie se règle sur l'appareil, pas dans le pilote. Configurez les cadences par paquet du Pollux 3 dans l'interface graphique Aeron Connect Suite avant le déploiement, puis réglez le paramètre data_rate_hz du pilote en conséquence afin que le diagnostic de cadence sache ce qu'il doit attendre. Pour plus d'informations, reportez-vous à la section AICS du manuel d'utilisation de l'INS Pollux 3.

4. Le nœud à cycle de vie

Le pilote est un nœud à cycle de vie géré , exactement ce qu'il faut sur un robot où un orchestrateur décide quand les capteurs démarrent. Il passe de unconfigured → inactive → active : configure valide les paramètres, ouvre le port et diffuse les TF statiques (pas encore de données) ; activate démarre le fil d'E/S et les données circulent. Le fichier de lancement fourni effectue les deux étapes pour vous. Pour piloter vous-même les transitions (essais de mise en service, orchestration externe), lancez avec auto_configure:=false auto_activate:=false et utilisez ros2 lifecycle set /ins_driver <transition>. Le nœud est aussi enregistré comme composant composable, afin de partager un processus avec le reste de votre chaîne de traitement.

5. Ce qui est publié

Topics standard : consommés directement par les piles ROS2 du commerce, tous en ENU/FLU et en unités SI :

/imu/data (sensor_msgs/Imu), /imu/mag, /imu/temperature, /imu/pressure, /imu/velocity (torseur cinématique dans le repère du corps, non conditionné par le GNSS), /navsat/fix et /navsat/status (toujours RELIABLE pour que les piles de navigation ne manquent jamais un point GNSS), /navsat/ecef, /odom (la solution fusionnée du PLX3), /time_reference, /tf + /tf_static, et /diagnostics.

Topics de paquets bruts : chaque paquet natif du Pollux 3 en unités natives, pour l'enregistrement et les estimateurs personnalisés : /aeron/nav_fused, /aeron/nav_extended, /aeron/sensors, /aeron/gnss_extended, /aeron/gnss, /aeron/device_info, /aeron/status, /aeron/calib_progress.

Les topics /aeron/* utilisent des types personnalisés aeron_pollux_driver/msg/* ; sourcez donc la surcouche de votre espace de travail (source install/setup.bash) avant de les lire avec ros2 topic echo. La référence complète champ par champ et les détails de QoS figurent dans le guide de l'utilisateur §6.

Le Pollux 3 ne fournit que des données inertielles étalonnées : il n'existe aucun flux brut d'IMU (imu/data_raw) .

6. Configuration à effectuer

Tous les réglages sont des paramètres ROS2 ordinaires. La voie durable est un fichier YAML de paramètres passé au lancement (params_file:=your.yaml); les paramètres modifiables à l'exécution peuvent aussi être définis à chaud avec ros2 param set. Deux choses que tout intégrateur doit régler.

▸ Transformations de montage

Le pilote diffuse deux transformations statiques à partir de vos paramètres : base_link → imu_link (pose de l'INS) et base_link → gnss_link (bras de levier de l'antenne). Les décalages sont en mètres, dans le repère du corps REP-103 : x vers l'avant, y vers la gauche, z vers le haut:

/**:  
ros__parameters:    
mounting_translation:             # base_link → INS
x:  0.12         #12 cm forward      
y: -0.04         #4 cm right (y is left-positive)  
z:  0.18         #18 cm up    
mounting_rotation:           # only if the INS is physically rotated     
roll: 0.0      
pitch: 0.0      
yaw: 0.0    
gnss_mounting_translation:    # base_link → antenna      
x: -0.20      
y:  0.00      
z:  1.20

Vérifiez avec ros2 run tf2_ros tf2_echo base_link imu_link. Deux règles : ces paramètres ne décrivent que la géométrie côté ROS (ils ne sont jamais envoyés à l'INS : ils indiquent aux nœuds en aval où se trouvent les capteurs), et chaque décalage physique ne doit être appliqué qu'une fois, soit dans l'appareil, soit dans ROS2, jamais les deux.

▸ Covariances de mesure

Le pilote est livré avec des covariances provisoires prudentes : réglez-les à nouveau pour votre plateforme. Un utilitaire fourni capture tous les capteurs pendant que le robot reste immobile et affiche des valeurs prêtes à intégrer au YAML :

ros2 run aeron_pollux_driver estimate_variances.py 60 > measured_vars.yaml

Utilisez directement le plancher mesuré pour le gyroscope, l'accéléromètre et le magnétomètre. Considérez orientation_variance à l'arrêt comme une borne inférieure seulement : prenez-la plutôt dans la fiche technique ou lors d'essais dynamiques. La covariance de position GNSS ne demande aucun réglage : par défaut, le pilote la renseigne en direct à partir de la précision rapportée par le PLX3 lui-même.

7. Intégration à votre pile de navigation

Le PLX3 est un véritable INS : il fusionne à bord ses données inertielles et GNSS et publie une solution de navigation complète. Contrairement à l'association d'une simple IMU et d'unrécepteur GNSS, vous n'avez pas besoin d'un estimateur côté hôte pour obtenir une pose : l'estimation est déjà faite dans l'appareil.

▸ Recommandé : consommer directement la solution fusionnée

Envoyez /odom à votre pile de navigation (par ex. Nav2) comme source de localisation, et laissez le pilote gérer la transformation odom → base_link :

ros2 param set /ins_driver publish_tf true

/odom publie une pose ENU locale ancrée au premier point GNSS, puis se poursuit pendant les interruptions suivantes grâce à la navigation à l'estime du PLX3. Elle est conditionnée par le GNSS : tant qu'un premier point n'est pas acquis, elle reste muette (voir §5). C'est la bonne voie pour la grande majorité des intégrations et des applications. navsat_transform_node peut aussi consommer /navsat/fix directement si vous avez besoin d'un repère de carte géoréférencé ; il utilise le bras de levier diffusé base_link → gnss_link pour rapporter le point à base_link.

▸ Facultatif : mélange avec l'odométrie des roues ou d'autres capteurs locaux

Si votre plateforme dispose de codeurs de roues ou d'autres sources locales que vous souhaitez combiner avec l'INS, vous pouvez exécuter un filtre côté hôte tel que le robot_localization's ekf_node ; notez qu'il s'agit d'un paquet ROS exécuté sur votre ordinateur, pas d'un mode du Pollux 3. Vous pouvez aussi transmettre des données d'odomètre externe directement à l'INS par le protocole de communication binaire d'Aeron. Comme l'appareil fournit déjà une solution fusionnée, considérez l'une ou l'autre voie comme un choix délibéré plutôt que comme le défaut, et évitez de fusionner à nouveau des informations que l'INS a déjà fusionnées. Un câblage typique envoie l'orientation, les vitesses angulaires et les accélérations de l'INS, ainsi que l'odométrie des roues, au filtre, et laisse publish_tf du pilote à sa valeur par défaut false, de sorte que le filtre externe gère odom → base_link:

ekf_filter_node:                      # robot_localization (host-side) — not a Pollux 3 mode               
    ros__parameters:    
        imu0: /imu/data    
        imu0_config: [false, false, false,       # x, y, z              
                      true,  true,  true,        # roll, pitch, yaw              
                      false, false, false,       # vx, vy, vz
                      true,  true,  true,        # vroll, vpitch, vyaw
                      true,  true,  true]        # ax, ay, az

      imu0_remove_gravitational_acceleration: true     # Pollux 3 outputs specific force (REP-145)

Un seul éditeur peut gérer odom → base_link. Si un filtre externe la gère, laissez publish_tf du pilote à false; si c'est le pilote qui la gère, n'exécutez pas de filtre concurrent. Deux éditeurs sur la même transformation sont un grand classique des pathologies TF.

Pour un fonctionnement entièrement sans GNSS, la solution de l'INS navigue à l'estime par elle-même ou fusionne aussi une assistance externe si elle est disponible ; vous pouvez également fusionner /imu/data et /imu/velocity (ni l'un ni l'autre n'est conditionné par le GNSS) dans votre propre estimateur. Tous les noms de topics et de services sont remappables (--ros-args -r imu/data:=/vehicle/imu, ou une liste remappings=[...] dans votre propre fichier de lancement), et le lancement avec namespace:=<prefix> préfixe tout en une seule fois.

8. Étalonnage & exploitation

Étalonnage du magnétomètre, lorsque l'environnement magnétique change :

ros2 service call /calibrate_ins aeron_pollux_driver/srv/CalibrateIns   #START (default) 
ros2 topic echo /aeron/calib_progress                                   #rotate slowly about Z 
ros2 service call /reboot_device std_srvs/srv/Trigger                   #reboot to apply

Le pilote s'arrête et enregistre automatiquement près de 100 % ; les nouveaux coefficients ne prennent effet qu'après le redémarrage.

Vérifier un pilote en fonctionnement. /diagnostics est le premier endroit à consulter lorsque quelque chose semble anormal : ses huit tâches signalent les pertes de liaison, les erreurs de vitesse de transmission (des octets arrivent mais rien n'est décodé), la dégradation du GNSS et la croissance de la mémoire. rqt_graph confirme que vos connexions vers les nœuds en aval existent bien.

Un arrêt propre est important. Le port série est une ressource exclusive gérée par le noyau ; arrêtez donc le pilote par un seul Ctrl+C dans le terminal de lancement : les rappels du cycle de vie ferment le port et quittent proprement. Un second Ctrl+C passe à SIGTERM, ignore les rappels et peut laisser le port verrouillé (« Device or resource busy » au lancement suivant). Le guide complet d'inspection et d'arrêt se trouve dans operations.md.

9. Dépannage

10. Référence & assistance

1. Référence complète des paramètres, topics & services : user_guide.md

2. Guide d'exploitation (inspection & arrêt d'un pilote en fonctionnement) : operations.md

3. Sources, tickets, versions : github.com/aeron-systems/ARN_DRIVERS

4. Configuration de l'appareil (cadences de sortie, bras de levier de l'antenne, notation du cap) : Aeron Connect Suite

5. Assistance : contactez Aeron Systems en indiquant la version de votre pilote, votre distribution ROS2 et une capture de /diagnostics . Le paquet aeron_pollux_driver est publié sous licence Apache-2.0.

Découvrez la Pollux 3 page produit pour consulter les spécifications détaillées, les principales fonctionnalités et les capacités d'intégration, ou contactez nos experts pour discuter des exigences de votre application.

Auteur : Vinayak Pundhir (Embedded Software Developer)