Luận văn thạc sĩ VNU intégration du wifibot dans larchitecture playerstage

Aujourd'hui, de plus en plus de robots sont utilisés et cela dans divers domaines.Ils sont aussi utilisés dans les laboratoires pour tester les algorithmes, les stratégies avant de les a

Intégration du WiFiBoT dans l'architecture

Player/Stage

Encadrement François Sempé Serge Stinckwich Victor Moraru

Étudiant TRAN Dinh Luyen - P13

20 décembre 2009

Avant de présenter mon rapport, je tiens à remercier :

 M François Sempé1, M Serge Stinckwich2, M Victor Moraru3 pour avoir proposé cesujet et pour m'avoir aidé beaucoup pendant mon stage

 L'ensemble du personnel de l'IFI et plus particulièrement mes collègues du laboratoireMSI, pour le déroulement du stage dans une ambiance agréable

 Les chercheurs de l'école des mines de Douai qui m'ont aidé à corriger les bugs sur lacompilation croisée et plusieurs autres points concernant le WiFiBoT

 M Nguyen Manh Cuong, M Nguyen Huu Nghia et les étudiants de l'IFI pour m'avoiraussi aidé durant mon stage

1 IFI / Univ Paris 6

2 IRD/UPMC

3 Professeur IFI

i

Aujourd'hui, de plus en plus de robots sont utilisés et cela dans divers domaines.

Ils sont aussi utilisés dans les laboratoires pour tester les algorithmes, les stratégies avant

de les appliquer à l'environnement réel Les simulateurs, permettant de faire évoluer les robotsdans un environnement précis, sont l'outil principal du chercheur Plusieurs simulateursexistent, celui que nous avons retenu se nomme Player/Stage Avec ce simulateur, beaucoup

de types de robots et de périphériques sont disponibles Il fonctionne en mode client/serveur,permettant à un client de contrôler les robots par une connexion de TCP/IP

Dans mon travail, nous souhaitons de créer un nouveau driver pour le WiFiBoT Cedriver permet au WiFiBoT de communiquer avec un programme client pour le contrôler

Tous les mécanismes de communications entre le client et le Wibot sont les mêmes qu'avec

le serveur Player Ce rapport présente tous les travaux d'implantation et de tests du serveurPlayer

Mots-clé : WiFiBoT, compilation croisée, Player/Stage

In my work, we want to create a new driver for the WiFiBoT This allows the driverWiFiBoT communicate with a client program to control it All the mechanisms of communi-cation between the client and Wibot are the same as the Player server This report providesall the implementation work and testing the server player.

Keywords : WiFiBoT, cross-compiling, Player / Stage

iii

Remerciements i

1.1 Contexte du stage 1

1.2 Problématique 1

1.3 L'objectif du travail 2

1.4 Plan du document 3

2 Le WiFiBoT 4G 4 2.1 Caractéristiques du WiFiBoT 4

2.2 Roue codeuse 6

2.3 Infra-rouge 6

2.4 Wi 7

2.5 Moteur 8

2.6 Précision des capteurs/actionneurs 8

2.7 La compilation croisée mipsel-linux pour le WiFiBoT 8

2.8 Conclusion du chapitre 9

3 Le simulateur 10 3.1 Choix du simulateur 10

3.2 Player/Stage/Gazebo 13

3.2.1 Player 14

Master en Informatique/Système et Réseaux

3.2.2 Stage 15

3.2.3 Intégration du WiFiBoT dans l'architecture Player/Stage 16

4 Modèle du WiFiBoT pour Stage 18 5 Implantation le serveur Player à wibot 25 5.1 Pilotage des actionneurs et lecture des informations du capteurs/détecteurs 25 5.2 Implantation du driver pour le WiFiBoT 28

5.2.1 La partie d'IR 32

5.2.2 La partie de wi 34

5.3 Compiler le serveur Player et le transforme à WiFiBoT 35

6 Évaluation du serveur Player sur le WiFiBoT 37 6.1 Méthodologie de test 37

6.2 Évaluation quantitative de calibration 37

6.3 Évaluation quantitative de comportement 42

6.3.1 Éviter les obstacles 42

6.3.2 Se rapprocher d'un autre robot 44

6.3.3 Résultat du test des comportements 45

