Test & analyse de Google Cartographer
Avant-dernier épisode du benchmark des technologies de cartographie utilisées par les robots mobiles dans des environnements intérieurs. C’est au tour de Google Cartographer de passer au crible, après GMapping et Hector Slam.
Cette technologie LIDAR 2D a été évaluée sur la base de différents critères (méthodologie de l’étude disponible en fin d’article) et testée dans un environnement fréquenté de type “open space”.
Pour rappel, 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 la technologie Google Cartographer
Intégrée depuis 2016 au système d’exploitation robotique de référence ROS (Robot Operating System), Google Cartographer est sans doute l’algorithme SLAM le plus populaire, en témoigne la multitude de projets qui l’utilisent. La documentation qui l’accompagne a notamment contribué à favoriser son rayonnement.
Google Cartographer se caractérise par un fonctionnement complexe : la solution propose des fonctionnalités de mapping 2D et 3D. Les fonctionnalités 3D nécessitent d’apporter à la plateforme les données d’une centrale inertielle ou d’un nuage de points généré par un lidar 3D ou une caméra stéréo ou RGBD.
Afin d’affiner la précision, il est possible d’utiliser les données de plusieurs lidars en parallèle. On peut également régler un large panel de paramètres afin d’améliorer les performances en fonction des variations de capteurs, de latences, etc. Ce procédé s’appelle le fine-tuning.
Qualité générale de la cartographie
Carte de la “trajectoire en P” générée avec Google Cartographer
Surimpression de la carte Google Cartographer de la “trajectoire en P” sur le plan du bâtiment
La cartographie est de bonne qualité : Google Cartographer modère de lui-même sa confiance sur la cartographie d’une section.
On observe en effet une légère surimpression, notamment au niveau des murs qui obtiennent ainsi un aspect flouté et des contours lissés après plusieurs passages.
- cartographie de la reconstruction de rotations : précis
- détourage des fauteuils (de forme circulaire) : précis
- cartographie en temps réels des couloirs en ligne droite (murs, alcôves, etc.). : nette
Fiabilité et résilience face aux entités mobiles
Concernant les entités mobiles, aucun trou, ni aucune instabilité n’ont été causées par des personnes en mouvement.
La capacité de Google Cartographer à donner une opacité variable à la carte permet de dégager un indice de confiance sur la présence ou non d’obstacles.
Fiabilité et résilience face aux bugs
TEST 1
- 10 secondes de gel LIDAR dans un couloir à t=100s
- 10 secondes de gel odométrie en plein virage à t=155s
On constate avec le premier test que la coupure du lidar seul ne génère pas de problème sur la cartographie. La coupure de l’odométrie dans un virage a quant à elle causé une désorientation visible dans la première partie de la carte.
TEST 2
- 10 secondes de gel LIDAR & odométrie dans un couloir à t=100s
- 10 secondes de gel LIDAR & odométrie en plein virage à t=155s
Le test 2 montre que l’algorithme a réussi à s’adapter au gel d’informations. Aucune donnée issue du lidar n’a été utilisée en même temps que l’odométrie erronée.
TEST 3
- publication de l’odométrie limitée à un message toutes les 3 secondes
En revanche, le test 3 fait état d’une dégradation de la qualité de la carte : les zones de rotation n’ont pu être construites correctement.
Consommation en ressources système
Graphe d’utilisation des ressources pour un ordinateur doté de 8 coeurs à 2.80GHz et de 16Go de RAM
Google Cartographer augmente sa consommation de RAM à mesure de la construction de la carte jusqu’à atteindre 1,1%, soit ~176Mo. Google Cartographer apparaît donc économe et optimisée en gestion de mémoire RAM.
Google Cartographer utilise 10 à 20% des ressources processeurs, mais exigera toutefois des pointes de calculs jusqu’à mobiliser l’équivalent de 4 processeurs : ces cycles semblent coïncider avec les opérations de fermeture de boucle.
Evaluation de Google Cartographer
LE VERDICT
Comparée à GMapping et HectorSLAM, Google Cartographer semble à ce stade plus résiliente aux bugs et capable de construire une carte riche en informations : l’opacité de la carte est variable en fonction de la confiance quant à la présence d’obstacles ou de zones libres. Cette force lui permet de corriger des erreurs lorsque la zone est parcourue de nouveau.
RTABMAP saura-t-il faire mieux ? Rendez-vous dans une quinzaine de jours !
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 une technologie caméra :
- RTABMAP.
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.
