Sujet 10 - Rapport de projet Un peu d’IA dans un cerveau ...

Ministere de l’Education Nationale

Universite Montpellier II

Rapport de projet de l’unite d’enseignement FMIN200Master Informatique a Finalites Professionelle et Recherche 1ere annee

Sujet 10 - Rapport de projet

Un peu d’IA dans un cerveau de robot

Encadrants BOURREAU Eric

Auteurs PERALTA EmmanuelSICCARDI ChristopheTHEOCARI Elie

Table des matieres

1 Introduction 41.1 Le sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Pourquoi ce choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Presentation du sujet 52.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Planning initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Une premiere approche : Lego Mindstorms NXT et URBI 73.1 Presentation des robots Lego Mindstorms NXT . . . . . . . . . . . . . . . . 8

3.1.1 Vue generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.1.2 Gros plan sur le Tribot . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Presentation d’URBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.1 Vue generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.2 URBI pour Mindstorms NXT . . . . . . . . . . . . . . . . . . . . . . 103.2.3 Faire fonctionner le NXT avec URBI . . . . . . . . . . . . . . . . . . 10

3.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4 Experimentations sur les robots . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4.1 Reflexion sur les experiences a realiser . . . . . . . . . . . . . . . . . 143.4.2 Algorithme et implementation du code URBI . . . . . . . . . . . . . 153.4.3 Realisation des experiences . . . . . . . . . . . . . . . . . . . . . . . . 16

3.5 Premieres conclusions... et perspectives . . . . . . . . . . . . . . . . . . . . . 173.6 John Robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.6.1 Presentation de l’experience . . . . . . . . . . . . . . . . . . . . . . . 183.6.2 Algorithme et implementation du code URBI . . . . . . . . . . . . . 193.6.3 Realisation des experiences . . . . . . . . . . . . . . . . . . . . . . . . 19

3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Vers un portage URBI pour HOAP ? 21

5 Conclusion et perspectives 225.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.2 Difficultes rencontrees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1

TABLE DES MATIERES 2

6 References 246.1 References bibliographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.2 References numeriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

A Implementation URBI du code ((attrape-canette)) 25

B Implementation URBI du code ((John Robot)) 27

C Cahier de laboratoire 28

Remerciements

Nous tenons a remercier l’Universite Montpellier II et le Laboratoire d’Informatique, deRobotique et de Micro-electronique de Montpellier pour nous avoir permis de travailler surce sujet de TER qui representait exactement ce que nous nous attendions a trouver aucroisement des domaines de l’Intelligence Artificielle et de la Robotique.

Merci a notre tuteur, M. Eric Bourreau, qui nous a parfaitement encadres et a su repondrea toutes nos questions. Merci egalement aux autres intervenants du LIRMM que nous avonseu l’occasion de rencontrer dans le cadre de notre etude, MM. Mathias Paulin et PhilippeFraisse du Departement de Robotique du LIRMM, et qui ont fait preuve de beaucoup d’interetquant a l’avancee de notre travail.

Merci enfin aux personnes qui liront ce rapport, a celles qui jugeront, critiqueront, oucomplimenteront notre travail, et a toutes celles qui, dans un futur plus ou moins proche,permettront a la robotique et a l’intelligence artificielle d’atteindre des sommets.

3

Chapitre 1

Introduction

Dans le cadre du Master 1 Informatique un TER (Travail d’Etude et de Recherche) a groscoefficient etait a realiser. Nous devions donc nous regrouper par groupes de 3 ou 4 maximumet choisir un sujet parmi une liste a notre disposition a cette adresse :

http ://www.lirmm.fr/ leclere/enseignements/TER/2008/sujets-08.html.Il etait bien sur preferable de choisir un sujet inscrit dans le parcours suivit (I2A, GL,

DIWEB, CASAR). Etant tout les trois en I2A nous avons choisi en commun le sujet de M.Bourreau a savoir “Un peu d’IA dans un cerveau de robot humanoıde”.

1.1 Le sujet

Voici le sujet tel qu’il etait presente sur le site.Au LIRMM, nous avons la double chance d’avoir a la fois un departement Robotique

et un Departement Informatique. Le departement Robotique a acquis en fevrier dernier unrobot humanoıde HOAP de Fujistu. Dans le meme temps, le departement informatique aconcu une nouvelle plateforme logicielle COGITOIDE permettant de simuler la reflexion afind’introduire de l’autonomie au sein du “cerveau” d’un robot.

Le sujet de ce TER est de coupler techniquement les deux approches afin de pouvoirrealiser de demonstrations reelles de comportements autonomes (non programmes) et intel-ligents.

Techniquement, la plateforme physique est une version de RTLinux. Plusieurs coucheslogicielles permettent d’acceder aux capteurs et moteurs physiques. De l’autre cote, la plate-forme de reflexion est basee sur des librairies Java. Pour faciliter la tache et rendre celle-cigenerique, un langage d’interface URBI a ete acquis au laboratoire. Il permet de s’abstrairede la couche physique a partir du moment ou la librairie existe... un portage et une extensionde la librairie Java/Linux sera donc a realiser.

1.2 Pourquoi ce choix

Ce sujet nous a beaucoup interesse pour son rapport direct au monde de la recherche etplus particulierement a la section intelligence artificielle sur la robotique du laboratoire. Enchoisissant ce sujet nous etions surs de travailler avec des robots afin de les programmer pourobtenir de leur part un comportement intelligent reproduit.

