Unpeud’IAdansuncerveauderobot Sujet10-Rapportdeprojet ann´ee Minist`eredel’EducationNationaleUniversit´eMontpellierIIRapportdeprojetdel’unit´ed’enseignementFMIN200MasterInformatique`aFinalit´esProfessionelleetRecherche1

29  Download (0)

Texte intégral

(1)

Minist` ere de l’Education Nationale Universit´ e Montpellier II

Rapport de projet de l’unit´ e d’enseignement FMIN200

Master Informatique ` a Finalit´ es Professionelle et Recherche 1

`ere

ann´ ee

Sujet 10 - Rapport de projet

Un peu d’IA dans un cerveau de robot

Encadrants BOURREAU Eric Auteurs PERALTA Emmanuel

SICCARDI Christophe THEOCARI Elie

(2)

Table des mati` eres

1 Introduction 4

1.1 Le sujet . . . 4

1.2 Pourquoi ce choix . . . 4

2 Pr´esentation du sujet 5 2.1 Contexte . . . 5

2.2 Objectifs . . . 5

2.3 Planning initial . . . 6

3 Une premi`ere approche : Lego Mindstorms NXT et URBI 7 3.1 Pr´esentation des robots Lego Mindstorms NXT . . . 8

3.1.1 Vue g´en´erale . . . 8

3.1.2 Gros plan sur le Tribot . . . 8

3.2 Pr´esentation d’URBI . . . 9

3.2.1 Vue g´en´erale . . . 9

3.2.2 URBI pour Mindstorms NXT . . . 10

3.2.3 Faire fonctionner le NXT avec URBI . . . 10

3.3 Objectifs . . . 14

3.4 Exp´erimentations sur les robots . . . 14

3.4.1 R´eflexion sur les exp´eriences `a r´ealiser . . . 14

3.4.2 Algorithme et impl´ementation du code URBI . . . 15

3.4.3 R´ealisation des exp´eriences . . . 16

3.5 Premi`eres conclusions... et perspectives . . . 17

3.6 John Robot . . . 18

3.6.1 Pr´esentation de l’exp´erience . . . 18

3.6.2 Algorithme et impl´ementation du code URBI . . . 19

3.6.3 R´ealisation des exp´eriences . . . 19

3.7 Conclusion . . . 20

4 Vers un portage URBI pour HOAP ? 21 5 Conclusion et perspectives 22 5.1 Conclusion . . . 22

5.2 Difficult´es rencontr´ees . . . 22

5.3 Perspectives . . . 23

1

(3)

TABLE DES MATI `ERES 2

6 R´ef´erences 24

6.1 R´ef´erences bibliographiques . . . 24 6.2 R´ef´erences num´eriques . . . 24 A Impl´ementation URBI du code ((attrape-canette)) 25 B Impl´ementation URBI du code ((John Robot)) 27

C Cahier de laboratoire 28

(4)

Remerciements

Nous tenons `a remercier l’Universit´e Montpellier II et le Laboratoire d’Informatique, de Robotique et de Micro-´electronique de Montpellier pour nous avoir permis de travailler sur ce sujet de TER qui repr´esentait exactement ce que nous nous attendions `a trouver au croisement des domaines de l’Intelligence Artificielle et de la Robotique.

Merci `a notre tuteur, M. Eric Bourreau, qui nous a parfaitement encadr´es et a su r´epondre

`

a toutes nos questions. Merci ´egalement aux autres intervenants du LIRMM que nous avons eu l’occasion de rencontrer dans le cadre de notre ´etude, MM. Mathias Paulin et Philippe Fraisse du D´epartement de Robotique du LIRMM, et qui ont fait preuve de beaucoup d’int´erˆet quant `a l’avanc´ee de notre travail.

Merci enfin aux personnes qui liront ce rapport, `a celles qui jugeront, critiqueront, ou complimenteront 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

(5)

Chapitre 1 Introduction

Dans le cadre du Master 1 Informatique un TER (Travail d’Etude et de Recherche) `a gros coefficient ´etait `a realiser. Nous devions donc nous regrouper par groupes de 3 ou 4 maximum et 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 pr´ef´erable 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 present´e sur le site.

Au LIRMM, nous avons la double chance d’avoir `a la fois un d´epartement Robotique et un D´epartement Informatique. Le d´epartement Robotique a acquis en f´evrier dernier un robot humano¨ıde HOAP de Fujistu. Dans le mˆeme temps, le d´epartement informatique a con¸cu une nouvelle plateforme logicielle COGITO¨IDE permettant de simuler la r´eflexion afin d’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 pouvoir r´ealiser de d´emonstrations r´eelles de comportements autonomes (non programm´es) et intel- ligents.

Techniquement, la plateforme physique est une version de RTLinux. Plusieurs couches logicielles permettent d’acc´eder aux capteurs et moteurs physiques. De l’autre cot´e, la plate- forme de r´eflexion est bas´ee sur des librairies Java. Pour faciliter la tˆache et rendre celle-ci g´en´erique, un langage d’interface URBI a ´et´e acquis au laboratoire. Il permet de s’abstraire de la couche physique `a partir du moment o`u la librairie existe... un portage et une extension de la librairie Java/Linux sera donc `a r´ealiser.

1.2 Pourquoi ce choix

Ce sujet nous a beaucoup int´eress´e pour son rapport direct au monde de la recherche et plus particuli`erement `a la section intelligence artificielle sur la robotique du laboratoire. En choisissant ce sujet nous ´etions sˆurs de travailler avec des robots afin de les programmer pour obtenir de leur part un comportement intelligent reproduit.

