Collaboration multi-robot pour l'aide à la personne.

Contexte général.

Ce projet, guidé par l'application envisagée, porte sur l'étude de l'utilisation d'un groupe de robots mobiles pour l'exécution de missions au profit d'un utilisateur humain (Il pourrait être envisagé de prendre en compte plusieurs utilisateurs mais dans une phase plus lointaine) temporairement ou définitivement immobilisé. Dans le scénario envisagé, cet utilisateur adresse une requête au système, expression d'un besoin de service, qui sera réalisée de manière collective et coopérative par le groupe de robots. Le projet vise à concevoir et à réaliser l'ensemble des fonctions qui vont de l'expression de la requête à sa réalisation par les robots sur la base de l'architecture ARMAGRA. Les figures 1 et 2 montrent les robots utilisés. La multiplication du nombre d'entités actives est un facteur d'accroissement des coûts. Aussi, pour rendre ce système envisageable, sur un plan purement économique, il faut envisager son utilisation chez un particulier, mais aussi dans des maisons de retraite, maisons médicalisées, unités de rééducation pour accidentés ...

En accord avec les autres études sur les dispositifs d'aide aux personnes handicapées ou en situation de handicap menées au LSC, l'utilisateur doit pouvoir intervenir de manière active dans le système. En effet, les contacts que le laboratoire a avec des organismes comme l'Association Française contre la Myopathie (AFM) montrent que l'utilisateur ne souhaite pas disposer d'un système entièrement automatique. Il veut au contraire pouvoir participer au contrôle au sens large du système, à la gestion de ses composants. De plus, il veut avoir en permanence une information sur l'évolution de l'exécution.

Intuitivement, on sent que la conception du système va faire appel à plusieurs niveaux d'abstraction. En effet, par l'intermédiaire de l'interface entre l'humain et le système, l'utilisateur va requérir le service. Cette demande va devoir être analysée pour décider quelles sont les ressources nécessaires et un scénario du déroulement va devoir être construit, scénario qui sera soumis à l'utilisateur et accepté ou non. Le travail de recherche s'intéresse à la définition de ces niveaux d'abstraction et du ou des langages associés.

Fig. 1

Fig. 2

Modèle général.

Comment, dès lors, imaginer un système qui reçoit une requête au travers d'un interface aussi convivial que possible et qui doit produire un ensemble d'ordres exécutables par les robots ?

Le modèle proposé pour mettre en place ce système est donné par la figure 3. On considère, dans ce schéma :
- l'acteur : élément actif soumis au stimulus (l'utilisateur et sa requête, par exemple),
- la forme objective : objet conçu (dans l'esprit de l'acteur si celui-ci est humain, mais pouvant se décrire en tant que programme si l'acteur est un compilateur),
- l'objet : état final, élément satisfaisant et correspondant au stimulus (ce peut être un processus dont l'exécution réalisera le stimulus).

Fig. 3: Modélisation de la démarche

La transition permettant de créer la forme objective est une déduction, conséquence tirée d'un raisonnement, raisonnement faisant appel à la connaissance et à l'expérience. La fabrication fait passer de la forme objective à sa forme matérielle : l'objet. Le retour, qui va de l'objet à l'acteur procède plutôt de l'induction puisqu'elle va du particulier vers une entité plus générale.

En accord avec le modèle ci-dessus, il faut s'attacher à :
- définir les différents niveaux d'abstraction qui vont du niveau de la requête au niveau de l'exécution,
- déterminer, pour chacun d'entre eux, les acteurs, les diverses formes objectives et les objets,
- dégager les fonctionnalités requises par chaque niveau,
- mettre en place ces fonctionnalités dans un cadre multi-agents,
- valider le modèle dans le cadre de l'application choisie.

Pour chaque niveau, on voit
- l'acteur comme l'objet du niveau supérieur,
- la forme objective comme un ensemble de ressources à mettre en oeuvre,
- l'objet comme le scénario utilisant ces ressources.

Travaux en cours sur l'architecture ARMAGRA.

Les travaux en cours s'intéressent au système permettant à un utilisateur de donner à une équipe de robots une mission, de modéliser l'ensemble des processus menant à son exécution par le groupe.

