SI SPECIAL ETE 97

le techno-quotidien

dessin Enrico

Alors, à quand votre premier agent?...

Didier Guzzoni, e-mail: Didier.Guzzoni@imt.dmt.epfl.ch,
VRAI Group, EPFL-DMT, Institut de Microtechnique

Table des matières

Retour à la table des matières

Introduction

Définition

Nous allons tout d'abord clarifier quelque peu la notion d'agent, sans pour autant en donner une définition précise, car le terme agent fait encore l'objet d'une guerre de religion parmi les informaticiens férus d'intelligence artificielle. C'est la raison pour laquelle les définitions qui suivent nous sont propres et découlent directement du cadre des activités de robotique mobile qui nous ont initialement amené à utiliser ce type d'architecture.

Dans le contexte de nos activités, un agent est une entité informatique qui satisfait aux conventions d'une communauté. Un agent remplit ces conditions par la mise à disposition des services qu'il propose, par le fait d'être capable de parler un langage commun et en partageant des fonctionnalités communes aux agents de sa famille. Le but étant de créer une communauté hétérogène d'agents qui vont travailler de concert afin d'accomplir une tâche globale, chaque élément apportant sa contribution propre. L'exemple le plus souvent cité est la colonie de fourmis (chaque fourmi peut être considérée comme un agent), certaines étant de même type (ouvrières, guerrières, nurses, etc.) et travaillant toutes dans un seul et même but: la survie du groupe.

Retour à la table des matières

Besoins et contraintes

Cette section décrit les outils et concepts nécessaires à l'élaboration d'un tel système.

Tout d'abord, il faut un support de communication entre les agents, par exemple de la mémoire partagée, une liaison directe câblée (fil, lien sériel ou parallèle) ou encore une liaison au travers d'un réseau.

Ensuite, il est nécessaire de savoir comment les agents sont reliés: si les membres de la communauté sont liés directement entre eux (système décentralisé), si tous les membres sont connectés à un agent « central téléphonique » qui aiguille les messages en fonction des besoins (système centralisé) ou encore un subtil mélange des deux.

Il faut enfin un langage commun que tous les membres de la colonie soient à même de comprendre, il peut s'agir de simples morceaux de mémoire contenant des structures fixes ou de complexes messages qui doivent passer au travers d'un interpréteur.

Retour à la table des matières

Utilité

Cette technologie a été adoptée par le VRAI Group (Virtual Reality and Active Interfaces) de l'Institut de Microtechnique, dont les activités consistent à concevoir des interfaces de haut niveau dans divers domaines et dans la robotique mobile en particulier. Dans ce cadre précis, cette technologie permet d'atteindre deux buts principaux. Le premier est d'avoir plusieurs utilisateurs distants qui peuvent coopérer (au travers d'interfaces agents) afin de contrôler un robot réel, vu lui aussi comme un agent membre de la communauté. L'extension logique de ce premier pas est d'avoir une communauté de robots-agents hétérogènes contrôlés ou observés par un groupe d'utilisateurs distants.

Un exemple d'architecture de type Agent

Nous utilisons l'Open Agent Architecture'1 (OAA) développée au sein du centre d'intelligence artificielle du Stanford Research Institute (SRI), situé à Menlo Park (CA). Reprenons les point précédemment décrits afin de présenter les spécificités de cet outil.

Retour à la table des matières

Communications à l'aide d'Internet

Ici, le support de communication entre agents est simplement le réseau Internet (liens TCP / IP). L'avantage principal est le grand taux de croissance de ce support. De plus, les plates-formes standard offrent des langages de programmation permettant l'accès à ce média. Il est ainsi possible d'écrire des agents depuis divers langages (Prolog, C, C++, Delphi, Visual Basic ou Java) et sur plusieurs plates-formes (Windows, UNIX, IRIX, LINUX). Un point faible réside dans le fait que ce type de liaison assure qu'un message sera délivré mais ne garantit aucun délai de livraison. Une amélioration possible serait d'utiliser un réseau de type ATM, afin de pouvoir fixer certaines contraintes liées au temps réel.

Retour à la table des matières

Les agents parlent PROLOG

