Architecture logicielle de contrˆ ole

Figure _{6.10 – Le robot Jido}

฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀

Le robot utilis´e pour les exp´erimentations r´eelles s’appelle Jido et est illustr´e par la figure 6.10. Ce robot est compos´e d’une plateforme mobile contrˆol´ee par deux roues motrices ainsi que d’un bras articul´e `a six degr´es de libert´e. La perception de l’environnement se fait par l’interm´ediaire de plusieurs capteurs, dont notamment un scanner laser orientable `a l’avant, un scanner laser fixe `a l’arri`ere, des capteurs d’efforts sur la pince, un banc de st´er´eovision fixe pour la manipulation d’objets, un banc de st´er´eovision orientable et une cam´era 3D. Jido est ´egalement ´equip´e d’un ´ecran tactile, lui permet de communiquer avec son partenaire humain via une interface.

L’utilisation d’un planificateur sur un robot exige que le robot soit dot´e d’une architecture logicielle adapt´ee permettant son implantation et son interfa¸cage avec les autres ´el´ements de l’architecture logicielle du robot. Nous avons donc d´evelopp´e une architecture logicielle [Clodic 09] pour le niveau d´elib´eratif de contrˆole du robot. Cette architecture permet une

supervision adapt´ee `a la probl´ematique des robots assistants et un interfa¸cage avec un

planificateur tel que HATP. L’architecture logicielle d´evelopp´ee pour des applications robotiques interactives est illustr´ee par la figure 6.11. Cette architecture se compose de deux niveaux : le niveau fonctionnel et le niveau d´elib´eratif. Le niveau fonctionnel est compos´e d’un ensemble de modules logiciels permettant de contrˆoler les actionneurs du robot et de transcrire les donn´ees fournies par les capteurs en informations exploitables par le niveau d´elib´eratif, ou bien d’ex´ecuter les commandes de ce dernier. Dans le cas de Jido, le niveau fonctionnel contient notamment un module de vision robotique [Burger 08] permettant la d´etection, la reconnaissance et le suivi des humains se trouvant aux alentours du robot, ainsi qu’un module de d´etection des positions des partenaires humains, `a l’aide des donn´ees fournies par les scanners lasers [Sisbot 06]. Jido est aussi ´equip´e d’un synth´etiseur vocal [Bailly 01] qui lui permet d’interagir avec ses partenaires humains, ainsi qu’un planificateur de mouvement et de d´eplacement en pr´esence d’humain [Sisbot 07a], [Sisbot 07c]. Ces modules fournissent des primitives fondamentales pour un robot interactif.

Le niveau d´elib´eratif est compos´e de trois modules principaux en plus de notre planificateur de tˆaches :

1. La base de connaissances est compos´ee de connaissances de trois types :

– Les connaissances a priori repr´esentent les donn´ees invariables ciblant l’environnement dans lequel ´evolue le robot : la carte, les meubles pr´esents, les zones topologiques, les objets pr´esents, etc. . . Les connaissances a priori sont des connaissances fixes dans le temps c’est-`a-dire qui ne seront pas modifi´ees lors du d´eroulement de la manipulation avec le robot.

– Les connaissances contextuelles repr´esentent les donn´ees portant sur l’environnement, qui vont changer pendant le d´eroulement de la manipulation : position des objets, personnes en pr´esence, etc.

– Les connaissances sur les partenaires repr´esentent les connaissances portant sur les partenaires humains du robot. Pour chaque partenaire humain du robot, on regroupe l’ensemble des informations le concernant.

2. L’agenda de tˆaches est charg´e de d´efinir les tˆaches de haut-niveau qui doivent ˆetre r´ealis´ees. Il maintient une liste ordonn´ee de tˆaches de haut niveau qu’on appelle TODO liste, il a un syst`eme de raisonnement qui donne au robot un comportement proactif, par exemple en prenant l’initiative d’adopter un comportement d’un robot curieux, en d´ecidant d’acqu´erir des informations sur l’´etat de l’environnement (Par exemple, l’exploration de nouveaux objets plac´es par une personne sur une table). Il est connect´e avec un syst`eme de reconnaissance de chroniques (CRS) [Dousson 93], qui permet de reconnaˆıtre une situation `