4

Chapitre 2

Presentation du sujet

2.1 Contexte

Pour ce Travail d’Etude et de Recherche, nous etions directement lies au LIRMM, le Lab-oratoire d’Informatique, de Robotique et de Micro-electronique de Montpellier, et plus par-ticulierement au croisement de la partie robotique et informatique de ce laboratoire, puisquenous avons eu la chance de travailler avec des enseignants chercheurs dans la programmationd’intelligence artificielle robotique.

Au LIRMM, plusieurs robots sont a la disposition des chercheurs. On y trouve notammentun modele du fameux HOAP de Fujitsu, le seul exemplaire en France, et plusieurs robotsde type Mindstorms NXT, une creation de Lego. Ces derniers sont de petites machinesprogrammables dotes de quelques capteurs et moteurs, tout ce qu’il y a de plus basique.

Le but de nos encadrants, qui travaillent au LIRMM, est de programmer leurs robots desorte a ce que ceux-ci ”apprennent”, en quelque sorte, de leurs erreurs et de leurs experiencespassees, donc de rendre leurs comportements ”intelligents” face a des situations faites pourles destabiliser.

Pour ce faire, ils utilisent un langage de programmation nomme URBI. Ce langage a laparticularite de se generaliser a tous les robots a partir du moment ou les pilotes necessairesexistent pour son portage. Et c’est le cas des robots Mindstorms. Deux exemplaires de cesautomates nous ont ainsi ete confies par nos encadrants, afin de pouvoir travailler librementsur les objectifs qui nous ont ete fixes.

2.2 Objectifs

Nous avons divise le TER en deux parties distinctes.La premiere consistait a prendre en main la programmation d’un robot afin de lui faire

effectuer des actions a partir de mouvements basiques, et de realiser un cahier de laboratoiredes experiences realisees. Cela nous permettrait d’observer les limites des automates liees al’environnement ou au materiel.

La seconde, quant a elle, tendait a trouver un moyen de realiser un portage du langageutilise pour Mindstorms vers d’autres types de robots, incluant HOAP. En effet, HOAP n’estpas une machine directement programmable via le langage URBI etant donne qu’aucun pilotene permet le portage pour ce robot dans ce langage.

5

2.3 Planning initial 6

C’est dans cette optique que nous avons decide de raisonner afin de realiser une vraieetude de recherche.

2.3 Planning initial

Voici le premier planning de travail que nous avons concu.Janvier - Mise en situation– Semaine 1 : prise de connaissance du sujet et des membres du groupe.– Semaine 2 : premier rendez-vous avec l’encadrant. Explications generales sur le contexte

du TER.– Semaine 3 : second rendez-vous avec l’encadrant. Explications plus precises sur le sujet

et ce qui est attendu de nous. Repartition du materiel et des taches.Fevrier - Travail avec URBI– Semaine 4 : prise en main des robots Lego Mindstorms NXT via l’applet graphique de

Lego, puis avec URBI.– Semaine 5 : reflexion quant a des experiences a realiser, outre le test de l’((attrape-

canette)) qui doit etre reussi.– Semaines 6 et 7 : realisation des experiences et elaboration du cahier de laboratoire.Mars - Travail avec HOAP– Semaines 8 a 11 : decouverte de HOAP. Reflexion a un eventuel portage du travail

realise avec URBI en fevrier.Avril - Finalisation– Semaines 12 a 14 : debordement. Finalisation du rapport. Preparation a la soutenance

orale.

Chapitre 3

Une premiere approche :Lego Mindstorms NXT et URBI

Fig. 3.1 – La brique programmable des Mindstorms

7

3.1 Presentation des robots Lego Mindstorms NXT 8

3.1 Presentation des robots Lego Mindstorms NXT

3.1.1 Vue generale

Les robots Mindstorms sont une invention du fabricant de jeu danois Lego. Comme tous lesLego, ils peuvent etre montes, demontes, remontes a l’infini, prennent n’importe quelle formeimaginable ; mais la particularite des Mindstorms est qu’ils integrent un bloc (aussi appele”brique”) programmable par l’utilisateur, lui permettant de rendre son appareil intelligent.Pour un usage plus intuitif, celui-ci prendra l’apparence d’une voiture telecommandee, d’unegrue ou encore d’un robot humanoıde, pour la version la plus recente.

La brique, en plus de pouvoir servir a commander le robot, peut etre reliee a diverscapteurs qui lui permettront de se faire une idee de l’environnement dans lequel il doit agir,et qui sont consultables a tout moment par l’utilisateur. C’est ici qu’entre en jeu l’aspect”intelligence artificielle”. Il ne s’agit plus de commander un robot comme on dirige unevoiture telecommandee : notre automate doit, en fonction des directives que nous lui auronsdonnees et de la representation qu’il se fait de son environnement, s’auto-gerer.

Les robots qui nous ont ete confies par le LIRMM sont des appareils de type NXT : ils’agit de la seconde version de Lego Mindstorms, la premiere etant le type RCX. La principaledifference entre les deux versions reside dans l’ajout de capteurs : le capteur d’ultrasons, parexemple, n’etait pas present chez les RCX. En revanche, le capteur de temperature a disparu.On note egalement la malheureuse disparition de l’adaptateur secteur, bien utile pourtantau vu de la consommation de la bete.

