Vous êtes sur la page 1sur 29

Ministère de l’Education Nationale

Université Montpellier II

Rapport de projet de l’unité d’enseignement FMIN200


Master Informatique à Finalités Professionelle et Recherche 1ère année

Sujet 10 - Rapport de projet


Un peu d’IA dans un cerveau de robot

Encadrants BOURREAU Eric

Auteurs PERALTA Emmanuel


SICCARDI Christophe
THEOCARI Elie
Table des matières

1 Introduction 4
1.1 Le sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Pourquoi ce choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Présentation du sujet 5
2.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Planning initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Une première approche : Lego Mindstorms NXT et URBI 7


3.1 Présentation des robots Lego Mindstorms NXT . . . . . . . . . . . . . . . . 8
3.1.1 Vue générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2 Gros plan sur le Tribot . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Présentation d’URBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Vue générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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érimentations sur les robots . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.1 Réflexion sur les expériences à réaliser . . . . . . . . . . . . . . . . . 14
3.4.2 Algorithme et implémentation du code URBI . . . . . . . . . . . . . 15
3.4.3 Réalisation des expériences . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5 Premières conclusions... et perspectives . . . . . . . . . . . . . . . . . . . . . 17
3.6 John Robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.6.1 Présentation de l’expérience . . . . . . . . . . . . . . . . . . . . . . . 18
3.6.2 Algorithme et implémentation du code URBI . . . . . . . . . . . . . 19
3.6.3 Réalisation des expériences . . . . . . . . . . . . . . . . . . . . . . . . 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és rencontrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1
TABLE DES MATIÈRES 2

6 Références 24
6.1 Références bibliographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2 Références numériques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

A Implémentation URBI du code ((attrape-canette)) 25

B Implémentation URBI du code ((John Robot)) 27

C Cahier de laboratoire 28
Remerciements

Nous tenons à remercier l’Université Montpellier II et le Laboratoire d’Informatique, de


Robotique et de Micro-électronique de Montpellier pour nous avoir permis de travailler sur
ce sujet de TER qui représentait exactement ce que nous nous attendions à trouver au
croisement des domaines de l’Intelligence Artificielle et de la Robotique.
Merci à notre tuteur, M. Eric Bourreau, qui nous a parfaitement encadrés et a su répondre
à toutes nos questions. Merci également aux autres intervenants du LIRMM que nous avons
eu l’occasion de rencontrer dans le cadre de notre étude, MM. Mathias Paulin et Philippe
Fraisse du Département de Robotique du LIRMM, et qui ont fait preuve de beaucoup d’intérêt
quant à l’avancée de notre travail.
Merci enfin aux personnes qui liront ce rapport, à celles qui jugeront, critiqueront, ou
complimenteront notre travail, et à toutes celles qui, dans un futur plus ou moins proche,
permettront à la robotique et à 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) à gros


coefficient était à realiser. Nous devions donc nous regrouper par groupes de 3 ou 4 maximum
et choisir un sujet parmi une liste à notre disposition à cette adresse :
http ://www.lirmm.fr/ leclere/enseignements/TER/2008/sujets-08.html.
Il était bien sur préférable de choisir un sujet inscrit dans le parcours suivit (I2A, GL,
DIWEB, CASAR). Étant tout les trois en I2A nous avons choisi en commun le sujet de M.
Bourreau à savoir “Un peu d’IA dans un cerveau de robot humanoı̈de”.

1.1 Le sujet
Voici le sujet tel qu’il était presenté sur le site.
Au LIRMM, nous avons la double chance d’avoir à la fois un département Robotique
et un Département Informatique. Le département Robotique a acquis en février dernier un
robot humanoı̈de HOAP de Fujistu. Dans le même temps, le département informatique a
conçu une nouvelle plateforme logicielle COGITOÏDE permettant de simuler la réflexion 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éaliser de démonstrations réelles de comportements autonomes (non programmés) et intel-
ligents.
Techniquement, la plateforme physique est une version de RTLinux. Plusieurs couches
logicielles permettent d’accéder aux capteurs et moteurs physiques. De l’autre coté, la plate-
forme de réflexion est basée sur des librairies Java. Pour faciliter la tâche et rendre celle-ci
générique, un langage d’interface URBI a été acquis au laboratoire. Il permet de s’abstraire
de la couche physique à partir du moment où la librairie existe... un portage et une extension
de la librairie Java/Linux sera donc à réaliser.

1.2 Pourquoi ce choix


