Fusion de capteurs - Partie 2

Auteurs : Harsh Vardhan Singh, Akash Parikh | Date : 21 March 2023 | Catégorie : Automobile

Introduction

Ce blog est la deuxième partie d'une série en deux parties où nous présenterons l'utilisation de la fusion de capteurs dans les Robots Mobiles Autonomes (AMR) qui sont capables de travailler avec ROS (Robot Operating System) 2. Dans la première partie, nous avons présenté la fusion de capteurs, brièvement couvert un algorithme de fusion de capteurs appelé EKF (Extended Kalman Filters), et ensuite nous avons passé en revue certaines des expériences que nous avons faites dans la simulation et sur notre AMR. La première partie se trouve dans Fusion de capteurs - Partie 1. Dans cette partie, nous allons discuter de certaines implications de l'utilisation de la fusion de capteurs et montrer comment la connaissance précise de l'état de notre AMR est une étape fondamentale qui permet à l'AMR d'exécuter de manière robuste d'autres fonctions telles que la navigation, l'évitement d'obstacles, la cartographie, etc. Pour ce faire, nous observerons les effets de l'utilisation de la fusion de capteurs sur deux algorithmes VSLAM distincts, à savoir RTAB-Map et Isaac ROS VSLAM (et Nvblox).

Avant d'aller plus loin, voyons rapidement ce qu'est le VSLAM. VSLAM signifie Visual Simultaneous Localization and Mapping (localisation et cartographie visuelles simultanées). Il s'agit d'un type de technique de localisation et de cartographie simultanées (SLAM) utilisé en robotique et en vision par ordinateur. Le VSLAM utilise les informations visuelles fournies par les caméras, telles que les capteurs RVB (rouge-vert-bleu) et les capteurs de profondeur, pour établir une carte de l'environnement tout en localisant simultanément la position du robot dans cette carte. Les données visuelles peuvent être utilisées pour identifier des points de repère dans l'environnement, suivre le mouvement du robot et estimer sa position et son orientation.

RTAB-MAP

RTAB-Map est un cadre open-source qui permet la localisation et la cartographie simultanées (SLAM) dans plusieurs types de robots, y compris les drones, les robots mobiles et les robots humanoïdes. Cette approche visuelle utilise des capteurs tels que des caméras pour construire une carte de l'environnement tout en localisant le robot dans la carte. Le cadre intègre également l'odométrie et la détection de fermeture de boucle, ce qui permet une localisation et une cartographie très précises dans des environnements difficiles. Parmi les fonctionnalités de RTAB-Map figurent la cartographie de nuages de points, l'optimisation basée sur les graphes, la détection de boucles et la visualisation en 3D. Pour plus de détails sur l'utilisation de RTAB-Map, nous encourageons nos lecteurs à consulter notre blog Navigation autonome de l'AMR à l'aide de RTAB-Map et d'une caméra ToF.

Lors de la cartographie de nos bureaux, nous avons expérimenté deux capteurs différents : une fois avec les données RGBD Realsense de l'AMR et une autre fois avec son capteur de temps de vol. Grâce à l'utilisation de RTAB-Map, nous montrerons comment la cartographie est affectée par une source d'odométrie médiocre, puis nous l'améliorerons en fournissant une odométrie par fusion de capteurs.

Observations RTAB-MAP avec RGBD Realsense

Lors de nos expériences d'utilisation de RTAB-Map avec les données RGBD de Realsense, nous avons obtenu des résultats très robustes dans des environnements riches en caractéristiques, et l'odométrie visuelle a bien fonctionné. Cependant, lorsque nous travaillions dans des régions à faibles caractéristiques, l'odométrie visuelle était perdue au point de ne plus pouvoir être récupérée, et le processus de création de la carte devait être relancé. Nous avons également observé que même si l'odométrie n'est pas perdue, la qualité de la carte est légèrement dégradée, et la carte globale n'est pas assez nette pour permettre une navigation correcte. Cela peut être dû à des dérives odométriques importantes ou à un grand nombre de caractéristiques similaires observées dans l'environnement. La figure 1 montre l'aspect d'une carte dégradée.

Après avoir utilisé la fusion de capteurs, nous avons pu créer une bonne carte de notre environnement à faibles caractéristiques en fournissant une source d'odométrie plus robuste à RTAB-Map. Pour ce faire, nous avons fusionné l'IMU et l'odométrie des roues. La figure 2 montre le résultat. Comme on peut le voir, nous avons obtenu une carte propre avec des limites bien définies qui ne se chevauchent pas. Une telle carte peut être sauvegardée et utilisée à des fins de navigation intérieure.