Voici la liste des capteurs que nous pouvons trouver sur ces robots :– un capteur photosensible qui permet de mesurer la luminosite ambiante ;– un capteur sonore qui evalue l’intensite sonore en decibels ;– un capteur d’ultrasons afin d’estimer la distance separant notre automate de l’objet qui

se trouve en face de lui ;– un capteur tactile qui detectera la pression a un endroit donne du Lego, le bumper, et

renverra une valeur en consequence.D’autres capteurs, vendus separement, comme le capteur de couleurs ou la boussole,

peuvent donner aux utilisateurs aguerris une bonne opportunite de composer des programmesencore plus fins. Pour les besoins de notre TER, nous avons travaille sur les quatre decritsci-dessus.

En sortie, les informations seront relayees a trois servo-moteurs. Selon la construction duprogrammateur, ils seront relies aux roues (robots roulants), aux jambes (robots humanoıdes),a la pince (grue)... et le Mindstorm pourra donc effectuer les actions qui lui sont assigneespar son constructeur ou en fonction des informations recues par les capteurs.

3.1.2 Gros plan sur le Tribot

Comme nous l’avons precise au-dessus, un NXT est avant tout un Lego et peut doncprendre une multitude de formes. Cependant, pour en tirer pleinement profit, il est preferablede suivre les conseils du fabricant qui nous propose quatre constitutions bien pensees : unrobot de type humanoıde, l’Alpha Rex, un robot de type animal (un scorpion), Spike, un detype grue, le RoboArm T-56, et enfin un de type vehicule, le Tribot. Il nous etait demandede travailler sur le dernier cite, etant donne que nos encadrants de TER menaient deja destravaux dessus.

3.2 Presentation d’URBI 9

Fig. 3.2 – Un Lego Mindstorms NXT sous sa forme Tribot

Le Tribot est constitue de la brique NXT qu’il arbore fierement en partie centrale, celle-cietant supportee par deux roues commandees par deux des trois servo-moteurs, et d’une roueque nous qualifierons de libre etant donnee qu’elle suit plus ou moins la direction imposee parles deux autres. Le capteur ultrasons est fixe a l’avant du vehicule, le capteur sonore a sonsommet, et enfin le capteur de luminosite est attache au niveau des roues, sous la brique. Letroisieme servo-moteur, celui qui n’est pas utilise par les roues, aura pour fonction d’ouvriret de fermer la pince qui se situe elle aussi a l’avant, permettant d’attraper des objets dediametre moyen, tels qu’un verre ou une bombe aerosol. Et au milieu des pinces, se trouvele dernier capteur, le capteur de pression.

3.2 Presentation d’URBI

3.2.1 Vue generale

Les quatre lettres URBI signifient Universal Real-time Behavior Interface, ou en francais,Interface Universelle pour les Systemes Interactifs. Celle-ci permet de commander a distancedes automates, exactement ce dont nous avons besoin dans notre Travail d’Etude et deRecherche. Elle marche sur le principe client – serveur, le serveur etant donc l’ordinateurde l’utilisateur, et le client etant le robot. Cette plate-forme logicielle a ete creee par une


entreprise francaise du nom de Gostai, basee a Paris, et a fait sa premiere apparition en2003.

Pour programmer, nous nous sommes servis du langage du meme nom, avec une syntaxeproche de celle du langage C++. Celui-ci permet, pour les utilisateurs avances, d’utiliser desnotions complexes comme la programmation dynamique. Cependant, dans le cadre de notreprojet, nous n’avons pas eu a aller jusque la.

3.2.2 URBI pour Mindstorms NXT

Gostai a developpe plusieurs plateformes, en fonction du type de robot qui doit etrecommande par URBI. Nous avons donc telecharge la version pour Lego Mindstorms. Nouscontinuerons d’evoquer par la suite cette version pour Mindstorms par le simple terme URBI.

L’avantage d’avoir une version specifique aux Mindstorms est que les developpeurs dulangage URBI correspondant connaissaient la structure de nos robots, et ont ainsi rendusimplissime la programmation pour des utilisateurs meme novices. Par exemple, la simplecommande

wheels = 20;

demande a notre automate de se deplacer en avant, a une vitesse de 20 [unite]. Vous trouverezen annexe un rapide tutorial sur la version Mindstorms de URBI, presentant les principalescommandes et quelques petits exemples de codes.

Cela a permis une prise en main quasi-immediate du langage, et nous avons donc pucommencer sans tarder a pratiquer nos premieres experiences sur les deux modeles de LegoMindstorms NXT que nous a procures le LIRMM.

3.2.3 Faire fonctionner le NXT avec URBI

Ainsi que nous l’avons explicite precedemment, URBI fonctionne sur le principe client -serveur. Il faut donc demarrer une application sur l’ordinateur de l’utilisateur (le serveur) ety connecter notre robot (le client) afin de pouvoir commander ce dernier.

Voici dans l’ordre les etapes que nous avons suivies pour effectuer nos experiences :– en premier lieu, relier le Mindstorms a l’ordinateur par l’intermediaire d’un cable USB.

Une connexion Bluetooth est egalement possible, en supposant toutefois que nous dis-posons d’un ordinateur equipe en consequence...

– lancer ensuite le serveur URBI pour Mindstorms. Si le robot n’est pas connecte ou horstension, un message d’erreur s’affiche.

