Mise en œuvre d un outil collaboratif pour l exploration d environnements inconnus, par des robots mobiles

Transcription

1 Université de Franche-Comté UFR Sciences et Techniques Master 2 Informatique Systèmes Distribuées et Réseaux Rapport de stage Tuteur : Huah Yong CHAN, Jean-Christophe LAPAYRE Mise en œuvre d un outil collaboratif pour l exploration d environnements inconnus, par des robots mobiles JOSEPH GARNIER Penang, Malaisie, le 12 juin 2012

2 Remerciements J adresse mes remerciements les plus sincères au Dr. Huah Yong CHAN, fondateur du Grid Computing Laboratory, pour son encadrement, ses conseils et son accompagnement tout au long du stage ainsi qu à Bee Hoon GOH qui fût ma collègue de travail durant une partie du stage. Je remercie également M. Jean-Christophe LAPAYRE pour m avoir permis de réaliser ce stage à l étranger. Mes remerciements vont également à toute l équipe du Grid Computing Laboratory grâce à qui mon stage s est déroulé dans un cadre de travail agréable. Concernant la rédaction de mon rapport, je tiens à remercier Mme Colette GAR- NIER pour ses relectures et ses corrections.

3 Table des matières Introduction 2 1 Contexte du stage Penang, Malaisie Le Grid Computing Laboratory erobory Présentation Structure générale Les interactions Exemple avec l aéroport de Kuala Lumpur Problématique Objectifs La plateforme erobory Critique de l existant erobory, un outil collaboratif Définition Participants Architecture Les ordres Les interactions Les contraintes Les algorithmes de robotique Parcours en profondeur Sensor-based Random Tree Method (SRT Method) Multi-SRT (MSRT Method) Multi-SRG (MSRG Method) Le serveur Le noyau Les sous-composants métier du noyau Les interfaces robot et client Les robots LEGO Mindstorms NXT et LeJOS Android Ses caractéristiques Protocole de communication Client-Serveur Serveur-Robot

4 2.6.3 Robot-Serveur Mise en œuvre Protocole de communication Le noyau du serveur La couche Communication La couche Proxy Les commandes Les synchronisations La borne interactive Le robot et l interface JADE L interface JADE Le robot Conclusion 60 Liste des figures 63 Liste des tableaux 64 Bibliographie 65 Index 65 1

5 Introduction Les robots prennent actuellement une place importante dans notre vie, on les trouve dans toutes les entreprises pour accélérer la production ou pour agir là où l homme ne peut travailler à cause du danger, à la maison pour aider à la cuisine et aux tâches ménagères, lors des conflits armés... La robotique mobile est devenue en quelques années une science importante qui ne cesse d évoluer. Les chercheurs parviennent petit à petit à donner à des machines une intelligence artificielle. Cependant pour certaine tâches, comme la surveillance, les robots peuvent être amenés à devoir travailler en groupes à la réalisation d un objectif en commun. Le laboratoire Grid Computing Laboratory de l Universiti Sains Malaysia à Penang, participe à un projet, appelé erobory, visant à créer un grand réseau de robots collaboratifs mobiles. Les robots évoluent dans des environnements mixtes, dispersés géographiquement, appelés PixRob, pouvant se connecter les uns aux autres. Ces environnements mettent à la disposition des acteurs, un ensemble de services offerts par les robots. L architecture générale est sous la forme d une infrastructure en grille capable de supporter cinq domaines : travail collaboratif, technologies de téléprésence, environnement de travail des robots, informatique ubiquitaire et réseaux ad hoc. Afin d étudier tous les aspects de ce projet, il a été divisé en plusieurs parties dont chacune se concentre sur une fonctionnalité spécifique. Le travail décrit dans ce rapport, porte sur l élaboration d un outil collaboratif pour l exploration, par des robots mobiles, d environnements inconnus. Il convient tout d abord de s intéresser au contexte du projet ainsi qu aux problématiques soulevées par le cahier des charges. Ensuite, mettre au point un serveur collaboratif nécessite une étude approfondie, des liens entre les participants, de l ordonnancement des messages, des algorithmes collaboratifs existants et pour finir, des technologies à utiliser. Finalement, il s agira de mettre en œuvre ce qui aura été étudié afin de fournir un outil fonctionnel au laboratoire. 2

