L’exemple de la manipulation

Nous allons maintenant voir les r`egles utilis´ees sur l’exemple du bras manipulateur avec la barre prise dans une cage (figure 4.1). Cet exemple a ´et´e pr´esent´e dans la th`ese d’Anis Sahabani [Sahbani 03]. Nous avons d´ej`a vu qu’il y avait une compatibilit´e entre les GCEs et le graphe de manipulation pour un robot et un objet. Cette compatibilit´e s’´etend aussi au syst`emes de r`egles.

L’algorithme de la manipulation pr´evoit des choix strat´egiques probabiliste pour choisir quelle roadmap ´etendre § 2.8.4.

Le premier choix se fait entre ´etendre Grasp ∩ Placement ou chercher des chemins de Transit et de Transfert . Ce choix se fait proportionnellement au nombre d’´echecs de la m´ethode de visibilit´e. Cela correspond `a une pr´econdition du type « coˆut de taille de roadmap ».

Ce premier choix peut ˆetre donc vu comme un syst`eme de deux r`egles :

« Coˆut de taille de roadmap » Effets:

R₁ ´echecs visibilit´e dans Grasp ∩ Placement Enrichir Grasp ∩ Placement

R2 coˆut fixe Extension Transit /Transfert

La m´ethode d’enrichissement de Grasp ∩ Placement est celle d´evelopp´e par Sahabani [Sahbani 03]. C’est une m´ethode par visibilit´e sauf qu’elle teste la validit´e d’une m´ethode locale en commen¸cant par tester l’objet seul. Si le mouvement est faisable pour l’objet seul et non faisable dans Grasp ∩ Placement alors elle cherche une position de pose interm´ediaire.

L’extension Transit /Transfert s´electionne un nœud de Grasp ∩ Placement et essai de le lier `a des nœuds de Grasp ∩ Placement appartenant `a d’autres composantes du graphe de manipulation. Ce lien se faisant par un couple de trajectoires (Transit , Transfert ) ou (Transfert , Transit ).

Nous avons modifi´e ces r`egles pour remplacer l’extension Transit /Transfert par le sous-ensemble de r`egles suivant :

« Int´erˆet de connexit´e » Effets: R1

N1, N 2 ∈ Grasp ∩ Placement N1 et N2 non connexe dans les GCEs

N1 et N2 connexe dans la roadmap heuristique de l’objet

Enrichir Transfert

R₂ N1, N 2 ∈ Grasp ∩ Placement N1 et N2 non connexe dans les GCEs N1 et N2 connexe dans Placement

Enrichir Transit

Cela permet d’utiliser la topologie de la roadmap heuristique. Les positions interm´ediaires dans Placement ´etant trouv´ees par la m´ethode d’enrichissement de Grasp ∩ Placement .

De mˆeme « Enrichir Transfert » peut ˆetre d´etaill´e pour avoir des r`egles qui vont cr´eer ou r´eutiliser des configurations de prises d’une roadmap heuristique.

4.5. Conclusion. 63

« Enrichir Transit » peut lui aussi faire des recherche dans Transit ou dans la roadmap relative `a l’objet d´epla¸cable. La figure 4.5 montre l’interface d’impl´ementation du syst`eme de r`egles et notam- ment les sous-r`egles de « Enrichir Transit ».

Figure 4.5:Syst`eme de r`egles impl´ement´e pour le probl`eme de manipulation un robot et un objet. Sous ensemble correspondant `a une liaison par un chemin de transit.

Les r`egles pr´esent´ees ci-dessus permettent d’´etendre les roadmaps pour r´esoudre le probl`eme de la manipulation avec un robot et un objet d´epla¸cable pour des positions de pose et des prise continues. Il est possible de multiplier le nombre de ces r`egles pour prendre en compte plusieurs robots et plusieurs objets.

Remarque :

Tout au long de cette th`ese, nous nous sommes int´eress´es au d´eveloppement des m´ethodes d’enrichisse- ment des roadmaps et aux param`etres qui jouent sur la combinaison de ces m´ethodes. C’est pourquoi nous avons d´evelopp´e un syst`eme fortement param´etrable. Toutefois, nous pensons qu’il est possible pour une classe donn´ee de probl`emes de g´en´erer automatiquement ces param`etres. Cela pourra ˆetre effectu´e dans de futurs travaux.

4.5

Conclusion.

Nous avons d´evelopp´e une m´ethodologie permettant d’utiliser les r´esultats de l’´etat de l’art et de les combiner pour aborder des probl`emes plus complexe.

64 Chapitre 4. L’apprentissage de la topologie.

Toutefois, hormis les roadmaps relatives, aucune roadmap ne prend en compte les autres robots ou objets. Autrement dit, un objet qui rompt la connexit´e d’une composante connexe n’a pas d’influence ni sur les GCEs ni sur les m´ethodes d’apprentissage des roadmaps.

Comme nous l’avons d´ej`a fait remarquer, pour parer `a ce probl`eme il est possible de prendre en compte explicitement les configurations des autres robots ou objets. Mais dans ce cas nous augmentons tr`es fortement la complexit´e des roadmaps.