– lancer la console URBI pour Mindstorms, qui fait office de client. Une fois celle-cidemarree, il faut connecter le client au serveur en cliquant sur le bouton ”Connectto the LEGO Mindstorms NXT”. Si un fichier URBI a ete cree, il est possible dedemander au robot de suivre les instructions y etant consignees en choisissant ce fichierdans l’explorateur Windows. Sinon, il suffit de les lui envoyer une par une grace a unchamp de texte situe en bas de la console. Cependant, cela ne permet pas de declarerdes fonctions par exemple. Usage reserve donc aux utilisateurs novices qui partent a ladecouverte d’URBI pour Mindstorms...

– cliquer sur Send ! pour envoyer les instructions au robot, et admirer le resultat...Cependant, dans notre situation avec un cahier de laboratoire a realiser, nous ne pouvions

en aucun cas envisager d’afficher les valeurs des capteurs et des moteurs toutes les n millisec-ondes puis de les enregistrer sous une feuille de calcul. Nous sommes donc partis sur le Net


a la recherche d’un programme qui ferait cela pour nous, et nous en avons trouve un, sur lesite UrbiForge dont le lien figure a la fin du rapport, repondant au doux nom d’actionfile.

Avant donc d’expedier nos instructions a notre robot Lego, nous avions une etape de plusa executer : le lancement en console du programme telecharge. Une fois celui-ci en route, ils’est charge de relever les valeurs des capteurs lorsque nous le lui demandions et nous n’avonsplus eu qu’a convertir le fichier cree en format .csv (Comma-Separated Values, un formatlisible par Excel ou le tableur d’Open Office).

Nous voici donc en possession de tous les elements afin de pouvoir mener a bien nosexperimentations.


Fig. 3.3 – Le serveur

Fig. 3.4 – L’executable du programme actionfile.exe


Fig. 3.5 – Le client

3.3 Objectifs 14

3.3 Objectifs

Une fois en possession de nos charmants robots et du langage adequat pour les fairetourner, l’objectif donne par notre encadrant etait de pratiquer diverses experiences sur lesdeux modeles disponibles afin de tester leur (( regularite )), si l’on puit dire. Le but etait doncle suivant :

– reflechir a diverses experiences realisables par des robots peu perfectionnes ;– tester exactement la meme experience, dans les memes conditions, sur les deux robots,

pour comparer leur rendement et le resultat final ;– tester deux experiences proches l’une de l’autre et devant rendre le meme resultat sur

un seul robot pour verifier que le robot reagissait bien de la meme maniere dans les deuxsituations, par exemple dans des conditions environnementales differentes (en matierede niveau sonore ou de luminosite par exemple) afin d’observer (ou non) des disparitesdans les resultats obtenus.

Les resultats devaient etre consignes dans un cahier de laboratoire que nous rendrions avecnotre rapport. Nous nous devions donc de noter le protocole de chaque experience realisee,et de creer des fichiers .csv representant les resultats obtenus.

3.4 Experimentations sur les robots

3.4.1 Reflexion sur les experiences a realiser

La principale difficulte etait de choisir les experiences que nous allions faire realiser anos robots. Au depart, des idees folles nous ont traverse l’esprit, comme par exemple fairetraverser un labyrinthe a nos Mindstorms... Jusqu’a ce que nous observions par nous-memesque meme equipes de technologies de pointe, ils restaient avant tout... des Lego.

Avec un materiel peu precis au niveau du montage, les pieces se clipsant les unes dans lesautres comme dans tout Lego qui se respecte, la precision des robots n’etait deja pas excep-tionnelle. Mais l’autre probleme des Mindstorms reside dans l’electronique... Il ne nous a falluque quelques minutes pour constater que les capteurs avaient parfois de serieux problemes,par exemple lorsque nous le mettions bien en face d’un objet d’une hauteur et d’une largeursuffisante pour qu’il soit detecte par les ultrasons, et qu’il ne le decelait pas.

Nous avons donc revu nos objectifs a la baisse, et nous sommes inspires des travaux de M.Mathias Paulin, chercheur au LIRMM, que nous avons eu l’occasion de rencontrer a plusieursreprises. Sur une video que nous avons pu voir, le robot devait attraper une canette qui etaitdeplacee lorsqu’il s’en approchait.

Nous avons donc realise deux experiences. La premiere consistait a disposer une canette(ou tout autre objet assez haut et large pour etre repere par les ultrasons de notre robot, nousparlerons par la suite de canette) en face du Lego, et la lui faire attraper sans la deplacer.Ce premier protocole nous fournirait une premiere indication de la fiabilite du Mindstorm :on peut difficilement faire plus basique, et il est complique d’imaginer que notre automatepuisse gerer un objet en mouvement s’il ne peut le faire avec une cible fixe.

La seconde experience nous plongeait en plein dans le concept d’intelligence artificielle :il ne s’agissait plus de dire au NXT, ”Tiens, voila une canette en face de toi, attrape-la !” ;mais plutot, ”Seras-tu assez intelligent pour trouver la canette si elle change de positionconstamment ?”. En gros, nous allions placer la canette en face du robot, la deplacer lorsqu’ilarriverait a proximite et observer la reaction du Lego.

3.4 Experimentations sur les robots 15

En realisant chacune de ces experiences plusieurs fois, nous pourrions ainsi nous faireune idee de la fiabilite des robots de type Mindstorms. Mais pourquoi se placer dans desconditions environnementales differentes pour les executer ?