6 Chapitre 1 Contexte du stage 1.1 Penang, Malaisie La Malaisie, en malais Malaysia, est un pays d Asie du Sud-Est, constitué de la Malaisie péninsulaire ou Malaisie occidentale (péninsule Malaise) et de la Malaisie orientale (nord de Bornéo). Elle est située à environ 200 km au nord de l équateur. Sa capitale est Kuala Lumpur et sa superficie est égale à km 2. Le pays, fédération de seize États et trois districts fédéraux, est membre du Commonwealth britannique. Il est aussi une monarchie constitutionnelle avec un roi élu pour 5 ans parmi les sultans de la Malaisie Occidentale. Le sous-sol (or, fer, bauxite) plus le gaz et le pétrole off-shore (côté oriental) sont, avec le bois et le caoutchouc, les principales ressources du pays. Figure 1.1 Localisation de la Malaisie Le pays compte, en 2010, environ 26.5 millions d habitants. Le nom de "Malaisie" vient de "Malais", qui désigne le groupe ethnique majoritaire (62%) du pays pratiquant l islam d obédience sunnite. Les Malais ne sont pas les uniques citoyens de la fédération. Il y a environ 25% de Malaisiens d origine chinoise et 10% d origine 3

7 indienne. La communauté chinoise, quant à elle, pratique un mélange de christianisme, de bouddhisme, de taoïsme et de culte des ancêtres. Les Indiens sont, pour la plupart hindous. On trouve aussi des chrétiens et des animistes, principalement au Sarawak et au Sabah. 1.2 Le Grid Computing Laboratory Le stage a été effectué au sein du département informatique de l Universiti Sains Malaysia et plus précisément dans le Grid Computing Laboratory. Le laboratoire a été créé de manière officieuse en 2001 par le Dr. FAZILAH et le Dr. CHAN. Il est né d une volonté d être à la pointe du calcul sur grille ainsi que celle de populariser les possibilités des grilles. Le laboratoire travaille notamment sur le projet erobory (Collaborative Explorer Robots Platform for remote Reality Discovery). 1.3 erobory Présentation Le projet erobory fait suite à plusieurs travaux de recherches élaborés et approuvés par le biais de la thèse soutenue par Nabil ELMARZOUQI, et de plusieurs publications internationales, sur les systèmes distribués, les réseaux ainsi que les grilles informatiques, issues de deux laboratoires de recherche : LIFC (Laboratoire d Informatique de l Université de Franche-Comté) en France et le GCL (Grid Computing Laboratory), en Malaisie. Le but du projet consiste en un réseau de ressources diverses, permettant à des utilisateurs de travailler de manière collaborative dans un monde non pas virtuel mais réel. erobory combine les travaux de recherche et les technologies fournis par quatre principaux domaines : les grilles de calcul, l informatique ubiquitaire, les environnements de travail collaboratif et les technologies de télé-présence [6]. 4

8 Figure 1.2 Les quatre principales approches de erobory Comme le montre la figure 1.2, le projet vise à fournir une norme portant sur les environnements de robots mixtes basés sur un service de grille, et un middleware permettant le travail collaboratif des robots semi-autonomes, couplés aux technologies de télé-présence (capteurs principalement). Les infrastructures en grille sont formées d une structure complexe de plusieurs ressources disponibles dans un réseau. Les grilles de calcul doivent supporter l organisation complexe du monde des robot afin d en assurer une accessibilité maximal et un accès constants aux services Structure générale 5