4

(6)

Chapitre 2

Pr´ esentation du sujet

2.1 Contexte

Pour ce Travail d’Etude et de Recherche, nous ´etions directement li´es au LIRMM, le Lab- oratoire d’Informatique, de Robotique et de Micro-´el´ectronique de Montpellier, et plus par- ticuli`erement au croisement de la partie robotique et informatique de ce laboratoire, puisque nous avons eu la chance de travailler avec des enseignants chercheurs dans la programmation d’intelligence artificielle robotique.

Au LIRMM, plusieurs robots sont `a la disposition des chercheurs. On y trouve notamment un mod`ele du fameux HOAP de Fujitsu, le seul exemplaire en France, et plusieurs robots de type Mindstorms NXT, une cr´eation de Lego. Ces derniers sont de petites machines programmables dot´es 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 de sorte `a ce que ceux-ci ”apprennent”, en quelque sorte, de leurs erreurs et de leurs exp´eriences pass´ees, donc de rendre leurs comportements ”intelligents” face `a des situations faites pour les d´estabiliser.

Pour ce faire, ils utilisent un langage de programmation nomm´e URBI. Ce langage a la particularit´e de se g´en´eraliser `a tous les robots `a partir du moment o`u les pilotes n´ecessaires existent pour son portage. Et c’est le cas des robots Mindstorms. Deux exemplaires de ces automates nous ont ainsi ´et´e confi´es par nos encadrants, afin de pouvoir travailler librement sur les objectifs qui nous ont ´et´e fix´es.

2.2 Objectifs

Nous avons divis´e le TER en deux parties distinctes.

La premi`ere consistait `a prendre en main la programmation d’un robot afin de lui faire effectuer des actions `a partir de mouvements basiques, et de r´ealiser un cahier de laboratoire des exp´eriences r´ealis´ees. Cela nous permettrait d’observer les limites des automates li´ees `a l’environnement ou au mat´eriel.

La seconde, quant `a elle, tendait `a trouver un moyen de r´ealiser un portage du langage utilis´e pour Mindstorms vers d’autres types de robots, incluant HOAP. En effet, HOAP n’est pas une machine directement programmable via le langage URBI ´etant donn´e qu’aucun pilote ne permet le portage pour ce robot dans ce langage.

5

(7)

2.3 Planning initial 6

C’est dans cette optique que nous avons d´ecid´e de raisonner afin de r´ealiser une vraie

´

etude de recherche.

2.3 Planning initial

Voici le premier planning de travail que nous avons con¸cu.

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 g´en´erales sur le contexte du TER.

– Semaine 3 : second rendez-vous avec l’encadrant. Explications plus pr´ecises sur le sujet et ce qui est attendu de nous. R´epartition du mat´eriel et des tˆaches.

F´evrier - Travail avec URBI

– Semaine 4 : prise en main des robots Lego Mindstorms NXT via l’applet graphique de Lego, puis avec URBI.

– Semaine 5 : r´eflexion quant `a des exp´eriences `a r´ealiser, outre le test de l’((attrape- canette)) qui doit ˆetre r´eussi.

– Semaines 6 et 7 : r´ealisation des exp´eriences et ´elaboration du cahier de laboratoire.

Mars - Travail avec HOAP

– Semaines 8 `a 11 : d´ecouverte de HOAP. R´eflexion `a un ´eventuel portage du travail r´ealis´e avec URBI en f´evrier.

Avril - Finalisation

– Semaines 12 `a 14 : d´ebordement. Finalisation du rapport. Pr´eparation `a la soutenance orale.

(8)

Chapitre 3

Une premi` ere approche :

Lego Mindstorms NXT et URBI

Fig. 3.1 – La brique programmable des Mindstorms

7

(9)

3.1 Pr´esentation des robots Lego Mindstorms NXT 8

3.1 Pr´ esentation des robots Lego Mindstorms NXT

3.1.1 Vue g´ en´ erale

Les robots Mindstorms sont une invention du fabricant de jeu danois Lego. Comme tous les Lego, ils peuvent ˆetre mont´es, d´emont´es, remont´es `a l’infini, prennent n’importe quelle forme imaginable ; mais la particularit´e des Mindstorms est qu’ils int`egrent un bloc (aussi appel´e

”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 t´el´ecommand´ee, d’une grue ou encore d’un robot humano¨ıde, pour la version la plus r´ecente.

La brique, en plus de pouvoir servir `a commander le robot, peut ˆetre reli´ee `a divers capteurs qui lui permettront de se faire une id´ee 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 une voiture t´el´ecommand´ee : notre automate doit, en fonction des directives que nous lui aurons donn´ees et de la repr´esentation qu’il se fait de son environnement, s’auto-g´erer.

Les robots qui nous ont ´et´e confi´es par le LIRMM sont des appareils de type NXT : il s’agit de la seconde version de Lego Mindstorms, la premi`ere ´etant le type RCX. La principale diff´erence entre les deux versions r´eside dans l’ajout de capteurs : le capteur d’ultrasons, par exemple, n’´etait pas pr´esent chez les RCX. En revanche, le capteur de temp´erature a disparu.

On note ´egalement la malheureuse disparition de l’adaptateur secteur, bien utile pourtant au vu de la consommation de la bˆete.

Voici la liste des capteurs que nous pouvons trouver sur ces robots :

– un capteur photosensible qui permet de mesurer la luminosit´e ambiante ; – un capteur sonore qui ´evalue l’intensit´e sonore en d´ecibels ;