Certains robots ont beau sembler a la pointe de la technologie, il suffit d’un rien pour lesamener a un echec. Demandez par exemple a votre nouvel appareil menager de faire tournervotre machine a laver. Intelligent comme tout, si vous le lui demandez, il commencera partrier le blanc et les couleurs. Et la, survient une panne de courant... Plonge dans l’obscuritela plus totale, le robot est perdu. Nous avons donc voulu savoir ce qu’il en etait avec les LegoMindstorms, qui sont encore loin d’etre les robots de l’an 3000.

3.4.2 Algorithme et implementation du code URBI

L’algorithme auquel nous avons reflechi devait s’inspirer du diagramme etats - transitionssuivant.

Fig. 3.6 – Diagramme etats-transitions

Nous avons donc elabore l’algorithme suivant :

si bumper enfonce alorsrefermer la pince

sinonsi objet detecte a moins de 60cm alors

se deplacer tout droitsinon

chercher un objet a moins de 60 cmfin si

fin si

Le langage URBI fournit tous les predicats necessaires aux tests sur les capteurs, etpermet de fixer les valeurs des moteurs par le biais d’une simplissime affectation. De plus,nous n’avions pas besoin d’expliquer au robot, via le code, d’utiliser telle fonction a telmoment de l’execution : des macros comme catch transition existent, et il suffit d’entrer du

3.4 Experimentations sur les robots 16

code au bon endroit pour que celui-ci soit pris en compte au bon moment. L’algorithmeci-dessus a donc pu etre traduit en code de moins d’une centaine de lignes. Celui-ci figure enannexe.

3.4.3 Realisation des experiences

Premiere experience

Conditions environnementales NormalesPosition de la canette En face du robot

Distance de depart Environ 35 cmCible fixe Oui

Taux de reussite 100%

Effectuee a plusieurs reprises sur les deux robots, cette experience a a chaque fois ete unsucces. Petit point negatif cependant : le Mindstorm NXT a tendance a devier plus ou moinsde sa trajectoire, de facon tres legere certes, mais d’une facon qui peut tout de meme in-fluer sur le resultat de l’experience. Dans notre cas, la faible distance entre le Lego et sonobjectif n’a permis que de constater que nos appareils ne heurtaient jamais ce dernier defacon perpendiculaire. Mais l’angle de deviation, entre 5 et 10 degres, aurait pu faire raterl’observation si la distance de depart avait ete de 80 centimetres ou plus...

Seconde experience - Phase 1

Conditions environnementales NormalesPosition de la canette En face du robot

Distance de depart Environ 25 cmCible fixe Non


Cette experience a ete realisee dans les memes conditions que la premiere. La differenceresidait dans le fait que l’objectif a atteindre par le robot etait, cette fois, en mouvement.Nous placions donc le robot a 25 centimetres de sa cible, droit en face de lui, le laissions tran-quillement avancer et des qu’il se trouvait a une distance minime de la canette (inferieure a5 centimetres), nous retirions celle-ci de sa position initiale. Nous la replacions a environ 25centimetres de lui selon un angle de 90 degres sur sa droite pour tester sa reaction.

Nous avons donc pu en tirer de nouvelles conclusions. Nous avions deja remarque lemanque de rigueur de nos automates dans leurs deplacements, nous avons pu, en plus, nousrendre compte de defaillances dans leur comprehension des situations, et d’un manque derapidite flagrant dans la reaction. Il est par exemple arrive que le Lego continue d’avancerapres que nous ayions deplace sa cible, alors que lui meme notifiait via la console utilisateurqu’il l’avait perdue de vue et que le simplissime code URBI ne laissait la place a aucuneambiguite, ou encore, apres avoir redecouvert la canette, qu’il continue a tourner quelquesdixiemes de seconde... assez pour que sa trajectoire ne se retrouve definitivement faussee.

Ces quelques rates ont donc fait chuter le taux de reussite des experiences... De 100%dans l’experience 1, il passe a 60% dans la premiere phase de cette experience 2.

3.5 Premieres conclusions... et perspectives 17


Conditions environnementales Noir totalPosition de la canette En face du robot



Le niveau de luminosite a-t-il une quelconque incidence sur le bon deroulement de notreexperience ? C’est ce que nous avons tente de decouvrir en plongeant l’environnement durobot dans le noir le plus complet avant de reiterer le protocole de cette experience.

En theorie, arme de son capteur ultrasons, le Lego Mindstorms NXT n’avait pas besoind’autre chose pour se reperer. Et les experiences menees lors de cette deuxieme phase l’ontconfirme. Si le premier robot a connu quelques difficultes, ce sont les memes qui existaientdeja lors de la phase 1 : temps de latence plus ou moins important entre l’evenement ”canettedeplacee” et l’evenement ”robot en mode deplacement”. Au final, il n’a pas paru plus ennuyepour se deplacer dans l’obscurite qu’en plein jour.


Conditions environnementales Niveau sonore tres elevePosition de la canette En face du robot



Comme dans la phase 2, nous avons altere l’environnement de nos Lego Mindstorms NXTen jouant sur un autre critere : cette fois, il s’agit du niveau sonore. Comment reagiront nosautomates au milieu d’un vacarme assourdissant ?