9 Figure 1.3 erobory : futur réseau mondial de PixRob - Zoom sur la Malaisie Le projet erobory [6] envisage la création d un grand réseau de robots ubiquitaires collaboratifs, composé d environnements dispersés géographiquement, appelés PixRob (Pervasive mixed reality environment of ROBot), capables de se connecter les uns aux autres. Ces environnements sont mis à la disposition de groupes de travail formés par un ou plusieurs robots pouvant être utilisés par un acteur externe : virtuel ou humain via une borne interactive. L architecture d un environnement PixRob offre une multitude de services (détection d objet par les robots, de lumière,...) aux acteurs, et un accès immédiat au monde réel exploré par les robots au travers d un monde virtuel. Les services proviennent majoritairement des robots par le biais de leurs capteurs et caméras. Plus exactement, ils sont fourni en temps réel ou non, par le noyau de la plateforme de l environnement, qui a la capacité de tirer pleinement parti des propriétés de l informatique ubiquitaire. L ensemble des environnements PixRob est géré par une infrastructure de grilles de calcul 1, qui permet de coordonner les robots ainsi que de mettre à disposition des services. L architecture générale est sous la forme d une infrastructure en grille 2 capable de supporter cinq domaines : travail collaboratif, technologies de télé-présence, environnement de travail des robots, informatique ubiquitaire et réseaux ad hoc. 1. infrastructure virtuelle constituée d un ensemble de calculateur reliés par un réseau et permettant de faire du calcul distribué. 2. infrastructure virtuelle constituée d un ensemble de ressources informatiques potentiellement partagées, distribuées, hétérogènes, délocalisées et autonomes. 6

10 Figure 1.4 Infrastructure en grille de la plateforme du projet erobory PixRob représente l environnement à distance [6], dans lequel les robots sont déployés, basé sur une réalité mixte formée d une part par le monde physique, composé et exploré par les robots, et d autre part par le monde virtuel, composé par la vision qu ont ces derniers sur l environnement réel. Le monde virtuel comprend les entités du monde physique numérisées ainsi qu une carte d exploration virtuelle de la vision local propre à chaque robot. D une manière plus formelle, PixRob peut être décomposé en quatre éléments principaux : (1) RW (Real World), (2) VW (Virtual World), (3) VR (Virtual Robot), et (4) RD (Robot Device). 7

11 Figure 1.5 Composants principaux de PixRob Tous les composants sont reliés entre eux et communiquent les uns avec les autres. Le composant RW fait le lien entre l environnement PixRob et le monde réel. Le plus souvent il prend la forme de capteurs (ultrasons, caméras,...) gérés par le robot. Il est couplé à un monde virtuel VW qui est le monde réel simulé par un ordinateur. VW est représenté par une carte virtuelle qui contient des objets virtuels. Le rassemblement de VW et RW donne la réalité mixte. VR est un composant conçu pour fonctionner indépendamment de tout dispositif, environnement de travail ou périphérique réseau. Il est capable de réaliser un travail en collaboratif et d être connecté à n importe quel autre VR à travers le réseau. Cet élément est incorporé dans le composant RD qui lui est le robot réel exécutant les tâches demandées dans l environnement réel Les interactions Un robot est amené à accomplir un certain nombre de tâches qui peuvent être ordonnées par un autre robot ou par un utilisateur. Par conséquent, le noyau de l environnement PixRob est capable de fournir une interface interactive pour les utilisateurs humains et des fonctions logiques pour les autres entités afin de diriger et de réaliser les tâches réclamées. Les fonctions sont gérées par la Runtime Machine (Machine d Exécution) intégrée à l environnement PixRob. Deux types d acteurs sont autorisés à utiliser et à contrôler les différents environnements ubiquitaires : les robots et les humains. Cela donne lieu à deux grands types d interactions : implicites et explicites. 8

