Mécanisme de gestion de ressources

Nous venons de voir qu’un acteur est composé de ressources internes. Chaque ressource

dispose d’un état. L’acteur possède donc un état courant qui est l’agrégation de l’état de ses

ressources et de son état global. Ces états vont également être exploités dans le scénario par

exemple en tant que pré-requis pour une action (nous y reviendrons dans le chapitre suivant).

Nous dotons donc l’acteur d’une activité interne lui permettant de raisonner sur ses ressources.

Ce raisonnement est effectué par un mécanisme de gestion de ressources. Partant de l’état

courant des ressources de l’acteur, ce module est capable de déterminer si un état donné (un

état figurant comme pré-condition d’une action du scénario par exemple) est atteignable (grâce

à des actions de base) et, le cas échéant, il peut fournir une séquence d’actions à réaliser pour

y arriver. Les actions de base qui constituent cette séquence calculée sont appelées actions

implicites (puisqu’elles ne figurent pas dans le scénario), nous y reviendrons dans la section

4.5.

Actuellement, le mécanisme de gestion des ressources raisonne uniquement sur l’état des

mains de l’acteur : l’état courant sera donc un couple représentant l’état de la main droite et

celui de la main gauche. L’état visé sera un couple non ordonné d’états à choisir parmi {libre,

tenant un objet, occupée, indifférent}. Les états tenant un objet et occupée sont accompagnés

d’une information respectivement sur l’objet attrapé et sur la cause de l’occupation. La

sé-quence d’actions obtenue est constituée d’actions de prise et de pose d’objets que l’acteur

devra réaliser pour atteindre l’état visé. Mais les solutions possibles sont rarement uniques

(tant en terme d’actions que de séquencement de ces actions) ; le module de gestion des

res-sources fournit simplement une possibilité parmi celles existantes. Par exemple si l’acteur a

une main vide et un tournevis dans l’autre main et qu’il vise l’action planter un clou qui a

comme pré-requis de posséder un marteau et un clou, la séquence d’actions proposée pourra

être la suivante : poser le tournevis, prendre un marteau, prendre un clou. Cette séquence n’est

pas la seule possible, mais ce qui est important c’est l’existence d’un chemin et la possibilité

de disposer de toutes les étapes sur ce chemin.

Nous avons choisi de considérer l’acteur comme parfaitement ambidextre et par

consé-quent de ne pas différencier dans l’état visé la main droite de la main gauche ou plutôt la main

dominante de la main dominée pour prendre en compte à la fois les droitiers et les gauchers. Ce

choix augmente un peu la complexité du mécanisme de gestion de ressources qui ne peut pas se

contenter de faire une comparaison pour chacune des mains entre l’état actuel et l’état voulu (il

y a plus de combinaisons possibles) mais en contrepartie la spécification du scénario est

sim-plifiée. En effet, cela évite pour commencer d’avoir à spécifier la main dominante de chaque

acteur. Ensuite, cela évite de devoir préciser, pour chaque action, si la main utilisée va être la

main dominante, la main dominée, ou indifféremment l’une ou l’autre. Lorsque l’acteur veut

réaliser une action prendre, cela évite qu’il ait à préciser quelle main il souhaite utiliser. Toutes

ces informations supplémentaires sont en effet fastidieuses à préciser et ne nous paraissent pas

essentielles dans notre contexte de formation. Cela évite également de proposer une action de

transfert d’un objet d’une main à l’autre (cette action ferait alors partie des actions pouvant

constituer la séquence d’actions fournie par le module de gestion des ressources). Néanmoins,

il est possible de spécifier certaines actions ne pouvant être réalisées que par la main

domi-nante par exemple : pour cela il suffit d’ajouter aux capacités requises par l’action une capacité

main dominante que l’on peut rajouter à la main dominante de l’acteur. Toutefois, si pour

d’autres applications nous nous rendons compte que cette distinction entre la main dominante

et l’autre main est importante, il suffira de modifier le mécanisme de gestion des ressources :

son raisonnement sera en effet simplifié puisqu’il suffira de comparer l’état requis pour la main

dominante avec l’état actuel de la main dominante, et de même pour l’autre main. Une nouvelle

action apparaîtra alors dans le calcul de plan qui sera l’action de transfert d’un objet d’une main

à l’autre. Il faudra alors changer la spécification dans le scénario des états pré-requis pour une

action en considérant un couple ordonné (main dominante puis main dominée par exemple)

avec éventuellement plusieurs possibilités (si l’action peut être réalisée indifféremment avec

l’une ou l’autre des mains). La gestion ambidextre de l’acteur revient à considérer les mains

comme une ressource à deux places. La gestion par main dominante revient à particulariser

chacune des deux main en considérant la main dominante comme une ressource à une place et