Le taux de reussite n’a ete cette fois que de 40%, et regresse donc par rapport aux deuxphases precedentes. Neanmoins, nous ne pensons pas que cela soit du au niveau sonore treseleve. Les causes d’echec ont ete sensiblement les memes que dans les experiences precedentes,a savoir un decalage entre la detection de la canette et la reprise de la marche avant ou deserreurs au niveau des capteurs.

3.5 Premieres conclusions... et perspectives

Revoyons le resultat de nos experimentations. Comme on pouvait s’y attendre, les robotsn’ont pas connu un taux de reussite de 100%... Quelles sont donc les causes des echecs de nospetites betes ? La plupart du temps, il s’agit d’une erreur de precision lors de la detectionde la canette. Souvent, le robot s’est arrete de balayer avant d’etre en face de son objectif,souvent aussi, il a continue a tourner un petit moment apres l’avoir apercue : cela se comptaiten dixiemes de seconde, mais c’etait suffisant pour lui faire rater son but.

Nous remarquons ensuite comme il nous etait demande, d’un point de vue statistique,que les robots Mindstorms NXT n’ont pas semble affectes par les alterations que nous avonsfait subir a leur environnement.

Toutefois, il en aurait ete autrement si nous avions decide de nous livrer a des experiencesplus pointues. Imaginons par exemple que nous souhaitions que notre robot parte a la chasse

3.6 John Robot 18

a la canette, puis, lorsque nous lui crierions quelque chose, arrete d’avancer et reviennevers nous comme un chien ferait avec son maıtre. L’experience aurait pu marcher dans desconditions sonores normales, mais aurait probablement echoue lors d’une demonstration dansun amphitheatre comble.

Nous avons donc decide d’aller plus loin et de realiser une experience de ce type afin deprouver les limites des automates face a des situations qui peuvent les confondre.

3.6 John Robot

3.6.1 Presentation de l’experience

Les Lego Mindstorms NXT sont equipes d’un capteur de luminosite, d’un capteur ul-trasons et d’un capteur sonore. Or, le premier cite est en realite un capteur qui permet demesurer la luminosite... sous les roues du robot, ou se trouve une LED rouge eclairant lasurface sur laquelle se deplace le robot. Nous en avons pris connaissance lors de la phase 2de l’experience 2, lorsque nous avons realise que les valeurs enregistrees par le capteur deluminosite etaient bien trop peu alterees par rapport aux conditions normales...

Le moyen le plus simple de mettre nos appareils en situation delicate etait donc de jouersur le niveau sonore. Nous avons donc imagine une experimentation mettant en scene JohnRobot, la version sur roues de John Rambo, qui se deplacerait dans une jungle amazonienneici incarnee par un sol carrele plat...

Que ferait John Rambo s’il entendait un coup de feu au-dessus de sa tete ? Il s’arreteraitprobablement un instant, puis reprendrait sa route quelques instants plus tard, une fois queles choses se seraient calmees. Mais si les coups de feu persistent, il prendrait ses jambes ason cou pour se mettre a l’abri plus loin.

Pour John Robot, le principe est le meme. Nous avons simplement remplace les coups defeu par des sifflements stridents. Le robot doit donc debuter son avancee, puis s’arreter s’ilentend un sifflement bref. Au bout de quelques secondes, il reprend son avancee. Seulement,si le sifflement dure assez longtemps, il repart en avant a une vitesse bien superieure a savitesse ((de croisiere)).

Mais le but final n’est bien entendu pas de s’amuser avec une simulation de film holly-woodien. Pour tester les limites du robot, nous allions realiser cette experience deux fois : unepremiere dans des conditions normales, une seconde dans des conditions sonores desastreuses,afin de tester les reactions des Lego dans les deux cas.

3.6 John Robot 19

3.6.2 Algorithme et implementation du code URBI

Voici le diagramme etats - transitions que nous avons concu pour decrire cette experience.

Fig. 3.7 – Diagramme etats-transitions

Nous en avons tire l’algorithme suivant.

si niveau sonore bas pendant 3s alorsavancer normalement

fin sisi niveau sonore eleve pendant 5s alors

avancer tres rapidementfin sisi niveau sonore eleve pendant moins de 5s alors

s’arreterfin si

Avec URBI, cela ne se traduira pas reellement avec des if. En effet, la syntaxe

at(capteur[< <= = >= >]valeur)

permet de tester en parallele (ou presque) les valeurs prises par les capteurs.Une fois encore, la syntaxe simpliste d’URBI nous a permis de coder cela avec une facilite

deconcertante. Le code figure en annexe.

3.6.3 Realisation des experiences

Ainsi que nous l’avions escompte, les deux experiences se sont deroulees de facons totale-ment differentes.

Menee dans le silence, la premiere a connu l’issue que l’on attendait. Le robot a commencea avancer lentement, jusqu’au premier sifflement qui l’a fait s’arreter. Il a repris sa marcheen avant quelques secondes apres et s’est arrete de nouveau apres un second sifflement. Alorsque le Lego etait a l’arret, un long sifflement l’a alors fait repartir a toute vitesse.

3.7 Conclusion 20

La deuxieme experience a ete realisee en creant un environnement bruyant. Apres unpremier arret qui s’est bien passe, une sonnerie de telephone portable a ete detectee par leLego Mindstorm NXT qui l’a percue comme il aurait pu percevoir le sifflement. Celle-ci a eupour effet de le faire repartir en avant alors meme que rien ne lui etait demande.

3.7 Conclusion