12 Figure 1.6 Les interactions implicites et explicites d erobory Différents niveaux d interactions sont impliqués pour réaliser le travail collaboratif au sein de l environnement pervasif [6] : robot-robot, environnement-robot, robot-humain et humain-humain. Un utilisateur peut soumettre des tâches à des services, via l interface distante, qui seront traitées par la grille qui choisira alors, la machine la plus appropriée pour la mener à bien. Les calculs des tâches soumises se font de manière transparente. erobory offre, en réalité, trois possibilités d environnement de travail : (1) espace de travail local, (2) espace de travail télécommandé et (3) espace de travail collaboratif Exemple avec l aéroport de Kuala Lumpur La plateforme erobory a pour but d être déployée dans des environnements extérieurs et intérieurs. Le premier lieu choisi est l aéroport de Kuala Lumpur. C est un espace, relativement grand, qui reste difficile à couvrir et à surveiller en raison du passage important de personnes. Les aéroports sont soumis à des règles de sécurité strictes concernant les passagers, les simples visiteurs ou encore les bagages dont le contrôle par les autorités augmente les temps d attente d embarquement. L utilisation de robots permettrait de contrôler très rapidement les bagages portés par les passagers, dans l enceinte de l aéroport, mais aussi de détecter les objets suspects. 9

13 Figure 1.7 AirPixRob, environnement PixRob La plateforme erobory permettrait de résoudre la plupart des problèmes de sécurité. Un environnement PixRob (appelé AirPixRobs) couvrirait tous les étages du bâtiment avec des robots équipés de détecteurs d explosifs (par exemple) et de caméras. 1.4 Problématique Le projet n étant qu au stade de l étude, plusieurs prototypes indépendants ont été développées où chacun se concentre sur une petite partie de la plateforme erobory. Le travail réalisé durant le stage concerne la "réalisation d objectifs communs par un ou plusieurs robots de manière collaborative en environnement intérieur". Deux types d acteurs sont supportés : les clients (humains et informatiques) et les robots. Actuellement ces derniers sont de type LEGO Mindstorm et ne sont pas 10

14 autonomes. Ils sont contrôlables à distance uniquement par liaison bluetooth, dont la portée varie de 3 à 5 mètres, au travers une API 3 fournie par la société LEGO. D autre part, les robots ne sont pas équipés de GPS qui permettraient de les localiser afin de cartographier l environnement ou de les guider lors de l accomplissement de leurs missions. De surcroît, l alimentation électrique du robot est fournie par une batterie dont la durée de vie est limitée. Chacun des éléments consomme de l énergie, mais les communications sont les plus gourmandes, il faut donc les limiter. En outre, les acteurs ne communiquent pas entre eux directement, un serveur y est interposé. Le nombre de participants ne peut pas être connu précisément à l avance, comment faire en sorte que le serveur puisse supporter plusieurs communications simultanées? Un système collaboratif de robot moderne ne peut se permettre de ne gérer qu un seul type de robot, en l occurrence LEGO Mindstorm. De ce fait comment se dissocier, lors du développement, des techniques de communication employées et du type de robot utilisé? Ce principe vaut aussi pour les utilisateurs via leurs interfaces de connexions. Ainsi, la plateforme doit gérer l hétérogénéité des participants. Finalement, les algorithmes utilisés pour un travail mono robot ne sont pas les mêmes que pour un travail collaboratif car il faut partager les temps de travail (équité) et la carte à explorer en plusieurs zones. De surcroît, la déconnexion d un robot pendant l exécution d un algorithme ne doit pas perturber l ensemble du système. 1.5 Objectifs Dans la suite du rapport, le nom erobory ne désignera plus le projet présenté dans la partie 1.3 mais le prototype développé durant le stage. L objectif principal du projet est de développer un serveur collaboratif auquel pourront se connecter des clients et des robots. Le serveur peut être comparé au noyau de la plateforme d un environnement PixRob. Les environnements explorés ne contiendront que des objets statiques. Les robots devront être capables de réaliser des tâches de façon collaborative ou autonome par le biais du serveur. Ils pourront supporter les communications en mode asynchrone dans le cas d une rupture de lien entre eux et le serveur. Leur puissance de calcul et l autonomie des batteries étant réduites, il convient de réaliser un maximum de traitements sur le serveur en veillant toutefois à ne pas multiplier les communications, ceci dans un souci de conservation de l énergie restante. Ce participant proposera des services de détections au serveur et aura la charge de maintenir à jour une carte virtuelle et locale de son environnement. Les clients pourront envoyer des ordres au serveur et en retour, ils seront avertis de chaque modification apportée à la carte. Ces ordres pourront être simples (avancer, reculer,...) ou complexes (rechercher une balle rouge dans la pièce,...). Le serveur jouera le rôle de coordinateur de robots et maintiendra une synchronisation régulière entre les participants. Il devra également tenir à jour une carte de l environnement exploré par l ensemble des robots. Il sera commandé par des 3. une interface de programmation est une interface fournie par un programme informatique. Elle permet l interaction des programmes les uns avec les autres, de manière analogue à une interface homme-machine, qui rend possible l interaction entre un homme et une machine. 11