Ce travail, pour qu'il soit réalisable, s'impose certaines limites et contraintes :
- l'environnement dans lequel vont évoluer les robots est de type intérieur de bâtiment,
- le nombre de robots est de quelques unités,
- les robots sont hétérogènes, non équipés des mêmes effecteurs et des mêmes capteurs,
- le coût est pris en compte très tôt, notamment dans le matériel des robots mobiles; ce qui aura une influence sur l'architecture du système,
- l'utilisateur fait partie du système. Il peut, à des degrés divers, intervenir sur celui-ci, en accepter ou en rejeter les décisions,
- l'opérateur humain est supposé dépourvu des moyens de déplacement,
- l'environnement est doté d'une installation domotique permettant la commande des appareils ménagers (exemple : ouverture de la porte du réfrigérateur).

L'utilisateur a à sa disposition :
- la connaissance de l'appartement,
- les robots et une vue externe de leurs possibilités,
- un nombre de missions de déplacement susceptibles d'être exécutées comme :
* aller à, aller vers, revenir,
* prendre, poser,
* stop,
* faire,
* rapporter, porter,
- et de missions domestiques comme :
* rapprocher, éloigner,
* prendre, poser,
* déplacer un objet en le poussant ou en le tirant,
* déplacer un objet en le ramassant.
- un compte rendu sur l'état du système.

Au stade actuel du travail, ont été effectué :
- un recencement les besoins en ressources pour un nombre réduit de missions (se_rassembler, rechercher_objet, prendre_objet, déposer_objet),
- un recencement des compétences de chaque robot (robot équipé d'un bras, d'un plateau),
- la prise en compte de l'état courant du système (position des objets fixes et mobiles de l'environnement, position des robots).

Le système effectue le choix du ou des robots, en fonction de la mission, vérifie, complète et valide l'expression de la requête. Le système utilisé pour modéliser et mettre en \oe{}uvre sous forme de règles cette phase est CLIPS.

