C10-2

ROBOTIQUE MOBILE

Romain Michalec et Aude Voinçon

Introduction

Dans le cadre du cours de robotique mobile, nous avons réalisé un projet de bout en bout. Nous avons choisi nous même le sujet et nous nous sommes fixés les limites de la réalisation pratique. Le but de se projet est de se familiariser avec les problématiques de la robotique mobile. Nous avons découvert les problèmes liés à la simulation de robots et entrevu les difficultés de passer de la simulation à la pratique.

Sujet du projet

1- Motivations

Forts de cette constatation, nous proposons ici une idée de projet de robotique visant à améliorer le quotidien douloureux des programmeurs, et plus particulièrement des élèves de l'Ensta que de longs et difficiles projets de maths ou d'informatique verrouillent les soirs, les week-ends et une bonne partie des vacances dans les salles informatiques de l'école, devant des écrans blafards et des compilateurs peu coopératifs.

Il s'agit de réaliser la commande d'un robot domestique Aibo pour l'accomplissement d'une tâche en apparence simple mais d'une importance vitale : aller chercher de la bière au bar de l'école, et la rapporter jusqu'à l'ordinateur du programmeur.

2- Sujet réellement traité

Ce sujet général peut se découper en trois parties :

• prendre la commande,

• planification de la trajectoire

• localisation et navigation autonome entre la salle et le bar

• attirer l'attention du barman et passer commande

De façon pratique, cette première bonne idée n'est pas réalisable dans sa totalité. Dans le temps imparti, nous nous sommes concentré sur la partie de localisation et de navigation de l'Aibo. Pour cela, nous avons choisi le filtrage particulaire pour la localisation et le recalage par rapport à la trajectoire donné par l'utilisateur. Le robot n'aura pas à réaliser la planification de façon autonome.

De plus, l'Aibo ne dispose pas de beaucoup de capteurs qui sont nécessaire pour le filtrage. En pratique, on utilise sa caméra et le blobfinder. Celui-ci permet de repérer des patchs colorés sur les murs. Le blobfinder de l'Aibo renvoie l'aire en pixels sur l'écran, ainsi que la position du centroïde du blob sur l'écran.

Le filtrage particulaire a été réalisé en simulation avec Player-Stage. Si cela avait été possible l'algorithme aurais été testé aussi sur l'Aibo en conditions réelles, c'est à dire dans les salles de l'école avec des patchs collés au mur.

Algorithme de filtrage particulaire en C++

1- Le filtrage particulaire

Le filtrage particulaire permet de localiser un robot grace à une population de particules ou « robots virtuels ». Chaque particule possède tous comme le robot une position et une orientation. De plus, elles ont toutes un poids représentant la probabilité de présence du robot au même endroit. Le principe du filtre est de faire évoluer les particules de la même façon que le robot pour déterminer la nouvelle position du robot en comparant ses perceptions à celles des particules. Ici on utilise un filtre particulaire SIR : sequential importance resampling, c'est à dire que les particules sont resélectionnées à chaque itération suivant leur importance. L'intérêt principal du filtrage particulaire est le suivi d'hypothèses multiples. Une itération du filtre peut se découper en trois étapes :

• Mutation : on fait évoluer les particules à peu près selon l'odométrie du robot. En pratique, on ajoute à la distance donnée par l'odométrie une variable aléatoire tirée selon une loi gaussienne représentant l'erreur de l'odométrie par rapport au déplacement réel. On fait de même avec l'angle de rotation retourné par l'odométrie.

• Pondération : les particules sont pondérées suivant la distance entre les perceptions du robot et leurs perceptions. Ici, les perceptions sont représentées par les caractéristiques des blobs vus. Plus les perceptions simulés de la particule sont proche des perceptions du robot plus celle-ci à un poids important.

• Redistribution : les particules sont sélectionnées avec une probabilité fonction de leur poids. On modifie donc la population de particules pour avoir à l'itération suivante une population plus rassemblée autour de la position réelle du robot.

2- Architecture C++

Nous nous sommes basé sur un algorithme de filtrage particulaire en Matlab fait auparavant. Cet algorithme considérait que le robot possédait une couronne de laser. En partant de conditions initiales aléatoires pour le nuage de particules, le robot est localisé en 3 ou 4 itérations avec 500 particules. Le problème de Matlab est principalement sa lenteur, nous avons donc décider de recoder l'algorithme en C++ pour que les itérations soient plus rapides.

Nous avons découpé le problème en quelques classes :

• une classe particule qui représente une particule avec sa position, son orientation, son poids et ses perceptions,

• une classe blob qui possède une position, une orientation (0 ou pi/2), et une aire réelle en m²,

• une classe carte qui fait l'affichage en utilisant la librairie Magick++,

• une classe monde qui contient la carte et ses blobs, le nuage de particules, la position estimée du robot et qui réalise la partie algorithmique du filtre.

A chaque fois qu'une itération est lancée, les particules évoluent. Ce qu'on cherche à savoir, c'est la position estimée du robot. Pour cela, on sélectionne un pourcentage des particules les plus probables et on regarde si elles sont toutes autour d'un seul point. Si c'est le cas, on estime la position du robot au barycentre des positions de particules. Si ce n'est pas le cas, cela signifie que les particules sont dispersées dans toute la carte, ou bien qu'il y a un suivi d'hypothèse multiple. Dans les deux cas, la position ne peux pas être connue avec précision. La position obtenue après chaque itération sera celle utilisé pour le contrôle de trajectoire et la localisation.