La solution que nous avons choisie est de prendre en compte un contexte. Ce contexte d´esignera les configurations des autres robots et objets. Les arcs de la roadmap auront une liste de configurations d’autres robots pour lesquelles ils ont ´et´e valid´es ou invalid´es. Ceci permet de connaˆıtre l’´etat de la roadmap dans diff´erents contextes.

Il ne reste plus qu’`a choisir de bons contextes qui vont servir lors de la recherche d’un plan valide. Un choix al´eatoire reviendrait `a l’utilisation d’une roadmap portant sur la concat´enation des configurations des robots. Pour ´eviter cette complexit´e, il faut se limiter aux contextes qui ont de grandes chances d’apparaˆıtre dans le plan solution.

Dans le chapitre pr´ec´edent, nous avons remarqu´e qu’une connexit´e au niveau des GCEs ne suffisait pas `a prouver l’existence d’une solution. Il faut en plus une ´etape de validation qui doit construire un plan solution.

C’est de ce plan dont on doit se servir pour ´etablir les bons contextes `a utiliser pour faire l’appren- tissage des roadmaps.

Nous avons d´ecid´e que pour la recherche de ce plan nous utiliserons des techniques de recherche dans l’espace d’´etat issue de la planification de tˆaches. Ainsi cette ´etape de planification devra non seulement servir `a trouver un chemin dans les GCEs mais aussi `a les construire en prenant en compte les autres robots et objets tels qu’ils apparaissent dans l’´elaboration du plan.

Le chapitre suivant va justement pr´esenter les techniques de planifications de tˆaches et comment les faire cohabiter avec la repr´esentation g´eom´etrique du monde que nous avons d´evelopp´ee dans le chapitre pr´ec´edent.

Chapitre 5

ASyMov et la planification de tˆaches.

Dans cette th`ese nous avons d´ecid´e d’´elaborer un planificateur « aSyMov » 1 nous permettant de r´ealiser des tˆaches de manipulation prenant en compte explicitement la g´eom´etrie de l’environnement. Les deux chapitres pr´ec´edents nous ont permis de d´efinir une repr´esentation de l’espace de recherche et des m´ethodes pour explorer la topologie du probl`eme. Mais ils ont tous les deux indiqu´e la n´ecessit´e de repr´esentation compl´ementaire de l’´etat du monde. Une recherche de solutions dans l’espace d’´etat permettrait `a la fois de valider la topologie trouv´ee et de faire un apprentissage des roadmaps qui prenne en compte tous les robots et les objets de l’environnement.

Il se trouve justement que les techniques de planification de tˆaches permettent d’explorer un espace d’´etat abstrait. Il peut ˆetre int´eressant de s’inspirer de ces techniques. Nous avons alors d´ecid´e de fran- chir une ´etape suppl´ementaire en d´ecidant d’impl´ementer compl`etement les techniques de planification de tˆaches pour permettre la r´esolution de probl`emes prenant en compte non seulement la g´eom´etrie de l’environnement mais aussi des informations symboliques. Il sera par exemple possible d’indiquer qu’il faut une clef pour ouvrir une porte, qu’il faut mettre de la colle avant d’assembler des objets, qu’un robot doit prendre des photos sur des zones donn´ees, etc.

Pour r´esoudre un probl`eme de planification, il est souvent impensable de parcourir enti`erement l’espace d’´etat pour trouver un plan qui satisfasse le but recherch´e. De nouvelles techniques ont r´ecem- ment relanc´e la course au meilleur planificateur, `a tel point qu’un langage de description commun : « PDDL » [M. Ghallab 98], et qu’une comp´etition, li´ee depuis 1998 aux conf´erences AIPS, ont vu le jour.

Dans un premier temps nous allons pr´esenter le probl`eme de la planification de tˆaches avec le langage de description de domaine « PDDL ». Puis nous pr´esenterons bri`evement les diff´erentes tech-

1

a Symbolic Move3D

68 Chapitre 5. ASyMov et la planification de tˆaches.

niques utilis´ees pour r´esoudre ces probl`emes ainsi que quelques limitations. Enfin nous montrerons un moyen original de combiner les techniques g´eom´etriques d´evelopp´ees dans les chapitres pr´ec´edents et les techniques symboliques de la planification de tˆaches.

5.1

Le domaine de la planification de tˆaches.

L’objectif de la planification de tˆaches et de trouver un ordonnancement d’actions (plan) qui est ex´ecut´e depuis un ´etat initial de l’environnement et permet d’atteindre un ensemble de buts.

Le probl`eme se d´efinit donc par le triplet < Einit, A, But > o`u Einit repr´esente l’´etat dans lequel se

trouve l’environnement au moment de l’ex´ecution du plan, A mod´elise l’ensemble des actions α que l’agent peut ex´ecuter afin de r´ealiser les buts d´efinis par But.

Avant de s’int´eresser au probl`eme algorithmique de la recherche de plan solution, il faut d´efinir un mod`ele pour repr´esenter le monde ainsi que les changements que les agents peuvent d´ecider d’appliquer. Nous allons maintenant pr´esenter le formalisme « STRIPS » et son extension « PDDL » dont nous allons nous servir tout au long de cette th`ese.