Avez-vous déjà créé un robot ? C’est fun, on peut le dot­er d’un sys­tème de loco­mo­tion, de cap­teurs de prox­im­ité, d’une web­cam… voir d’un bras artic­ulé. On fait mumuse quelques semaines et puis on se dit au final… hey, je fais com­ment main­tenant pour le ren­dre intel­li­gent et lui con­fi­er cer­taines tâches ?

Quand on créé des robots en jeu vidéo, on peut utilis­er des déclencheurs de prox­im­ité, on a des fonc­tions comme “Move­To” qui utilisent du pathfind­ing, etc. Pour saisir un objet, c’est sim­ple, on bal­ance une ani­ma­tion et on grip l’ob­jet au plus proche de la pince… c’est con­fort­able. Mais en robo­t­ique, c’est loin d’être aus­si sim­ple ! le robot n’a pas un “lev­el” qu’il peut inter­roger — enfin, pas directe­ment. C’est la recon­struc­tion du “niveau” par le robot qui nous intéresse.

Je crois que l’une des pre­mières tâch­es à laque­lle il faut réfléchir, c’est la “com­préhen­sion” par le robot de son envi­ron­nement. Cela com­mence par une capac­ité à car­togra­phi­er les lieux et à détecter des “vol­umes”. Ensuite, reste à iden­ti­fi­er ces vol­umes et recon­naitre des objets. C’est déjà une tâche assez com­plexe et nous allons rester sur la par­tie car­togra­phie pour cet arti­cle. SLAM sig­ni­fie Simul­ta­ne­ous Local­iza­tion And Map­ping: cela con­siste à con­stru­ire ou amélior­er une carte de son envi­ron­nement et de s’y localiser.

Le robot doit, pour cela, col­lecter un cer­tain nom­bre de don­nées de son envi­ron­nement et utilis­er ses pro­pres bases de don­nées, de règles et de faits, pour pren­dre des déci­sions en fonc­tion de la tâche qui lui est assignée.

Pour col­lecter des don­nées, le robot utilise des cap­teurs: cela va du cap­teur ultra­son, à la balise GPS, en pas­sant par les caméras et cap­teurs lasers. Nous allons pren­dre un exem­ple sim­ple, con­nu de tous: le kinect de Microsoft. C’est loin d’être le meilleur, mais ça nous donne une base d’étude.

Le Kinect est une caméra dite “RGBD” : c’est à dire qu’au delà du pix­el (RGB), elle four­nit égale­ment une indi­ca­tion de dis­tance pour chaque point. Nous auri­ons pu égale­ment utilis­er plusieurs caméras, avec des angles dif­férents, pour déduire la dis­tance. C’est ce que font nos yeux !

Les car­ac­téris­tiques à retenir sont celles-ci:

• Lentilles détec­tant la couleur et la pro­fondeur: en fait, c’est le cou­ple caméra IR/Laser qui sert à l’es­ti­ma­tion de distance.
  
• Champ de vision hor­i­zon­tal : 57 degrés — Champ de vision ver­ti­cal : 43 degrés — Cap­teur motorisé pour suiv­re les déplace­ments (Marge de déplace­ment du cap­teur : ± 27 degrés)
• 640 × 480 en couleur 32 bits à 30 images par sec­onde — Bon, ça pêche un peu de coté là…
• caméra IR en pus de RGB, mais ne dépasse pas quelques mètres

La pré­ci­sion de la Kinect est rel­a­tive­ment bonne pour de faibles dis­tances mais qu’au-delà de quelques mètres elle devient trop impor­tante pour être exploité cor­recte­ment. Cela reste surtout fonc­tion­nel pour de l’in­térieur. Mais pas­sons, peu importe le cap­teur, intéres­sons nous à la méthode.

La THEORIE

Dans tous les cas, nous util­isons la tech­niques des points d’in­térêt. C’est un point qui car­ac­térise de façon unique une par­tie de l’im­age. Nous en avons déjà par­lé avec l’ar­ti­cle sur ACAZE. l existe une mul­ti­tude d’autres méth­odes de détection/description de points d’intérêt par­mi lesquelles SIFT et SURF. Il s’agit de méth­odes par­ti­c­ulière­ment appré­ciées pour leur robustesse et leur efficacité.

Une fois les points d’intérêts cal­culés dans chaque image il faut pou­voir déter­min­er quel est le mou­ve­ment glob­al de la caméra. Pour cela on doit trou­ver quelle trans­for­ma­tion per­met de rec­oller cor­recte­ment les deux nuages de points for­més par les points d’intérêt.