15 clients mais pourra recevoir des ordres des robots pour l exécution de traitements "lourds". Les techniques de développement employées ne doivent pas être liées aux technologies utilisées pour les clients et les robots ; le couplage entre les clients et le serveur ainsi qu entre les robots et le serveur doit être faible. On doit pouvoir à tout moment être capable d utiliser un autre type de robot que LEGO Mindstorm. C est pourquoi le serveur devra disposer d "interfaces", ou "portes d entrées", auxquels se connecteront les participants. En définitive, afin de pouvoir tester les algorithmes collaboratifs mis en place, il est intéressant de disposer d un émulateur de robot capable d exécuter des algorithmes, sans se soucier de problèmes matériels qui pourraient survenir. C est pourquoi un tel outil doit être intégré au sein de erobory. 12

16 Chapitre 2 La plateforme erobory 2.1 Critique de l existant Un outil a été développé, en Java, par une employée du laboratoire, afin de commander les robots à distance, de manière direct, sans serveur, à l aide d une interface graphique. Les robots n étant pas équipés de caméras, pour "visualiser" l environnement, une tablette tactile avec un système Android embarqué a été placée entre le client et le robot. L application Android reçoit les ordres du client et les transmet au robot à l aide de la bibliothèque de la société LEGO conçue à cet effet. Les communications entre le client et la tablette se font en wifi alors que les communications entre la tablette et le robot sont en bluetooth. Une première idée a été de transformer le client en serveur pour l adapter aux besoins. Cependant après plusieurs modifications et quelques semaines de travail, il s est avéré que ce prototype souffrait d un gros manque de souplesse dans son architecture (chaque modification était contraignante à mettre en place) et d un couplage très fort entre le client et le robot. Une modification sur le client entrainait une modification sur le robot et inversement. De même, modifier le type de robot ou supprimer la tablette entrainait des changements importants sur le client. Par ailleurs, le client et le serveur étaient fusionnés ce qui, empêchait d atteindre un des objectifs fixés qui est d avoir une séparation et une indépendance du serveur vis-à-vis des clients et des robots. 13

17 Figure 2.1 Architecture de l existant. Les technologies montrées ici seront détaillées dans la suite du rapport. A la suite de ces constats, un outil complètement nouveau a été pensé et développé après une analyse poussée des besoins en tenant compte des objectifs et des contraintes que ces derniers impliquent. Le premier prototype aura servi tout d abord, à la découverte des outils et au développement des commandes simples du robot, puis à la mise en avant des contraintes posées par les objectifs du projet. A savoir : couplage lié aux technologies employées architecture du client/serveur nécessité de développer un protocole de communication séparation de manière efficace des différents participants un serveur robuste et fiable capable de traiter efficacement les nombreuses requêtes des clients et des robots Pour finir, cet ébauche a montré, d une part la lourdeur de l application Android développée pour la tablette tactile et d autre part les erreurs de mouvements des robots liées à la bibliothèque utilisée. Le travail mené durant le stage a été focalisé sur la création d un nouveau serveur, d un client puis, d une nouvelle application Android de commande des robots. 14