6.4 Les limitations 47

6.5 Les dicultés 47

2.1 WiFiBoT 4G 4

2.2 la valeur du signal en fonction de la distance 7

3.1 Les modules de SimRobot et ses dépendances 11

3.2 (a) Le simulateur en 2D, (b) Le simulateur en 3D 13

3.3 Communication du Player 14

3.4 Modèle Client/Serveur du Player 15

3.5 Le schéma de comunication 17

4.1 Le modèle du robot sur le simulateur 24

5.1 Structure d'une commande moteur 27

5.2 Le processus d'un driver 29

5.3 Le graphe des dépendances includes 29

5.4 Le graphe d'appel les fonctions d'enregistrer 30

5.5 La relation entre la valeur brute du robot et la valeur de la distance 33

5.6 La relation entre la valeur brute du robot et la valeur de la distance 34

5.7 Le contenu de chier signalWi 35

6.1 Schéma illustre de test IR : (a) schéma, (b) résultat 38

6.2 Le test des valeurs réels et les valeurs récupérées du robot 39

6.3 Le test des moteurs 40

6.4 Les résultats reçus quand on récupère le signal de wi (schéma 1) 41

6.5 Les résultats reçus quand on récupère le signal de wi (schéma 2) 41

6.6 L'algorithme d'éviter un obstacle 42

6.7 L'algorithme d'approcher 44

Master en Informatique/Système et Réseaux

6.8 Illustrer le fonctionnement du comportement sur le simulateur : (a) au début,(b) à la n 466.9 Illustrer le fonctionnement du comportement sur le robot réel : (a) début, (b)

à la n 46

Un robot est un outil programmable capable de réaliser des actions précises, adaptées

et répétitif dans un environnement donné Les robots sont progressivement sortis du mondeindustriel pour rentrer dans le monde médical, et sont actuellement des systèmes complexesintégrant de la perception et des actions

1 Modélisation et Simulation Informatique de systèmes complexes

2 Institut de Recherche pour le Développement

3 Jeune Equipe Associée

4 quatrième génération

Master en Informatique/Système et Réseaux

On a utilisé les robots depuis longtemps dans les entreprises pour plus économie et plusecacité Il est possible aujourd'hui de coner une multitude de tâches à un robot (explo-ration ; géo localisation ; communication, )

Actuellement on utilise aussi de nombreux de robots dans les laboratoires pour tester lesalgorithmes avant de les appliquer à l'environnement réel Plusieurs dicultés existent eneet lorsqu'il s'agit de travailler directement sur les robots On utilise donc des simulateurs,permettant de reproduire toutes (ou une grande partie) les caractéristiques matérielles etactions du robot

En eet, il y a plusieurs limitations quand on travaille directement sur les robots réels

À cause de la mémoire limitée des robots, on va perdre beaucoup de temps pour tester lestravails, alors un simulateur est très nécessaire D'abord, avec le simulateur, les program-meurs peuvent créer les environnements, avec les objets comme les murs, les obstacles, , ilfournit la variété des environnements De plus, ils permettent de simuler plusieurs types desactionneurs, des détecteurs des robots diérents Alors, des simulateurs sont très utiles pourtravailler sans robot réel et ils assurent l'exactitude de fonctionnement des programmes Enoutre, il n'y a pas beaucoup de diérents entre les résultats obtenus sur le simulateur et lesrésultats sur le robots réels

Un des problèmes est qu'on doit assurer que le fonctionnement sur le simulateur et surles robots réels soient le même En détail, dans mon travail sur le simulateur et le robotréel, nous devons utiliser même le programme client pour les communiquer C'est-à-dire, lemécanisme pour fonctionner sur le simulateur et sur le robot est même

Avec cela, on peut développer une seule fois les comportements qu'on peut les utiliser ensimulateur et en robot réel Et on peut faire l'évaluation d'un comportement se fait à la foispar simulateur et en robot réel

1.3 L'objectif du travail