Nous avons donc pu en deduire que l’environnement dans lequel est plonge un robotinflue bien sur ses reactions. Si un humain ou un robot tres perfectionne aurait pu discernerle sifflement au milieu des autres sons emanant de celui-ci, cela n’a pas ete le cas du Lego quis’est retrouve perdu entre sifflements et sonneries de telephone portable. Nous avons donc eul’occasion de constater les limites de l’intelligence artificielle appliquee a la robotique.

Nous avons egalement pu verifier, comme nous le demandait notre encadrant, que deuxrobots identiques auxquels nous aurions demande la meme chose ne reagiraient pas de lameme maniere. Ou encore, que deux experiences censees produire les memes resultats maisexecutees sur des machines differentes dans les memes conditions peuvent connaıtre des issuesdifferentes. C’est sur cette conclusion que nous avons remis notre cahier de laboratoire a M.BOURREAU et au LIRMM.

Chapitre 4

Vers un portage URBI pour HOAP ?

Le cahier de laboratoire que nous avons concu nous a permis de nous forger une solideapproche de l’univers a l’intersection des mondes de la robotique et de l’intelligence artificielle.Travailler avec des robots peu performants nous a egalement ouvert les yeux sur les limites quenous pourrions rencontrer plus tard dans ce domaine, et nous a fait reflechir a d’eventuellesameliorations pouvant etre apportees.

Cependant, pour ce qui est de notre Travail d’Etude et de Recherche, les ameliorationsen question existent deja, et sont a notre portee. Les Lego Mindstorms NXT allaient cederla place a un tout autre modele de machine aux possibilites bien plus etendues : le HOAPde Fujitsu.

Mais la facilite avec laquelle nous avons manipule les robots Lego ne serait plus alorsqu’un lointain souvenir... Revenons quelques jours (semaines) en arriere, nous commandionsdeux automates equipes de trois capteurs (ultrasons, sonore, lumineux) et trois moteurs(pince, roue gauche, roue droite). Avec HOAP, il nous faudra jouer avec 28 degres de liberte(comprenez, 28 moteurs) et 13 capteurs !

De plus, nous ne pouvons pas compter sur la stabilite dont disposaient les Lego, poses surleurs trois roues, avec le dernier ne de Fujitsu. Comme un enfant auquel nous apprendrions afaire ses premiers pas, il dispose d’un centre de gravite dont nous devons tenir compte pourparer a toute chute, notamment lors de l’execution d’un pas ou le robot tient sur une seulede ses deux jambes metalliques. Et lorsqu’on joue avec un robot qui coute plus de 30.000euros, il vaut mieux eviter ce genre de mesaventures.

Lors d’une reunion au LIRMM avec notre encadrant, M. BOURREAU, celui-ci nous adonc conseille d’explorer d’abord la piste Aibo. Le gentil petit chien robot de Sony se situea mi-chemin entre les Lego Mindstorms NXT et HOAP : naturellement instable puisqu’il nepeut pas garder l’equilibre dans n’importe quelle position, tout comme HOAP, il est toutefoispossible de le commander grace a URBI qui, s’il nous a simplifie la vie avec les Lego, peuttout autant le faire avec Aibo...

Ceci dit, le LIRMM ne disposant pas de modeles d’Aibo, cette piste semble compromise.Elle aurait cependant pu etre un bon compromis entre le travail realise et le portage surHOAP.

21

Chapitre 5

Conclusion et perspectives

5.1 Conclusion

Au cours de ce projet, nous avons atteint la limite dont nous avions parle initialement :celle qui separe le monde theorique du monde physique. Le code ecrit peut s’averer juste,neanmoins l’environnement dicte toujours ses regles. Un rien suffit parfois a faire echouer uneexperience meme facilement realisable : une defaillance des capteurs, un obstacle imprevu, etle robot se retrouve dans une situation qu’il ne sait pas gerer.

La realisation du cahier de laboratoire nous a permis de toucher du doigt le monde dela recherche en laboratoire avec ses experiences, ses compte-rendus et ses publications. Larealisation d’un protocole, la mise en pratique d’une “simple” experience qui semble plutotbanale pour nous, s’est revelee plus difficile que prevu. Si rendre les automates intelligents,leur donner la capacite de penser, n’est deja pas une chose facile, les faire reagir positivementface a n’importe quelle situation imaginable ressemble fort a une tache interminable.

Soulignons egalement que la realisation de ce TER fut differente de celle escomptee audepart. En effet, le travail qui nous a ete assigne consistait a effectuer un portage du codeURBI sur le robot HOAP, qui est sur une plateforme logicielle RTLinux. Pour des raisonstechniques et de disponibilite des chercheurs ce portage n’a pas pu etre effectue. Nous avonsdonc ete assignes a une autre tache : realiser un cahier de laboratoire complet avec realisationd’experiences sur les robots Mindstorms. Cela ne devait constituer que l’introduction de notreTER, mais nous l’avons longuement approfondi en attendant un signe du LIRMM qui nousautoriserait a travailler avec HOAP.

5.2 Difficultes rencontrees

Nous avons souffert, lors des experimentations, d’un gros manque de documentation surla notion de cahier de laboratoire, que ce soit sur Internet ou en format papier. Nous n’avionsjamais eu a travailler sur un tel concept, et n’avons rien trouve qui puisse reellement nousaider sur ce sujet. Nos encadrants n’ont pas ete plus prolixes sur le sujet. Nous avons doncete obliges d’avancer seuls, en notant ce qui nous paraissait etre utile.