– un capteur d’ultrasons afin d’estimer la distance s´eparant notre automate de l’objet qui se trouve en face de lui ;

– un capteur tactile qui d´etectera la pression `a un endroit donn´e du Lego, le bumper, et renverra une valeur en cons´equence.

D’autres capteurs, vendus s´epar´ement, comme le capteur de couleurs ou la boussole, peuvent donner aux utilisateurs aguerris une bonne opportunit´e de composer des programmes encore plus fins. Pour les besoins de notre TER, nous avons travaill´e sur les quatre d´ecrits ci-dessus.

En sortie, les informations seront relay´ees `a trois servo-moteurs. Selon la construction du programmateur, ils seront reli´es aux roues (robots roulants), aux jambes (robots humano¨ıdes),

`

a la pince (grue)... et le Mindstorm pourra donc effectuer les actions qui lui sont assign´ees par son constructeur ou en fonction des informations re¸cues par les capteurs.

3.1.2 Gros plan sur le Tribot

Comme nous l’avons pr´ecis´e au-dessus, un NXT est avant tout un Lego et peut donc prendre une multitude de formes. Cependant, pour en tirer pleinement profit, il est pr´ef´erable de suivre les conseils du fabricant qui nous propose quatre constitutions bien pens´ees : un robot de type humano¨ıde, l’Alpha Rex, un robot de type animal (un scorpion), Spike, un de type grue, le RoboArm T-56, et enfin un de type v´ehicule, le Tribot. Il nous ´etait demand´e de travailler sur le dernier cit´e, ´etant donn´e que nos encadrants de TER menaient d´ej`a des travaux dessus.

(10)

3.2 Pr´esentation d’URBI 9

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

Le Tribot est constitu´e de la brique NXT qu’il arbore fi`erement en partie centrale, celle-ci

´

etant support´ee par deux roues command´ees par deux des trois servo-moteurs, et d’une roue que nous qualifierons de libre ´etant donn´ee qu’elle suit plus ou moins la direction impos´ee par les deux autres. Le capteur ultrasons est fix´e `a l’avant du v´ehicule, le capteur sonore `a son sommet, et enfin le capteur de luminosit´e est attach´e au niveau des roues, sous la brique. Le troisi`eme servo-moteur, celui qui n’est pas utilis´e par les roues, aura pour fonction d’ouvrir et de fermer la pince qui se situe elle aussi `a l’avant, permettant d’attraper des objets de diam`etre moyen, tels qu’un verre ou une bombe a´erosol. Et au milieu des pinces, se trouve le dernier capteur, le capteur de pression.

3.2 Pr´ esentation d’URBI

3.2.1 Vue g´ en´ erale

Les quatre lettres URBI signifient Universal Real-time Behavior Interface, ou en fran¸cais, Interface Universelle pour les Syst`emes Interactifs. Celle-ci permet de commander `a distance des automates, exactement ce dont nous avons besoin dans notre Travail d’Etude et de Recherche. Elle marche sur le principe client – serveur, le serveur ´etant donc l’ordinateur de l’utilisateur, et le client ´etant le robot. Cette plate-forme logicielle a ´et´e cr´e´ee par une

(11)

3.2 Pr´esentation d’URBI 10

entreprise fran¸caise du nom de Gostai, bas´ee `a Paris, et a fait sa premi`ere apparition en 2003.

Pour programmer, nous nous sommes servis du langage du mˆeme nom, avec une syntaxe proche de celle du langage C++. Celui-ci permet, pour les utilisateurs avanc´es, d’utiliser des notions complexes comme la programmation dynamique. Cependant, dans le cadre de notre projet, nous n’avons pas eu `a aller jusque l`a.

3.2.2 URBI pour Mindstorms NXT

Gostai a d´evelopp´e plusieurs plateformes, en fonction du type de robot qui doit ˆetre command´e par URBI. Nous avons donc t´el´echarg´e la version pour Lego Mindstorms. Nous continuerons d’´evoquer par la suite cette version pour Mindstorms par le simple terme URBI.

L’avantage d’avoir une version sp´ecifique aux Mindstorms est que les d´eveloppeurs du langage URBI correspondant connaissaient la structure de nos robots, et ont ainsi rendu simplissime la programmation pour des utilisateurs mˆeme novices. Par exemple, la simple commande

wheels = 20;

demande `a notre automate de se d´eplacer en avant, `a une vitesse de 20 [unit´e]. Vous trouverez en annexe un rapide tutorial sur la version Mindstorms de URBI, pr´esentant les principales commandes et quelques petits exemples de codes.

Cela a permis une prise en main quasi-imm´ediate du langage, et nous avons donc pu commencer sans tarder `a pratiquer nos premi`eres exp´eriences sur les deux mod`eles de Lego Mindstorms NXT que nous a procur´es le LIRMM.

3.2.3 Faire fonctionner le NXT avec URBI

Ainsi que nous l’avons explicit´e pr´ec´edemment, URBI fonctionne sur le principe client - serveur. Il faut donc d´emarrer une application sur l’ordinateur de l’utilisateur (le serveur) et y connecter notre robot (le client) afin de pouvoir commander ce dernier.

Voici dans l’ordre les ´etapes que nous avons suivies pour effectuer nos exp´eriences : – en premier lieu, relier le Mindstorms `a l’ordinateur par l’interm´ediaire d’un cˆable USB.