Le but du travail est de trouver une soulution qui permet de développer les comportementsqui peuvent fonctionner sur n'importe quel type robot À partir de ce but, durée le stage,dans le premier temps nous devons trouver un simulateur qui satisfait les critères :

 Le code source est disponible

 Permet de simuler multi-robots

 Utilise sur multi-Platforms

 Peut transformer à robot réelPuis le matériel choisi pour est le WiFiBoT 4G Ce type de ce robot est disponible au MSImaitenant Dans deuxième de temps, nous allons implanter cette solution, c'est-à-dire faireune intégration le serveur sur le WiFiBoT Le fonctionnement de ce serveur doit être mêmeavec le simulateur et il permet d'utiliser les mêmes programmes clients pour communiquersoit sur le simulateur, soit sur le robot réel

En détail, le travail du stage se compose de trois parties principales :

 La partie du choix le simulateur

 La partie d'implantation le serveur sur le WiFiBoT

 La partie de test du WiFiBoT

Dans la première partie, nous allons choisir et implanter le simulateur et dénir le modèle

de WiFiBoT sur ce simulateur Ce sont les dénitions de l'infra-rouge, la taille et la forme

du WiFiBoT

La deuxième partie présente les travaux d'implémentation le serveur au WiFiBoT C'est

un nouveau driver pour le WiFiBoT Ce driver se compose trois interfaces correspondant àl'infra-rouge, au wi et le dernier gérant les actions du moteur

La dernière partie est le travail de test du serveur sur le robot réel Les deux programmesont pour but de tester le serveur sur le robot réel

1.4 Plan du document

Ce document se compose 7 parties

La première partie introduira le contexte et la problématique du stage La deuxièmeprésentera les caractéristiques du WiFiBoT que nous l'avons utilisé La partie suivante ex-pliquera les simulateurs et la raison du choix le simulateur Player/Stage et ensuite ce sont

le détail du simulateur choisi avec sa structure et son fonctionnement La quatrième partieprésente un modèle du WiFiBoT pour Stage Et la cinquième partie est les travaux sur l'im-plantation du serveur Player et des comportements des robots Vous trouverez l'évaluation

de la solution, les dicultés et les limitations du serveur Player dans la sixième partie Nousconclurons ce rapport par une conclusion et des perspectives d'évolution sur ce projet

Chapitre 2

Le WiFiBoT 4G

Le WiFiBoT 4G est un robot avant tout exible On peut l'utiliser dans de multiplesenvironnements et de situations Il possède un routeur Erthenet sur lequel sont connectésune caméra IP mobile et un bus I2C qui permettent la communication avec les diérentsactionneurs et capteurs/détecteurs du robot par l'intermédiaire de microcontrôleurs

Processeur MIPS AMD Au1500

RAM 64 MBMémoire ash 32 MB4x Ethernet 10/100 BaseTInterfaces 1x USB (optionnel)

1x I2C bus1x RS232 portWiFi 802.11a/b/gSeamless RoamingWIFI réseau maillé (OLSR)

WLAN AP, pond, Clientpasserelle / routeur1x Antenne 5dBi1x Caméra IP Pan-Tilt2x capteurs IR

Capteurs 2x encodeurs odométriques (2 PID indépendants, sur chaque roue)

2 x DSPIC30F2010Niveau de la batterie4x moteurs 7.2VMoteurs 50 :1

8.87Kg/cm

120 rpmLongeur : 28 cmDimensions Largeur : 30 cm

Hauteur : 20 cmPoids : 4.5Kg9.6V NiMh

9500 mAHBatteries 2h d'autonomie

Remplacement facileChargeur inclus

Master en Informatique/Système et Réseaux2.2 Roue codeuse

Ses 4 roues motrices permettent au robot d'évoluer sur des surfaces irrégulières et sur

de petits obstacles Ses dimensions raisonnables et sont poids réduit le rendent facilementtransportable et parfait explorer les moindres recoins

Il y a une roue codeuse associée à chaque roue du robot Elle permet d'obtenir uneindication sur la vitesse

La formule pour se trouver la vitesse :

vitesse de la roue = nombre de secteurs1/25 secondRemarque : On peut seulement connaître la vélocité du déplacement Il n'est pas possible

de savoir si le robot avance ou recule

2.3 Infra-rouge

Le WiFiBoT est équipé de deux télémètres infra-rouges1 qui mesurent la distance entre

le robot et un obstacle Ils sont situés à l'avant du robot sur le châssis La portée de cecapteur est comprise entre 20 et 150cm