a partir d’une conjonction d’´ev´enements partiellement ordonn´es. Dans la mise en œuvre courante, CRS a ´et´e essentiellement utilis´e pour interpr´eter les activit´es des humains qui se trouvent dans le voisinage du robot. L’agenda de tˆaches g´en`ere les tˆaches `a accomplir `

a partir d’un ordre explicite des humains ou bien `a partir des situations reconnues par CRS, il ordonne ces tˆaches en fonction de leur priorit´e et du contexte dans lequel le robot se trouve. Ce module permet donc au robot de r´epondre aux ordres/suggestions de ses partenaires, mais ´egalement de r´eagir `a des situations sp´ecifiques.

3. Le superviseur : Il est en charge d’´emettre les requˆetes vers le niveau fonctionnel afin de permettre la r´ealisation des actions courantes. Il est ´egalement en charge de contrˆoler le bon d´eroulement de l’ex´ecution des tˆaches courantes, de g´erer la communication ciblant l’interaction homme-robot, et de contrˆoler les activit´es de l’humain au cours de la r´ealisation d’un plan. Le superviseur qui a ´et´e d´evelopp´e s’appelle SHARY, son fonctionnement est d´etaill´e dans [Clodic 07]. De plus, ce superviseur est capable de consid´erer une hi´erarchie compl`ete de tˆaches afin de pouvoir v´erifier le bien fond´e de l’action courante `a diff´erents niveaux d’abstraction.

Dans l’´etat actuel de l’impl´ementation de l’architecture, la base de connaissances et le superviseur SHARY sont ´ecrits `a l’aide du syst`eme de raisonnement proc´edural OpenPRS [Ingrand 96]. L’agenda est implant´e, mais il ne g`ere qu’une liste pr´ecise et limit´ee de tˆaches. Les sch´emas de communication sont ´egalement d´ecrits sous une forme exploitable par OpenPRS. Le planificateur HATP est quant `a lui implant´e sous la forme d’un ex´ecutable se connectant au syst`eme OpenPRS utilis´e par SHARY, et communiquant avec celui-ci par l’interm´ediaire de messages sous forme de chaˆınes de caract`eres. Les requˆetes ´echang´ees et leurs syntaxes entre SHARY et HATP sont les suivants :

Les messages de SHARY vers HATP

Il existe deux types de requˆetes qui passent du superviseur vers HATP :

Message de mise `a jour de la base de faits :

La mise `a jour de la base de faits est r´ealis´ee par l’envoi d’un message d’initialisation puis d’une s´erie de messages qui mettent `a jour les valeurs des attributs, et enfin un message de fin de mise `a jour.

Message de d´ebut de mise `a jour : ce message permet de sortir le planificateur de sa mise en veille et aussi de vider tous les attributs de type dynamique. Pour cela on utilise la syntaxe :

(HATP-START-UPDATE)

Message de fin de mise `a jour : ce message permet de remettre le planificateur en mode veille. Pour cela on utilise la syntaxe :

(HATP-END-UPDATE) Messages de mise `a jour : pour ce message on utilise la syntaxe :

(WP-(axt-id <ID>) <attribut> <entit´e> <valeur>)

On peut constater que dans le message, on re¸coit l’identifiant de requˆete, les noms de l’entit´e et de l’attribut concern´es et la nouvelle valeur de l’attribut. Si le couple (<entit´e>, <attribut>) est un atome dans HATP, sa valeur sera instanci´ee `a <valeur>. Si le couple est un ensemble dans HATP, l’´el´ement <valeur> sera ajout´e dans l’ensemble.

On consid`ere qu’il est de la responsabilit´e du superviseur de renvoyer une mise-`a-jour compl`ete des ´el´ements dynamiques du monde, sinon l’´etat du monde de HATP sera diff´erent de celui de SHARY, ce qui peut conduire `a la production de plans erron´es s’ils existent.

Demande de planification :

Cette requˆete permet de d´efinir le but et aussi de lancer la planification. La requˆete prend cette syntaxe :

(HATP-SEARCH (parent-id <pID>) (task-type <task name>) (p (<param type> < param1 >) (<param type> < param2 >). . . (<param type> < paramn>))) Une fois que le superviseur a envoy´e la requˆete `a HATP, il va attendre un message de fin de planification.

