7.3 Description du syst`eme de supervision : l’avant Shary
Nous d´ecrivons ici le syst`eme de supervision d´efini avant Shary qui a consist´e en notre premi`ere impl´ementation de la th´eorie de l’intention jointe.
Dans ce syst`eme chaque homme entrant dans le champ du robot ´etait pris en compte comme un agent avec qui le robot pouvait collaborer ou interagir. Pour ˆetre homog`ene, le robot lui-mˆeme ´etait consid´er´e comme un agent. Ainsi dans les explications nous utiliserons le terme agent si l’on se r´ef`ere de mani`ere indiff´erente `a un homme ou au robot, sinon le terme robot sera utilis´e.
7.3.1 Espace d’´etat
L’espace d’´etat ´etait compos´e de trois variables :
– l’engagement des agents dans la tˆache (=AgentCo (exemple : RobotCo)) : engag´e commit-ted, non-engag´e uncommitted (default),
– la croyance des agents concernant l’´etat de la tˆache (=AgentTS (exemple :RobotTS)) : en cours unachieved (par d´efaut), termin´e achieved, non-pertinent irrelevant, impossible
impossible,
– progr`es du robot dans la tˆache (=RobotP) : inactifidle, commencementstart, planification
planning, en cours de r´ealisationin task, en cours d’arrˆetstopping, arrˆet´estopped 7.3.2 D´efinition d’une tˆache
En consid´erant la diff´erence entre le cas individuel et le cas joint, et la granularit´e disponible entre les tˆaches et les sous-tˆaches, nous avons d´efini quatre types de tˆaches :
tˆache racine root task correspond `a l’impl´ementation actuel de l’agenda et est limit´e `a une tˆache unique,
tˆache individuelle individual task une tˆache qui peut ˆetre d´ecompos´ee mais qui ne concerne que le robot,
tˆache jointe joint task une tˆache qui peut ˆetre d´ecompos´ee mais qui va concerner le robot et un autre agent,
activit´e activity une tˆache non-d´ecomposable qui correspond `a une routine de bas-niveau ou une activit´e atomique pour l’homme telle qu’il est possible de l’observer pour l’homme. Une tˆache est d´efinie par :
– son plan courant : qui correspond `a l’ensemble des activit´es et des sous-tˆaches que le robot doit ex´ecuter pour r´ealiser la tˆache, des exemples de plans sont donn´es figure 16
– un ensemble de moniteurs qui vont suivre le progr`es de la tˆache et v´erifier si la tˆache est termin´ee achieved, non-pertinente irrelevant ou impossible impossible. Des exemples de moniteurs sont donn´ees figure 17.
Dans la version actuelle du syst`eme, les moniteurs sont passifs, i.e. un moniteur ne peut pas ˆetre la cause d’une action du robot. Ils utilisent juste les informations provenant du d´eroulement de la tˆache pour conclure. Les moniteurs sont une mani`ere de g´erer la multi-modalit´e, en effet il est possible d’associer un nombre arbitraire de moniteurs `a une valeur (`a un ´etat) donn´ee correspondant `a diff´erentes modalit´es.
L’affinage de la tˆache est r´ealis´e par l’interm´ediaire d’une phase de replanification. Dans cette version, les plans sont stock´es dans une biblioth`eque de plans. La figure 18 illustre la structure dynamique de la tˆache et le contexte de planification.
(=>(PLAN (ROOT)
(. (. Robot (INITIALISATION) .)
(. Robot (LOOKING FOR INTERACTION) (. Robot Agent (DOSERVICE) .) .))
(=>(PLAN (GO_TO $destination)
(. (. Robot (FIND TRAJECTORY $destination) .) (. Robot (MOVE $destination).)
.) .))
Fig.16 – Exemples de plans de tˆaches stock´es dans la biblioth`eque de plans
(=>(MONITOR (GO TO $destination) $who1 $who1 ACHIEVED OK (GOTOACHIEVED)))
; watch BRAKESON
(=>(MONITOR (GO TO $destination) $who1 $who1 IRRELEVANT BRAKES (RFLEXTRACKSPEEDSTARTBRAKESON)))
; watch ASPECTFAILED
(=>(MONITOR (GO TO $destination) $who1 $who1 IMPOSSIBLE ASPECT_FAILED (ASPECTFROMPOSTERCONFIGFAILED)))
; watch people blocking the robot ; few time
(=>(MONITOR (GO TO $destination) $who1 $who1 IMPOSSIBLE PEOPLE (ATBLOCKED))) (=>(MONITOR (GO TO $destination) $who1 $who1 ACHIEVED NEXT_TO (ATNEXTTO)))
; delay
(=>(MONITOR (GO TO $destination) $who1 $who1 IMPOSSIBLE DELAY (ELAPSED-TIME (TIME) 600)))
; segloc
(=>(MONITOR (GO TO $destination) $who1 $who1 IMPOSSIBLE LOCLOOP_FAILED (SEGLOCLOCLOOPFAILED)))
(=>(MONITOR (GO TO $destination) $who1 $who1 IMPOSSIBLE PEOPLE (ATBLOCKED)))
TASK Agent Concerned Monitor Tag
Agent concerned by the belief AgentTS concerned Condition that trigger the monitor
7.3. Description du syst`eme de supervision : l’avant Shary Bring an object to the human Go to the object Take the object Go to the human Give the object Go to the object Find a trajectory Execute the trajectory achieved impossible irrelevant achieved impossible irrelevant Find a Trajectory achieved impossible irrelevant Supervision Level Execution Level
the human has the object
the human does not want the object
the robot is next to the object
a trajectory is available
problem with trajectory computation the object is missing
FUNCTIONAL MODULES
P Planning
Planning
Fig. 18 – La structure hi´erarchique de tˆaches g´er´ee par le superviseur
L’activit´e de planification associ´ee `a une tˆache est un processus continu, il v´erifie de mani`ere p´eriodique la faisabilit´e de la tˆache et fournit les prochaines tˆaches `a r´ealiser en fonction du contexte courant. Les ´ev´enements d´etect´es par les moniteurs `a un certain niveau sont propag´es `
a travers la tˆache et ses sous-tˆaches et occasionnent des cr´eations/destructions de sous-tˆaches et des replanifications.
7.3.3 Tˆaches jointes
Chaque tˆache jointe suit un sch´ema identique. Le plan d’une tˆache jointe est divis´ee en 4 sous-tˆaches comme illustr´e figure 19 :
PRETASK correspondant `a la phase d’´etablissement des engagements,
DOTASK correspondant `a l’ex´ecution de la tˆache,
POSTTASK correspondant `a la terminaison de la tˆache,
CHECKTASK correspondant aux traitements des probl`emes, potentiels pouvant survenir concernant la croyance mutuelle entre l’homme et le robot,
Chacune des ces sous-tˆaches peut ˆetre d´efinie comme une tˆache individuelle, jointe ou une activit´e.
Concernant les tˆaches jointes, plusieurs types de moniteurs peuvent ˆetre d´efinis. La figure 17 montre la tˆache individuelle (GO TO $dest) o`u les moniteurs sont d´efinis pour $who1 concernant $who1, i.e. les moniteurs concernant les croyances du robot sur lui-mˆeme. Pour une tˆache jointe,
PRETASK DOTASK POSTTASK
CHECKTASK AgentCo = Committed
RobotCo = Committed
AgentCo || RobotCo = Uncommitted
RobotTS = Achieved || Irrelevant || Impossible and
AgentTS = Achieved || Irrelevant || Impossible AgentTS =
Achieved || Irrelevant || Impossible and RobotTS = Unachieved AgentTS = Unachieved and RobotTS = Unachieved RobotTS =
Achieved || Irrelevant || Impossible
Fig. 19 – Une tˆache jointe est divis´e en 4 sous-tˆaches : (1) PRETASK : correspondant `a la phase d’´etablissement des engagements, (2) DOTASK : correspondant `a l’ex´ecution de la tˆache, (3) CHECKTASK : correspondant aux traitements des probl`emes, potentiels pouvant survenir concernant la croyance mutuelle entre l’homme et le robot, (4) POSTTASK : correspondant `a la terminaison de la tˆache.
il est possible de d´efinir des moniteurs concernant les croyances d’un agent vis `a vis d’un autre agent.
7.3.4 R´esum´e et Le¸cons
Nous avons d´evelopp´e et impl´ement´e un syst`eme de supervision permettant la gestion de tˆaches individuelles, jointe et d’activit´es. Chaque tˆache est d´efinie par un plan et des moniteurs associ´es. Un plan correspond `a une s´equence de sous-tˆaches et/ou d’activit´es. Les moniteurs servent `a ´etablir si une tˆache est termin´ee achieved, impossible impossible ou stopp´ee stopped.
Le syst`eme peut ˆetre contrˆol´e `a diff´erents niveaux au mˆeme moment. Si un ´ev´enement est d´etect´e `a un certain niveau, le syst`eme est capable de le prendre en compte `a ce niveau et d’appliquer les solutions adapt´ees (´eventuellement en propageant aux niveaux sup´erieurs ou inf´erieurs).
Le superviseur est ´ecrit en OpenPRS. Les plans proviennent d’une biblioth`eque de plans et seul le robot peut proposer une tˆache.
Le syst`eme a ´et´e test´e lors de la derni`ere visite de Rackham `a la Cit´e de l’espace pour la r´ealisation du sc´enario pr´esent´e section 7.2.3 page 146.
Il constitue notre premiere tentative de construction d’un syst`eme bas´e sur la th´eorie de l’in-tention jointe. Il a montr´e des r´esultats encourageants, notamment sur la facilit´e de d´efinir des tˆaches et des moniteurs, sur la r´eutilisation de morceaux de tˆaches d´ej`a d´efinis (ainsi le syst`eme a ´et´e utilis´e au LAAS pour une tˆache consistant pour Rackham `a proposer ses services et `a la conf´erence RO-MAN en Angleterre) et sur la souplesse qu’apportait l’encadrement de l’inter-action (par exemple l’utilisation du CHECK TASK lorsqu’un probl`eme survenait). Cependant, le sch´ema d’interaction d´efini (i.e. la figure 19), nous est vite apparu trop restreint car il ne permettait pas de rajouter des ´etapes d’interaction, c’est pourquoi il nous est apparu important de rendre possible la d´efinition de nouveau sch´emas en fonction de la tˆache et/ou du contexte.