18 2.2 erobory, un outil collaboratif Définition Les environnements collaboratifs existent sous une multitude de formes et son composés d un ensemble d outils collaboratifs. Ils peuvent être de simples outils web pour le travail collaboratif, des plateformes de réseaux sociaux, des sites communautaires, des systèmes de gestion de versions, des environnements de jeu multijoueurs, ou même des mondes virtuels. Un exemple connu est Google Apps, qui offre entre autre des outils pour la gestion de mail, l édition de documents, la planification de tâches,... Les caractéristiques communes à ces systèmes sont : plusieurs personnes peuvent travailler en leur sein à la fois, les utilisateurs peuvent laisser une trace de leur travail et ils peuvent aider les autres utilisateurs à partir de n importe quel endroit, à n importe quel moment. Tout ceci dans le but de réaliser un travail et/ou un objectif commun. Figure 2.2 Définition de la collaboration On peut considérer la collaboration comme l intrication de trois processus complexes [12], distincts dans leur finalité respective mais interdépendants : Le premier processus de base, celui sans lequel les deux autres ne peuvent s effectuer, est la communication. Il permet les interactions entre individus (acteurs/sujets). Le deuxième processus, rendu possible par la communication, est la coopération. Il permet le partage et la mutualisation des ressources utiles pour la coaction (action à plusieurs, action collective qui ne repose pas nécessaire- 15

19 ment sur un objectif unique et partagé). L exemple type est la communication/coopération. Le troisième processus, optimisé et rendu possible par la communication et la coopération, est la coordination. Il permet la synchronisation des acteurs et des actions en interdépendance dans le cadre d un processus de travail. Autrement dit, dans le cadre d une activité collective et conjointe. Contrairement à la coopération, la coordination repose nécessairement sur un objectif unique et partagé. L exemple type est la communication/coopération/coordination que l on retrouve dans une équipe de projet. Un outil collaboratif impose un certain nombre de contraintes liées : au mode de communication, (réseau filaire ou aérien dont dépend le débit), à l ordonnancement des requêtes et réponses des participants, au partage des ressources et accès concurrents, à la synchronisation des informations en veillant à ce que les acteurs et les sujets disposent en permanence des données les plus récentes. Depuis quelques années, les terminaux fixes et mobiles se sont considérablement développés, par conséquent, un outil collaboratif doit s adapter à cette hétérogénéité. Pour finir, certain systèmes dit "critiques", où la vie des personnes est en jeux, embarque des mécanismes de tolérance aux pannes afin de prévenir et agir contre toute défaillance matérielle ou logiciel. erobory se définit comme un outil collaboratif. Il est composé d acteurs, appelés "client", et de sujets appelés "robot". Les clients envoient des ordres au serveur qui les diffuse aux robots (processus 1). Cet outil permet le partage des ressources matérialisées par les robots ainsi que l accès aux services offerts par le serveur (processus 2). Enfin les robots sont capables de réaliser des objectifs en coopération sans que les clients aient besoin d intervenir (processus 3). Chacune des contraintes qu impose la nature de cet outil ont été prises en compte, mise à part la tolérance aux pannes qui n est pas justifiée. Figure 2.3 Les participants sont hétérogènes 16