Ce sujet nous a beaucoup intéressé pour son rapport direct au monde de la recherche et
plus particulièrement à la section intelligence artificielle sur la robotique du laboratoire. En
choisissant ce sujet nous étions sûrs de travailler avec des robots afin de les programmer pour
obtenir de leur part un comportement intelligent reproduit.

4
Chapitre 2

Présentation du sujet

2.1 Contexte
Pour ce Travail d’Etude et de Recherche, nous étions directement liés au LIRMM, le Lab-
oratoire d’Informatique, de Robotique et de Micro-éléctronique de Montpellier, et plus par-
ticulièrement 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 à la disposition des chercheurs. On y trouve notamment
un modèle du fameux HOAP de Fujitsu, le seul exemplaire en France, et plusieurs robots
de type Mindstorms NXT, une création de Lego. Ces derniers sont de petites machines
programmables dotés 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 à ce que ceux-ci ”apprennent”, en quelque sorte, de leurs erreurs et de leurs expériences
passées, donc de rendre leurs comportements ”intelligents” face à des situations faites pour
les déstabiliser.
Pour ce faire, ils utilisent un langage de programmation nommé URBI. Ce langage a la
particularité de se généraliser à tous les robots à partir du moment où les pilotes nécessaires
existent pour son portage. Et c’est le cas des robots Mindstorms. Deux exemplaires de ces
automates nous ont ainsi été confiés par nos encadrants, afin de pouvoir travailler librement
sur les objectifs qui nous ont été fixés.

2.2 Objectifs
Nous avons divisé le TER en deux parties distinctes.
La première consistait à prendre en main la programmation d’un robot afin de lui faire
effectuer des actions à partir de mouvements basiques, et de réaliser un cahier de laboratoire
des expériences réalisées. Cela nous permettrait d’observer les limites des automates liées à
l’environnement ou au matériel.
La seconde, quant à elle, tendait à trouver un moyen de réaliser un portage du langage
utilisé pour Mindstorms vers d’autres types de robots, incluant HOAP. En effet, HOAP n’est
pas une machine directement programmable via le langage URBI étant donné qu’aucun pilote
ne permet le portage pour ce robot dans ce langage.

5
2.3 Planning initial 6

C’est dans cette optique que nous avons décidé de raisonner afin de réaliser une vraie
étude de recherche.

2.3 Planning initial


Voici le premier planning de travail que nous avons conçu.
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énérales sur le contexte
du TER.
– Semaine 3 : second rendez-vous avec l’encadrant. Explications plus précises sur le sujet
et ce qui est attendu de nous. Répartition du matériel et des tâches.
Février - 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éflexion quant à des expériences à réaliser, outre le test de l’((attrape-
canette)) qui doit être réussi.
– Semaines 6 et 7 : réalisation des expériences et élaboration du cahier de laboratoire.
Mars - Travail avec HOAP
– Semaines 8 à 11 : découverte de HOAP. Réflexion à un éventuel portage du travail
réalisé avec URBI en février.
Avril - Finalisation
– Semaines 12 à 14 : débordement. Finalisation du rapport. Préparation à la soutenance
orale.
Chapitre 3

Une première approche :


Lego Mindstorms NXT et URBI

Fig. 3.1 – La brique programmable des Mindstorms

7
3.1 Présentation des robots Lego Mindstorms NXT 8

3.1 Présentation des robots Lego Mindstorms NXT