RTAB - Observations cartographiques avec un capteur à temps de vol

Lors de l'exécution de RTAB-Map avec des données de nuages de points provenant de notre capteur de temps de vol, nous avons utilisé l'odométrie de la roue comme source d'odométrie. L'odométrie de la roue dérive, en particulier dans les virages, et affecte la qualité de la carte générée. Dans la figure 3, on peut voir que la fermeture de la boucle n'est pas correcte, ce qui entraîne un désalignement des murs.

Après avoir fusionné les données IMU avec l'odométrie des roues, nous avons pu fournir une source d'odométrie plus stable, ce qui a permis d'améliorer la cartographie globale et de fermer correctement les boucles. Comme le montre la figure 4, la carte finale ne contient pas d'obstacles inconnus errants, ce qui la rend plus adaptée à la navigation.

Figure 1 : Cartographie dégradée dans un environnement à faibles caractéristiques

Figure 2 : Carte propre dans un environnement à faibles caractéristiques après utilisation de la fusion de capteurs.

Figure 3 : Fermeture incorrecte de la boucle

Figure 4 : Alignement correct des murs grâce à la fusion des capteurs.

Architecture

La figure 5 montre l'architecture générale de l'utilisation de la fusion de capteurs avec RTAB-Map. Le nœud ekf_localisation est l'implémentation ROS 2 de l'algorithme EKF. Il consomme les données d'orientation calculées à partir de l'accélération linéaire et de la vitesse angulaire de notre IMU en utilisant le paquetage imu_filter_madgwick tel qu'illustré à la Figure 6. Le nœud EKF consomme également l'odométrie générée à partir des données de l'encodeur de roue de l'AMR. Le nœud EKF produit une transformation entre les trames /odom et /base_link tout en publiant l'odométrie calculée sur un sujet distinct. Le nœud RTAB-Map reçoit les données des capteurs RGB-D ou temps de vol ainsi que les informations d'odométrie fournies par le nœud EKF. Le nœud RTAB-Map produit ensuite une carte de la grille d'occupation et diffuse la transformation entre les trames /map et /odom. Celles-ci sont ensuite utilisées par la pile de navigation Nav 2 pour effectuer des tâches de navigation.

Figure 5 : odométrie donnée à la carte RTAB à partir de la fusion des capteurs

Figure 6 : Calcul de l'orientation de l'IMU à l'aide du logiciel imu_filter_madgwick.

Isaac ROS VSLAM + Nvblox

Dans cette section, nous utiliserons une approche différente de la fusion des capteurs. Au lieu d'utiliser simplement l'EKF comme source d'odométrie (estimation locale de la pose), nous l'utiliserons pour effectuer une estimation locale et globale de la pose. Veuillez noter que la source d'odométrie peut être considérée comme un estimateur de pose local qui donne l'estimation de l'état de notre AMR par rapport à sa position initiale, tandis que l'estimation de pose globale signifierait l'estimation de la position du robot par rapport à une carte globale donnée de l'environnement. Nous utiliserons les algorithmes Isaac ROS VSLAM et Nvblox pour le démontrer.

Isaac ROS SLAM visuel

Isaac_ros_visual_slam est un package ROS2 qui fournit une solution VSLAM puissante. Le package utilise le VSLAM stéréo et tire parti de la bibliothèque Isaac Elbrus accélérée par le GPU pour estimer l'odométrie inertielle visuelle stéréo. En prenant une paire d'images stéréo en niveaux de gris synchronisées dans le temps, ainsi que les paramètres intrinsèques respectifs de la caméra, le package publie la position actuelle de la caméra par rapport à sa position de départ.

Isaac_ros_nvblox

Nvblox est un outil puissant pour construire des modèles 3D précis de l'environnement d'un robot. Ce processus est accéléré à l'aide de NVIDIA CUDA, ce qui permet des taux de fonctionnement en temps réel. Il offre un avantage significatif pour la planification du chemin et la navigation dans des environnements dynamiques, permettant aux robots de fonctionner de manière sûre et efficace. Le logiciel est intégré à ROS 2, ce qui le rend facile à utiliser avec les robots basés sur ROS 2.

