S’agissant du monitoring des actions de l’homme, le robot doit ˆetre en mesure d’identifier un mouvement de l’homme comme ´etant la r´ealisation d’une action donn´ee. Les ”moniteurs” tels qu’´evoqu´es dans la section 3.3 permettent d’inf´erer la r´ealisation d’actions au moyen de tests de complexit´e variable. On pourrait imaginer des moniteurs complexes construits `a partir de mod`eles de Markov cach´es. Dans le syst`eme actuel, on utilise un moniteur tr`es simple de la prise d’un objet. Il est d´efini par une sph`ere virtuelle autour des objets qui sont pos´es sur un support. D`es qu’une main de l’homme p´en`etre dans cette sph`ere, ce moniteur d´eclenche. Ce d´eclenchement n’implique pas obligatoirement que cette action a ´et´e effectivement r´ealis´ee mais il nous permet de supposer que c’est une ´eventualit´e `a consid´erer.
l’algorithme 7, explicite la gestion associ´ee `a la v´erification par le robot de l’ex´ecution par l’homme de ses actions. Imaginons que l’homme doive prendre la cassette grise grey tape sur la table. TakeObject(human,grey tape). On doit choisir le param`etre timeStep qui donne la fr´equence avec laquelle l’al-gorithme examine le d´eclenchement des moniteurs et waitM onitorDelay qui donne la dur´ee maximale d’attente de la r´ealisation de l’action par l’homme. On choisira waitM onitorDelay comme une estimation de la dur´ee maximale
de r´ealisation de l’action. La fonction action.getMonitor(actionMonitor)
permet de r´ecup´erer le ”moniteur” associ´e `a l’action s’il existe. Dans notre exemple il s’agit de la sph`ere autour de la cassette grise. La fonction
informAttentionAboutAction(action)
pr´evient le syst`eme attentionnel de l’action en cours. S’il n’y a pas de re-quˆete de priorit´e sup´erieure `a l’action en cours (c’est-`a-dire si le robot n’est pas en train de verbaliser une indication `a l’homme d’apr`es la section 3.4), cela se traduira pour TakeObject par une focalisation des cam´eras du robot sur l’objet qui doit ˆetre attrap´e, c’est-`a-dire grey tape. La fonction
newTriggeredMonitor(monitor)
permet de r´ecup´erer le dernier ”moniteur” monitor ayant d´eclench´e depuis le dernier appel `a la fonction. La fonction
getCurrentTime(curTime)
permet de r´ecup´erer la valeur de l’horloge. On boucle ensuite jusqu’`a at-teindre le temps d’attente maximum ou le d´eclenchement d’un moniteur. L’algorithme conclut au succ`es de la r´ealisation de l’action si c’est le moni-teur attendu qui d´eclenche. L’algorithme conclut `a l’´echec de la r´ealisation de l’action s’il y avait un moniteur attendu et que, soit aucun moniteur n’a d´eclench´e, soit un autre moniteur a d´eclench´e. Dans le cas o`u il n’y a pas de moniteur attendu, l’algorithme ne peut conclure.
Algorithm 7 assessHumanActionExecution (action,timeStep,waitM onitorDelay)
action.getM onitor(actionM onitor) inf ormAttentionAboutAction(action) action.isRealized= U N KN OW N getCurrentT ime(curT ime)
for all timeStep bef ore curT ime + waitM onitorDelay do if newT riggeredM onitor(monitor) then
if monitor == actionM onitor then action.isRealized= T RU E
else
if actionM onitor! = N U LL then action.isRealized= F ALSE end if
end if
exit FOR Loop end if
end for
if monitor == N U LL then
if actionM onitor! = N U LL then action.isRealized= F ALSE end if
Chapitre 6
Exp´erimentations
Ce chapitre a pour objet de d´emontrer le fonctionnement r´eel du syst`eme pr´esent´e dans les trois chapitres pr´ec´edents ainsi que dans la publication [2]. Dans la section 6.1, on d´ecrit rapidement l’architecture LAAS qui facilite l’impl´ementation. Dans la section 6.2 nous d´ecrivons de mani`ere approfondie la r´ealisation d’un sc´enario simple pour expliciter tous les processus d´ecrits dans les chapitres pr´ec´edents. La section 6.3 d´ecrit de mani`ere globale le r´esultat d’une premi`ere campagne d’exp´erimentations. Enfin, nous d´ecrivon dans la section 6.4 la migration vers le robot PR2 qui est plus facile `a mettre en oeuvre que le robot Jido et qui offre un aspect ext´erieur plus agr´eable qui se prˆete mieux `a des ´etudes utilisateurs.
6.1 L’architecture LAAS
L’architecture LAAS [1] pour syst`emes autonomes, pr´esent´ee figure 6.1, a ´et´e d´evelopp´ee de mani`ere incr´ementale durant un grand nombre d’ann´ees et est mise en oeuvre sur l’ensemble des robots mobiles du LAAS. Il faut noter que les aspects g´en´ericit´e et programmabilit´e de cette architecture permettent une mise en oeuvre rapide et une bonne int´egration des syst`emes utilis´es (GenoM ( [17], [18]), OpenPRS ([26],[25]),. . .). Cette suite logiciel comprend trois niveaux :
– Le niveau d´ecisionnel : Ce plus haut niveau int`egre les capacit´es d´eli-b´eratives par exemple : produire des plans de tˆaches, reconnaˆıtre des situations, d´etecter des fautes, etc. Dans notre cas, il comprend : – un ex´ecutif proc´edural OpenPRS qui est connect´e au niveau
inf´e-rieur auquel il envoie des requˆetes qui vont lancer des actions (cap-teurs/actionneurs) ou d´emarrer des traitements. Il est responsable de la supervision des actions tout en ´etant r´eactif aux ´ev´enements
provenant du niveau inf´erieur et aux commandes de l’op´erateur. Cet ex´ecutif a un temps de r´eaction garanti,
– un planificateur (HATP),
– une base de fait sous la forme d’une ontologie (ORO).
– Le niveau fonctionnel : Le plus bas niveau comprend toutes les actions et fonctions de perception de base de l’agent. Ces boucles de contrˆole et traitements de donn´ees sont encapsul´es dans des modules contrˆolables (d´evelopp´es avec GenoM). Chaque module fournit des services et trai-tements accessibles par des requˆetes envoy´ees par le niveau sup´erieur ou un autre module. Le module envoie en retour un bilan lorsqu’il se termine correctement ou est interrompu. Ces modules sont compl`ete-ment contrˆol´es par le niveau sup´erieur et leurs contraintes temporelles d´ependent du type de traitement qu’ils ont `a g´erer (servo- contrˆole, algorithmes de localisation, etc.).
– Le niveau de contrˆole des requˆetes (d´efini dans l’architecture mais non utilis´e au sein de nos instanciations sur Jido et Rackham) : Situ´e entre les deux niveaux pr´ec´edents, le R2C « Requests and Replies Checker » [27] v´erifie les requˆetes envoy´ees aux modules fonctionnels (par l’ex´e-cutif proc´edural ou entre modules) et l’utilisation des ressources.