Test & analyse de RTAB-Map
Après Google Cartographer, GMapping et Hector Slam, l’heure est venue d’évaluer RTAB-Map (pour Real-Time Appearance-Based Mapping). Cet algorithme permet de cartographier l’environnement à l’aide d’une caméra RGB-D – pour Red Green Blue-Depth -, à la différence des technologies LIDAR 2D étudiées précédemment.
Pour rappel, la comparaison de ces différents algorithmes a été menée sur la base de différents critères (méthodologie de l’étude disponible en fin d’article), dans un environnement fréquenté de type “open space”. Les résultats sont tirés de l’étude produite par Awabot Intelligence, disponible à la demande en cliquant sur le bouton ci-dessous.
Présentation de l’algorithme RTAB-Map
Le projet RTAB-Map a vu le jour en 2011 grâce à l’initiative de Mathieu Labbé, professeur à l’Université de Sherbrooke. Ce projet a connu une très forte popularité dans son domaine : en témoigne son intégration sur de nombreuses plateformes telles que ROS, Windows, MacOS, Linux, Android, Docker…
Les technologies basées sur des caméras sont généralement de moins bonne précision que leurs homologues laser. Une observation qui ne se vérifie pas forcément avec RTAB-Map : cet algorithme permet en effet de cartographier un espace en 3D avec une technologie bien moins onéreuse qu’un LIDAR 3D.
Par ailleurs, la carte 3D générée peut être utilisée pour la navigation, mais également dans des applications de numérisation de bâtiments pour une expérience “esthétique”.
Qualité générale de la cartographie
Carte projetée en 2D de la “trajectoire en P” générée par RTAB-Map
Surimpression de la carte projetée de RTAB-Map sur le plan du bâtiment
Nous pouvons observer que la partie inférieure droite de la carte est absente. Cela est dû à un environnement trop linéaire : le robot navigue dans un couloir au décor uniforme où la luminosité est relativement basse. Ainsi, RTAB-Map a “perdu le fil” de cette zone et n’a pas été en mesure de cartographier l’espace correctement : les images n’ont pu être ajoutées à la numérisation, malgré 3 passages.
L’odométrie et l’algorithme d’analyse des correspondances ont permis à RTAB-Map de reprendre la cartographie un peu après cette zone.
Malgré la calibration de la caméra, les angles de la carte générée divergent avec la réalité. Les obstacles sont également vus comme particulièrement épais.
- cartographie de la reconstruction de rotations : imprécis
- détourage des fauteuils (de forme circulaire) : imprécis
- cartographie en temps réels des couloirs en ligne droite (murs, alcôves, etc.). : irrégulier
Précision : nous évaluons ici une carte en 2D issue d’une projection d’un système ayant la capacité de numériser son environnement en 3D. De nouveaux cas d’usages sont rendus possibles avec l’exploitation de la 3D.
Fiabilité et résilience face aux entités mobiles
Etant donné que RTAB-Map ne fonctionne pas avec un LIDAR, nous ne retrouverons pas les artefacts rencontrés dans les précédentes cartographies.
En comparaison avec les précédents résultats des algorithmes SLAM basés sur laser 2D, l’aspect incomplet de la carte issue de RTAB-Map est principalement dû à l’orientation de la caméra 3D : la position de l’émetteur infrarouge par rapport aux vitres des bureaux fermés induit nécessairement des réflexions des faisceaux infrarouges sur celles-ci et empêche leur cartographie. De même, par rapport au laser 2D, le champ de vision horizontal réduit de la caméra 3D impacte fortement la qualité des données d’entrées et donc, les résultats de la cartographie.
L’exemple de RTAB-Map illustre ici l’influence de la géométrie du capteur source de données sur la façon de parcourir l’environnement pour des problématiques de cartographie.
RTAB-Map est sensible au déplacement d’objets sur son chemin : la présence de personnes passées dans le champ au premier passage figure notamment dans la cartographie finale.
Fiabilité et résilience face aux bugs
Comme observé plus haut, RTAB-Map a pu reconstruire la carte grâce à l’odométrie. L’algorithme est donc bien résilient aux bugs, mais introduit toutefois un nouveau type d’erreur dans le cas d’un environnement trop uniforme.
Il est de même très sensible aux pertes d’odométrie.
Evaluation de RTAB-Map
LE VERDICT
Pour rappel, RTAB-Map est la seule technologie « caméra » de ce comparatif, qui étudie également trois technologies LIDAR 2D : Hector SLAM, GMapping, Google Cartographer.
En comparaison, cet algorithme présente des résultats peu concluants dû à une imprécision globale : celle-ci est toutefois compensée par l’odométrie et l’algorithme d’analyse des correspondances. Résilient face aux bugs et dépourvus d’artefacts, RTAB-Map fait malgré tout preuve d’une sensibilité globale, notamment vis-à-vis des entités mobiles.
Le démonstrateur robotique “Emox One” au service du benchmark technologique
L’étude se construit à partir de données recueillies par la plateforme de test EMOX One développée par Awabot Intelligence.
Critères de sélection des algorithmes
Cette étude vise à évaluer les SLAM utilisant des télémètres laser (LIDAR) 2D ainsi que des technologies de cartographie par caméras. En effet, les LIDAR 2D permettent de générer la carte d’un environnement à altitude fixe, l’altitude où est fixé le laser. À l’inverse, une caméra bien calibrée pourra scanner une pièce dans sa totalité et proposer une modélisation 3D de l’environnement. Cette modélisation sera moins précise, mais l’investissement sera réduit comparé à l’utilisation d’un système LIDAR 3D.
Pour réaliser notre étude, nous avons sélectionné des algorithmes sur la base de plusieurs critères : projet disponible pour ROS, code Open Source, nombre de contributeurs au développement du code, date de la dernière évolution du code, popularité du projet basée sur le nombre de forks, le nombre de vues des vidéos internet, ratio de bugs repérés et résolus par la communauté.
Un tableau comparatif a été établi :
- Hector SLAM,
- GMapping,
- Google Cartographer.
Ainsi qu’une technologie caméra :
- RTAB-Map.
Enfin, les éléments étudiés concernant les algorithmes cités portent sur :
- la qualité générale de la carte ;
- les artefacts et la résilience face aux entités mobiles ;
- la résilience aux bugs ;
- la consommation des ressources systèmes.