Ce système est complètement intégré dans l'architecture ARMAGRA présentée plus haut. En d'autres termes, il est possible d'envoyer la requête par le réseau LAN ou FAN et d'en recevoir la réponse. Celle-ci est, pour le moment, proposée à l'utilisateur sous forme d'une liste de doublets <robot, mission>. En fonction la mission et selon son mode de traitement, le système peut n'utiliser qu'un seul robot (tentative de mise en place d'un mode dégradé), utiliser le robot le moins coûteux (au sens des ressources à mettre en oeuvre) ou bien privilégier le parallélisme entre les robots. Par ce biais, nous introduisons par ce biais une certaine qualité de service.

Ce scénario doit maintenant être repris et transcrit, en plusieurs étapes si nécessaire, jusqu'à la description spatio-temporelle correspondant à l'ensemble des actions qui seront exécutées.

Quelles sont donc les directions à explorer pour mettre en place cette description ?

Tout d'abord,
- étudier l'interaction humain-machine,
- choisir les niveaux d'abstraction,
- définir les langages correspondant,
- concevoir les logiciels qui vont les mettre en oeuvre dans un contexte multi-agents.

Ensuite, il faut valider les solutions sur le démonstrateur ARMAGRA.

Interface utilisateur.

L'organisation de l'interface utilisateur est conçu avec une préoccupation importante, celle de l'ergonomie et de la facilité d'utilisation. L'interface graphique dont la fenêtre principale est présentée sur la figure 4, propose plusieurs zones :
- la carte de l'environnement dans lequel va évoluer l'équipe de robots comportant les robots aussi bien que les obstacles,
- une zone dans laquelle est visualisé l'état de chacun des robots,
- une zone permettant l'entrée de la requête de l'utilisateur.

Fig. 4: Interface utilisateur

Cet interface, qui communique avec les autres éléments au travers d'une liaison réseau, n'est en charge que de la visualisation graphique et de de l'envoi des requêtes vers l'élément suivant dans le système : le moteur d'inférence.

Mécanisme d'inference pour le traitement de la requête utilisateur.

Lorsque la requête a été entrée par l'utilisateur, elle est analysée par le système. Une analyse syntaxique est effectuée suivie d'une analyse sémantique. Les arguments de la requête peuvent être complètés et/ou modifiés par le système. Le choix des robots en fonction la mission, de leurs capacités et des disponibilités des ressources requises est modélisé au moyen d'un ensemble de règles et d'un moteur d'inférence.

Dans la formulation des missions telle qu'elle est mise en place par l'utilisateur du système, un certain nombre d'informations sont obligatoires, en particulier la classe de la tâche. La classe définit le type d'action qui doit être menée. L'ensemble des règles est divisé en deux groupes :
- les règles produisant les arguments,
- les règles vérifiant les arguments.

Cette distinction n'est vraie que dans la modélisation du processus. Elle n'est pas vraie dans le traitement effectué au sein du mécanisme d'inférence qui ne fait pas de différence entre les arguments entrés par l'utilisateur et ceux que le système met en place lui même. Le tableau 5 montre, pour certaines actions le lien avec les arguments obligatoires et optionnels entrant dans les règles. Tout argument obligatoire manquant produit une erreur et conduit le système à redemander certaines précisions à l'utilisation. Quelques actions dont l'action PUT (tableau 6) présentent quelques particularités et ont besoin d'un groupe de règles spécifiques : l'utilisateur peut désigner ou bien le robot qui doit transporter ou bien l'objet à transporter.

L'application des diverses règles par le moteur d'inférence conduit à la génération d'une requête correcte qui répertorie et réserve les ressources n\'cessaires à l'exécution. Un premier projet de résolution peut alors être proposé à l'utilisateur. Parmi les différents moteurs d'inférence utilisables, nous avons choisi CLIPS à laquelle a été ajoutée une interface réseau tout à fait indispensable pour l'architecture ARMAGRA.

Un autre jeu de règles permet au système de déterminer le nombre et les cractéristiques des robots pour l'accomplissement de la tâche. Il propose ègalement, le cas échéant, des arguments à l'utilisateur, arguments qu'il peut aussi modifier.

Fonctionalités du système.

Se pose alors la question du choix des robots à impliquer dans l'accomplissement de la mission. Chaque robot a, pour cela, un niveau d'expertise, calculé en fonction de ses fonctionnalités. Lorsque l'utilisateur n'impose pas de contraintes sur le choix des robots devant participe à la mission qu'il confie au système. le système choisit alors le ou les robots qui ont le score le plus bas. Deux modes de fonctionnement peuvent être alors déclenchés dans le moteur d'inférence.
- le mode parallèle, dans lequel le système essaie de paralléliser au mieux les tâches devant être exécutées par les robots. Son critère de choix principal est le minimum d'expertise.
- le mode séquentiel, dans lequel le système se veut une aide pour l'utilisateur dans la construction de la mission. Il essaie d'affecter le maximus de tâches à un même robot choisi pour son expertise maximum. Dans l'état actuel de l'étude, un certain nombre de limitations existent dans ce mode. Notamment, si le robot le plus expert est déjà utilisé pour uner autre tâche, il n'est pris en considération lors du choix de l'expertise maximum.

Première évaluation de l'exécution de la mission.

Cette première étape dans l'exécution de la mission consiste à envisager le déplacement des robots. Il faut, pour cela, déterminer:
- les trajectoires possibles entre une origine et le lieu de destination du groupe,
- les passages possibles pour le groupe de robots dans la formation choisie,
- la trajectoire du groupe en tenant compte des possibilités de changement de formation,
- le point de rassemblement des robots,
- faire exécuter la trajectoire par le groupe.

A ce jour, les quatre premiers points sont réalisés et validés.

La figure 7 montre l'environnement de test de notre travail. Le calcul des trajectoires possibles fait appel au graphe de Voronoï. Le graphe correspondant à l'environnement de test est représenté sur la figure 8.

Fig. 7: Environnement de test et trajectoire envisagée pour exécution de la mission

FIG. 8: Graphe de Voronoï dans l'environnement de test

Un exemple de déplacement en formation des robots peut être vu sur ce film. Un autre exemple de mise en file indienne est donné sur ce film.