Comme explicite plus haut, nous avons egalement du revoir le sujet du projet suite auxreticences du LIRMM de nous laisser travailler sur le robot de type HOAP leur appartenant.Alors que celui-ci devait constituer le point central de notre travail, les roboticiens du labo-ratoire ne nous ont meme pas laisse l’apercevoir, meme apres que nous leur ayons presente

22

5.3 Perspectives 23

un cahier de laboratoire complet et malgre les requetes de notre encadrant. Au final, nousavons compose sans HOAP a ce jour...

5.3 Perspectives

Le but actuel de la recherche en intelligence artificielle, c’est de donner plus d’autonomieaux robots afin de limiter l’intervention humaine. Par exemple dans le cas des robots sauveteursauxquels on donnerait simplement l’ordre de recuperer des humains dans des decombres, lesrobots prenant le reste des decisions.

A court terme, le principal objectif des roboticiens devrait donc etre de forcer l’appren-tissage de leurs robots en les mettant face a des situations differentes, avant meme de leurdonner des fonctionnalites plus avancees. N’importe quel appareil, tout aussi evolue qu’il soitau niveau des possibilites, ne pourra rien sans une intelligence a tout epreuve le permettantd’avoir une solution pour chaque cas imaginable.

C’est ce que nous esperons realiser ces prochains mois, en participant au Concours RobAFIS2008, qui nous occupera a compter de la fin du mois d’avril jusqu’au mois de decembre 2008.L’objectif : evaluer les performances d’un robot Lego confronte a un environnement truffed’obstacles... et d’adversaires. La presence d’autres automates represente un challenge nou-veau que nous sommes prets a relever.

Chapitre 6

References

6.1 References bibliographiques

6.2 References numeriques

– http://mindstorms.lego.com/

Site officiel de Lego Mindstorms NXT (anglais)– http://www.gostai.com/

Site officiel de Gostai (anglais)– http://www.gostai.com/doc/fr/mindstormNXT

Documentation d’URBI pour Mindstorms (francais)– http://www.urbiforge.com/

Le site de reference sur URBI (multilingue)– http://www.wikipedia.com/

L’Encyclopedie en ligne (multilingue)– http://www.automation.fujitsu.com/

La section Automates de Fujitsu (anglais)

24

Annexe A

Implementation URBIdu code ((attrape-canette))

// Variables globales

global.dirL = -2;

global.dirR = 2;

global.temps = 0;

global.toSave = "Temps (ms),WheelLeft,WheelRight,Sonar,Light,Decibel,

Bumper,Claw\n";

// Toutes les 500 millisecondes, on concatene la variable globale toSave

// avec les valeurs des capteurs a l’instant t

every (500) {

global.temps += 500;

global.toSave = global.toSave + global.temps

+ "," + wheelL + "," + wheelR + "," + sonar

+ "," + light + "," + decibel + "," + bumper

+ "," + claw.val + "\n";

};

// Ouverture des pinces

function openClaws() {

claw.val = 90;

wait(2s);

};

// Fermeture des pinces

function closeClaws(){

claw.val = 0;

wait(2s);

};

// Fonction qui sera appelee lors de la phase de recherche

search_transition:

at (sonar > 60) {

25

A Implementation URBI du code ((attrape-canette)) 26

echo ("***** PERDU DE VUE *****");

stop goto;

search: searchCan();

};

// Fonction qui sera appelee lors de la phase de deplacement

goto_transition:

at (sonar <= 60) {

stop search;

goto: goToCan();

};

// Fonction qui sera appelee lors de la phase de saisie

catch_transition:

at(bumper == 1 100ms) {

echo ("***** BUMPED INTO SOMETHING ! *****");

freeze goto_transition;

freeze search_transition;

wheels = 0;

closeClaws();

actionfile.save(global.toSave, "toSave");

freeze catch_transition;

};

function searchCan() {

echo("***** MODE RECHERCHE *****");

wheels = 0;

global.dirL = - global.dirL;

global.dirR = - global.dirR;

wheelL = global.dirL & wheelR = global.dirR;

};

function goToCan() {

echo("***** MODE DEPLACEMENT *****");

openClaws();

wheels = 10;

};

Annexe B

Implementation URBIdu code ((John Robot))

// Variables globales

global.normalSpeed = 10;

global.fullSpeed = 30;

global.time = 0;

// Toutes les 500 millisecondes, on concatene la variable globale toSave

// avec les valeurs des capteurs a l’instant t

every (1000) {

global.time += 1000;

echo ("Son a t = " + global.time + " : " + decibel);

};

goto_transition:

at (decibel <= 0.4 ~5s) {

wheels = global.normalSpeed;

};

at (decibel > 0.4 ~2s) {

wheels = global.fullSpeed;

};

at (decibel > 0.4) {

wheels = 0;

};

27

Annexe C

Cahier de laboratoire

Un extrait du cahier de laboratoire que nous avons eu a produire, selon les attentes denotre encadrant et du Laboratoire d’Informatique, de Robotique et de Micro-electronique deMontpellier, est joint a ce dossier.

28

Sujet 10 - Rapport de projet Un peu d’IA dans un cerveau ...

Documents

Transcript of Sujet 10 - Rapport de projet Un peu d’IA dans un cerveau ...