Ce projet se situe dans un contexte totalement différent de la médecine. L’intérêt de choisir un cadre totalement différent est double : tout d’abord, cela permet de généraliser la problématique afin d’éviter de trop spécialiser les méthodes recherchées au seul cadre de la médecine.
Ensuite, d’un point de vue pratique, travailler sur une application dont aucune vie ne dépend est sécurisant. Non seulement les données nécessaires peuvent être rassemblées au fur et à mesure de l’apparition des besoins, mais en plus, j’ai pu essayer des méthodes d’apprentissage et de planification sans arrière-pensée. En effet, les seuls risques encourus sont les dégâts matériels infligés au robot.
Dans ce projet, l’objectif est de piloter un robot mobile autonome à travers un environnement structuré, tel que des bureaux. Cet environnement peut être connu à l’avance ou non, selon le problème que l’on désire étudier. De plus, cet environnement peut être dynamique et non contrôlé.
La navigation est une fonction qui permet à un agent mobile de se diriger dans un environnement vers un but défini. C’est donc une méthode utile à la résolution de nombreux autres problèmes. Par exemple, on pourrait imaginer une application de surveillance d’un bâtiment, ou encore la distribution automatisée de courrier. Dans ce dernier cas, il faudra à notre robot se diriger tout d’abord vers la boîte aux lettres, y prélever le courrier et se rendre dans les bureaux de chaque personne devant recevoir l’une de ces lettres.
Il est donc nécessaire de pouvoir préparer un chemin permettant de rejoindre une position précise à partir de n’importe quelle autre position. C’est le rôle du module de navigation d’un robot. La problématique peut être décomposée de façon à isoler des modules plus simples à traiter.
Comme le robot est mobile, il peut occuper différentes positions à divers instants dans l’environnement. Il est alors nécessaire de recourir à une suite de déplacements et d’observations, de façon à déterminer sa position avec le minimum d’incertitude possible. Ces actions destinées à accroître la précision de la localisation peuvent être passives ou actives : le robot peut mener à bien une tâche tout en affinant sa connaissance de sa position. Alternativement, il peut aussi se consacrer à cette localisation et entreprendre les actions qui devraient lui amener un maximum d’informations, quitte à ralentir sa progression vers son but.
Une fois que la position du robot est connue, ou tout du moins, supposée connue, il est nécessaire de planifier la suite d’actions à entreprendre afin de résoudre le but qui lui est fixé. Il peut s’agir de se rendre à un point précis, pour se recharger, par exemple, ou simplement de parcourir la zone régulièrement. La tâche d’un robot aspirateur pourrait être de passer partout, alors qu’un robot de surveillance peut se contenter d’un passager rapide dans chaque salle. Lorsque le plan d’action est connu, il est nécessaire de l’exécuter correctement. Cela peut être très facile si les instructions du plan sont simples et certaines, mais cela peut se compliquer très rapidement dans le cas contraire. Si la localisation du robot est incertaine, le plan peut en tenir compte de façon à assurer une efficacité et une sécurité optimales.
Ainsi, si le robot sait qu’il se trouve au milieu d’un couloir, mais qu’il ignore s’il est dos à un escalier ou si l’espace derrière lui est vide, choisir de reculer peut s’avérer dangereux. Il peut alors être plus rentable pour lui de choisir d’autres actions, comme par exemple de se retourner pour le vérifier.
Si les instructions sont d’un niveau d’abstraction supérieur à ce que sait exécuter le robot, il sera nécessaire de traduire chacune de ces directives en une suite de commandes exécutables directement. Puisque le résultat d’une commande est toujours plus ou moins incertain, il peut être nécessaire de modifier le plan si ce denier n’a pas prévu d’échec ou d’erreur possible. En effet, de nombreux aléas, tels que des imprécisions de vitesse, de position, ou de temps d’exécution, sont susceptibles de perturber chaque commande.
Dans le cas où toutes les hypothèses ont été prévues, et que le plan permet au robot d’atteindre son but quelles que soient les perturbations qu’il reçoit, on parlera d’une politique d’asservissement.
Finalement, si l’environnement est dynamique, il faut que le robot soit capable de s’adapter aux modifications de ce dernier. Par exemple, dans un environnement de bureaux, une porte peut s’ouvrir ou se fermer. Si le robot est incapable d’agir sur une porte fermée pour l'ouvrir, il lui faudra choisir un autre chemin pour arriver au point voulu. De même, les conditions ambiantes peuvent biaiser plus ou moins fortement les capteurs, faussant par ainsi la localisation du robot. Par exemple, les conditions d’éclairage peuvent modifier les caractéristiques d’une image obtenue par une caméra, ou déplacer l’échelle de distances mesurée par un capteur infrarouge.
Afin de pouvoir tester et de mettre en pratique les algorithmes que nous étudions dans le projet MAIA, nous avons conçu et réalisé un robot mobile autonome : Simplet. Je vais résumer rapidement les fonctionnalités disponibles de façon à permettre la mise en évidence de leurs effets sur le module développé. La suivante présente une vue schématique de Simplet montrant l’agencement de ses capteurs et ses effecteurs.
Nous avons conçus ce robot dans l’optique d’en créer une population permettant de tester des algorithmes de coopération multi-agents. Cela impliquait donc une réduction maximale des coûts. Nous avons alors choisi de déporter la puissance de calcul sur des stations de travail et de limiter celle qui est embarquée sur le robot lui-même. Le robot se contentera donc d’exécuter les ordres au fur et à mesure que le logiciel de navigation les lui enverra. L’aspect correspondant aux communications est donc primordial. Afin de permettre une gestion transparente du robot, nous avons conçu le système sous la forme d’un serveur relié à un ou plusieurs robots. Des clients peuvent se connecter à ce serveur à travers une interface réseau TCP standard. La communication se déroule alors en ASCII ; De cette façon, l’implantation du client peut être complètement différente de celle du serveur.
L’inconvénient de cette architecture repose sur la latence qu’elle engendre. Lorsque le robot envoie une lecture de ses capteurs à son client, les informations passent tout d’abord par le serveur. Ce dernier redirige alors ce message vers le client associé à ce robot. Ce client va alors interpréter ces données, et fournir une action que le robot doit exécuter pour atteindre son but. Cet ordre va parcourir le chemin inverse, passant par le serveur avant d’atteindre le robot pour y être exécuté. Chacune de ces transmissions est rapide, mais cette suite de délais peut être gênante dans les cas où une réponse rapide est absolument nécessaire.
La propulsion de Simplet est assurée par deux moteurs pas à pas situés de part et d’autre du robot. Cela permet d’obtenir un mouvement simple et précis, au détriment cependant de la vitesse. La palette de mouvements disponibles inclut donc le déplacement linéaire vers l’avant comme vers l’arrière, la rotation sur place, et le mouvement en arc de cercle. Les moteurs sont commandés en vitesse, mais il est possible de demander un mouvement d’un certain nombre de pas, et donc sur une distance précise. Des mouvements plus compliqués sont possibles, sous reserve d'être en mesure d'envoyer les ordres assez rapidement au robot.
Les capteurs du robot incluent une caméra couleur à transmission HF et une série de 6 capteurs infrarouges. Ces derniers sont placés tout autour du robot, de façon à donner une image de l’environnement immédiat de ce dernier.
La caméra permet d’obtenir une information riche et détaillée, mais elle est limitée à une position fixée à l’avant du robot. Ironiquement, la caméra est peut-être un capteur trop riche pour être utilisable en temps réel sans circuits dédiés à son traitement. Néanmoins, le DEA de Franck Gechter a permis la prise en compte de cette image ŕ travers l'ACP. Cependant, ce capteur n'a pas encore pu être intégré aux traitements, faute de temps pour constituer la base d'images nécessaire.
Les capteurs infrarouges donnent quant à eux une indication sur la proximité des obstacles situés entre 10 centimètres et 80 centimètres. Nos expériences montrent que leur mesure est assez fiable sur des distances allant de 10 à 60 centimètres, sous réserve de ne pas être exposé à la lumière directe du soleil. Au-delà de 60 cm, la réponse des capteurs est soumise à un bruit beaucoup plus important qui rend incertaine leur interprétation. Cette disposition des capteurs donne donc une vue de l’environnement local du robot.
Néanmoins, l’espace environnant le robot n’est pas entièrement couvert, et de gros angles morts sont présents de chaque côté du robot. Cela n’est pas véritablement gênant, puisque le robot ne peut pas se déplacer latéralement. Il faut cependant en tenir compte lors des rotations. De même, aucune mesure n’est disponible à l’arrière du robot. Il est donc préférable d’éviter de reculer, à moins que l’espace ne soit connu par une exploration précédente.
Finalement, des capteurs de contaxt, ou moustaches sont à l’avant du robot, et le protègent d'une éventuelle rencontre avec un mur. Leur activation entraîne en effet un arrêt en urgence du robot, suivi de l'envoi d'une alerte au client distant.
Le module de localisation et de planification situé au sein du robot a été conçu à l'aide de l'interface de création d'agents intelligents que j'ai réalisée durant ma thèse. Il a été conçu sur la même base que les modules des projets médicaux. En voici donc le diagramme correspondant :
En construction...
Page Créée par Laurent JEANPIERRE.
Dernière modification : dimanche 8 février 2004