Les lecteurs peuvent trouver plus de détails sur l'exécution de Isaac ROS VSLAM et Nvblox dans notre blog AMR navigation using Isaac ROS VSLAM and Nvblox with Intel Realsense camera.

Isaac ROS : VSLAM+Nvblox Observations

Au cours de nos expériences avec le VSLAM, nous avons remarqué que, bien que la précision de l'estimation de l'état global du VSLAM soit satisfaisante, l'odométrie générée par le VSLAM posait problème. Dans la figure 7, nous montrons les poses odométriques de notre AMR lorsqu'il a été exécuté dans une trajectoire en boucle fermée. Les poses générées par le VSLAM lorsque l'AMR tourne sont cinématiquement irréalisables car notre AMR ne dispose que de deux paramètres de contrôle, à savoir la vitesse x et la vitesse angulaire dans la direction z. L'AMR est incapable d'une telle odométrie latérale. L'AMR est incapable d'effectuer un tel mouvement latéral. Ce type de comportement pourrait être dû à l'absence de modèle de mouvement dans l'algorithme.

Lors de l'exécution de VSLAM avec NVBLOX, nous avons observé un désalignement croissant entre les cartes de coûts locales et globales générées par le plugin de cartes de coûts NVBLOX. La figure 8 en donne un aperçu. Cela a commencé à affecter négativement la pile de navigation, l'AMR commençant à observer des obstacles dans la carte de coûts locale alors qu'il n'y en avait pas. En outre, l'AMR était un peu instable lorsqu'il s'alignait sur un objectif donné et, dans certaines circonstances, la carte des coûts NVBLOX globale s'est embrouillée au point de ne plus pouvoir être récupérée.

Tout comme pour RTAB-Map, les performances dans les environnements à faibles fonctionnalités diminuent, et les observations ci-dessus sont encore plus évidentes.

Figure 7 : L'odométrie visuelle du ROS VSLAM d'Isaac donne des poses cinématiquement infaisables.

Figure 8 : Les cartes de coûts globales et locales sont mal alignées

Solution et architecture

Un schéma architectural de notre solution est présenté à la figure 9. Nous avons utilisé deux instances différentes d'EKF, l'une pour l'estimation globale de la pose et l'autre pour l'estimation locale de la pose. L'estimateur de pose local est chargé de fournir une transformation entre un cadre odom fixe et la liaison de base AMR. Il remplace l'odométrie du VSLAM. Il utilise les données des capteurs de l'IMU monté, des codeurs de roue et de l'odométrie visuelle générée par le VSLAM. L'estimateur de pose global est chargé de fournir une transformation entre un cadre de carte fixe et le cadre d'odométrie fixe. Cette transformation remplace la pose globale générée par le VSLAM. Il consomme les mêmes données que l'estimateur de pose local, ainsi que la pose globale calculée par VSLAM.

Figure 9 : Schéma d'architecture pour l'utilisation de capteurs pour l'estimation locale et globale de l'état avec Isaac ROS VSLAM et Nvblox.

Nous avons énuméré quelques-unes des configurations importantes utilisées pour mettre en œuvre l'architecture présentée dans le document Figure 10. Nous exécutons les nœuds EKF locaux et globaux avec le mode two_d_mode réglé sur True, car nous travaillons avec un AMR. Pour le nœud d'estimation de la pose locale, nous fusionnons l'orientation de l'IMU provenant du nœud imu_filter, la vitesse provenant de l'odométrie visuelle du VSLAM et la vitesse provenant de l'odométrie de l'encodeur de roue. Pour le nœud d'estimation de la pose globale, nous fusionnons la position globale rapportée par le VSLAM avec les données consommées par le nœud d'estimation de la pose locale. Le nœud de localisation du robot nous permet de spécifier ces données à l'aide du paramètre sensorN_config. L'IMU est réglé pour démarrer à une valeur de lacet nulle à l'aide du paramètre sensorN_relative. Pour l'estimation de la pose locale, la world_frame a été réglée sur odom_frame et pour l'estimation de la pose globale, elle a été réglée sur map_frame. Nous avons réglé la fréquence du cycle de prédiction EKF à 10 Hz, ce qui correspond également à la fréquence de nos sources de données. L'EKF est autorisé à prendre des commandes de vitesse en réglant le paramètre use_control sur True. Nous avons également fixé une période d'attente de 0,1 et 0,2 seconde pour que les données d'entrée et les données des capteurs arrivent avant qu'une prédiction ne soit effectuée. Pour ce faire, nous utilisons les paramètres control_timeout et sensor_timeout. Le bruit du processus est suffisamment élevé pour permettre à l'EKF de croire les mesures entrantes un peu plus que le modèle de mouvement omnidirectionnel. Veuillez noter que la covariance du bruit du capteur n'est pas techniquement un paramètre du paquetage de localisation du robot. Nous la mentionnons ici car il s'agit d'un aspect important qui a nécessité un réglage pour stabiliser l'estimation EKF, en particulier en ce qui concerne l'odométrie VSLAM.

