- Titre du projet
- Eurobot06 : Couche Haute
- École
- HE-ARC ingénierie informatique
- Chef de projet
- Matthieu Amiguet
- Date
- 20 janvier 2006
- Candidat
- Batiste Bieler
- Julien Senn
- Numéro du projet
- i05d19
This project relates to the creation and the simulation of the artificial intelligence of a robot for the Eurobot06 competition. The challenges of this project were the real time systems, industrial vision, and team work. We have created an AI, an environnement simulator and an 3D display program of the environnement.
Ce projet porte sur la création et la simulation de l'intelligence artificielle d'un robot devant participer à la compétition Eurobot06. Les défis de ce projet furent les systèmes temps réel, la vision industrielle, et le travail en équipe. Nous avons donc créé une IA, un simulateur de l'environnement du robot et un afficheur 3D pour de cette environnement de simulation.
Le but du projet est de concevoir et d'implémenter l'intelligence artificielle d'un robot qui va défendre les couleurs de notre école lors du concours Eurobot 06
Le but du concours sera de faire jouer les robots au golf. Notre robot doit être capable de prendre des balles et les mettre dans les trous correspondant à sa couleur (bleu ou rouge)
Cette intelligence représente la couche haute de l'architecture informatique qui est divisée en trois parties distinctes
Pour un projet de cette importance, avec autant d'intervenant et de corps de métier différent, il était nécessaire d'avoir des séances d'information afin de constater l'avancement de chacune des parties. Pour qu’elles soient utiles ces séances ont pris trois formes :
Les informaticiens de ce projet ont utilisé un système de communication Wikiafin de centraliser les informations concernant le développement.
La solution a été de créé une architecture de décision dynamique grâce à un système d'arbitrage. Cet arbitre choisi le meilleur objectif en fonction de différentes variables.
Cette architecture nous permet d'ajouter ou de supprimer un comportement stratégique au robot. Un tel comportement doit fournir un lot de commande (un objectif) à envoyer au robot et une série de variables qui indiquent les avantages à suivre cet objectif. L'arbitre choisi ensuite dans la liste des objectifs envoyés par les différentes stratégies et choisi le meilleur selon ce qui est important à ce moment précis.
Deuxièmement, afin de pouvoir tester l'effet de nos commandes, il était indispensable de créer un simulateur des couches inférieures. C'est pourquoi nous avons développé un simulateur complet et un afficheur qui permet de d'avoir un retour visuel très précis de l'environnement.
Finalement nous avons améliorés le comportement général du robot en lui ajoutant une mémoire du monde alentour. Cette mémoire est importante car la fréquence à laquelle les informations nous parviennent est relativement lente. Elle nous permet de savoir où se trouvent les objets du monde qui ne sont pas vus et cela même lors du déplacement de la machine.
Nous avons créé un système de prise de décision flexible et autonome qui se base sur une représentation du monde. Pour arriver à ce résultat, nous avons créé les outils de débogage nécessaires : Un simulateur des couches inférieurs et un afficheur 3D.
L'intégration avec la couche intermédiaire à l'aide de l'interface définie en début de projet s'est faite sans problèmes. Les délais ont été respectés et les tests concluants.
Il reste du travail dans l'intégration avec le robot final. Nous avons commenté notre code au mieux et réalisé ce rapport dans le but de faciliter la compréhension de notre système aux futurs ingénieurs qui poursuivront notre travail.
L'analyse du projet a consisté à prendre plusieurs décisions importantes. Nous avons pris le temps d'envisager les alternatives et de d'agir en connaissances de cause. La plupart de nos choix nous ont été dictés par les limitations logicielles rencontrées et par les connaissances et les informations que nous avions en début de projet.
Le but du projet est de concevoir et d'implanter la couche haute (CH), partie intelligente de l'architecture du robot.
Le langage, l'environnement et la plateforme sont à choisir dans l'optique d'une architecture robuste et adaptative :
Les interactions de la couche haute avec les autres éléments doivent être clairement définies et testées de manière approfondie. L'utilisation des outils suivants, que nous ne connaissions pas, sont venus s'ajouter à notre cahier des charges :
Au début du projet, un choix important est survenu. Fallait-il utiliser un système en temps réel ou pas ?
L'expérience en ce domaine des collaborateurs de Saint-Imier, qui ont participé à Eurobot 05, nous a influencé. En effet, l'année passée, le club a opté pour un système en temps réel sous Linux. Ayant perdu du temps à cause de ce choix, ils nous ont conseillé d'éviter la véritable programmation temps réel.
L'expérience a montré que le temps réel n'est pas une priorité pour la conduite de l'intelligence artificiel du robot.
Les informaticiens de ce projet avaient des connaissances théoriques sur les problèmes de la concurrence. Nous
avons du les mettre quelque peu à jour pour les utiliser dans le cadre du langage Java. Nous avons surtout
utilisé le modificateur synchronized. Nous avions donc besoin de mettre à jour nos connaissances
dans ce domaine car elles étaient insuffisantes.
En ce qui concerne notre couche, nous avons limité l'utilisation des threadcar nous n'en avions besoin que d'une seule.
Par contre, nous en avons utilisé plusieurs dans le simulateur pour les déplacements du robot.
L'utilisation des thread ne nous a pas posé de problèmes particuliers.
Afin de pouvoir réunir la couche haute et la couche basse à la fin du projet, il était nécessaire de définir une interface de communication. Plusieurs solutions étaient possibles. Elles étaient liées au type d'architecture logiciel que nous allions choisir :
La première direction du projet était de créer deux processus indépendants. Il a donc été nécessaire d'étudier cette communication. On distingue plusieurs types de communication interprocessus :
L'intérêt d'avoir plusieurs processus est de pouvoir utiliser des langages différents dans chaque processus sans aucun problème particulier. De plus les processus étant autonomes, ils peuvent être développés facilement dans des bases de code séparées.
Il existe plusieurs solutions standard de communication interprocessus. La plus simple et la plus efficace est celle des tubes nommés. Un tube est un fichier mémoire qui simule une pile FIFO (First In First Out).
Un tube est aussi un canal de communication unidirectionnel. D'un coté du tube on écrit les informations et de l'autre on attend de lire une certaine quantité d'informations. Pour créer une communication bidirectionnel, il faut donc deux tubes nommés.
La lecture dans un tube est bloquante. Le processus qui désire lire une information dans le tube doit donc attendre que l'information soit réellement écrite. Ce mécanisme d'attente permet de facilement réaliser des mécanismes de synchronisation en plus de l'échange des données.
Selon nous, cette solution aurait été viable et efficace si le choix avait été de réaliser un système multi-processus.
La principale limitation des tubes c'est que les processus doivent tourner sur la même machine. Les sockets offrent une abstraction pour la communication interprocessus via le réseau. Cette communication est bidirectionnel et synchrone. Les sockets ont tout de même un temps de latence plus élevé.
La solution finalement retenue dans ce projet fut de créer un programme monolithique
en Java utilisant les thread. La communication se faisant via une interface implantant
les mécanismes de synchronisation nécessaires. Cette solution est
similaire à celle des tubes nommés. Avec le modificateur synchronizedde Java la plupart des problèmes
de synchronisation sont très simples à résoudre.
À l'origine, nous pensions faire un système sur Linux avec plusieurs processus, mais finalement c'est le système Miscrosoft Windows et le langage Java qui a été retenu. Le logiciel devait être programmé d'un seul bloc en Java avec des thread pour gérer les problèmes de concurrence.
Linux a été rejeté car les bibliothèques de vision crées par LabView ne semblent pas compatibles.
De plus avec certains périphériques (bus CAN, webcam), il était délicat de savoir sans expérience si le matériel est véritablement fonctionnel avec les pilotes de périphériques Linux. Une plus grande expérience en amont du projet serait utile pour savoir si les pilotes Linux sont viables sur ce point.
Linux n'est toutefois pas à exclure des prochains projets si une bibliothèque de vision portable et efficace pouvait être utilisée.
Python a été proposé comme langage de programmation du projet. Python est un langage qui amène des avantages syntaxiques par rapport au langage Java et des structures de données plus puissantes. Il est prouvé que le langage Python permet de produire un logiciel avec moins de lignes de codes que le langage Java. Ceci permet de gagner du temps et de la lisibilité dans le code.
Python aurait demandé un apprentissage pour certains intervenants du projet. Java étant déjà bien maîtrisé par la plupart, nous avons décidé que cela était un avantage suffisant. Les questions de performances sont également en faveur de Java (Jython serait une solution). Rétrospectivement, nous avons constaté que les considérations de performances sont assez peu importante par rapport à ce que demande la partie d'analyse d'image du logiciel. En effet cette partie d'analyse consomme 80% du temps processeur alors que notre IA n'en consomme que 5% maximum.
Java a été également jugé plus utile pour les années futures, car il n'est pas prévu pour l'instant d'enseigner le langage Python dans l'école. Comme Java est plus connu dans le monde du travail que Python, il serait donc plus vendeur pour un futur poste.
À ce stade de l'analyse nous ne savions pas encore quelle serait la forme finale du robot. Certaines fonctionnalités ne seront peut être pas disponible dans le robot final. Voici une petite liste des fonctionnalités évoquées :
Dans cette optique, nous avons du nous concentrer sur les composants dont nous étions sûr de disposer. Nous avons choisi de nous concentrer sur les caméras car c'est avec elles que nous pouvions réaliser un travail intéressant au niveau de l'IA.
Nous avons identifié plusieurs points essentiels que nous devrons respecter afin de pouvoir fournir une IA fiable :
Un des grands besoin de l'intelligence artificielle est quelle puisse s'adapter au différents cas de figures et éventuellement aux pannes qui pourraient survenir durant le jeu. Pour ce faire, nous avons identifié des stratégies de déplacement qui utilisent différentes parties du robot :
Ainsi, si l'une des parties matérielle tombe en panne, il reste d'autres stratégies capables de fournir un objectif. La plupart de ces stratégies utilise la représentation du monde. Pour quelle soit efficace, il faut que l'odométrie fonctionne. Les moteurs et l'odométrie sont des composants indispensables.
Le processus d'analyse s'est déroulé bien en amont de la première ligne de code. Nous avons eu le temps de discuter les différents choix avec les différents intervenants informatique.
En ce qui concerne la couche haute, le choix du langage Java ne nous a posé aucun véritable problème. l'IDE Eclipse nous a certainement permit de gagner du temps. Subversion est un excellent outil pour le travail en équipe.
Dans un premier temps, nous avons pensé a un objet de prise de décision qui créait un objectif (suite de commande) en se basant sur une représentation du monde
Dans un second temps, l'arbitre choisissait une stratégie (action à exécuter) et cette stratégie créait un objectif avec un lot de commande.
Nous avons commencé l'implémentation à partie de ce dernier diagramme. La forme finale du logiciel est relativement semblable. Il y a déjà les trois packages principaux, l'idée des objectifs et des stratégies. Par contre la représentation du monde avait été momentanément abandonnée car jugée trop complexe. Comme il nous restait suffisament de temps nous avons eu le loisir d'implémenter cette partie pour créer des stratégies de haut niveau.
Afin d'unifier les traitements entre les couches, nous avons créé une structure de données nommée ObjectPositionqui permet
de considérer les objets du terrain de jeu comme des spécialisations de cet Objet (trous, balles, totems, adversaire).
Cet objet contient tous les attributs nécessaires à chaque type d'objet. Il permet également au deux couches de travailler
ensemble sans se soucier de la valeur des différents paramètres car ceux-ci sont définis une fois pour toute dans la classe.
Pour pouvoir communiquer entre la couche haute et la couche intermédiaire, une interface a été implémentée. Cette interface représente les éléments du robot : les commandes déplacement, les caméras (lointaine et proche), les IRs, le magasin, le retour du déplacement...
Deux classes d'interface ont été implémentées, une pour les interactions avec la CI et une pour le simulateur des couches inférieures.
D'autres classes apparaissent dans cette interface, ces classes servent de structure d'échange de données entre la CH et la CI.
Ces classes s'appellent ObjectIR pour les informations des infrarouges, ObjectMove pour les informations
de déplacement, ObjectStore pour les informations du magasin, ObjectViewFront pour les informations
de la caméra champ lointain et ObjectViewLower pour les informations de la caméra champ proche. Ces classes possèdent toutes une
fonction statique de copie synchronisée. Quand cette fonction est appelée dans une instance de classe, les autres
instances doivent attendre la fin de la copie pour pouvoir entrer dans la fonction de copie. Cela garanti qu'une copie sera toujours cohérente
car la copie d'un objet de données est atomique.
Nous avons utilisé le mots clé synchronized pour résoudre nos problèmes.
Ce mot clé permet de contrôler l'accès aux fonctions d'un objet ou à l'objet dans sa globalité.
Par exemple, lorsqu'une threadveut exécuter une méthode d'instance portant le modificateur
synchronized, Java verrouille l'instance de classe. Si une autre Thread invoque une méthode
synchronisée sur ce même objet, elle sera bloquée tant que le verrou ne sera pas levé, c'est à dire quand
la première fonction aura terminé son travail.
De la même façon, si une Thread veut exécuter une méthode de
classe static portant le modificateur synchronized, Java pose un verrou empêchant
un autre Thread de solliciter une méthode synchronisée de la même classe. C'est cette méthode
que nous avons utilisée pour réaliser la copie de nos objets de données entre les deux couches.
La décomposition des classes ce fait entre trois différent packages:
Manager : Prise de décision ;Strategy : Les stratégies ;Command : Les commandes.Le packages Manager regroupe les classes d'arbitrages et la représentation du monde.
LayerHigh est la classe de lancement de la couche haute,
c'est elle qui lance le début du jeux et le mécanisme d'arbitrage. Elle la classe racine du projet, elle contient
toute les autres classes.
C'est cette classe qui contient le mécanisme d'arbitrage. Cette classe est une Thread qui va devoir tourner pendant toute la durée du jeu. Elle va déterminer si il est nécessaire de changer de stratégie, de lancer une nouvelle commande, ou d'attendre la fin de l'exécution d'une tâche.
Dans cette classe se trouve une copie de tous les objets présent dans l'interface, elle permet d'économiser des copies inutils et de garantir la cohérence des informations pendant tout un cycle de l'IA.
Orders est la classe de gestion des objectifs, les objectifs sont des suites de commandes qui doivent
s'exécuter consécutivement. L'exécution d'une commande doit attendre la fin de la précédante avant de pouvoir être exécutée
. C'est le rôle de la classe Manager de contôler le bon fonctionnement de ce processus.
Dans cette classe se trouve des outils de géométries simple comme le théorème de pythagore et les matrices de rotations.
Nous utilisons principalement ces fonctions dans la classe WorldMemory. La plupart des fonctions foncionne directement
avec des ObjectPosition en entrée.
C'est cette classe permet d'évaluer un objectif en fonction de différents critères (nombre de balles mises, avantage positionnel, etc).
Manager l'utilise afin de différencier les différents objectif possibles et de choisir le meilleur.
WorldMemory contient la représentation du monde : la positions des trous, des balles, des totems, etc.
Elle offre également des filtres qui permettent de sélectionner uniquement des éléments valides ou qui se trouve dans une certaine trajectoire. Elle mémorise également l'emplacement des totems, qui sont considérés comme des obstacles. Cette classe est en fait le point névralgique de l'intelligence du robot. Sans elle le robot se bornerait à utiliser ce qu'il voit dans l'immédiat, c'est à dire pas grand chose.
Si un objet considéré comme un obstacle (dans cet exemple un totem), est présent sur la trajectoire du robot, on ne peut pas se diriger vers la cible. Cette cible est donc considérée comme non atteingnable.
La zone sensible dans la mémoire à été implémentée selon la première méthode. les obstables sont détéctés par une suite de cercle. Cette méthode appromimative fonctionnant très bien dans nos tests nous avons jugés qu'il n'était pas nécessaire d'implémenter la deuxième méthode qui est plus correcte et qui, à notre avis, consomerait moins de ressources processeurs.
Le packagesStrategycontient toutes les stratégies que nous avons implémenté,
une stratégie sert à créer un lot de commandes
en fonction de l'état du jeu. Les stratégies utilisent le plus souvent les filtres et les informations
disponibles dans WorldMemory.
Strategy est une classe abstraite de stratégie. Toutes les statégies dérive de cette classe.
Stratégie d'évitement utilisant le capteur infrarouge arrière. Quand le capteur atteint une limite inférieur à une certaine valeur, un évitement est commandé. Il s'agit d'un avancement de 10 cm.
Stratégie d'évitement utilisant le capteur infrarouge arrière. Quand le capteur atteint une limite inférieur à une certaine valeur, un évitement est commandé. Il s'agit d'un recul de 15 cm.
Stratégie d'évitement qui provoque une rotation de coté en fonction des capteurs latéraux. Il s'agit d'une rotation de + ou - 60°.
Cette stratégie d'approche se rend vers le premier trou adversaire en mémoire.
Cette stratégie d'approche se rend vers le premier trou adversaire visible.
Cette stratégie ramasse la première balle en mémoire.
Cette stratégie ramasse de manière optimise les premières balles. Elle prend toutes les balles qui sont sur la même trajectoire.
Cette stratégie ramasse la première balle visible.
StGoBetterPosition se déplace vers un des point stratégique définit faute de mieux. Mais ces points sont enregistrés en absolu sur
le terrain donc en cas de dérive grave du robot ces points ne seront pas atteints.
Cette stratégie d'approche se rend vers le premier trou ami en mémoire.
Cette stratégie d'approche se rend vers le premier trou ami visible.
StGoStraight permet au robot de se placer jusqu'au milieu du jeu.
Cette stratégie ne doit être utilisé qu'en cas de problème grave pour passer la première ligne.
Stratégie de recherche d'informations. Le robot fait un tour sur soi pour voir des balles ou des trous.
Cette stratégie permet de mettre une balle noire dans un trou ennemi si il est visible dans la caméra champ proche.
Cette stratégie permet de mettre une balle blanche dans un trou ami s'il est visible dans la caméra champ proche.
Le package Command rassemble toutes les commandes à donner au robot(déplacement, mettre une balle, etc).
Classe abstraite de commande. Toutes les commandes dérive de cette classe.
Cette commande nettoie complètement la mémoire. Elle utilise pour cela une méthode de WorldMemory.
Elle pourrait être utilisée après un contact par exemple.
Commande de mise d'une balle dans un trou.
Commande de rotation selon un angle.
Commande de déplacement en ligne droite sur une distance donnée.
Le mécanisme d'arbitrage est implémenté dans les classes Arbitre et StrategyEvaluator.
La classe Arbitre va parcourir toutes les stratégies à la recherche de celle qui a le plus de poids et parallèlement StrategyEvaluator va attribuer un poids a chaque stratégie.
Toutes les stratégies ont des paramètres qui vont influencer sur l'intérêt à suivre cet objectif : nombre de balles mettables dans des trous, nombre de balles attrapables, temps d'exécution, déplacement avec avantage de positionnement.
De son côte StrategyEvaluator va multiplier ces paramètre en fonction critère : nombre de balles déjà attrapées, temps de jeu restant,... pour avoir une valeur de poids la plus plausible possible.
Ensuite l'arbitre va simplement sélectionner la stratégie avec le plus d'intérêt sauf en cas de contact où là seules les stratégies d'évitement seront considérées. Dans ce cas le mécanisme de sélection sera utilisé.
Les stratégies ont été pensées par couche. Les stratégies les plus simples (ne nécessitant ni caméra, ni capteur) ont été implémentées au début. Ceci afin de ne pas oublier que de nombreux imprévus peuvent survenir pendant le concours et qu'il est important que le robot réagisse si l'un des composants matériel tombait en panne.
StGoStraight (ne nécessite aucun périphérique)(peu d'intérêt).
StLookAround (nécessite les IR mais fonctionne sans) ;StGoBetterPosition (nécessite l'odométrie).StGoBallMemory (nécessite une représentation du monde évolué) ;StGoHoleMemory (nécessite une représentation du monde évolué) ;StGoAdvHoleMemory (nécessite une représentation du monde évolué) ;StGoBallOptimizedMemory (nécessite une représentation du monde évolué).StGoBallView (nécessite la webcam champ lointain) ;StGoHoleView (nécessite la webcam champ lointain) ;StGoAdvHoleView (nécessite la webcam champ lointain) ;StPutBlackBall (nécessite la webcam champ proche) ;StPutWhiteBall (nécessite la webcam champ proche).StEscBehindIR (nécessite les IR) ;StEscFrontIR (nécessite les IR) ;StEscSideIR (nécessite les IR).La simulation de la couche haute c'est découper en deux parties distinctes, la simulation de la couche intermediaire en Java et un afficheur en OpenGl.
Créer un simulateur s'est révélé un choix très judicieux car comprendre le comportement du robot sans retour visuel est laborieux voir impossible. Le simulateur nous a permis de détecter une multitude de comportement non désiré qu'il aurait été très difficile à prévoir. Notamment les problèmes de boucle où le robot répète inlassablement la même action annulée par un contact.
De plus, il a été nécessaire de créer une autre couche intermédiaire pour le simulateur. En effet, le but du simulateur étant de voir les actions de la couche haute, il était nécessaire de simuler complètement une couche intermédiaire.
La simulation de la couche intermédiaire pour l'afficheur graphique se trouve dans le package simulateur. Dans ce package se trouvent plusieurs classes :
Simu et RobotDisplayThread) ;
InitGl) ;
LayerIntermediaryMove, LayerIntermediaryRotate et LayerIntermediaryPutBall) ;
tableDisplay et tableDisplayJNI).
Après la réalisation du simulateur, il nous fallait pouvoir afficher l'état du monde tel qu'il était dans le simulateur. Pour cela nous avons créé un petit logiciel qui nous permet de visionner et de guider le robot adverse sur la table de jeu.
L'afficheur a été réalisé avec la technologie graphique OpenGL et a été lié au simulateur Java grâce à un connecteur JNI (Java Native Interface). SWIG (Simplified Wrapper and Interface Generator) a été utilisé dans cette optique.
Le projet OpenGl est intègré au projet Java bien que seul la dll est utilisée, il est situé dans le dossier afficheur_simulateur. Pour créer cet afficheur, nous avons utiliser le caneva standard d'inforgraphie utilisé lors des cours de M.Chatelain en 3e année.
Ce projet comporte les bibliothèques de fonctions suivantes:
displayTable.c qui contient les fonctions d'entrée/sortie de la dll ;displayTable_wrap.c qui permet d'utiliser les fonctions de displayTable.cen Java ;geometrie.c qui contient les fonctions de dessins de l'afficheur ;calllistes.c qui contient le model des trous rouges et bleus ;event.c qui contient la gestion des évenements ;global.c qui contient les variables globales au projet.Première idée idée préalable pour un filtre au niveau de la représentation du monde :
Pour gérer les imprécisions de la vue et la dérives de l'odométrie, nous avons utilisé des filtres qui mettent la mémoire à jour intelligement. Quand un trou est vu, on compare sa position à à ceux de la mémoire. Si l'un d'eux correspond à notre trou, c'est à dire qu'il se trouve dans périmètre relativement réduit, l'information est mise à jour dans la mémoire. Si ce n'est pas le cas, c'est qu'il s'agit d'un trou jamais observé. Un nouveau trou est alors créé dans la mémoire.
Cette méthode fonctionne bien en simulation. Nous n'avons pas encore testé cet algorithme en situtation réel et notamment avec un taux de rafraichissement de la vue réaliste. Il serait intéressant de simuler cela pour voir si ça fonctionne toujours.
Il existe une méthode intéressante pour découvrir l'environnement matériel du robot, il s'agit de la méthode par nuage de points. On pourrait utiliser les capteurs infra-rouge afin de connaître un maximum de points de contact avec les murs. Ces points devraient être enregistré dans une représentation du monde. Pour que cette méthode soit fiable il faut que le robot sache avec une certaine précision ou il se trouve dans l'air de jeu. Si on ajoute un temps de vie aux points de contacts, on peut tolérer une certaine dérive du positionnement ce qui arrive quand on utilise les moteurs et l'odométrie.
Un autre algorithme de positionnement a été étudié, il s'agissait de détecter deux totems et en sachant leurs positions, de recalibrer notre position sur le terrain. Le principal problème de ce concept est que la position des totems doit être connue très précisément alors que la caméra champ lointain ne peut pas avoir une précision suffisante. De plus il y a toujours une ambiguïté suivant l'orientation du robot et depuis quelle position le robot voit les totems.
Le principal problème lors de la conception était le manque d'informations précises sur le robot final :
Il est évident que nous aurions pu mieux planifier et organiser notre travail si les composants matériels étaient déjà décidé depuis le début, car nous sommes souvent parti sur des pistes que nous avons du abandonner en cours de route.
SLe positionnement du robot a posé beaucoup de problème. À l'origine, un positionnement absolu était envisagé, plusieurs pistes ont été étudiées :
Ces recherches n'ont pas abouties, ces technologies auraient coûtés trop chère ou n'étaient pas assez précises.
Finalement la position du robot sera donnée par les moteurs grâce à l'odométrie : Tous les déplacements des moteurs sont enregistrés et permettent de positionner le robot.
Cette méthode peut être efficace mais il faut gérer une certaine dérive du système. En effet les glissements sont inévitables et il est donc impossible de savoir avec précision ou se trouve le robot après quelque déplacements. En donnant un temps de vie aux informations de positions des différents objets vus, on peut résoudre ce problème.
La partie intelligente de notre logiciel se situe dans le package Manager. C'est la que toutes les décisions sont prisent.
Manager va évaluer toutes les stratégies et sélectionner si la stratégie à suivre est une stratégie d'évitement ou pas ;StrategyEvaluator va donner l'intérêt à suivre cet objectif pour chaque stratégie ;WorldMemory reçoit et filtre toutes les informations qui parviennent au robot. C'est la qu'est implémentée la représentation du monde ;Orders est le conteneur des lots de commande.
Le mécanisme d'arbitrage a été une des choses les plus complexes à implémenter. Il était important de faire une architecture souple qui permette de changer d'objectif si il y en avait un autre meilleur ou si un obstacle survenait.
Ensuite c'est la méthode d'affectation du meilleur objectif qu'il a fallut implémentée. Le but étant de donner la priorité aux stratégies d'évitement en cas de contact.
Ces problèmes ont été résolus en considérant d'abord toutes les stratégies d'évitement. Si l'une de ces stratégies peut s'appliquer, alors les autres stratégies ne sont pas considérées.
Nous sommes tombés souvent sur un problème connu en robotique : Les boucles.
Une boucle est une succession de deux ou plusieurs ordres contradictoires, le robot va alors alterner entre ces ordres et se mettre dans un état de boucle récurrente d'où il ne peut plus sortir.
Les causes d'une boucle sont parfois difficiles à déterminer, il est donc difficile de corriger ce genre d'erreur.
Un exemple de boucle est apparut quand il a été question de diviser l'approche d'un trou en deux phases : Un premier déplacement et ensuite un recalibrage avec la camera champ proche pour avoir suffisament de précision. Le robot étant à proximitée du point d'approche, mais pas exactement au bon endroit, il préférait effectuer une correction minime pour se rapprocher de ce point plutôt que de finir le mouvement jusqu'au trou pour mettre la balle.
Nous avons donc désactivé l'interêt de réaliser une très petite correction sur les points d'approches car elle ne serait pas utile.
Nous avons trouvé une solution efficace pour éviter toutes boucles : Désactiver la cible dans la mémoire s'il y a une répétition ou s'il y a une annulation par un contact.
La réalisation s'est déroulée sans problème. Nous conseillons à ceux qui travaillent à niveau de l'IA de ne prêter aucune attention à l'optimisation de leur code. Il faut privilégier la lisibilité à la rapidité. Il est toujours possible d'optimiser par la suite, mais rendre le code plus lisible est autrement plus délicat.
Le goulet d'étranglement en terme de performance ne venait pas notre partie mais de l'analyse d'images de la couche intermèdiaire. C'est cette partie qu'il faudrait améliorer car elle consomme plus de 80% des ressources matérielles.
Nous avons identifié certaines parties du logiciel qui pourraient être améliorées facilement :
L'organisation et l'utilisation des outils appropriés au travail en équipe furent des points intéressant du projet. Nous devions faire en sorte que le travail des informaticiens se rejoingne vers la fin du projet. Pour cela de nombreuses sessions de communication ont été organisées. Ce fut l'occasion d'apprendre comment réaliser un compte rendu de l'avancement de notre travail.
Durant ce projet, nous avons appris à utiliser l'environnement de développement Eclipse. Ce logiciel est un logiciel libre avec des fonctions avancées qui facilitent le développement des applications Java. La compilation se fait en tâche de fond, il offre des fonctionnalités qui permettent de contrôler la syntaxe en cours de rédaction et son architecture à base de plugin est efficace. Mention spéciale au plugin Subcilpse qui permet à Eclipse de fonctionner merveilleusement avec le gestionnaire de version Subversion.
Nous avons également abordé les problèmes de la programmation concurrente en Java via l'utilisation des thread. La gestion de la concurrence apparaît entre les couches, ce qui impliquait une excellente communication entre les intervenants.