1 http ://sharp-world.com/products/device/lineup/data/pdf/datasheet/gp2y0a02_e.pdf

Fig 2.2  la valeur du signal en fonction de la distance

La mesure retournée n'est pas proportionnelle à la distance Il est donc souvent nécessaire

de linéariser la réponse du capteur

Le gure 2.2 représente la valeur du signal en fonction de la distance Un lien sur unexemple de linéarisation sur un capteur de la même série : http://www.acroname.com/

robotics/info/articles/irlinear/irlinear.html

2.4 Wi

Un des grands avantages du WiFiBot, c'est qu'on peut l'utiliser suivant trois modesdiérents qui sont le mode piloté (mode piloté à distance, mode contrôle déporté et modecontrôle embarqué) Dans le mode piloté à distance, on se connecte au robot dans un modeWiFi quelconque, par exemple homologue à homologue (Adhoc) et on peut aussi utiliser lepoint d'accès (Infrastructure), et on le pilote à distance comme un véhicule téléguidé Cemode demande au préalable une conguration du robot, adresses IP, numéros de port et lechoix du mode de fonctionnement On peut transmettre les commandes de base au robot etvisualiser l'état ou les valeurs de mesure de ses capteurs/détecteurs

Master en Informatique/Système et Réseaux2.5 Moteur

Le WiFiBoT possède quatre moteurs de type pas à pas à courant continu Ce type

de moteur est plus facile à commander pour obtenir des positions précises Il est possibled'activer un système d'asservissement au prix d'une diminution de la vitesse maximum Lesmoteurs sont regroupés en deux blocs : droite et gauche pour ce qui est de la commande Ilfaut donc combiner deux ordres pour avoir accès à tous les types de déplacement possibles

du robot

2.6 Précision des capteurs/actionneurs

Comme actionneurs, le WiFiBoT possède quatre moteurs, un pour chacune de ses roues,pouvant être pilotés en boucle ouverte comme en boucle fermée à travers le bus I2C (voirplus détail dans le schéma 5.1, le bit 7 permet d'activer ou non le correcteur PID associé

à chaque actionneur pour la régulation de la vitesse Avec le bit7 on décide si on veut queles actionneurs fonctionnent en boucle ouverte ou en boucle fermée) Chaque roue possède

un codeur incrémental servant à la régulation de sa vitesse par l'intermédiaire de son proprecorrecteur PID

Il est à noter qu'on peut éventuellement approximer une distance parcourue grâce à cescodeurs quand on est en mode autonome Pour les capteurs/détecteurs, le robot récupère,dans un premier temps, une mesure de sa vitesse de déplacement grâce à ses codeurs in-crémentaux, puis, par l'intermédiaire de deux détecteurs de proximité, il peut connaître ladistance à laquelle il se trouve d'un obstacle dans un rayon de 1m30 Finalement, il peutaussi obtenir une mesure de son niveau de batterie

2.7 La compilation croisée mipsel-linux pour le WiFiBoT

Pour pouvoir commencer des programmes dans le WiFiBoT, il est nécessaire de pouvoircompiler des exécutables pour son systèmes d'exploitation Nylon Mais le problème est que

le NyLon ne possède pas de compilateur On ne peut donc pas utiliser le compilateur Cgcc De plus la capacité mémoire du robot est très limitée, on ne peut donc pas installer uncompilateur

La solution consiste à utiliser un compilateur spécial qui s'appelle  Mipsel-gcc et quis'installe sur une distribution quelconque Celui-ci permet de compiler des programmesdont les exécutables sont compréhensibles par le WiFiBoT On utilise alors l'appellation

de  Cross-Compiler 

Une compilation croisée (cross compiler) traduit un code source sur une ordinatrice source(HOST) en code objet pour un environnement d'exécution cible (TARGET), d'architecturematérielle diérente de celui ó la compilation a été eectuée

L'environnement de compilation croisée s'appelle  chaỵne d'outils (toolchain) Une chaỵned'outils est un ensemble de programmes utilisés pour créer un binaire Ces outils peuventêtre utilisés en chaỵne, c'est-à-dire que la sortie d'un outil est l'entrée d'un autre

Durant mon stage, nous avons utilisé une chaỵne d'outils qui s'appelle Mipsel-Linux,disponible au site web http://wifibot.com (http://www.wifibot.com/download/crosslast

