Utilisation des POMDP sous contraintes temporelles : optimisation anticip´ee et
6.1 D ´efinition de l’application robotique
Dans ce chapitre nous ´etudions la mission de d´etection, reconnaissance et atterrissage, pr´esent´ee dans le chapitre 3 section 3.3.2, qui se rapporte `a une probl´ematique de d´ecision s´equentielle sous incertitude et observabilit´e partielle de d´etection et de reconnaissance de cible par un h´elicopt`ere autonome. Cette mission est mod´elis´ee sous forme d’un POMDP d´efini en ligne, une fois que le nombre de zones `a explorer a ´et´e analys´e en ligne, en utilisant des techniques de traitement d’image. Le nombre de cibles, ainsi que leurs identit´es ne sont pas connus de l’h´elicopt`ere autonome. Nous rappelons que le but de la mission est de trouver une cible particuli`ere, parmi celles connues de la base de donn´ees et d’atterrir `a cˆot´e de cette cible.
Cette application robotique est stimulante et originale pour deux raisons principales : – la mission de d´etection et reconnaissance de cibles est consid´er´ee comme un probl`eme
de planification s´equentielle `along terme, avec des actions `a la fois de perception (chan-gement d’angle de vue, chan(chan-gement d’altitude, chan(chan-gement de zone) et d’aboutissement de mission (atterrissage) ; Dans le cadre g´en´eral de la perception active, les applications existantes optimisent plutˆot une mesure de l’incertitude de l’´etat de croyance `a court terme [Eidenbergeret al., 2009].
– le POMDP est r´esolu en ligne pendant le vol, en tenant compte des contraintes de temps requises par la dur´ee de la mission et de l’anticipation des ´etats futurs possibles du syst`eme robotique.
Mener enti`erement de fa¸con automatique une mission de ce type requiert plusieurs briques, techniques et th´eoriques : la mod´elisation duale du traitement d’image et de la d´ecision, la r´esolution (interpr´etation d’image et optimisation de la politique) et le contrˆole de l’ex´ecution du plan. En ce qui concerne la mod´elisation, nous avons vu dans le Chapitre 3 que l’appren-tissage d’un mod`ele d’observation `a partir de donn´ees r´eelles est un facteur tr`es important si l’on veut traiter le probl`eme de fa¸con r´ealiste. Pour cela, nous avons appris le mod`ele d’obser-vation pour cette application robotique `a partir d’une ´etude statistique des images collect´ees lors de campagnes de prise de vue. Ce mod`ele appris est adapt´e `a cette application, puisqu’il
6.1. D´efinition de l’application robotique ne suppose pas un nombre fix´e de zones. Il se base seulement sur le fait qu’une cible est ou non dans une zone particuli`ere sachant la zone et l’altitude de vol de l’agent h´elicopt`ere.
Toutefois, le mod`ele ne peut pas ˆetre consid´er´e comme parfaitement r´ealiste puisque l’ap-prentissage d´epend des conditions de prise de vue (ensoleillement, ombre, etc). Comme d´ej`a discut´e dans le chapitre 3 nous ne supposons pas d’inf´erence en ligne du mod`ele d’observa-tion, ceci a ´et´e appris hors ligne `a partir des donn´ees acquises dans des vols exp´erimentaux pr´ealables. A noter que l’attention de ce travail de th`ese a port´e sur la faisabilit´e de m´ethodes de d´ecision s´equentielle `along terme pour des applications robotiques d’identification et re-connaissance de cibles en environnement incertain et pas sur le d´eveloppement de nouvelles techniques de traitement d’image.
6.1.1 G ´en ´eration en ligne du probl `eme `a r ´esoudre
Comme dans notre application robotique nous supposons que le nombre de zones `a ex-plorer est inconnu au d´ebut de mission, il ´etait n´ecessaire de mettre en place, en compl´ement du cadre de planification et d’ex´ecution en parall`ele de la politique, une fonction responsable de la g´en´eration automatique du mod`ele POMDP `a r´esoudre. Cette fonction suppose qu’une phase initiale de balayage du terrain est effectu´ee en d´ebut de mission, afin d’extraire les zones d’int´erˆet, au moyen d’un traitement d’image. Une fois que le nombre et les coordonn´ees des zones ont ´et´e obtenus, et que le mod`ele de voiture recherch´e a ´et´e fix´e, le probl`eme POMDP est g´en´er´e. Cette g´en´eration automatique, impl´ement´ee en C++, est un service disponible dans le composant superviseur de la mission (l’architecture embarqu´ee sera pr´esent´ee dans la section suivante). Dans la suite, nous d´etaillerons la g´en´eration automatique du probl`eme POMDP `a r´esoudre.
Conform´ement le chapitre 3, nous disposons de variables d’´etat qui d´ependent : du nombre de zonesNz, d’altitudes de volNh et de mod`eles connus de la base de donn´eesNmodels. Nous avons donc :
– z, avec Nz valeurs possibles, qui indique la position de l’h´elicopt`ere autonome ; – h, avec Nh valeurs possibles, qui indique l’altitude de vol de l’h´elicopt`ere autonome ; – IdT az1 (respectivement IdT az2, IdT az3, etc), avec Nmodels+ 1 valeurs possibles, qui
indique l’identit´e ou l’absence d’une cible dans la zone 1 (respectivement dans la zone 2, dans la zone 3, etc.)
Nous rappelons que la fonction de transition d’´etats est consid´er´ee comme d´eterministe. Pour chaque variable d’´etat, nous d´efinissons sa matrice de transition selon l’action. Par exemple, pour Nz = 3 et pour l’action go to(z1), la matrice de transition d’´etat Tzz1 de la variable d’´etat z sera donn´ee par :
Tzz1 =
1 0 0 1 0 0 1 0 0
Pour les autres variables, une matrice de transition ´egale `a la matrice identit´e est d´efinie.
Ainsi la construction de la matrice de transition d’´etat compl`ete pour l’actiongo to(z1)est donn´e par le produit de Kronecker entre les matrices de transition des variables d’´etat :
Tgo to(z1)=Tzz1O IhO
IIdT az
1
OIIdT az
2
OIIdT az
3
Pour tenir compte de l’´etat terminal, qui est atteint lors que l’action d’atterrissage est r´ealis´ee, on ajoute une ligne et une colonne `a cette matrice avec une composante ´egale `a 1 dans la diagonale. Ceci parce qu’une fois que l’on est dans l’´etat terminal, l’action go to(z1) n’a aucun effet (cf. chapitre 3).
La mˆeme proc´edure est utilis´ee pour la g´en´eration de la fonction de r´ecompense. Par exemple, pour la g´en´eration de la fonction de r´ecompense de l’actiongo to(z1), la distance entre le centre des zones est calcul´ee et la matrice distance entre zonesDzest construite. Ceci est possible parce que les coordonn´ees de zones sont des donn´ees d’entr´ee pour la g´en´eration automatique. La matrice coˆut associ´ee au changement de zone Cz,z1 est donc obtenue par :
Cz,z1(i, j) =
Dz(i,j)
10 , si i6=j 100, sinon
o`u la valeur de 100 mod´elise le fait que si on est dans une zone ion ne veut pas aller vers cette mˆeme zonei(le point de rendez-vous d’entr´ee dans une zone est fix´e, voir figure 3.1(a) du chapitre 3). Puis, le produit ´el´ement par ´el´ement entre Tzz1 et Cz,z1 est r´ealis´e, et la matriceRss0(a) est obtenue par le produit de Kronecker. Pour obtenir la fonction r(s, a) on somme les colonnes de Rss0(a), pour chaque s. Le mˆeme calcul est utilis´e pour les action de changement d’altitude. Pour l’action de changement d’angle de vue, un coˆut constant est consid´er´e Cview = H10mφ, proportionnel `a l’altitude moyenne de vol Hm (par exemple 35 m`etres), et `a l’arc de cercle parcouru par l’agent h´elicopt`ere, qui d´epend de la valeur de l’angle φfix´e par le concepteur (par exempleφ= 10 d´egr´ees), conform´ement la d´efinition de l’action change view donn´ee dans la section 3.2.2 du chapitre 3 (voir figure 3.1(b) du chapitre 3).
Pour toutes les actions de d´eplacement (sauf atterrissage), un coˆut constantCproc= 0.5 est aussi ajout´e `a chaque ´etat, qui mod´elise le coˆut du traitement d’image engendr´e une fois que l’action est ex´ecut´ee.
La g´en´eration de la fonction d’observation, qui est la mˆeme pour toutes les actions du mod`ele, est faite `a partir d’une m´ethode r´ecursive. Cette m´ethode identifie pour chaque ´etat sla valeur des variables d’´etat au moyen d’une division euclidienne. A partir des valeurs des variables d’´etatz,h etIdT az, la table de probabilit´e apprise est consult´ee et les probabilit´es de toutes les observations sont copi´ees en tant que ligne de la matrice Oso. Par exemple, si l’h´elicopt`ere est dans la zone z1, `a une altitude h1, et que IdT az
1 = mod`ele A, la premi`ere ligne de la table 4.2 (chapitre 4) est copi´ee dans la matrice Oso. Dans cette mˆeme proc´edure r´ecursive, la fonction de r´ecompense associ´ee `a l’action d’atterrissage est g´en´er´ee, puisque dans cette fonction l’on peut tester les valeurs des variables z et IdT az, conform´ement la d´efinition de la fonction de r´ecompense de l’action land, donn´ee dans la section 3.3.2 du chapitre 3. La r´ecompense attribu´ee `a l’atterrissage proche de la cible recherch´ee est fix´ee `a 50, et une p´enalit´e de 100 est associ´ee `a une atterrissage manqu´ee.
Le r´esultat de la g´en´eration automatique est un fichier texte o`u le mod`ele POMDP est d´ecrit selon le format standard Cassandra1.
Maintenant que nous avons d´ecrit la g´en´eration automatique du probl`eme `a r´esoudre, nous pr´esentons l’architecture Orocos, qui est l’architecture embarqu´ee sur les drones de l’Onera. Nous focaliserons l’attention sur les diff´erents composants cr´e´es pour la mission de d´etection et de reconnaissance de cibles.
6.1.2 Pr ´esentation de l’architecture Orocos impl ´ement ´e pour l’application robotique L’architecture embarqu´ee sur l’h´elicopt`ere autonome est une architecture Orocos2 [Soe-tens et Bruyninckx, 2005]. Orocos est une librairie pour la robotique impl´ement´e en C++.
Elle fournit un cadre de d´eveloppement temps r´eel et modulaire. Orocos est bas´e sur des composants qui facilitent le d´eveloppement des applications robotiques, en reposant sur la s´eparation des fonctions : calcul, communication, configuration et coordination.
1. disponible enhttp://www.pomdp.org/pomdp/code/pomdp-file-spec.shtml 2. http://www.orocos.org/