Une connexion Bluetooth est ´egalement possible, en supposant toutefois que nous dis- posons d’un ordinateur ´equip´e en cons´equence...

– lancer ensuite le serveur URBI pour Mindstorms. Si le robot n’est pas connect´e ou hors tension, un message d’erreur s’affiche.

– lancer la console URBI pour Mindstorms, qui fait office de client. Une fois celle-ci d´emarr´ee, il faut connecter le client au serveur en cliquant sur le bouton ”Connect to the LEGO Mindstorms NXT”. Si un fichier URBI a ´et´e cr´e´e, il est possible de demander au robot de suivre les instructions y ´etant consign´ees en choisissant ce fichier dans l’explorateur Windows. Sinon, il suffit de les lui envoyer une par une grˆace `a un champ de texte situ´e en bas de la console. Cependant, cela ne permet pas de d´eclarer des fonctions par exemple. Usage r´eserv´e donc aux utilisateurs novices qui partent `a la d´ecouverte d’URBI pour Mindstorms...

– cliquer sur Send ! pour envoyer les instructions au robot, et admirer le r´esultat...

Cependant, dans notre situation avec un cahier de laboratoire `a r´ealiser, 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

(12)

3.2 Pr´esentation d’URBI 11

`

a la recherche d’un programme qui ferait cela pour nous, et nous en avons trouv´e un, sur le site UrbiForge dont le lien figure `a la fin du rapport, r´epondant au doux nom d’actionfile.

Avant donc d’exp´edier nos instructions `a notre robot Lego, nous avions une ´etape de plus

`

a ex´ecuter : le lancement en console du programme t´el´echarg´e. Une fois celui-ci en route, il s’est charg´e de relever les valeurs des capteurs lorsque nous le lui demandions et nous n’avons plus eu qu’`a convertir le fichier cr´e´e en format .csv (Comma-Separated Values, un format lisible par Excel ou le tableur d’Open Office).

Nous voici donc en possession de tous les ´el´ements afin de pouvoir mener `a bien nos exp´erimentations.

(13)

3.2 Pr´esentation d’URBI 12

Fig. 3.3 – Le serveur

Fig. 3.4 – L’ex´ecutable du programme actionfile.exe

(14)

3.2 Pr´esentation d’URBI 13

Fig. 3.5 – Le client

(15)

3.3 Objectifs 14

3.3 Objectifs

Une fois en possession de nos charmants robots et du langage ad´equat pour les faire tourner, l’objectif donn´e par notre encadrant ´etait de pratiquer diverses exp´eriences sur les deux mod`eles disponibles afin de tester leur(( r´egularit´e)), si l’on puit dire. Le but ´etait donc le suivant :