tar.gz) C'est une chaỵne d'outils complète, on a uniquement besoin de congurer le chemind'accès des outils On modie la variable d'environnement PATH comme ci-dessous :

$export PATH = $PATH:</chemin_du_répertoire_mipsel_linux/bin>

à partir de là, on peut utiliser le compilateur et les outils associés

2.8 Conclusion du chapitre

Le WiFiBoT est un type simple de robot On peut l'utiliser pour tester avec les actions

de la rotation, le déplacement, la récupération de la distance

simu-a ses simu-avsimu-antsimu-ages et ses déssimu-avsimu-antsimu-ages.

Pour simuler les environnements et les robots, plusieurs simulateurs s'oraient à moi :

éduca-de l'IA dans le cardre éduca-des robots autonomes 

Simbad permet aux programmeurs d'écrire leurs programmes de contrôler les robots,

et de modier l'environnement en utilisant des capteurs/détecteurs

Il a les caractéristiques suivantes :

10

 La visualisation en 3D

 Permet de simuler multi-robots

 Fournit les capteurs/détecteurs comme le caméra, le sonar, l'IR et le bumper

 Une interface proche les utilisateurs

3 Le simulateur Simrobot [10]

Le projet SimRobot a été commencé dans les années 1990 Ce simulateur permet lesutilisateurs à dénir les robots et leur environnement dans un espace à trois dimensions(3D) dans l'espace à trois dimensions

Fig 3.1  Les modules de SimRobot et ses dépendances

Il est exible pour la construction des modèles précis Il fournit une variété

d'organ-Master en Informatique/Système et Réseaux

ismes diérents, des capteurs et actionneurs En outre, le simulateur a une approcheorientée vers les utilisateurs en incluant plusieurs mécanismes de la visualisation, de lamanipulation directement des actionneurs, et l'interaction avec l'environnement simulé

Utilisation facile exigence de l'expertise facile assez bien

Tab 3.1  La comparaison entre les simulateurs disponibles

Le tableau 3.1 est une brève comparaison en fonctionnement de Gazebo, Webots et bad Le Simbad est très utile pour étudier des modèles dans les moyens projets ainsi quedans l'enseignement en domaine IA ou le robotique, alors que Player et Webots sont les bonschoix pour appliquer au projet à long terme avec les robots réels

Sim-On a choisi parmi ceux-ci le simulateur Player/Stage avec le trio Player/Stage/Gazebo

Grâce à une structure exible et au mécanisme de communication de type client/serveur, ilpermet de communiquer entre le client et le simulateur ou bien entre le client et le robotréel

De plus, avec ce simulateur, le programmeur peut choisir son langage, parmi une longueliste :

• Python

• Ruby

• Pour résumé, Player est un serveur de périphérique qui fournit une interface exible etune variété de capteurs et d'actionneurs Parce que Player utilise une structure de type clien-t/serveur avec une connexion de TCP/IP, les programmeurs peuvent utiliser n'importe quellangage pour contrôler les robots En outre, avec le trio Player/Stage/Gazebo, ils permettent

de simuler les robots dans un environnement de 2D et 3D C'est un choix idéal pour tester

et valider d'avant les exécuter sur les robots réels

En suite, nous présentons plus détail de simulateur Player/Stage ce que nous allonsutiliser

3.2 Player/Stage/Gazebo

Player/Stage/Gazebo est un projet qui permet la simulation de robot sur un ordinateuravec le trio Player, Stage et Gazebo Ce simulateur a été créé par les chercheurs de l'Uni-versité South Californie Il permet de simuler un très grand nombre de matériels y comprisles caméras (mais la simulation est plus que sommaire) La dynamique des robots peut êtreaussi simulée : on dispose de deux interfaces de visualisation : 2D et 3D (le gure 3.2)

Fig 3.2  (a) Le simulateur en 2D, (b) Le simulateur en 3DPlayer/Stage/Gazebo est un avancé simulateur robotique et une plate-forme d'interface

Master en Informatique/Système et Réseaux

Elle donne à la fois des outils pour simuler, ainsi que pour communiquer avec un systèmerobotique Nous avons utilisé le Player/Stage 2.1.2 alors tous les modications correspondcette version