Figure 10 : Configurations importantes utilisées pour l'EKF.

En utilisant l'architecture et la configuration ci-dessus, nous avons pu améliorer la cartographie et la navigation globales de notre AMR. Cela a également bien fonctionné dans les environnements à faible fonctionnalité. Les cartes de coûts locales et globales générées par Nvblox ont été alignées avec précision. La navigation a commencé à être plus fluide et la présence d'obstacles dynamiques dans la vue de l'AMR n'a pas détruit la carte globale produite par Nvblox.

Conclusion

Dans ce blog, nous avons passé en revue deux cas d'utilisation où la fusion de capteurs peut être utilisée pour améliorer les capacités de cartographie et de navigation d'un AMR. Dans le premier cas, nous avons fourni une source d'odométrie stable à RTAB-Map, et dans le second cas, nous avons fourni des estimations de pose globales et locales de notre AMR à Nvblox afin d'améliorer les résultats de la cartographie. Ces expériences ont également contribué à améliorer les capacités de navigation de notre AMR.

Auteurs

Harsh Vardhan Singh

Ingénieur en solutions, eInfochips (An Arrow Company)

Harsh Vardhan Singh est titulaire d'une maîtrise en informatique de l'Institut de technologie de Géorgie, avec une spécialisation en apprentissage automatique. Il est ingénieur de recherche en solutions et travaille actuellement sur la fusion de capteurs et la pile de navigation dans l'environnement ROS 2 pour un prototype de robot mobile autonome. En mars 2023, Harsh a sept ans d'expérience industrielle, dont six ans passés dans des laboratoires de recherche et d'innovation. Il a travaillé sur de nombreux projets tels que les chariots élévateurs autonomes pour la préparation de palettes, la gestion de flotte pour les systèmes multi-robots, la préparation de bacs, la palettisation automatisée et l'emballage de bacs en ligne, qui impliquaient l'application de la vision par ordinateur, de l'IA, de l'apprentissage profond, de l'apprentissage automatique, de l'apprentissage par renforcement et de la robotique.

Akash Parikh

Ingénieur embarqué, einfochips (An Arrow Company)

Akash Parikh est titulaire d'une maîtrise en mécatronique et technologies de l'information de l'Institut de technologie de Karlsruhe, en Allemagne, avec une spécialisation en robotique. Il a environ trois ans d'expérience diversifiée, par exemple dans les techniques de vision par ordinateur et a travaillé sur la conception d'un pipeline de détection/classification/segmentation d'objets. Il a également travaillé avec ROS1/2 et des logiciels de CAO pour la modélisation 3D, tels que CreO et Autodesk Inventor.

Fusion de capteurs - Partie 2

Auteurs : Harsh Vardhan Singh, Akash Parikh | Date : 21 March 2023 | Catégorie : Automobile

Introduction

Observations RTAB-MAP avec RGBD Realsense

RTAB - Observations cartographiques avec un capteur à temps de vol

Architecture

Isaac ROS VSLAM + Nvblox

Isaac ROS : VSLAM+Nvblox Observations

Solution et architecture

Conclusion

Auteurs

Services

Industries

Perspectives

Explorer eInfochips

Entamez une conversation dès aujourd'hui

Entamez une conversation dès aujourd'hui

Entamez une conversation dès aujourd'hui

Entamez une conversation dès aujourd'hui

Veuillez remplir les champs ci-dessous pour obtenir un exemple de rapport

Modèles de référence

Notre travail

Innover

Transformer.

Échelle

Partenariats

Partenariats pour les appareils

Partenariats numériques

Partenariats de qualité

Partenariats en silicium

Entreprise

Mobilité

Soins de santé

Industriel

Hi-Tech

Produits et PI

Dispositif

Numérique

Qualité

Silicium