L’al­go­rithme RANSAC (RAN­dom SAm­ple Con­sen­sus) est clas­sique­ment util­isé pour extraire un mod­èle d’un ensem­ble de don­nées bruitées. L’estimation de mou­ve­ment avec RANSAC est en générale assez bonne mais dans le cadre de la con­struc­tion d’une carte il est préférable d’affiner cette esti­ma­tion avec une autre méth­ode comme ICP. ICP (Iter­a­tive Clos­est Point) est un algo­rithme qui per­met de min­imiser la dis­tance entre deux nuages de points A et B.

Avec ces méth­odes com­binées on peut donc estimer le déplace­ment de la caméra entre deux images suc­ces­sives. On recon­stru­it alors au fur et à mesure des déplace­ments la tra­jec­toire de la caméra tout en mod­élisant l’espace 3D.

Bien que la pré­ci­sion de ces méth­odes soit bonne, on con­state une dérive de la posi­tion au cours du temps due à l’accumulation des erreurs de mesure. L’al­go SLAM per­met de cor­riger les erreurs accu­mulées pen­dant la phase d’estimation de mou­ve­ment en vue d’obtenir un mod­èle cohérent de l’environnement.

En fait, on part du principe que ni la posi­tion de départ ni l’es­ti­ma­tion du mou­ve­ment du robot ne sont exactes. On va donc insér­er un peu de prob­a­bil­ités dans l’al­go.  Il existe deux formes de SLAM. Le pre­mier nom­mé «online prob­lem» con­siste à cal­culer à chaque instant la posi­tion actuelle du robot en fonc­tion des esti­ma­tions de mou­ve­ments et des obser­va­tions.  La sec­onde est nom­mée «full SLAM prob­lem» et con­siste cette fois à cal­culer à chaque instant l’ensem­ble de la tra­jec­toire à par­tir de l’odométrie et des obser­va­tions. Donc dans le pre­mier cas, la posi­tion, dans le sec­ond, la tra­jec­toire complète.

La PRATIQUE

Bon, je ne vais pas entr­er dans le détail dans le fond de l’al­go­rithme, mais voyons plutôt com­ment l’u­tilis­er. Nous allons utilis­er le pro­jet RTAB-Map: La détec­tion de fer­me­ture de boucle est le proces­sus impliqué en SLAM lorsqu’on tente de trou­ver une cor­re­spon­dance entre un endroit présent et un autre déjà vis­ité. Plus la carte interne aug­mente en taille, plus le temps req­uis pour la détec­tion de fer­me­ture de boucle aug­mente, ce qui peut affecter le traite­ment en temps réel. RTAB-Map est une nou­velle approche de détec­tion de fer­me­ture de boucle fonc­tion­nant en temps réel pour du SLAM à grande échelle et à long terme.

Ce pro­jet s’ap­puie sur d’autres librairies:

• TORO: c’est l’im­plé­men­ta­tion de l’al­go prin­ci­pal de SLAM
• ROS: Pour la visu­al­i­sa­tion — ROS est un méta sys­tème d’ex­ploita­tion open-source qui four­nit l’ensem­ble des ser­vices clas­sique­ment four­nis par un sys­tème d’ex­ploita­tion comme la ges­tion des tâch­es de bas niveau ou les com­mu­ni­ca­tions inter-process. Il four­nit aus­si un très grand nom­bre d’outils et de bib­lio­thèques facil­i­tant les développements.
• PCL (incluse dans ROS): Il s’ag­it d’une bib­lio­thèque dédiée au traite­ment de don­nées type nuage de points (Point Cloud Library). Ca fonc­tionne sous win­dows, Lin­ux, MacOs, Android et iOS — c’est par­fait. PCL sup­porte Kinect mais aus­si d’autres periphériques et stan­dards. Et ce qui ne gâche rien, il y a des bind­ings pour Python (native­ment en C++).  Et puis ça nous chang­era d’OpenCV qu’on con­nait déjà bien.
• Open­ni (incluse dans ROS): pour la récup des don­nées de la Kinect.

Pour ma part, j’ai com­mandé l’adap­ta­teur Kinect 360 pour PC et je compte enchain­er les tests autour de RTAB-Map pour voir ce qu’il a dans le ven­tre.  J’aimerais aus­si cou­pler l’ensem­ble à un autre sys­tème de cap­teurs pour les envi­ron­nements extérieurs, mais on ver­ra un peu plus tard. Donc, soyez patient, la suite d’i­ci quelques mois après mes pre­miers tests.