Fig 3.3  Communication du Player

3.2.1 Player

Player est en réalité une interface réseau de type client/serveur (cf g 3.3 et g 3.4) quipermet de réaliser la simulation de robots dans leur environnement Il donne une possibilitéd'appliquer un algorithme d'intelligence avec les trois langages proposés (Java, C et C++)

Il permet de recueillir et de traiter les informations portées par les diérents capteurs quepossède chacun des robots de la simulation Il utilise un protocole TCP/IP pour la connexionentre client et serveur, et il permet aussi de contrôler les robots via les ports (attributiond'un port supérieur à 1024 pour chaque robot) Le port par défaut étant le port 6665, cequi en terme pratique, signie que si la simulation ne comporte qu'un seul robot, il n'est pasnécessaire de lui assigner un port, le 6665 lui sera attribué d'oce Le modèle client/serveurutilisé permet en outre de partager les données de la simulation en cours avec n'importe quelordinateur mis en réseau avec celui qui est le siège de la simulation, ce qui, pour une équipe

de recherche, peut se révéler particulièrement ecace et utile.

Fig 3.4  Modèle Client/Serveur du Player

Player fonctionne sous le modèle de Client/Server ayant beaucoup d'avantages :

• Distribution : Le modèle permet à un client d'accéder à des capteurs et à des tionneurs n'importe ó dans le réseau Un client peut accéder à plusieurs serveurs et

ac-un serveur peut gérer plusieurs clients Cela permet à ac-un programme de contrơler lesdiérents aspects d'un robot

• Indépendance : Les programmes clients peuvent être écrit dans l'importe quel langage

et sur n'importe quelle plateforme matérielle proposant une programmation des sockets

• Commodité : Le serveur fournit un abstract interface à des périphériques (device) Leprogramme de client s'abonne à un ensemble de périphériques et à une fréquence parpériphérique La fréquence permet au client de retirer les données d'un périphériquedonné à un instant donné

3.2.2 Stage

Stage est comme un driver de Player Il fournit une interface graphique à la simulation

en 2D, modélisant ainsi les déplacements des diérents robots Selon les programmeurs, on

Master en Informatique/Système et Réseaux

peut utiliser exactement le même mécanisme pour communiquer entre Player et les robotsréels La diérence est uniquement dans le chier conguration Avec Stage, pour simulerles robots, on utilise le driver Stage avec plugin  libstageplugin  Quand on travaille avecStage, on s'intéresse au chier de la conguration qui décrit le modèle des robots et l'envi-ronnement du simulateur

Remarque : Nous utilisions le simulateur Player/Stage avec la version 2.1.2 Avec cetteversion, la partie de wi ne fonctionne pas, alors nous devons d'avoir du modier un chier

de Stage pour récupérer les informations relatives au signal wi Le nom de chier modiéest p_wi.c avec la méthode :

InterfaceWifi::InterfaceWifi( player_devaddr_t addr,

StgDriver* driver,ConfigFile* cf,int section ): InterfaceModel( addr, driver, cf, section, wifi_init )

3.2.3 Intégration du WiFiBoT dans l'architecture Player/Stage

Après choisir le simulateur avec le matériel utilisé, ce sont le simulateur Player/Stage et

le WiFiBoT Les travaux suivants sont :

 Implémentation le simulateur Player/Stage

 Dénition du nouveau driver pour le WiFiBoT

 Compilation croisée du serveur Player et implantation sur le WiFiBoT

 Réalisation des comportements du robot pour tester le réalisme sur le simulateur

Fig 3.5  Le schéma de comunication

Le serveur qu'on implémentera au WiFiBoT, doit permettre de communiquer au teur 2D (Stage) et avec le WiFiBoT Avec cela, on pourra donc utiliser un même programme

simula-de client pour les simula-deux plateformes Le schéma 3.5 représente le mécanisme simula-de communicationentre client et serveur

Chapitre 4 Modèle du WiFiBoT pour Stage

Le simulateur Stage permet de simuler un système multi-robot avec plusieurs capteurs

et les objets dans un environnement 2D

Pour le Stage, on a besoin plusieurs de chiers pour créer un environnement simulé

• Fichier cfg : c'est le chier de conguration qui dénit quell Stage sera simulé et quelsdriver utilisera Dans ce chier, il consulte le chier  world  pour savoir quel modèle

et quelle carte utilisé

 Le driver de la simulation L'avantage d'une simulation avec Stage c'est la possibilitéd'avoir une vision graphique de l'évolution des robots Mais pour ce faire, il faut dire

à Player que Stage doit être utilisé Pour ce faire, on indique dans le driver de lasimulation le chier Stage qui devra être utilisé (*.world) Voici une déclarationtypique de ce driver :

Driver (Name xx // Nom de l a simulationProvides [ simulation : 0 ] // Indique que ce d r i v e r concerne

l a simulationPlugin l i b s t a g e p l u g i n //La simulation u t i l i s e r a l a

l i b r a i r i e l i b s t a g e p l u g i n ( l i b r a i r i e de Stage )

W o r l d f i l e xx world //Dans l e cas d ' une simulation u t i l i s a n t

Stage , un f i c h i e r ∗ world e s t n e c e s s a i r e)

18

 Le driver de la carte de l'environnement : pour indiquer à Player l'environnementdans lequel la simulation va se dérouler Voilà le prototype de ce driver :

Driver (Name xx // Nom de l a simulationProvides [ map : 0 ] // Indique que ce d r i v e r concerne l a mapModel xx // U t i l i s e l e modele de map xx d e f i n i dans

l e f i c h i e r ∗ world)

 Dernier type de driver, mais pas des moindres, c'est celui des robots En eet, il fautindiquer à Player pour chaque robot les diérents capteurs qu'il possède, et sur quelport aller chercher ce qu'ils renvoient Si aucun port n'est précisé, c'est le port 6665qui sera utilisé, mais attention, 2 robots sur le même port est source de conit Voilà

à quoi doit ressembler un driver de robot :Driver (

Name xx // Nom de l a simulationModel xx // Nom d ' un modele de robot d e f i n i dans

l e f i c h i e r ∗ worldprovides [ xx : xx : x ] // Indique de q u e l s capteurs

e s t equippe l e robot , a i n s i que de quel port

se s e r v i r pour en r e c u p e r e r l e s donnees Exemple : provides 6665: l a s e r : 0 ]

)