Les messages de HATP vers SHARY

Le seul message que SHARY re¸coit de HATP est un message de fin de planification. Ce message peut prendre deux formes :

– ´Echec de planification : le message est ´emis par HATP quand aucun plan n’a ´et´e trouv´e durant le processus de planification. La syntaxe du message est :

(HATP-END (axt-id <ID>) (report NO-PLAN))

– Retour d’un plan : le message est ´emis par HATP quand un plan est retenu par le processus de planification. Dans ce message, on d´ecrit tout l’arbre de raffinement, c’est-`a-dire toutes les tˆaches pr´esentes, les liens de pr´ec´edence et les liens de d´ecomposition. Pour cela on utilise la syntaxe suivante :

1. Les tˆaches :

(HATP-TASK (hatp-id <ID>) (axt-id <ID>) (parent-task <taskID>) (task-type <task name> ) (Actor (A <agent name1 >). . . (A <agent namen>)) (p (<param type> < param1 >). . . (<param type> < paramn>))

฀

฀ ฀

฀ ฀ ฀

(a) Repr´esentation graphique d’un plan produit par HATP

(HATP-TASK (hatp-id 1) (axt-id 0) (parent-task -1) (task-type GetObject) (Actor (A Jido)) (p (Object Planche)) (coop-type AUTONOMOUS)) (HATP-LINK (axt-id 0) (t-1 1) (t-st 2))

(HATP-TASK (hatp-id 2) (axt-id 0) (parent-task 1) (task-type GetObjectFromFurniture) (Actor (A Jido)) (p (Object Planche) (Furniture PlancheCupboard)) (coop-type AUTONOMOUS)) (HATP-LINK (axt-id 0) (t-1 2) (t-st 3))

(HATP-TASK (hatp-id 3) (axt-id 0) (parent-task 2) (task-type ReachFurniture) (Actor (A Jido)) (p (Furniture PlancheCupboard)) (coop-type AUTONOMOUS)) (HATP-TASK (hatp-id 4) (axt-id 0) (parent-task 2) (task-type PickupIn) (Actor (A Jido)) (p (Object Planche) (Furniture PlancheCupboard)) (coop-type AUTONOMOUS)) (HATP-LINK (axt-id 0) (t-1 3) (t-2 4))

(b) Plan HATP traduit pour SHARY

Figure_{6.12 – Exemple de traduction d’un plan produit par HATP pour SHARY : Dans cet exemple, le} but est que le robot Jido prenne une bouteille.

Dans ces tˆaches, on retrouve l’identifiant de la requˆete de planification axt-id, l’identifiant que HATP donne `a la tˆache hatp-id, parent-task va servir `a d´ecrire la hi´erarchie des tˆaches en identifiant la tˆache m`ere de la tˆache en cours. On retrouve ensuite le nom de la tˆache, les acteurs et la liste des param`etres de celle-ci, et enfin le type de la tˆache si c’est une tˆache jointe ou individuelle.

2. les liens de pr´ec´edence :

(HATP-LINK (axt-id <ID>) (t-1 <taskID> ) (t-2 <taskID>))

Dans la description on a l’identifiant de la requˆete de planification axt-id et les identifiant HATP des deux tˆaches. Le sens de la pr´ec´edence va de la tˆache t-1 vers t-2

3. les liens de d´ecomposition :

(HATP-LINK (axt-id <ID>) (t-1 <taskID> ) (t-st <taskID>))

C’est exactement la mˆeme description que pour les liens de pr´ec´edence. La seule diff´erence est que le symbole pr´ec´edant la deuxi`eme tˆache change de t-2 `a t-st, ce nouveau symbole identifie la premi`ere tˆache de la d´ecomposition puisque les autres tˆaches sont toutes identifi´ees dans la description de la tˆache par (parent-task <taskID>).

La traduction du plan de HATP vers SHARY est illustr´ee par les figures 6.12(a) et 6.12(b) dans lesquelles on peut voir la repr´esentation d’un plan et sa traduction.

(a) L’environnement o`u ´evolue le robot (b) Le mod`ele 3D de l’environnement

Figure_{6.13 – Environnement de travail du robot et sa repr´esentation en 3D}

Figure_{6.14 – Situation de d´epart du sc´enario}