II. 2 5 degr´es d’autonomie d´ecisionnelle (C signifie Centralis´e, et D signifie distribu´e)
VI.5 Monitoring coop´eratif d’un foyer par Marvin et Heliv
La photo de la figure VI.5 a ´et´e prise `a Lousa, Portugal, au mois de Mai 2005, pendant la 3`eme session d’exp´erimentation du projet COMETS. Les UAV sont en train de r´ealiser une tˆache de perception coordonn´ee du foyer (3`eme phase du sc´enario). Le dirigeable Karma (hors champ) est en train de r´ealiser une cartographie des lieux.
VI.1.4
Conclusions sur les exp´erimentations r´eelles
Les exp´erimentations r´ealis´ees ont d´emontr´e l’utilit´e de disposer d’ex´ecutifs g´en´eriques, g´erant de fac¸on coh´erente, proche du temps r´eel, le d´eroulement des plans partiellement or- donn´es. Au degr´e 3 d’autonomie d´ecisionnelle, les synchronisations directes entre EMD se sont op´er´ees de fac¸on transparente pour les autres entit´es du syst`emes, que ce soit le CC ou les CPE. Cette mise en œuvre effective a repr´esent´e un tr`es important effort d’int´egration, les EMD se trouvant, en terme de communication de donn´ees, aux interfaces entre le CC et les CPE propres `a chacun des UAV.
VI.2
R´esultats obtenus en simulation
Dans cette partie, nous d´ecrivons l’impl´ementation de la couche d´elib´erative et les tests r´ealis´es en simulation, sur une base de “probl`emes de type COMETS”.
VI.2.1
D´eveloppement li´es `a la couche d´elib´erative
La couche d´elib´erative regroupe 4 composants principaux : un planificateur symbolique for- tement li´e `a un ensemble de raffineurs g´eom´etriques, un gestionnaire d’interaction en charge de la r´esolution de tˆaches jointes, et un superviseur de la couche d´elib´erative dont l’objectif est d’as- surer la coh´erence de la d´elib´eration.
En termes de d´eveloppements, notre d´emarche `a consiste, dans un premier temps, `a se munir du moyen de g´en´erer des plans au niveau d’un UAV, abstraction faite des interactions entre UAV. Deux motivations `a l’origine de ce choix :
– la n´ecessit´e d’ˆetre rapidement en mesure de g´en´erer des plans mono-robot sans reposer sur les capacit´es du Centre de Contrˆole (contraintes de d´eveloppement li´ees au projet COMETS). – un choix de paradigme orient´e vers une coordination de plan a posteriori, et non en cours de construction du plan. Dans cette optique, il ´etait plausible de r´ealiser des plans sans consid´erer explicitement le contexte multi-robots, puis coordonner les plans dans un second temps.
Le couple planificateur / raffineur que nous proposons r´epond `a cette aspiration, sans pour au- tant fermer les portes `a la consid´eration future de tˆaches raffinables uniquement dans un contexte multi-robots, i.e. reposant sur des processus de coordination multi-robots. La sous-section sui- vante pr´esente les tests r´ealis´es avec le couple planificateur symbolique / raffineurs sp´ecialis´es uniquement.
VI.2.2
Impl´ementation : choix techniques
– Le planificateur symbolique, comme nous l’avons d´eja introduit pr´ec´edement, est construit autour du planificateur Shop2. Celui-ci est programm´e en langage Lisp, et nous avons choisi
l’impl´ementation Lisp “CMUCL” [CMUCL 05], apr`es diff´erents tests d’environnements Lisp : CMUCL est gratuit (la plupart du code est dans le domaine public), compatible sparc-solaris, linux, et est maintenu par une ´equipe tr`es active. Par ailleurs, cette impl´ementation fournit des m´ecanismes int´eressants pour interagir (transmission de messages par “pipes”) avec d’autres processus. En l’occurence, nous ex´ecutons les raffineurs sp´ecialis´es (voir le point suivant) en tant que processus fils depuis Lisp, et communiquons par transmission de messages de processus `a processus (“streams” vers flux de donn´ees d’entr´ees et sorties respectives).
– Les raffineurs sp´ecialis´es sont impl´ement´es en java, dans leur r´ealisation actuelle : il s’agit du travail de stage de DEA de Gautier Hattenberger [Hattenberger 04]. Dans un soucis d’ho- mog´en´eit´e des sous-syst`emes de la couche d´elib´erative, une r´e-impl´ementation des raffineurs en C ou C++ serait sans doute profitable.
– Le gestionnaire d’interaction est d´evelopp´e en C++ : la repr´esentation des donn´ees rela- tives au mod`ele d’interaction se prˆete tr`es bien `a une impl´ementation objet. Par ailleurs, le b´en´efice de l’utilisation de librairies standards (ou en passe de le devenir) comme STL (mani- pulation de listes, vecteurs...) ou BOOST (utilis´e en l’occurence pour du multi-threading) est tr`es appr´eciable.
– Le superviseur de la couche d´elib´erative est r´ealis´e avec OpenPRS : le paradigme que pro- pose OpenPRS est tr`es pertinent pour cette entit´e de supervision, qui doit g´erer et r´eagir `a de multiples entr´ees d’informations. Par ailleurs, l’impl´ementation OpenPRS du superviseur de CD permet de rapprocher celui-ci de l’EMD, lorsque c’est possible. On obtient alors un super- viseur ´etendu `a deux couches : l’une proche de l’ex´ecution, et l’autre proche de la d´elib´eration. – La communication entre les entit´es de la couche d´elib´erative est assur´ee par un serveur de communication qui porte le nom de message passer : celui-ci fonctionne sur un principe assez basique de transmission de messages par sockets. Tout processus enregistr´e aupr`es du mes- sage passerpeut recevoir et envoyer des messages de et vers tout autre processus ´egalement enregistr´e aupr`es du message passer (“peer to peer” ou “broadcast”). Ce syst`eme de commu- nication, d´evelopp´e au mˆeme moment qu’OpenPRS (et par la mˆeme personne : Felix Ingrand), est encore utilis´e au LAAS, principalement pour des travaux avec des d´eveloppements exploi- tant OpenPRS.
– Un module de simulation d’UAV (tr`es ´el´ementaire) a ´et´e d´evelopp´e sur la base d’un mo- dule GenoM [Fleury 97] : il s’agit d’un outil de conception et de d´eveloppement de modules fonctionnels. GenoM permet d’encapsuler les fonctions op´erationnelles dans des modules ind´ependants r´eutilisables. Les modules GenoM peuvent alors ˆetre interfac´es avec un ex´ecutif (d´evelopp´e par exemple avec OpenPRS) qui pourra leur adresser des requˆetes (lancement, in- terruption...) et recevoir (et traiter en cons´equence) des retours d’ex´ecution. GenoM est un outil utilis´e pour tous les robots du LAAS.
– Un module de visualisation d’UAV simul´e, a ´et´e ´egalement d´evelopp´e sur une base de Ge- noM. Cette interface exploite un autre outil d´evelopp´e au LAAS : GDHE [GDHE 05]. Celui-ci est un outil de visualisation 3D orient´e application robotique, et utilisant la librairie OpenGL. Le module de visualisation simule l’environnement : il permet de connecter les diff´erents UAV (sous forme de modules UAV simul´es, comme d´ecrits au point pr´ec´edent), et interface leurs affichages respectifs vers GDHE. Les images de simulation pr´esent´ees dans cette section sont g´en´er´ees par ce modules, et rendues avec GDHE.
VI.2.3
Planification et raffinement de tˆaches dans la couche d´elib´erative
Nous pr´esentons ici des r´esultats obtenus en simulation sur l’utilisation du planificateur sym- bolique et des raffineurs sp´ecialis´es.Configuration de tests
Nous nous plac¸ons dans un contexte ou la couche d´elib´erative, associ´ee `a l’EMD d’un UAV, interragit avec un niveau fonctionnel simul´e. Au cours de nos tests, la configuration employ´ee est illustr´ee sur la figure VI.6.
NDD CD EMD Exécutif générique Interface BBCS RS PS Superviseur de CD CPE Exécutif propriétaire Niveau fonctionnel Module de com. BBCS Module de simulation
Plan généré par le couple PS / RS
Communications BBCS Retour de données / status
Requête
FIG. VI.6 – Configuration de test de plans produits par le couple planificateur / raffineurs