Le langage utilisé par les agents (ICL) est une extension du langage de programmation PROLOG qui permet aisément aux agents de soumettre des requêtes en profitant du naturel, de la simplicité et de la puissance de ce langage informatique. Ainsi, en prenant un programme développé spécifiquement pour accomplir une tâche (par exemple un programme de navigation d'un robot mobile) le concepteur peut aisément le faire devenir membre de la jeune, mais grandissante, famille des agents de l'OAA. En effet, par l'adjonction d'éléments informatiques qui lui permettent de se connecter au travers d'une réseau et de parler l'ICL, un programme peut se métamorphoser en agent, et ainsi offrir ses compétences à d'autres ou demander des services à ses camarades.

Retour à la table des matières

Un agent centralisateur: Le facilitator

Afin d'assurer la bonne cohésion d'un système impliquant plusieurs agents, l'un d'entre eux a une tâche bien spécifique. Il fonctionne comme un central téléphonique, sa mission étant de connaître les agents présents dans l'architecture ainsi que les services qu'ils offrent. Quand un agent rejoint un système, il se connecte au facilitator en lui disant quelles sont les compétences qu'il met à disposition; le centralisateur connaît ainsi, à tout instant, la configuration du système: tel agent est capable de résoudre tel problème. Lorsqu'un agent a besoin d'un service, il soumet sa requête au facilitator qui la fait suivre vers la personne compétente et attend une réponse. Une fois celle-ci reçue, il la communique à l'agent requérant qui, fort de cette information, peut continuer sa tâche. Afin de ne pas surcharger un point central unique, le système est conçu pour supporter une hiérarchie de facilitators interconnectés et qui s'échangent les requêtes des agents qui leur sont attachés. La figure 1 montre un exemple impliquant quatre agents et un facilitator.

Figure 1

Retour à la table des matières

Un exemple d'application

Une tentative heureuse

Pour un laboratoire cherchant à offrir à plusieurs utilisateurs le moyen de contrôler le même robot mobile en temps réel au travers de diverses interfaces, cette architecture s'impose d'elle même. En considérant chaque interface utilisateur et les robots comme des agents, un tel système remplit notre cahier des charges. Il nous a même ouvert des horizons plus vastes, en envisageant plusieurs personnes contrôlant non pas un robot unique mais une équipe de robots interconnectés.

Les agents impliqués

Saphira

Saphira est un logiciel de navigation capable de contrôler des robots allant de l'imposant Flakey, jusqu'au petit Khepera, grâce à un fichier décrivant physiquement le robot à piloter (taille, capteurs, vitesses, etc.). Ce système de navigation permet à un robot d'éviter des obstacles tout en cherchant à remplir une mission simple (aller vers une position donnée, suivre un corridor ou maintenir sa vitesse constante). Un point fort de ce logiciel est d'être capable d'exploiter en permanence les informations issues des capteurs du robot pour les confronter à des données a priori connues de son environnement dans le but de ne pas se perdre (extractions de caractéristiques du milieu comme par exemple des corridors, des portes, etc.).

La base de données agent

Afin de centraliser toutes les informations inhérentes à un tel système (position des divers robots, topographie des lieux, etc.) une base de données agent est utilisée. Elle est accessible par tous les agents impliqués: les robots vont régulièrement y écrire leur position, ainsi les diverses interfaces sont constamment informées quant aux données présentées à l'utilisateur. Dès qu'un robot-agent joint le groupe, il se déclare auprès de la base de données (ce qui provoque son apparition dans les interfaces) et commence à mettre régulièrement sa position à jour permettant ainsi aux opérateurs de suivre en temps réel l'évolution du système.

Retour à la table des matières

Une interface utilisateur

Afin de contrôler et visualiser un tel système, de nouvelles interfaces ont été conçues et d'autres réutilisées en les transformant en agents. Donc, des interfaces hétérogènes de par la plate-forme sur laquelle elles s'exécutent (DOS, Windows, UNIX ou LINUX) et aussi par leur nature (bi-dimensionnelles, type réalité virtuelle ou simple fenêtre texte) permettent en même temps d'accéder à un groupe de robots eux aussi hétérogènes (Khepera, Koala, Pioneer ou Flakey). Le seul point commun de toutes ces entités étant d'être des agents.

Un système simple

Figure 2

La figure 2 montre un système faisant intervenir deux robots différents et deux interfaces hétérogènes. Le logiciel Saphira s'exécute sur des ordinateurs portables physiquement posés sur les dos des robots (un Koala et un Pioneer) qui sont reliés au réseau pas des liens Ethernet sans fil. Une station Sun Sparc 20 supporte le facilitator et la base de données tandis que deux autres stations (une Silicon Graphics sous IRIX et un PC sous LINUX) sont utilisées par deux opérateurs distants. Il est a noter que les deux interfaces sont très différentes: le Remote controller est une simple fenêtre texte affichant la position courante du robot et permettant une télémanipulation directe, tandis que le map manager est un programme plus complexe, offrant une vision graphique (2D) à l'utilisateur qui, muni d'un crayon électronique, peut sélectionner un robot et lui donner des ordres en dessinant directement sur la carte des symboles simples tels que des flèches ou des croix. Ce programme est aussi capable d'extraire des informations topographiques de la base de données (calcul de chemins optimums entre deux positions) afin de générer une séquence de missions simples émise vers le robot.

Retour à la table des matières

Un essai grandeur nature

Le concours

Une application du système présenté fut réalisée dans le cadre d'un concours organisé en août 1996 par l'AAAI>, les règles en étaient les suivantes: un robot doit organiser une conférence entre un directeur et deux professeurs. Pour se faire, il doit quitter le bureau du directeur afin de trouver une salle de conférence libre (grâce une petite caméra embarquée), puis naviguer vers les bureaux des deux professeurs impliqués afin de leur dire (en utilisant un synthétiseur vocal) où et quand la conférence aura lieu, avant de revenir chez le directeur afin de lui notifier le lieu et l'heure de la réunion. Notre architecture correspondait bien à ce cahier des charges: nous avions un robuste logiciel de navigation capable d'utiliser des données a priori connues des lieux (la carte des lieux était distribuée une heure avant le début du concours) pour contrôler nos robots. Nous bénéficiions aussi du map manager capable d'extraire des informations topographiques d'une base de données et de fonctionner comme interface pour l'opérateur.

Nantis d'un système multi-agents, nous avons présenté une équipe de trois robots (Un Koala et deux Pioneers), sous le contrôle d'un unique opérateur capable d'aider les robots en cas de problème. Ayant une communauté de robots, nous pouvions donc aisément paralléliser la tâche: un robot vers chaque salle de conférence, puis une fois la salle disponible trouvée, chaque robot va prévenir la personne la plus proche de lui.

Retour à la table des matières

Réutilisabilité

Pour le concours, un seul programme nouveau a été conçu: un agent chargé de la stratégie. Il représente la pièce faîtière du système en utilisant les autres agents (base de données, map manager et les robots) pour fonctionner comme un chef d'orchestre et envoyer le bon robot, au bon moment vers la bonne position.

Le système complet

Figure 3

La figure 3 montre le système complet. On remarque qu'un autre agent a pu être incorporé sans requérir de longs travaux de développement et d'intégration, c'est le reconnaisseur vocal. L'opérateur pouvait ainsi contrôler les robots et le map manager à la voix avec des commandes simples. Décrivons l'une d'entre elles, l'opérateur dit: robot 2 va vers la pièce numéro 8. Le système de reconnaissance vocale, transcrit mot à mot la phrase prononcée, qui est envoyée à l'agent dit de langage naturel qui lui interprète le sens de la phrase. Il demande ensuite au map manager de calculer le plus court chemin entre le robot 2 et la pièce 8. Ce dernier, trouve le plus court chemin, le convertit en une séquence de missions simples et envoie le tout à l'agent Saphira qui va directement contrôler le robot. Saphira mettant régulièrement (une fois par seconde) la position du robot dans la base de données, l'opérateur voit sur son écran (au travers de l'interface graphique du map manager) le robot évoluer et peut ainsi l'arrêter ou l'aider en cas de problème. Cette architecture s'est montrée payante car, grâce à un gain de temps issu de la parallélisation des tâches, nous avons remporté le concours.

Retour à la table des matières

Conclusion

Résultats actuels

Le système a permis de montrer les avantages, au travers d'activités de robotique mobile, d'une architecture éclatée de type agents. Le premier avantage est la re-utilisabilité, il est en effet possible de faire coexister et coopérer des programmes déjà existants afin d'en tirer les avantages sans avoir à les refaire (système de reconnaissance vocale, logiciel de navigation robotique, base de données, etc.). Le second est l'hétérogénéité des composants impliqués autant au niveau logiciel (plates-formes et langages de programmation différents) que du matériel (les robots collaborant on été développés de chaque côté de l'Atlantique).

Retour à la table des matières

Le futur

Les résultats très encourageants présentés ont soulevé moult problèmes non triviaux qui restent encore à résoudre, tels que la cohérence des informations stockées dans la base de donnée répartie. En effet, imaginons que nous lâchons deux robots dans un monde inconnu afin qu'ils en dressent la carte. Si deux robots voient les même mur physique, ils ne vont certainement pas le situer au même endroit (à cause d'erreurs de positionnement ou de capteurs) et donc le déclarer dans la base de données à deux places différentes. Il faudra donc décider quel robot a raison pour maintenir une certaine cohérence des informations ainsi collectées. Un autre problème est la priorité donnée aux opérateurs: si deux commandes contradictoires sont émises vers un robot, il doit décider laquelle est le plus pertinente.

Tendances

Au sein de notre groupe, nous pensons que cette technologie à un grand avenir. En effet, elle tire profit et regroupe des disciplines variées telles que l'intelligence artificielle, les télécommunications, la robotique mobile ou encore la vision en agissant comme ciment pour l'élaboration de systèmes complexes, et ne semble ainsi pas connaître de limites dans ses champs d'application. Elle nous permet aussi de collaborer activement avec nos partenaires (SRI, NASA, 4thPlanet) par le développement parallèle d'agents qui, une fois mis ensemble, forment un système pluridisciplinaire et complexe.

Alors, à quand votre premier agent ?...

Retour à la table des matières


retour au sommaire du Flash informatique spécial été 97

retour à la page principale des Flash informatique

Vos commentaires

© FI SPECIAL ETE du 2 septembre 1997