Extension de la d´efinition des tˆ aches de haut niveau

Pour la description des m´ethodes dans ce mod`ele, nous avons gard´e la mˆeme description que pr´ec´edemment. Une m´ethode est d´efinie par le tuple M =< N ame, P ar, goal, Replan, D >, o`u : – N ame repr´esente un symbole qui d´efinit le nom de la tˆache. Dans l’exemple de la figure 4.7 le nom de la m´ethode est GetObject.

method GetObject ( Agent Ag , O b j e c t Obj ) {

c o n d i t i o n {

{ Obj . f u r n i t u r e = = unknown;

Obj . owner = = unknown; } ;

subtasks {AG = SELECT( Agent , { AG. MySelf = = t r u e ; } ) ; 1 : S e a r c h F o r (AG, Obj ) ; 2 : PlanAgain (AG)>1; } } ; goal { Obj >> Ag . o b j e c t s ; Obj . owner = = Ag; } ; // d e c o m p o s i t i o n 1 { preconditions { Obj . owned = = ” f a l s e ” ; } ; subtasks

{ 1 : GetObjectFromFurniture (Ag , Obj , Obj . f u r n i t u r e ) ; } ;

} // d e c o m p o s i t i o n 2 { preconditions { Obj . owned = = ” f a l s e ” ; } ; subtasks {

AG = SELECT( Agent , { AG ! = Ag; } ) ;

1 : GetObjectFromFurniture (AG, Obj , Obj . f u r n i t u r e ) ; 2 : T r a n s m i t O b j e c t (AG, Ag , Obj ) > 1 ; } ; } // d e c o m p o s i t i o n 3 { preconditions { Obj . owned = = ” t r u e ” ; Obj . owner ! = Ag; } ;

subtasks

{ 1 : Tr a ns m i t O b j e c t ( Obj . owner , Ag , Obj ) ; } ;

} }

d’agents. Dans l’exemple de la figure 4.7 les param`etres sont : un agent Ag et une entit´e de type objet Obj.

– goal repr´esente une liste des conditions qui d´efinissent le but ou les m´eta-effets associ´es `a la m´ethode. Si ces conditions sont respect´ees alors le but de la m´ethode est d´ej`a r´ealis´e. Dans ce cas, la m´ethode est r´eduite `a un ensemble vide. Le but de la m´ethode d´ecrit dans la figure 4.7 est que l’agent Ag soit en possession de l’objet Obj. Cela se traduit par Obj >> Ag.objects et Obj.owner == Ag.

– Replan repr´esente une liste des conditions qui permettent de tester s’il y a un manque d’information ou s’il y a une inconsistance sur les croyances pour la d´ecomposition et la r´ealisation de la m´ethode. Si les conditions sont respect´ees, la m´ethode est remplac´ee par

une liste de tˆaches. Pour l’exemple de la figure 4.7, la condition pour que la m´ethode

GetObject soit non r´ealisable est que la position de l’objet soit inconnue. Cela se traduit par Obj.f urniture == unknown ∧ Obj.owner == unknown. Si ces conditions sont valides, la m´ethode sera remplac´ee par la liste de tˆaches correspondante.

– D repr´esente l’ensemble des d´ecompositions possibles de la m´ethode. Ces d´ecompositions ont la mˆeme description que celles donn´ees dans la section 3.3.2 du chapitre pr´ec´edent.