Snapshot filtre particulaire

Itération 0	Itération 2	Itération 4
Itération 8	Itération 12	Itération 16

Interface avec Player–Stage, loi de commande

1- Simulation d'un Aibo avec Stage

2- Utilisation de la localisation dans un problème de suivi de trajectoire

Une fois le robot localisé avec précision, au bout de quelques itérations de filtre, il devient possible de l'asservir en position sur la trajectoire prédéfinie, dans le cas où le robot en dévierait (glissement des pattes sur le sol). Compte tenu du peu de commandes disponibles (tourner « ou » avancer, et le « ou » est exclusif), il est illusoire d'espérer réaliser un contrôleur décent. La stratégie adoptée est donc la suivante : si la position estimée du robot, obtenue à chaque itération du filtre, s'écarte trop de la trajectoire « point de départ – point à atteindre » (une ligne droite ; la trajectoire de référence est un ensemble de segments de droite à suivre), on réoriente le robot de façon à lui faire suivre un nouveau segment de trajectoire, le segment « position estimée courante – point à atteindre ». Ceci permet le suivi de la trajectoire de référence, quoique la marche résultante soit un peu mécanique. Le cas où le robot s'emballe et part dans une direction opposée est aussi théoriquement prévu.

Difficultés rencontrées

1- Le blobfinder : des perceptions difficiles à analyser

La difficulté majeure rencontrée pendant tout le projet a été d'utiliser les données du blobfinder. Pour les perceptions des particules, il a fallu simuler les perceptions des particules et notamment trouver l'aire des blobs vus par les particules. Le calcul d'aire sur l'écran par rapport à l'aire réelle est bien plus compliqué qu'un calcul de distance entre deux points comme pour la simulation de données laser.

De plus, les perceptions retournées par le blobfinder sont peu nombreuses, contrairement à des données de lasers ou de sonars (5 ou 6 blobs vus en même temps). Elles sont surtout de taille variable, ce qui rend difficile le calcul d'une mesure de similitude entre les perceptions du robot et celle d'une particule. Pour s'affranchir de cette situation, la solution la plus naturelle consiste à appliquer brutalement un poids de zéro aux particules qui n'observent pas le même nombre de blobs que le robot. Ceci nous prive parfois de particules proches de la position réelle du robot.

En outre, les données du blobfinder sont peu fiables pour les blobs lointains et ceux parallèles à la direction de regard de la caméra : du fait de la faible résolution de la caméra, deux blobs proches peuvent être fusionnés. Alors que pour les particules, tous les blobs sont distincts et il n'existe pas d'erreur de vision.

Enfin, certains blobs lointains partiellement masqués par des murs plus proches restent détectés par le blobfinder du simulateur; en revanche, leur centre étant masqué, ils ne sont pas détectés par nos calculs sur les particules. Robot et particules n'ont donc pas la même perception, même s'ils sont rigoureusement au même endroit.

Dans nos efforts désespérés de nous affranchir des problèmes de ce capteur peu fiable, nous avons :

• réduit la taille des blobs pour les rendre quasi ponctuels (pour réduire le problème des blobs partiellement visibles),

• disposé un grand nombre de blobs le long des murs de façon à matérialiser l'espace aux yeux du blobfinder (cela permet aussi d'avoir plus de perceptions)

• réduit la portée de détection du blobfinder pour éviter la fusion des blobs dans le lointain.

Malgré tous ces compromis et aménagements, les perceptions restaient trop mauvaises pour se localiser correctement. Nous en avons été réduit à utiliser une information de distance retournée par le blobfinder simulé, substituant cette information à l'aire des blobs. Cette astuce n'est pas très naturelle car le blobfinder réel de l'Aibo retourne des aires en pixels et non des distances. Cependant elle reste légitime, car aire et distance sont corrélées : un blob petit est un blob lointain en général.

2- Utilisation de libplayerc++

Il faut aussi mentionner que la librairie d'interfaçage avec le simulateur, libplayerc++, nous a réservé quelques surprises "amusantes", qui ne sont hélas pas allées dans le sens d'une aide. Parmi elles, on doit citer la concision, souvent désarmante, de la documentation, et son exactitude, parfois approchée, qui laisse l'impression d'une documentation générée par Doxygen à partir de vieux commentaires ne correspondant plus à la réalité du code de la librairie...

Mais la bizarrerie la plus mémorable restera sans doute la fonction Position2dProxy::ResetOdometry (), qui est censée réinitialiser les compteurs d'odométrie du robot, et dont on a remarqué... qu'elle prenait un certain temps ! Très curieusement, son effet n'est pas immédiat, de sorte qu'on as dû temporiser chacun de ses appels par un sleep(1). Cette "fonctionalité", assez incroyable, restera un des grands mystères de libplayerc++.

Conclusion

Le projet a aboutit à un module de localisation / navigation par vision et détection d'amers de couleur à peu près fonctionnel. Cependant, il reste du travail avant d'envisager le passage au monde réel avec implémentation sur Aibo ; en particulier, il faut améliorer la localisation par amers en utilisant les informations d'aire retournées par le blobfinder.

Ce projet nous a permis de nous confronter au problème de la localisation lorsque peu de données capteurs sont disponibles (en l'occurrence, il s'agit d'une petite caméra embarquée). La conclusion est simple : réaliser dans de telles conditions une localisation correcte est, sinon illusoire, au moins très difficile.