la main dominée comme une ressource à une place.

F

IG

. 3.3 – La compatibilité entre un état de départ et un état cible grâce aux actions de base

uniquement

Nous allons maintenant détailler l’algorithme utilisé pour obtenir une séquence d’actions

permettant de passer d’un état des mains de départ à un état cible. En entrée il prend un couple

représentant l’état actuel des deux mains et un couple représentant l’état visé pour les deux

mains. Son objectif est d’associer chaque état courant à un état cible, en mettant à jour le

nombre d’actions de prise et/ou de pose nécessaires. Les différentes associations possibles

sont : état actuel de la main droite avec premier état cible, état actuel de la main droite avec

deuxième état cible, état actuel de la main gauche avec premier état cible, état actuel de la main

gauche avec deuxième état cible. Le tableau de la figure 3.3 illustre la compatibilité entre les

différents états, ainsi que les actions de base requises pour passer de l’un à l’autre. Lorsque

“impossible” figure dans une case de ce tableau, cela signifie qu’il faut impérativement passer

par une action spécifique, figurant dans le scénario, pour pouvoir passer de l’état de départ à

l’état cible ; la transition n’est pas possible en utilisant seulement les actions de base. En sortie

de l’algorithme nous obtenons un booléen indiquant si l’état visé est atteignable, le nombre

de prise d’outils requis, le nombre de pose d’objets requis ainsi que l’objet impliqué dans la

première action de la séquence calculée. Nous considérons que si plusieurs actions

intermé-diaires sont requises, la pose sera la première à effectuer (et donc l’objet à considérer sera celui

qu’il faudra reposer). L’algorithme est détaillé sur la figure 3.4. L’étape 2, l’association directe,

consiste à rechercher les associations grâce à une compatibilité directe : (libre,libre),

un objet ayant le bon type

1

). A la sortie de cette étape, s’il reste des états cibles occupée qui

n’ont pas été associés (cela signifie qu’il n’y a pas d’état occupée comme état de départ ou que

la cause de l’occupation est différente), alors on sait qu’il n’y a pas de séquence d’actions de

base possible pour arriver à l’état cible en partant de l’état courant (voir le tableau d’association

sur la figure 3.3). Ensuite on passe en revue les différentes associations nécessitant des actions

implicites, on commence par l’association libre et objet qui nécessite une actions de prise, puis

l’association objet et libre qui nécessite une action de pose et enfin l’association objet et objet

qui nécessite une action de pose suivie d’une action de prise. A chaque fois on met à jour le

compteur d’actions de prise et de pose et la variable indiquant le premier objet à considérer

dans la séquence résultat. L’ordre de considération fait que cet objet correspondra toujours à

une action de pose s’il y en a une. A la fin de l’algorithme, s’il reste des états de départ non

associés et qu’il n’y a pas assez d’indifférent pour les associer, alors l’algorithme renvoie faux

pour indiquer qu’il n’y a pas de séquence d’actions possibles, sinon il renvoie vrai et renvoie

les diverses informations détaillées précédemment.

La séquence d’actions obtenue n’est pas mémorisée entièrement car en réalité elle sera

recalculée suite à une action dans l’environnement ; on effectue en effet une reconsidération

dynamique du plan d’actions (voir chapitre 5). Seules les informations utiles au mécanisme

de sélection d’action sont ainsi fournies : la faisabilité et le nombre d’actions de prise et de

pose nécessaires. Le premier objet impliqué sera quant à lui utile pour l’acteur s’il sélectionne

l’action associée ; en effet il saura ainsi quelle est la première action à effectuer (si le nombre

d’actions de pose requis est supérieur à zéro il s’agira de poser cet objet, sinon s’il y a au

moins une action de prise requise il s’agira de prendre cet objet, sinon cela signifie qu’il n’y a

pas d’action implicite nécessaire). Les séquences sont toujours calculées en posant d’abord les

objets nécessaires puis en prenant les objets manquants, afin de libérer au plus vite des objets

dont l’acteur ne se sert pas. En revanche il n’y a pas de raison particulière sur le choix d’un

objet à poser plutôt qu’un autre s’il y a plusieurs possibilités. Il serait envisageable d’utiliser des

heuristiques pour déterminer l’objet qui a le moins de chance d’être réutilisé et qu’il faudrait

donc reposer en priorité (en analysant les actions suivantes par exemple ou en mémorisant les

outils qui ont déjà servi).

En résumé le mécanisme de gestion de ressources permet de savoir si un état donné est

atteignable à partir d’un état de départ, et il permet également d’obtenir une séquence d’actions

possible pour rejoindre l’état cible.

Dans le document Contribution à la formation en réalité virtuelle : scénarios collaboratifs et intégration d'humains virtuels collaborant avec des utilisateurs réels (Page 79-82)