Comme dans notre mod´elisation, chaque agent a sa propre base de croyance, nous avons cr´e´e un type particulier de m´ethode, appel´e m´ethode terminale. Une m´ethode terminale est une macro-action, c’est-`a-dire que la m´ethode ne fait intervenir qu’un seul agent qui est l’acteur de la m´ethode. La figure 4.8 illustre la description d’une m´ethode terminale.

Cette distinction va nous servir pour le test des pr´econditions. En effet, comme pour les actions, les tests sur les pr´econditions, la condition goal et la condition Replan d’une m´ethode terminale vont se faire avec les croyances de l’agent qui r´ealise la m´ethode. La figure 4.8 illustre la description d’une m´ethode terminale. Pour les m´ethodes non-terminales, les mˆemes tests vont se faire avec les croyances de MySelf, comme on peut le constater sur l’exemple de la figure 4.7.

Pour l’interaction homme-robot, cette distinction a trois avantages :

– Elle permet la production de plan sˆur dans le sens o`u il n’y a pas d’´echec dˆu `a un manque d’information ou `a une information erron´ee.

– Elle permet de produire des plans qui sont plus compr´ehensibles pour l’humain. – Elle permet de donner au robot un comportement proactif.

Lors de la planification, nous pouvons d´etecter les cas o`u, soit l’humain ne dispose pas d’information pour r´ealiser sa partie du plan, soit ses informations sont erron´ees. Cette d´etection se fait au niveau des conditions Replan, puisque c’est `a ce niveau que le test pour l’inconsistance des croyances est fait. S’il y a inconsistance, la tˆache est remplac´ee par une nouvelle s´equence de tˆaches qui inclut une action de communication entre MySelf et l’agent qui doit r´ealiser la

terminal method GetObjectFromFurniture ( Agent Ag , O b j e c t Obj , F u r n i t u r e F) {

c o n d i t i o n {

{ Obj (Ag ) . f u r n i t u r e = = unknown;

Ag . MySelf = = f a l s e ; } ;

subtasks {AG = SELECT( Agent , { AG. MySelf = = t r u e ; } ) ; 1 : ReachAgent (AG, Ag) ;

2 : G i v e I f o r m a t i o n A b o u t (AG, Ag , Obj , f u r n i t u r e )>1 3 : GetObjectFromFurniture (Ag , Obj , F)>2; }

{ Obj (Ag ) . f u r n i t u r e = = unknown;

Ag . MySelf = = t r u e ; } ; subtasks { 1 : S e a r c h F o r (Ag , Obj ) ; 2 : PlanAgain (Ag)>1} } ; goal { Obj (Ag) >> Ag . o b j e c t s ; Obj (Ag ) . owner = = Ag; } ;

// d e c o m p o s i t i o n 1

{

preconditions {

Obj (Ag) >> F(Ag ) . o b j e c t s ;

} ; subtasks { 1 : R e a c h F u r n i t u r e (Ag , F) ; 2 : FreeOneHand (Ag) ; 3 : PickupOn ( Ag , Obj , F) > 1 , > 2 ; } ; } }

tˆache, comme il est illustr´e sur la figure 4.8. L’inclusion de cette nouvelle s´equence de tˆaches va permettre de corriger les informations de l’agent en charge de la r´ealisation de la tˆache. Si c’est un humain, il pourra mieux comprendre le plan produit par le robot, mais cela va donner ´egalement au robot un comportement proactif.

Dans le cas o`u c’est MySelf qui ne poss`ede pas l’information, la tˆache est ´egalement

remplac´ee par une s´equence de tˆaches. Sur l’exemple de la figure 4.7, la tˆache GetObject est remplac´ee par la s´equence (SearchF or(AG, Obj) → P lanAgain(AG)). Dans cette s´equence le robot va r´ealiser la tˆache SearchFor dont le but est de localiser la position de l’objet Obj. L’action PlanAgain(AG) est une action de communication entre HATP et l’ex´ecuteur du plan. Elle lui indique que HATP demande une re-planification apr`es l’ex´ecution du plan courant. Cette action n’a pas d’effets et ses pr´econditions sont toujours valides.

Il est important d’indiquer que le choix de la s´equence de tˆaches associ´ee `a la condition Replan n’est pas pr´ed´etermin´e, et sa d´efinition reste `a l’appr´eciation du concepteur du domaine et au comportement qu’il veut donner au robot.