20 2.2.2 Participants L outil développé comprend un ensemble de trois participants, à savoir un serveur, des clients et des robots couplés éventuellement à des tablettes tactiles Android. Le serveur : élément centrale de l application, il a la charge d assurer le lien entre les acteurs et les sujets. Les autres participants s y connectent en utilisant les "interfaces" ou "portes d entrée" proposées, afin de faire partie de l outil collaboratif. Robuste et fiable, il est capable d ordonnancer les communications synchrones et asynchrones tout comme de traiter les demandes des clients et des robots. Il maintient à jours la liste des participants connectés ainsi qu une carte virtuelle de l environnement réel dans lequel évoluent les robots. Lors de ces opérations, les clients sont avertis en temps réel des changements. De plus, il propose un ensemble de service, comme le traitement d image, dont chacun peu user pour mener à bien les tâches à accomplir. Le dernier point concerne l efficacité du traitement des communications. Le nombre de collaborant peut être élevé, plusieurs centaines, impliquant un risque de latence au niveau de l exécution des requêtes. Hors, les serveurs de calcul sont pourvus d une architecture multi-coeur. Un microprocesseur multi-cœur est un processeur possédant plusieurs cœurs physiques (ou unités de calcul) qui travaillent en parallèle. Le serveur d erobory exploite pleinement cette technologie afin de diminuer les temps de traitements des opérations. Figure 2.4 Différence entre un processeur mono-coeur et multi-coeurs Le client : participant (humain ou non) de l outil collaboratif, il est l unique initiateur des ordres envoyés au serveur et indirectement aux robots. Avant toute opération, il se connecte au serveur, via une interface, pour récupérer en retour, la liste des robots connectés et la carte virtuelle de l environnement d exploration dont il est capable de suivre en temps réel l évolution. Il reçoit des notifications lorsque d autres clients envoient des ordres au serveur. 17

21 Le robot : participant de l outil collaboratif, il est commandé, après connexion au serveur, indirectement par les clients et exécute les ordres qu il reçoit. Il est le seul à avoir une vue direct sur l environnement réel et à interagir avec lui au moyen d appareils mesurant la distance, la lumière, les ondes sonores,.. Il met à jour une carte locale de son environnement, dont lui seul à connaissance, qu il envoie régulièrement au serveur. Il est aussi capable de connaitre sa position exacte à tout instant. Les robots utilisés lors des tests ne sont pas pourvus de caméra, indispensable à la reconnaissance des objets, et ne sont capables de communiquer qu à l aide de la technologie bluetooth. Si bien, qu ils ont chacun été couplés à une tablette tactile afin d utiliser la webcam, positionnée devant le robot et sa technologie wifi. Ainsi donc, elle sert de relais entre le robot et le serveur Architecture L architecture générale de erobory est représentée sur le schéma suivant : Figure 2.5 Architecture générale de erobory Au centre se trouve le serveur, entouré par des clients quelconques et des robots. Chacun des participants se connecte via les interfaces mises à disposition, ici RMI, HTTP et la Borne Interactive pour les clients ainsi que SSH et HTTP pour les robots Les ordres Un ordre est défini comme étant une commande que peut envoyer un participant, en cliquant sur un bouton principalement. Leur nombre est très limité par rapport 18

22 aux communications qu ils engendrent. Dans la version de base de erobory il est prévu que seul le client puisse initier et envoyer des commandes. Elles sont de deux types : simples ou complexes. Par commandes simples on entend : avancer, reculer, tourner à gauche, tourner à droit un robot. Quant aux commandes complexes, elles sont un enchainement de commandes simples et exécutent les algorithmes coopératifs ou mono robot. Par défaut il en existe quatre : chercher une balle rouge avec un robot, chercher une balle rouge avec tout les robots, chercher une balle bleue avec un robot, chercher une balle bleue avec tout les robots. La création d autres commandes complexes est cependant possible et permet de réaliser n importe quel objectif dans la mesure des capacités des robots. Les résultats des interactions sont visibles sur la carte virtuelle du client ou par le biais de boites de dialogues Les interactions Les interactions sont définies comme étant les actions internes à un système pouvant être déclenchées par des acteurs externes (humains ou non). Elles sont représentées par des diagrammes de cas d utilisation. Figure 2.6 Les interactions du client Avant de pouvoir faire quoi que ce soit, le client doit au préalable se connecter au serveur. Après ça, il sera capable de récupérer la carte virtuelle ainsi que la liste des robots connectés au serveur dont il pourra faire usage en utilisant les commandes simples et complexes. Seul un utilisateur humain manipule le client. 19