• Fichier world : dans ce chier, il y a la dénition de la taille de fenêtre de simuler,

la carte simulé, et les initiations des modèles des robots Voici une présentation desprincipales commandes :

Resolution x xx // Resolution de l a f e n e t r e : en metre par p i x e l

gu i _ i n te rv a l xx // Taux de r a f r a i c h i s s e m e n t de l a f e n e t r e en msWindow(

s i z e [ xx xx ] // T a i l l e de l a f e n e t r e

c en te r [ xx xx ] // c e nt re de l a f e n e t r e

Master en Informatique/Système et Réseaux

)map(

bitmap xx/xx png // d e s s i n de l a map en png

S i z e [ xx xx ] // T a i l l e de l a map appliquee a l ' imageName xx // Nom de l a map

)

w i f i b o t (// Type du robot ( l e mot c l e " p o s i t i o n " s e r a u t i l i s e s i

l ' on souhaite c r e e r de toute p i e c e un nouveau type de robotname "xx" // Nom du robot

c o l o r "xx" // Couleur du robotpose [ xx xx xx ] // p o s i t i o n du robot dans l a map

xx // Equipements supplementaires a equipper au prototype)

• Fichier inc : c'est le détail pour le modèle de robot utilisé Nous dénissons d'ici lataile, la forme du WiFiBoT et ses capteurs

Alors, on dénit d'abord un modèle pour le WiFiBoT (wibot.inc) Ce modèle se poser la taille du WiFiBoT , la position des deux infra-rouge, la portée minimale et la portéemaximale :

polygon [ 0 ] points 4polygon [ 0 ] point [ 0 ] [ 0 1 4 0 1 5 ]polygon [ 0 ] point [ 1 ] [ −0.14 0 1 5 ]polygon [ 0 ] point [ 2 ] [ −0.14 −0.15]

polygon [ 0 ] point [ 3 ] [ 0 1 4 −0.15]

d r i v e " d i f f "

w i f i b o t _ i r ( ))

Puis, on l'utilise dans le chier *.world avec les dénitions de l'environnement simulé

# load an environment bitmapmap