– r´efl´echir `a diverses exp´eriences r´ealisables par des robots peu perfectionn´es ;

– tester exactement la mˆeme exp´erience, dans les mˆemes conditions, sur les deux robots, pour comparer leur rendement et le r´esultat final ;

– tester deux exp´eriences proches l’une de l’autre et devant rendre le mˆeme r´esultat sur un seul robot pour v´erifier que le robot r´eagissait bien de la mˆeme mani`ere dans les deux situations, par exemple dans des conditions environnementales diff´erentes (en mati`ere de niveau sonore ou de luminosit´e par exemple) afin d’observer (ou non) des disparit´es dans les r´esultats obtenus.

Les r´esultats devaient ˆetre consign´es dans un cahier de laboratoire que nous rendrions avec notre rapport. Nous nous devions donc de noter le protocole de chaque exp´erience r´ealis´ee, et de cr´eer des fichiers .csv repr´esentant les r´esultats obtenus.

3.4 Exp´ erimentations sur les robots

3.4.1 R´ eflexion sur les exp´ eriences ` a r´ ealiser

La principale difficult´e ´etait de choisir les exp´eriences que nous allions faire r´ealiser `a nos robots. Au d´epart, des id´ees folles nous ont travers´e l’esprit, comme par exemple faire traverser un labyrinthe `a nos Mindstorms... Jusqu’`a ce que nous observions par nous-mˆemes que mˆeme ´equip´es de technologies de pointe, ils restaient avant tout... des Lego.

Avec un mat´eriel peu pr´ecis au niveau du montage, les pi`eces se clipsant les unes dans les autres comme dans tout Lego qui se respecte, la pr´ecision des robots n’´etait d´ej`a pas excep- tionnelle. Mais l’autre probl`eme des Mindstorms r´eside dans l’´electronique... Il ne nous a fallu que quelques minutes pour constater que les capteurs avaient parfois de s´erieux probl`emes, par exemple lorsque nous le mettions bien en face d’un objet d’une hauteur et d’une largeur suffisante pour qu’il soit d´etect´e par les ultrasons, et qu’il ne le d´ecelait pas.

Nous avons donc revu nos objectifs `a la baisse, et nous sommes inspir´es des travaux de M.

Mathias Paulin, chercheur au LIRMM, que nous avons eu l’occasion de rencontrer `a plusieurs reprises. Sur une vid´eo que nous avons pu voir, le robot devait attraper une canette qui ´etait d´eplac´ee lorsqu’il s’en approchait.

Nous avons donc r´ealis´e deux exp´eriences. La premi`ere consistait `a disposer une canette (ou tout autre objet assez haut et large pour ˆetre rep´er´e par les ultrasons de notre robot, nous parlerons par la suite de canette) en face du Lego, et la lui faire attraper sans la d´eplacer.

Ce premier protocole nous fournirait une premi`ere indication de la fiabilit´e du Mindstorm : on peut difficilement faire plus basique, et il est compliqu´e d’imaginer que notre automate puisse g´erer un objet en mouvement s’il ne peut le faire avec une cible fixe.

La seconde exp´erience nous plongeait en plein dans le concept d’intelligence artificielle : il ne s’agissait plus de dire au NXT, ”Tiens, voil`a une canette en face de toi, attrape-l`a !” ; mais plutˆot, ”Seras-tu assez intelligent pour trouver la canette si elle change de position constamment ?”. En gros, nous allions placer la canette en face du robot, la d´eplacer lorsqu’il arriverait `a proximit´e et observer la r´eaction du Lego.

(16)

3.4 Exp´erimentations sur les robots 15

En r´ealisant chacune de ces exp´eriences plusieurs fois, nous pourrions ainsi nous faire une id´ee de la fiabilit´e des robots de type Mindstorms. Mais pourquoi se placer dans des conditions environnementales diff´erentes pour les ex´ecuter ?

Certains robots ont beau sembler `a la pointe de la technologie, il suffit d’un rien pour les amener `a un ´echec. Demandez par exemple `a votre nouvel appareil m´enager de faire tourner votre machine `a laver. Intelligent comme tout, si vous le lui demandez, il commencera par trier le blanc et les couleurs. Et l`a, survient une panne de courant... Plong´e dans l’obscurit´e la plus totale, le robot est perdu. Nous avons donc voulu savoir ce qu’il en ´etait avec les Lego Mindstorms, qui sont encore loin d’ˆetre les robots de l’an 3000.

3.4.2 Algorithme et impl´ ementation du code URBI

L’algorithme auquel nous avons r´efl´echi devait s’inspirer du diagramme ´etats - transitions suivant.

Fig. 3.6 – Diagramme ´etats-transitions

Nous avons donc ´elabor´e l’algorithme suivant : si bumper enfonc´e alors

refermer la pince sinon

siobjet d´etect´e `a moins de 60cm alors se d´eplacer tout droit

sinon

chercher un objet `a moins de 60 cm fin si

fin si

Le langage URBI fournit tous les pr´edicats n´ecessaires aux tests sur les capteurs, et permet 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 tel moment de l’ex´ecution : des macros comme catch transition existent, et il suffit d’entrer du

(17)

3.4 Exp´erimentations sur les robots 16

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

3.4.3 R´ ealisation des exp´ eriences

Premi`ere exp´erience

Conditions environnementales Normales

Position de la canette En face du robot Distance de d´epart Environ 35 cm

Cible fixe Oui Taux de r´eussite 100%

Effectu´ee `a plusieurs reprises sur les deux robots, cette exp´erience a `a chaque fois ´et´e un succ`es. Petit point n´egatif cependant : le Mindstorm NXT a tendance `a d´evier plus ou moins de sa trajectoire, de fa¸con tr`es l´eg`ere certes, mais d’une fa¸con qui peut tout de mˆeme in- fluer sur le r´esultat de l’exp´erience. Dans notre cas, la faible distance entre le Lego et son objectif n’a permis que de constater que nos appareils ne heurtaient jamais ce dernier de fa¸con perpendiculaire. Mais l’angle de d´eviation, entre 5 et 10 degr´es, aurait pu faire rater l’observation si la distance de d´epart avait ´et´e de 80 centim`etres ou plus...

Seconde exp´erience - Phase 1

Conditions environnementales Normales

Position de la canette En face du robot Distance de d´epart Environ 25 cm

Cible fixe Non Taux de r´eussite 60%

Cette exp´erience a ´et´e r´ealis´ee dans les mˆemes conditions que la premi`ere. La diff´erence r´esidait dans le fait que l’objectif `a atteindre par le robot ´etait, cette fois, en mouvement.

Nous placions donc le robot `a 25 centim`etres de sa cible, droit en face de lui, le laissions tran- quillement avancer et d`es qu’il se trouvait `a une distance minime de la canette (inf´erieure `a 5 centim`etres), nous retirions celle-ci de sa position initiale. Nous la replacions `a environ 25 centim`etres de lui selon un angle de 90 degr´es sur sa droite pour tester sa r´eaction.

Nous avons donc pu en tirer de nouvelles conclusions. Nous avions d´ej`a remarqu´e le manque de rigueur de nos automates dans leurs d´eplacements, nous avons pu, en plus, nous rendre compte de d´efaillances dans leur compr´ehension des situations, et d’un manque de rapidit´e flagrant dans la r´eaction. Il est par exemple arriv´e que le Lego continue d’avancer apr`es que nous ayions d´eplac´e sa cible, alors que lui mˆeme notifiait via la console utilisateur qu’il l’avait perdue de vue et que le simplissime code URBI ne laissait la place `a aucune ambig¨uit´e, ou encore, apr`es avoir red´ecouvert la canette, qu’il continue `a tourner quelques dixi`emes de seconde... assez pour que sa trajectoire ne se retrouve d´efinitivement fauss´ee.

Ces quelques rat´es ont donc fait chuter le taux de r´eussite des exp´eriences... De 100%

dans l’exp´erience 1, il passe `a 60% dans la premi`ere phase de cette exp´erience 2.

(18)

3.5 Premi`eres conclusions... et perspectives 17

Seconde exp´erience - Phase 2

Conditions environnementales Noir total

Position de la canette En face du robot Distance de d´epart Environ 25 cm

Cible fixe Non Taux de r´eussite 70%

Le niveau de luminosit´e a-t-il une quelconque incidence sur le bon d´eroulement de notre exp´erience ? C’est ce que nous avons tent´e de d´ecouvrir en plongeant l’environnement du robot dans le noir le plus complet avant de r´eit´erer le protocole de cette exp´erience.

En th´eorie, arm´e de son capteur ultrasons, le Lego Mindstorms NXT n’avait pas besoin d’autre chose pour se rep´erer. Et les exp´eriences men´ees lors de cette deuxi`eme phase l’ont confirm´e. Si le premier robot a connu quelques difficult´es, ce sont les mˆemes qui existaient d´ej`a lors de la phase 1 : temps de latence plus ou moins important entre l’´ev´enement ”canette d´eplac´ee” et l’´ev´enement ”robot en mode d´eplacement”. Au final, il n’a pas paru plus ennuy´e pour se d´eplacer dans l’obscurit´e qu’en plein jour.

Seconde exp´erience - Phase 3

Conditions environnementales Niveau sonore tr`es ´elev´e Position de la canette En face du robot

Distance de d´epart Environ 25 cm Cible fixe Non

Taux de r´eussite 40%

Comme dans la phase 2, nous avons alt´er´e l’environnement de nos Lego Mindstorms NXT en jouant sur un autre crit`ere : cette fois, il s’agit du niveau sonore. Comment r´eagiront nos automates au milieu d’un vacarme assourdissant ?

Le taux de r´eussite n’a ´et´e cette fois que de 40%, et r´egresse donc par rapport aux deux phases pr´ec´edentes. N´eanmoins, nous ne pensons pas que cela soit dˆu au niveau sonore tr`es

´

elev´e. Les causes d’´echec ont ´et´e sensiblement les mˆemes que dans les exp´eriences pr´ec´edentes,

`

a savoir un d´ecalage entre la d´etection de la canette et la reprise de la marche avant ou des erreurs au niveau des capteurs.

3.5 Premi` eres conclusions... et perspectives

Revoyons le r´esultat de nos exp´erimentations. Comme on pouvait s’y attendre, les robots n’ont pas connu un taux de r´eussite de 100%... Quelles sont donc les causes des ´echecs de nos petites bˆetes ? La plupart du temps, il s’agit d’une erreur de pr´ecision lors de la d´etection de la canette. Souvent, le robot s’est arrˆet´e de balayer avant d’ˆetre en face de son objectif, souvent aussi, il a continu´e `a tourner un petit moment apr`es l’avoir aper¸cue : cela se comptait en dixi`emes de seconde, mais c’´etait suffisant pour lui faire rater son but.

Nous remarquons ensuite comme il nous ´etait demand´e, d’un point de vue statistique, que les robots Mindstorms NXT n’ont pas sembl´e affect´es par les alt´erations que nous avons fait subir `a leur environnement.

Toutefois, il en aurait ´et´e autrement si nous avions d´ecid´e de nous livrer `a des exp´eriences plus pointues. Imaginons par exemple que nous souhaitions que notre robot parte `a la chasse

(19)

3.6 John Robot 18

`

a la canette, puis, lorsque nous lui crierions quelque chose, arrˆete d’avancer et revienne vers nous comme un chien ferait avec son maˆıtre. L’exp´erience aurait pu marcher dans des conditions sonores normales, mais aurait probablement ´echou´e lors d’une d´emonstration dans un amphith´eˆatre comble.

Nous avons donc d´ecid´e d’aller plus loin et de r´ealiser une exp´erience de ce type afin de prouver les limites des automates face `a des situations qui peuvent les confondre.

3.6 John Robot

3.6.1 Pr´ esentation de l’exp´ erience

Les Lego Mindstorms NXT sont ´equip´es d’un capteur de luminosit´e, d’un capteur ul- trasons et d’un capteur sonore. Or, le premier cit´e est en r´ealit´e un capteur qui permet de mesurer la luminosit´e... sous les roues du robot, o`u se trouve une LED rouge ´eclairant la surface sur laquelle se d´eplace le robot. Nous en avons pris connaissance lors de la phase 2 de l’exp´erience 2, lorsque nous avons r´ealis´e que les valeurs enregistr´ees par le capteur de luminosit´e ´etaient bien trop peu alt´er´ees par rapport aux conditions normales...

Le moyen le plus simple de mettre nos appareils en situation d´elicate ´etait donc de jouer sur le niveau sonore. Nous avons donc imagin´e une exp´erimentation mettant en sc`ene John Robot, la version sur roues de John Rambo, qui se d´eplacerait dans une jungle amazonienne ici incarn´ee par un sol carrel´e plat...

Que ferait John Rambo s’il entendait un coup de feu au-dessus de sa tˆete ? Il s’arrˆeterait probablement un instant, puis reprendrait sa route quelques instants plus tard, une fois que les choses se seraient calm´ees. Mais si les coups de feu persistent, il prendrait ses jambes `a son cou pour se mettre `a l’abri plus loin.

Pour John Robot, le principe est le mˆeme. Nous avons simplement remplac´e les coups de feu par des sifflements stridents. Le robot doit donc d´ebuter son avanc´ee, puis s’arrˆeter s’il entend un sifflement bref. Au bout de quelques secondes, il reprend son avanc´ee. Seulement, si le sifflement dure assez longtemps, il repart en avant `a une vitesse bien sup´erieure `a sa vitesse ((de croisi`ere)).

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 r´ealiser cette exp´erience deux fois : une premi`ere dans des conditions normales, une seconde dans des conditions sonores d´esastreuses, afin de tester les r´eactions des Lego dans les deux cas.

(20)

3.6 John Robot 19

3.6.2 Algorithme et impl´ ementation du code URBI

Voici le diagramme ´etats - transitions que nous avons con¸cu pour d´ecrire cette exp´erience.

Fig. 3.7 – Diagramme ´etats-transitions

Nous en avons tir´e l’algorithme suivant.

si niveau sonore bas pendant 3salors avancer normalement

fin si

si niveau sonore ´elev´e pendant 5salors avancer tr`es rapidement

fin si

si niveau sonore ´elev´e pendant moins de 5s alors s’arrˆeter

fin si

Avec URBI, cela ne se traduira pas r´eellement avec des if. En effet, la syntaxe at(capteur[< <= = >= >]valeur)

permet de tester en parall`ele (ou presque) les valeurs prises par les capteurs.

Une fois encore, la syntaxe simpliste d’URBI nous a permis de coder cela avec une facilit´e d´econcertante. Le code figure en annexe.

3.6.3 R´ ealisation des exp´ eriences

Ainsi que nous l’avions escompt´e, les deux exp´eriences se sont d´eroul´ees de fa¸cons totale- ment diff´erentes.

Men´ee dans le silence, la premi`ere a connu l’issue que l’on attendait. Le robot a commenc´e

`

a avancer lentement, jusqu’au premier sifflement qui l’a fait s’arrˆeter. Il a repris sa marche en avant quelques secondes apr`es et s’est arrˆet´e de nouveau apr`es un second sifflement. Alors que le Lego ´etait `a l’arrˆet, un long sifflement l’a alors fait repartir `a toute vitesse.

(21)

3.7 Conclusion 20

La deuxi`eme exp´erience a ´et´e r´ealis´ee en cr´eant un environnement bruyant. Apr`es un premier arrˆet qui s’est bien pass´e, une sonnerie de t´el´ephone portable a ´et´e d´etect´ee par le Lego Mindstorm NXT qui l’a per¸cue comme il aurait pu percevoir le sifflement. Celle-ci a eu pour effet de le faire repartir en avant alors mˆeme que rien ne lui ´etait demand´e.

3.7 Conclusion

Nous avons donc pu en d´eduire que l’environnement dans lequel est plong´e un robot influe bien sur ses r´eactions. Si un humain ou un robot tr`es perfectionn´e aurait pu discerner le sifflement au milieu des autres sons ´emanant de celui-ci, cela n’a pas ´et´e le cas du Lego qui s’est retrouv´e perdu entre sifflements et sonneries de t´el´ephone portable. Nous avons donc eu l’occasion de constater les limites de l’intelligence artificielle appliqu´ee `a la robotique.

Nous avons ´egalement pu v´erifier, comme nous le demandait notre encadrant, que deux robots identiques auxquels nous aurions demand´e la mˆeme chose ne r´eagiraient pas de la mˆeme mani`ere. Ou encore, que deux exp´eriences cens´ees produire les mˆemes r´esultats mais ex´ecut´ees sur des machines diff´erentes dans les mˆemes conditions peuvent connaˆıtre des issues diff´erentes. C’est sur cette conclusion que nous avons remis notre cahier de laboratoire `a M.

BOURREAU et au LIRMM.

(22)

Chapitre 4

Vers un portage URBI pour HOAP ?

Le cahier de laboratoire que nous avons con¸cu nous a permis de nous forger une solide approche 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 que nous pourrions rencontrer plus tard dans ce domaine, et nous a fait r´efl´echir `a d’´eventuelles am´eliorations pouvant ˆetre apport´ees.

Cependant, pour ce qui est de notre Travail d’Etude et de Recherche, les am´eliorations en question existent d´ej`a, et sont `a notre port´ee. Les Lego Mindstorms NXT allaient c´eder la place `a un tout autre mod`ele de machine aux possibilit´es bien plus ´etendues : le HOAP de Fujitsu.

Mais la facilit´e avec laquelle nous avons manipul´e les robots Lego ne serait plus alors qu’un lointain souvenir... Revenons quelques jours (semaines) en arri`ere, nous commandions deux automates ´equip´es de trois capteurs (ultrasons, sonore, lumineux) et trois moteurs (pince, roue gauche, roue droite). Avec HOAP, il nous faudra jouer avec 28 degr´es de libert´e (comprenez, 28 moteurs) et 13 capteurs !

De plus, nous ne pouvons pas compter sur la stabilit´e dont disposaient les Lego, pos´es sur leurs trois roues, avec le dernier n´e de Fujitsu. Comme un enfant auquel nous apprendrions `a faire ses premiers pas, il dispose d’un centre de gravit´e dont nous devons tenir compte pour parer `a toute chute, notamment lors de l’ex´ecution d’un pas o`u le robot tient sur une seule de ses deux jambes m´etalliques. Et lorsqu’on joue avec un robot qui coˆute plus de 30.000 euros, il vaut mieux ´eviter ce genre de m´esaventures.

Lors d’une r´eunion au LIRMM avec notre encadrant, M. BOURREAU, celui-ci nous a donc conseill´e d’explorer d’abord la piste Aibo. Le gentil petit chien robot de Sony se situe

`

a mi-chemin entre les Lego Mindstorms NXT et HOAP : naturellement instable puisqu’il ne peut pas garder l’´equilibre dans n’importe quelle position, tout comme HOAP, il est toutefois possible de le commander grˆace `a URBI qui, s’il nous a simplifi´e la vie avec les Lego, peut tout autant le faire avec Aibo...

Ceci dit, le LIRMM ne disposant pas de mod`eles d’Aibo, cette piste semble compromise.

Elle aurait cependant pu ˆetre un bon compromis entre le travail r´ealis´e et le portage sur HOAP.

21

(23)

Chapitre 5

Conclusion et perspectives

5.1 Conclusion

Au cours de ce projet, nous avons atteint la limite dont nous avions parl´e initialement : celle qui s´epare le monde th´eorique du monde physique. Le code ´ecrit peut s’av´erer juste, n´eanmoins l’environnement dicte toujours ses r`egles. Un rien suffit parfois `a faire ´echouer une exp´erience mˆeme facilement r´ealisable : une d´efaillance des capteurs, un obstacle impr´evu, et le robot se retrouve dans une situation qu’il ne sait pas g´erer.

La r´ealisation du cahier de laboratoire nous a permis de toucher du doigt le monde de la recherche en laboratoire avec ses exp´eriences, ses compte-rendus et ses publications. La r´ealisation d’un protocole, la mise en pratique d’une “simple” exp´erience qui semble plutˆot banale pour nous, s’est r´ev´el´ee plus difficile que pr´evu. Si rendre les automates intelligents, leur donner la capacit´e de penser, n’est d´ej`a pas une chose facile, les faire r´eagir positivement face `a n’importe quelle situation imaginable ressemble fort `a une tˆache interminable.

Soulignons ´egalement que la r´ealisation de ce TER fut diff´erente de celle escompt´ee au depart. En effet, le travail qui nous a ´et´e assign´e consistait `a effectuer un portage du code URBI sur le robot HOAP, qui est sur une plateforme logicielle RTLinux. Pour des raisons techniques et de disponibilit´e des chercheurs ce portage n’a pas pu ˆetre effectu´e. Nous avons donc ´et´e assign´es `a une autre tˆache : r´ealiser un cahier de laboratoire complet avec r´ealisation d’exp´eriences sur les robots Mindstorms. Cela ne devait constituer que l’introduction de notre TER, mais nous l’avons longuement approfondi en attendant un signe du LIRMM qui nous autoriserait `a travailler avec HOAP.

5.2 Difficult´ es rencontr´ ees

Nous avons souffert, lors des exp´erimentations, d’un gros manque de documentation sur la notion de cahier de laboratoire, que ce soit sur Internet ou en format papier. Nous n’avions jamais eu `a travailler sur un tel concept, et n’avons rien trouv´e qui puisse r´eellement nous aider sur ce sujet. Nos encadrants n’ont pas ´et´e plus prolixes sur le sujet. Nous avons donc

´

et´e oblig´es d’avancer seuls, en notant ce qui nous paraissait ˆetre utile.

Comme explicit´e plus haut, nous avons ´egalement dˆu revoir le sujet du projet suite aux r´eticences 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 mˆeme pas laiss´e l’apercevoir, mˆeme apr`es que nous leur ayons pr´esent´e

22

(24)

5.3 Perspectives 23

un cahier de laboratoire complet et malgr´e les requˆetes de notre encadrant. Au final, nous avons compos´e sans HOAP `a ce jour...

5.3 Perspectives

Le but actuel de la recherche en intelligence artificielle, c’est de donner plus d’autonomie aux robots afin de limiter l’intervention humaine. Par exemple dans le cas des robots sauveteurs auxquels on donnerait simplement l’ordre de r´ecup´erer des humains dans des d´ecombres, les robots prenant le reste des d´ecisions.

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 diff´erentes, avant mˆeme de leur donner des fonctionnalit´es plus avanc´ees. N’importe quel appareil, tout aussi ´evolu´e qu’il soit au niveau des possibilit´es, ne pourra rien sans une intelligence `a tout ´epreuve le permettant d’avoir une solution pour chaque cas imaginable.

C’est ce que nous esp´erons r´ealiser ces prochains mois, en participant au Concours RobAFIS 2008, qui nous occupera `a compter de la fin du mois d’avril jusqu’au mois de d´ecembre 2008.

L’objectif : ´evaluer les performances d’un robot Lego confront´e `a un environnement truff´e d’obstacles... et d’adversaires. La pr´esence d’autres automates repr´esente un challenge nou- veau que nous sommes prˆets `a relever.

(25)

Chapitre 6 R´ ef´ erences

6.1 R´ ef´ erences bibliographiques 6.2 R´ ef´ erences num´ eriques

– 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 (fran¸cais) – http://www.urbiforge.com/

Le site de r´ef´erence sur URBI (multilingue) – http://www.wikipedia.com/

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

La section Automates de Fujitsu (anglais)

24

(26)

Annexe A

Impl´ ementation URBI

du 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 concat`ene 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 appel´ee lors de la phase de recherche search_transition:

at (sonar > 60) {

25

(27)

A Impl´ementation URBI du code ((attrape-canette)) 26

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

stop goto;

search: searchCan();

};

// Fonction qui sera appel´ee lors de la phase de d´eplacement goto_transition:

at (sonar <= 60) { stop search;

goto: goToCan();

};

// Fonction qui sera appel´ee 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;

};

(28)

Annexe B

Impl´ ementation URBI du code (( John Robot ))

// Variables globales global.normalSpeed = 10;

global.fullSpeed = 30;

global.time = 0;

// Toutes les 500 millisecondes, on concat`ene 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

(29)

Annexe C

Cahier de laboratoire

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

28

Figure

Updating...

Références

Sujets connexes :