3.1.1 Vue générale
Les robots Mindstorms sont une invention du fabricant de jeu danois Lego. Comme tous les
Lego, ils peuvent être montés, démontés, remontés à l’infini, prennent n’importe quelle forme
imaginable ; mais la particularité des Mindstorms est qu’ils intègrent un bloc (aussi appelé
”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élécommandée, d’une
grue ou encore d’un robot humanoı̈de, pour la version la plus récente.
La brique, en plus de pouvoir servir à commander le robot, peut être reliée à divers
capteurs qui lui permettront de se faire une idée de l’environnement dans lequel il doit agir,
et qui sont consultables à 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élécommandée : notre automate doit, en fonction des directives que nous lui aurons
données et de la représentation qu’il se fait de son environnement, s’auto-gérer.
Les robots qui nous ont été confiés par le LIRMM sont des appareils de type NXT : il
s’agit de la seconde version de Lego Mindstorms, la première étant le type RCX. La principale
différence entre les deux versions réside dans l’ajout de capteurs : le capteur d’ultrasons, par
exemple, n’était pas présent chez les RCX. En revanche, le capteur de température a disparu.
On note également la malheureuse disparition de l’adaptateur secteur, bien utile pourtant
au vu de la consommation de la bête.
Voici la liste des capteurs que nous pouvons trouver sur ces robots :
– un capteur photosensible qui permet de mesurer la luminosité ambiante ;
– un capteur sonore qui évalue l’intensité sonore en décibels ;
– un capteur d’ultrasons afin d’estimer la distance séparant notre automate de l’objet qui
se trouve en face de lui ;
– un capteur tactile qui détectera la pression à un endroit donné du Lego, le bumper, et
renverra une valeur en conséquence.
D’autres capteurs, vendus séparément, comme le capteur de couleurs ou la boussole,
peuvent donner aux utilisateurs aguerris une bonne opportunité de composer des programmes
encore plus fins. Pour les besoins de notre TER, nous avons travaillé sur les quatre décrits
ci-dessus.
En sortie, les informations seront relayées à trois servo-moteurs. Selon la construction du
programmateur, ils seront reliés aux roues (robots roulants), aux jambes (robots humanoı̈des),
à la pince (grue)... et le Mindstorm pourra donc effectuer les actions qui lui sont assignées
par son constructeur ou en fonction des informations reçues par les capteurs.

3.1.2 Gros plan sur le Tribot


Comme nous l’avons précisé 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éférable
de suivre les conseils du fabricant qui nous propose quatre constitutions bien pensées : 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éhicule, le Tribot. Il nous était demandé
de travailler sur le dernier cité, étant donné que nos encadrants de TER menaient déjà des
travaux dessus.
3.2 Présentation d’URBI 9

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

Le Tribot est constitué de la brique NXT qu’il arbore fièrement en partie centrale, celle-ci
étant supportée par deux roues commandées par deux des trois servo-moteurs, et d’une roue
que nous qualifierons de libre étant donnée qu’elle suit plus ou moins la direction imposée par
les deux autres. Le capteur ultrasons est fixé à l’avant du véhicule, le capteur sonore à son
sommet, et enfin le capteur de luminosité est attaché au niveau des roues, sous la brique. Le
troisième servo-moteur, celui qui n’est pas utilisé par les roues, aura pour fonction d’ouvrir
et de fermer la pince qui se situe elle aussi à l’avant, permettant d’attraper des objets de
diamètre moyen, tels qu’un verre ou une bombe aérosol. Et au milieu des pinces, se trouve
le dernier capteur, le capteur de pression.

3.2 Présentation d’URBI


3.2.1 Vue générale
Les quatre lettres URBI signifient Universal Real-time Behavior Interface, ou en français,
Interface Universelle pour les Systèmes Interactifs. Celle-ci permet de commander à 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 étant donc l’ordinateur
de l’utilisateur, et le client étant le robot. Cette plate-forme logicielle a été créée par une
3.2 Présentation d’URBI 10

entreprise française du nom de Gostai, basée à Paris, et a fait sa première apparition en


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

3.2.2 URBI pour Mindstorms NXT


Gostai a développé plusieurs plateformes, en fonction du type de robot qui doit être
commandé par URBI. Nous avons donc téléchargé la version pour Lego Mindstorms. Nous
continuerons d’évoquer par la suite cette version pour Mindstorms par le simple terme URBI.
L’avantage d’avoir une version spécifique aux Mindstorms est que les développeurs du
langage URBI correspondant connaissaient la structure de nos robots, et ont ainsi rendu
simplissime la programmation pour des utilisateurs même novices. Par exemple, la simple
commande
wheels = 20;
demande à notre automate de se déplacer en avant, à une vitesse de 20 [unité]. Vous trouverez
en annexe un rapide tutorial sur la version Mindstorms de URBI, présentant les principales
commandes et quelques petits exemples de codes.
Cela a permis une prise en main quasi-immédiate du langage, et nous avons donc pu
commencer sans tarder à pratiquer nos premières expériences sur les deux modèles de Lego
Mindstorms NXT que nous a procurés le LIRMM.

3.2.3 Faire fonctionner le NXT avec URBI


Ainsi que nous l’avons explicité précédemment, URBI fonctionne sur le principe client -
serveur. Il faut donc démarrer 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 étapes que nous avons suivies pour effectuer nos expériences :
– en premier lieu, relier le Mindstorms à l’ordinateur par l’intermédiaire d’un câble USB.
Une connexion Bluetooth est également possible, en supposant toutefois que nous dis-
posons d’un ordinateur équipé en conséquence...
– lancer ensuite le serveur URBI pour Mindstorms. Si le robot n’est pas connecté 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émarrée, il faut connecter le client au serveur en cliquant sur le bouton ”Connect
to the LEGO Mindstorms NXT”. Si un fichier URBI a été créé, il est possible de
demander au robot de suivre les instructions y étant consignées en choisissant ce fichier
dans l’explorateur Windows. Sinon, il suffit de les lui envoyer une par une grâce à un
champ de texte situé en bas de la console. Cependant, cela ne permet pas de déclarer
des fonctions par exemple. Usage réservé donc aux utilisateurs novices qui partent à la
découverte d’URBI pour Mindstorms...
– cliquer sur Send ! pour envoyer les instructions au robot, et admirer le résultat...
Cependant, dans notre situation avec un cahier de laboratoire à réaliser, 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
3.2 Présentation d’URBI 11

à la recherche d’un programme qui ferait cela pour nous, et nous en avons trouvé un, sur le
site UrbiForge dont le lien figure à la fin du rapport, répondant au doux nom d’actionfile.
Avant donc d’expédier nos instructions à notre robot Lego, nous avions une étape de plus
à exécuter : le lancement en console du programme téléchargé. Une fois celui-ci en route, il
s’est chargé de relever les valeurs des capteurs lorsque nous le lui demandions et nous n’avons
plus eu qu’à convertir le fichier créé 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 éléments afin de pouvoir mener à bien nos
expérimentations.
3.2 Présentation d’URBI 12

Fig. 3.3 – Le serveur

Fig. 3.4 – L’exécutable du programme actionfile.exe


3.2 Présentation d’URBI 13

Fig. 3.5 – Le client


3.3 Objectifs 14

3.3 Objectifs
Une fois en possession de nos charmants robots et du langage adéquat pour les faire
tourner, l’objectif donné par notre encadrant était de pratiquer diverses expériences sur les
deux modèles disponibles afin de tester leur (( régularité )), si l’on puit dire. Le but était donc
le suivant :
– réfléchir à diverses expériences réalisables par des robots peu perfectionnés ;
– tester exactement la même expérience, dans les mêmes conditions, sur les deux robots,
pour comparer leur rendement et le résultat final ;
– tester deux expériences proches l’une de l’autre et devant rendre le même résultat sur
un seul robot pour vérifier que le robot réagissait bien de la même manière dans les deux
situations, par exemple dans des conditions environnementales différentes (en matière
de niveau sonore ou de luminosité par exemple) afin d’observer (ou non) des disparités
dans les résultats obtenus.
Les résultats devaient être consignés dans un cahier de laboratoire que nous rendrions avec
notre rapport. Nous nous devions donc de noter le protocole de chaque expérience réalisée,
et de créer des fichiers .csv représentant les résultats obtenus.

3.4 Expérimentations sur les robots


3.4.1 Réflexion sur les expériences à réaliser
La principale difficulté était de choisir les expériences que nous allions faire réaliser à
nos robots. Au départ, des idées folles nous ont traversé l’esprit, comme par exemple faire
traverser un labyrinthe à nos Mindstorms... Jusqu’à ce que nous observions par nous-mêmes
que même équipés de technologies de pointe, ils restaient avant tout... des Lego.
Avec un matériel peu précis au niveau du montage, les pièces se clipsant les unes dans les
autres comme dans tout Lego qui se respecte, la précision des robots n’était déjà pas excep-
tionnelle. Mais l’autre problème des Mindstorms réside dans l’électronique... Il ne nous a fallu
que quelques minutes pour constater que les capteurs avaient parfois de sérieux problèmes,
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étecté par les ultrasons, et qu’il ne le décelait pas.
Nous avons donc revu nos objectifs à la baisse, et nous sommes inspirés des travaux de M.
Mathias Paulin, chercheur au LIRMM, que nous avons eu l’occasion de rencontrer à plusieurs
reprises. Sur une vidéo que nous avons pu voir, le robot devait attraper une canette qui était
déplacée lorsqu’il s’en approchait.
Nous avons donc réalisé deux expériences. La première consistait à disposer une canette
(ou tout autre objet assez haut et large pour être repéré 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éplacer.
Ce premier protocole nous fournirait une première indication de la fiabilité du Mindstorm :
on peut difficilement faire plus basique, et il est compliqué d’imaginer que notre automate
puisse gérer un objet en mouvement s’il ne peut le faire avec une cible fixe.
La seconde expérience nous plongeait en plein dans le concept d’intelligence artificielle :
il ne s’agissait plus de dire au NXT, ”Tiens, voilà une canette en face de toi, attrape-là !” ;
mais plutôt, ”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éplacer lorsqu’il
arriverait à proximité et observer la réaction du Lego.
3.4 Expérimentations sur les robots 15

En réalisant chacune de ces expériences plusieurs fois, nous pourrions ainsi nous faire
une idée de la fiabilité des robots de type Mindstorms. Mais pourquoi se placer dans des
conditions environnementales différentes pour les exécuter ?
Certains robots ont beau sembler à la pointe de la technologie, il suffit d’un rien pour les
amener à un échec. Demandez par exemple à votre nouvel appareil ménager de faire tourner
votre machine à laver. Intelligent comme tout, si vous le lui demandez, il commencera par
trier le blanc et les couleurs. Et là, survient une panne de courant... Plongé dans l’obscurité
la plus totale, le robot est perdu. Nous avons donc voulu savoir ce qu’il en était avec les Lego
Mindstorms, qui sont encore loin d’être les robots de l’an 3000.

3.4.2 Algorithme et implémentation du code URBI


L’algorithme auquel nous avons réfléchi devait s’inspirer du diagramme états - transitions
suivant.

Fig. 3.6 – Diagramme états-transitions

Nous avons donc élaboré l’algorithme suivant :

si bumper enfoncé alors


refermer la pince
sinon
si objet détecté à moins de 60cm alors
se déplacer tout droit
sinon
chercher un objet à moins de 60 cm
fin si
fin si

Le langage URBI fournit tous les prédicats nécessaires 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 à tel
moment de l’exécution : des macros comme catch transition existent, et il suffit d’entrer du
3.4 Expérimentations 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 être traduit en code de moins d’une centaine de lignes. Celui-ci figure en
annexe.

3.4.3 Réalisation des expériences


Première expérience
Conditions environnementales Normales
Position de la canette En face du robot
Distance de départ Environ 35 cm
Cible fixe Oui
Taux de réussite 100%
Effectuée à plusieurs reprises sur les deux robots, cette expérience a à chaque fois été un
succès. Petit point négatif cependant : le Mindstorm NXT a tendance à dévier plus ou moins
de sa trajectoire, de façon très légère certes, mais d’une façon qui peut tout de même in-
fluer sur le résultat de l’expérience. 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çon perpendiculaire. Mais l’angle de déviation, entre 5 et 10 degrés, aurait pu faire rater
l’observation si la distance de départ avait été de 80 centimètres ou plus...

Seconde expérience - Phase 1


Conditions environnementales Normales
Position de la canette En face du robot
Distance de départ Environ 25 cm
Cible fixe Non
Taux de réussite 60%
Cette expérience a été réalisée dans les mêmes conditions que la première. La différence
résidait dans le fait que l’objectif à atteindre par le robot était, cette fois, en mouvement.
Nous placions donc le robot à 25 centimètres de sa cible, droit en face de lui, le laissions tran-
quillement avancer et dès qu’il se trouvait à une distance minime de la canette (inférieure à
5 centimètres), nous retirions celle-ci de sa position initiale. Nous la replacions à environ 25
centimètres de lui selon un angle de 90 degrés sur sa droite pour tester sa réaction.
Nous avons donc pu en tirer de nouvelles conclusions. Nous avions déjà remarqué le
manque de rigueur de nos automates dans leurs déplacements, nous avons pu, en plus, nous
rendre compte de défaillances dans leur compréhension des situations, et d’un manque de
rapidité flagrant dans la réaction. Il est par exemple arrivé que le Lego continue d’avancer
après que nous ayions déplacé sa cible, alors que lui même notifiait via la console utilisateur
qu’il l’avait perdue de vue et que le simplissime code URBI ne laissait la place à aucune
ambigüité, ou encore, après avoir redécouvert la canette, qu’il continue à tourner quelques
dixièmes de seconde... assez pour que sa trajectoire ne se retrouve définitivement faussée.
Ces quelques ratés ont donc fait chuter le taux de réussite des expériences... De 100%
dans l’expérience 1, il passe à 60% dans la première phase de cette expérience 2.
3.5 Premières conclusions... et perspectives 17

Seconde expérience - Phase 2


Conditions environnementales Noir total
Position de la canette En face du robot
Distance de départ Environ 25 cm
Cible fixe Non
Taux de réussite 70%
Le niveau de luminosité a-t-il une quelconque incidence sur le bon déroulement de notre
expérience ? C’est ce que nous avons tenté de découvrir en plongeant l’environnement du
robot dans le noir le plus complet avant de réitérer le protocole de cette expérience.
En théorie, armé de son capteur ultrasons, le Lego Mindstorms NXT n’avait pas besoin
d’autre chose pour se repérer. Et les expériences menées lors de cette deuxième phase l’ont
confirmé. Si le premier robot a connu quelques difficultés, ce sont les mêmes qui existaient
déjà lors de la phase 1 : temps de latence plus ou moins important entre l’événement ”canette
déplacée” et l’événement ”robot en mode déplacement”. Au final, il n’a pas paru plus ennuyé
pour se déplacer dans l’obscurité qu’en plein jour.

Seconde expérience - Phase 3


Conditions environnementales Niveau sonore très élevé
Position de la canette En face du robot
Distance de départ Environ 25 cm
Cible fixe Non
Taux de réussite 40%
Comme dans la phase 2, nous avons altéré l’environnement de nos Lego Mindstorms NXT
en jouant sur un autre critère : cette fois, il s’agit du niveau sonore. Comment réagiront nos
automates au milieu d’un vacarme assourdissant ?
Le taux de réussite n’a été cette fois que de 40%, et régresse donc par rapport aux deux
phases précédentes. Néanmoins, nous ne pensons pas que cela soit dû au niveau sonore très
élevé. Les causes d’échec ont été sensiblement les mêmes que dans les expériences précédentes,
à savoir un décalage entre la détection de la canette et la reprise de la marche avant ou des
erreurs au niveau des capteurs.

3.5 Premières conclusions... et perspectives


Revoyons le résultat de nos expérimentations. Comme on pouvait s’y attendre, les robots
n’ont pas connu un taux de réussite de 100%... Quelles sont donc les causes des échecs de nos
petites bêtes ? La plupart du temps, il s’agit d’une erreur de précision lors de la détection
de la canette. Souvent, le robot s’est arrêté de balayer avant d’être en face de son objectif,
souvent aussi, il a continué à tourner un petit moment après l’avoir aperçue : cela se comptait
en dixièmes de seconde, mais c’était suffisant pour lui faire rater son but.
Nous remarquons ensuite comme il nous était demandé, d’un point de vue statistique,
que les robots Mindstorms NXT n’ont pas semblé affectés par les altérations que nous avons
fait subir à leur environnement.
Toutefois, il en aurait été autrement si nous avions décidé de nous livrer à des expériences
plus pointues. Imaginons par exemple que nous souhaitions que notre robot parte à la chasse
3.6 John Robot 18

à la canette, puis, lorsque nous lui crierions quelque chose, arrête d’avancer et revienne
vers nous comme un chien ferait avec son maı̂tre. L’expérience aurait pu marcher dans des
conditions sonores normales, mais aurait probablement échoué lors d’une démonstration dans
un amphithéâtre comble.
Nous avons donc décidé d’aller plus loin et de réaliser une expérience de ce type afin de
prouver les limites des automates face à des situations qui peuvent les confondre.

3.6 John Robot


3.6.1 Présentation de l’expérience
Les Lego Mindstorms NXT sont équipés d’un capteur de luminosité, d’un capteur ul-
trasons et d’un capteur sonore. Or, le premier cité est en réalité un capteur qui permet de
mesurer la luminosité... sous les roues du robot, où se trouve une LED rouge éclairant la
surface sur laquelle se déplace le robot. Nous en avons pris connaissance lors de la phase 2
de l’expérience 2, lorsque nous avons réalisé que les valeurs enregistrées par le capteur de
luminosité étaient bien trop peu altérées par rapport aux conditions normales...
Le moyen le plus simple de mettre nos appareils en situation délicate était donc de jouer
sur le niveau sonore. Nous avons donc imaginé une expérimentation mettant en scène John
Robot, la version sur roues de John Rambo, qui se déplacerait dans une jungle amazonienne
ici incarnée par un sol carrelé plat...
Que ferait John Rambo s’il entendait un coup de feu au-dessus de sa tête ? Il s’arrêterait
probablement un instant, puis reprendrait sa route quelques instants plus tard, une fois que
les choses se seraient calmées. Mais si les coups de feu persistent, il prendrait ses jambes à
son cou pour se mettre à l’abri plus loin.
Pour John Robot, le principe est le même. Nous avons simplement remplacé les coups de
feu par des sifflements stridents. Le robot doit donc débuter son avancée, puis s’arrêter s’il
entend un sifflement bref. Au bout de quelques secondes, il reprend son avancée. Seulement,
si le sifflement dure assez longtemps, il repart en avant à une vitesse bien supérieure à sa
vitesse ((de croisière)).
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éaliser cette expérience deux fois : une
première dans des conditions normales, une seconde dans des conditions sonores désastreuses,
afin de tester les réactions des Lego dans les deux cas.
3.6 John Robot 19

3.6.2 Algorithme et implémentation du code URBI


Voici le diagramme états - transitions que nous avons conçu pour décrire cette expérience.

Fig. 3.7 – Diagramme états-transitions

Nous en avons tiré l’algorithme suivant.

si niveau sonore bas pendant 3s alors


avancer normalement
fin si
si niveau sonore élevé pendant 5s alors
avancer très rapidement
fin si
si niveau sonore élevé pendant moins de 5s alors
s’arrêter
fin si

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

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

permet de tester en parallèle (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é
déconcertante. Le code figure en annexe.

3.6.3 Réalisation des expériences


Ainsi que nous l’avions escompté, les deux expériences se sont déroulées de façons totale-
ment différentes.
Menée dans le silence, la première a connu l’issue que l’on attendait. Le robot a commencé
à avancer lentement, jusqu’au premier sifflement qui l’a fait s’arrêter. Il a repris sa marche
en avant quelques secondes après et s’est arrêté de nouveau après un second sifflement. Alors
que le Lego était à l’arrêt, un long sifflement l’a alors fait repartir à toute vitesse.
3.7 Conclusion 20

La deuxième expérience a été réalisée en créant un environnement bruyant. Après un


premier arrêt qui s’est bien passé, une sonnerie de téléphone portable a été détectée par le
Lego Mindstorm NXT qui l’a perçue comme il aurait pu percevoir le sifflement. Celle-ci a eu
pour effet de le faire repartir en avant alors même que rien ne lui était demandé.

3.7 Conclusion
Nous avons donc pu en déduire que l’environnement dans lequel est plongé un robot
influe bien sur ses réactions. Si un humain ou un robot très perfectionné aurait pu discerner
le sifflement au milieu des autres sons émanant de celui-ci, cela n’a pas été le cas du Lego qui
s’est retrouvé perdu entre sifflements et sonneries de téléphone portable. Nous avons donc eu
l’occasion de constater les limites de l’intelligence artificielle appliquée à la robotique.
Nous avons également pu vérifier, comme nous le demandait notre encadrant, que deux
robots identiques auxquels nous aurions demandé la même chose ne réagiraient pas de la
même manière. Ou encore, que deux expériences censées produire les mêmes résultats mais
exécutées sur des machines différentes dans les mêmes conditions peuvent connaı̂tre des issues
différentes. C’est sur cette conclusion que nous avons remis notre cahier de laboratoire à M.
BOURREAU et au LIRMM.
Chapitre 4

Vers un portage URBI pour HOAP ?

Le cahier de laboratoire que nous avons conçu nous a permis de nous forger une solide
approche de l’univers à l’intersection des mondes de la robotique et de l’intelligence artificielle.
Travailler avec des robots peu performants nous a également ouvert les yeux sur les limites que
nous pourrions rencontrer plus tard dans ce domaine, et nous a fait réfléchir à d’éventuelles
améliorations pouvant être apportées.
Cependant, pour ce qui est de notre Travail d’Etude et de Recherche, les améliorations
en question existent déjà, et sont à notre portée. Les Lego Mindstorms NXT allaient céder
la place à un tout autre modèle de machine aux possibilités bien plus étendues : le HOAP
de Fujitsu.
Mais la facilité avec laquelle nous avons manipulé les robots Lego ne serait plus alors
qu’un lointain souvenir... Revenons quelques jours (semaines) en arrière, nous commandions
deux automates équipés de trois capteurs (ultrasons, sonore, lumineux) et trois moteurs
(pince, roue gauche, roue droite). Avec HOAP, il nous faudra jouer avec 28 degrés de liberté
(comprenez, 28 moteurs) et 13 capteurs !
De plus, nous ne pouvons pas compter sur la stabilité dont disposaient les Lego, posés sur
leurs trois roues, avec le dernier né de Fujitsu. Comme un enfant auquel nous apprendrions à
faire ses premiers pas, il dispose d’un centre de gravité dont nous devons tenir compte pour
parer à toute chute, notamment lors de l’exécution d’un pas où le robot tient sur une seule
de ses deux jambes métalliques. Et lorsqu’on joue avec un robot qui coûte plus de 30.000
euros, il vaut mieux éviter ce genre de mésaventures.
Lors d’une réunion au LIRMM avec notre encadrant, M. BOURREAU, celui-ci nous a
donc conseillé d’explorer d’abord la piste Aibo. Le gentil petit chien robot de Sony se situe
à mi-chemin entre les Lego Mindstorms NXT et HOAP : naturellement instable puisqu’il ne
peut pas garder l’équilibre dans n’importe quelle position, tout comme HOAP, il est toutefois
possible de le commander grâce à URBI qui, s’il nous a simplifié la vie avec les Lego, peut
tout autant le faire avec Aibo...
Ceci dit, le LIRMM ne disposant pas de modèles d’Aibo, cette piste semble compromise.
Elle aurait cependant pu être un bon compromis entre le travail réalisé et le portage sur
HOAP.

21
Chapitre 5

Conclusion et perspectives

5.1 Conclusion
Au cours de ce projet, nous avons atteint la limite dont nous avions parlé initialement :
celle qui sépare le monde théorique du monde physique. Le code écrit peut s’avérer juste,
néanmoins l’environnement dicte toujours ses règles. Un rien suffit parfois à faire échouer une
expérience même facilement réalisable : une défaillance des capteurs, un obstacle imprévu, et
le robot se retrouve dans une situation qu’il ne sait pas gérer.
La réalisation du cahier de laboratoire nous a permis de toucher du doigt le monde de
la recherche en laboratoire avec ses expériences, ses compte-rendus et ses publications. La
réalisation d’un protocole, la mise en pratique d’une “simple” expérience qui semble plutôt
banale pour nous, s’est révélée plus difficile que prévu. Si rendre les automates intelligents,
leur donner la capacité de penser, n’est déjà pas une chose facile, les faire réagir positivement
face à n’importe quelle situation imaginable ressemble fort à une tâche interminable.
Soulignons également que la réalisation de ce TER fut différente de celle escomptée au
depart. En effet, le travail qui nous a été assigné consistait à effectuer un portage du code
URBI sur le robot HOAP, qui est sur une plateforme logicielle RTLinux. Pour des raisons
techniques et de disponibilité des chercheurs ce portage n’a pas pu être effectué. Nous avons
donc été assignés à une autre tâche : réaliser un cahier de laboratoire complet avec réalisation
d’expériences 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 à travailler avec HOAP.

5.2 Difficultés rencontrées


Nous avons souffert, lors des expérimentations, 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 à travailler sur un tel concept, et n’avons rien trouvé qui puisse réellement nous
aider sur ce sujet. Nos encadrants n’ont pas été plus prolixes sur le sujet. Nous avons donc
été obligés d’avancer seuls, en notant ce qui nous paraissait être utile.
Comme explicité plus haut, nous avons également dû revoir le sujet du projet suite aux
réticences 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ême pas laissé l’apercevoir, même après que nous leur ayons présenté

22
5.3 Perspectives 23

un cahier de laboratoire complet et malgré les requêtes de notre encadrant. Au final, nous
avons composé sans HOAP à 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écupérer des humains dans des décombres, les
robots prenant le reste des décisions.
A court terme, le principal objectif des roboticiens devrait donc être de forcer l’appren-
tissage de leurs robots en les mettant face à des situations différentes, avant même de leur
donner des fonctionnalités plus avancées. N’importe quel appareil, tout aussi évolué qu’il soit
au niveau des possibilités, ne pourra rien sans une intelligence à tout épreuve le permettant
d’avoir une solution pour chaque cas imaginable.
C’est ce que nous espérons réaliser ces prochains mois, en participant au Concours RobAFIS
2008, qui nous occupera à compter de la fin du mois d’avril jusqu’au mois de décembre 2008.
L’objectif : évaluer les performances d’un robot Lego confronté à un environnement truffé
d’obstacles... et d’adversaires. La présence d’autres automates représente un challenge nou-
veau que nous sommes prêts à relever.
Chapitre 6

Références

6.1 Références bibliographiques


6.2 Références numériques
– 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çais)
– http://www.urbiforge.com/
Le site de référence sur URBI (multilingue)
– http://www.wikipedia.com/
L’Encyclopédie en ligne (multilingue)
– http://www.automation.fujitsu.com/
La section Automates de Fujitsu (anglais)

24
Annexe A

Implémentation 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ène la variable globale toSave


// avec les valeurs des capteurs à 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ée lors de la phase de recherche


search_transition:
at (sonar > 60) {

25
A Implémentation URBI du code ((attrape-canette)) 26

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


stop goto;
search: searchCan();
};

// Fonction qui sera appelée lors de la phase de déplacement


goto_transition:
at (sonar <= 60) {
stop search;
goto: goToCan();
};

// Fonction qui sera appelée 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

Implémentation URBI
du code ((John Robot))

// Variables globales
global.normalSpeed = 10;
global.fullSpeed = 30;
global.time = 0;

// Toutes les 500 millisecondes, on concatène la variable globale toSave


// avec les valeurs des capteurs à 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 à produire, selon les attentes de
notre encadrant et du Laboratoire d’Informatique, de Robotique et de Micro-électronique de
Montpellier, est joint à ce dossier.

28