Planicateurs basés sur GraphPlan

Plusieurs techniques ont été employées pour améliorer GraphPlan : la réduction de l'espace de recherche avant la phase d'extraction du plan [Fox & Long 98,Nebel et al. 97], l'amélio-ration du langage de représentation des domaines et des problèmes [Koehler et al. 97,Weld

et al. 98, Guere & Alami 99, Koehler 98] et l'amélioration de la phase d'extraction de la

solution [Kambhampati 99,Kautz & Selman 99,Long & Fox 99,Fox & Long 99,

Zim-merman & Kambhampati 99]. Dans cette section, nous présentons les planicateurs IPP,

 Une technique permettant de réduire la taille du graphe de planication est proposée dans

[Nebel et al. 97], pour le planicateur IPP fondé sur GraphPlan. Comme dans

Graph-Plan, la construction du graphe de planication se fait de l'état initial à l'état nal et la recherche d'un plan solution se fait par la méthode de recherche en arrière. Elle ore plusieurs heuristiques qui permettent de supprimer de l'état initial les eets qui ne sont probablement pas utiles pour résoudre le problème. L'inconvénient majeur est donc qu'elle rend GraphPlan incomplet, mais il semble qu'elle fournisse pourtant de bons résultats. De plus, il y a de fortes chances pour que GraphPlan échoue rapidement si l'heuristique a supprimé trop d'eets ; il reste donc toujours la possibilité de relancer la planication avec l'état initial complet. Le principe de ce calcul est de construire un graphe ET/OU à partir des buts du problème. La racine de l'arbre est un n÷ud ET et correspond au but du problème. Les descendants de ce n÷ud sont des n÷uds OU correspondant à chacun des sous-buts. Les descendants de ces n÷uds sont les ensembles des pré-conditions des actions qui établissent ces sous-buts. Un n÷ud OU est résolu si l'eet qui lui correspond appar-tient à l'état initial ou si un de ses descendants est résolu. Un n÷ud ET est résolu si tous ses descendants sont résolus. Un ensemble d'eets utiles pour résoudre un problème est donc constitué par les feuilles d'un sous-arbre solution du graphe. Le but est de trouver les ensembles les plus petits possibles pour l'inclusion, mais comme il s'agit d'un problème NP-complet, on doit faire des approximations. De plus, comme on ne tient pas compte des retraits des actions, prendre un seul de ces ensembles sera a priori trop restrictif pour constituer l'état initial. Plusieurs possibilités sont alors envisagées pour sélectionner un ensemble assez grand, le principe étant de prendre un ensemble susamment réduit pour améliorer les performances globales du planicateur, mais susamment grand pour ne pas rejeter des eets absolument nécessaires.

 Le planicateur LCGP9 [Cayrol et al. 00] procède de manière similaire à GraphPlan en construisant incrémentalement un graphe avant d'en extraire un plan solution. Le graphe construit par GraphPlan est un sous-graphe de celui construit par LCGP à profondeur égale. La préférence donnée au temps de réponse sur la qualité des plans produits est un point essentiel de LCGP : le temps de production d'un plan solution (pas forcément optimal) est plus réduit pour LCGP quand GraphPlan est incapable de produire une solu-tion au bout d'un temps considérable. GraphPlan n'impose aucune hypothèse sur la façon dont l'exécution peut se dérouler dans le monde réel : on connaît pas la durée d'exécution d'une action, on ne sait pas combien de temps met un eet pour être établi, ni com-bien de temps une pré-condition doit rester vraie pour permettre d'exécuter une action... Toutes ces incertitudes obligent GraphPlan à contraindre fortement le choix des actions

2.6. La planication classique 25 an que le résultat de l'exécution en série d'un ensemble d'actions (dans n'importe quel ordre) conduise au même état que l'exécution en parallèle de ces mêmes actions. LCGP montre qu'on peut modier la propriété d'indépendance entre les actions simultanées d'un ensemble. Les résultats de comparaison de GraphPlan et LCGP sont du côté du dernier ; la perte d'optimalité est très largement compensée par le gain de temps (LCGP est 1000 fois plus rapide que GraphPlan dans certains problèmes). De plus, l'espace de recherche dans l'algorithme LCGP est plus compact (moins de niveaux que GraphPlan, chacun plus dense) et entraîne dans certains domaines une telle amélioration des performances que la perte de la propriété d'optimalité qui en résulte est négligeable. Les modications faites dans les algorithmes de GraphPlan ainsi que les tests expérimentaux sont détaillés dans

[Vidal et al. 99,Cayrol et al. 00].

 Une possibilité pour prendre en compte en partie les eets négatifs des actions est proposée pour le planicateur AltAlt [Nigenda et al. 00,Nguyen & Kambhampati 00,Nguyen

& Kambhampati 01] par le calcul complet du graphe de planication, c'est-à-dire

pre-nant en compte les exclusions mutuelles. Les eets et les actions n'apparaissent que plus tardivement dans le graphe fourni par le problème relaxé. Plusieurs heuristiques sont pro-posées : la plus performante fait intervenir le niveau d'apparition des eets pour calculer la longueur d'un plan sans prendre en compte les retraits des actions, et fait aussi intervenir le niveau de disparition des exclusions mutuelles entre eets an d'ajuster l'estimation de la longueur du plan, ce qui est une manière indirecte de prise en compte des retraits des actions.

AltAlt

Le planicateur AltAlt, dont l'architecture est illustrée dans la gure2.7, est basé sur une combinaison de GraphPlan et de techniques de recherche dans les espaces d'états avec chaî-nage arrière. Le problème et les actions sont d'abord introduits dans le système GraphPlan pour construire un graphe de planication en temps polynomial. Ce graphe est ensuite introduit dans un système d'extraction des heuristiques an de dénir les heuristiques eectives et admissibles, basées sur des théories développées dans [Nguyen &

Kamb-hampati 00]. Enn, le problème, les actions du dernier niveau du graphe de planication

produit par GraphPlan et les heuristiques choisies sont introduits dans le planicateur an de produire le plan-solution.