Simplet est un robot expérimental que nous avons développé entièrement. En effet, les problèmes de maintenance que nous avons eu avec des robots commercialisés nous ont encouragés à en maîtriser tous les aspects. Ce travail a été majoritairement conduit par Franck Gechter, Alain Dutech et moi-même, mais d’autres membres de l’équipe ont pu apporter leur touche personnelle à diverses étapes du développement. Ci-dessous se trouvent deux photographies de Simplet, prises à un an d’intervalle.
Ce robot mobile a été conçu originellement dans l’optique de mettre en œuvre des systèmes multi-agents hétérogènes. Cet objectif a conditionné une grande partie du développement. En majorité, ces contraintes ont porté sur la généralisation de l’architecture, ainsi que sur la réduction des coûts.
Le robot a été conçu autour du bus I²C, inventé par la société Philips. Ce bus, constitué de seulement deux fils, permet en effet de faire communiquer des plateformes hétérogènes avec peu de soucis de synchronisation. C’est à la base un système centralisé, dans lequel un maître peut interroger à volonté chacun de ses esclaves. Il est donc très modulaire, puisque la seule interface nécessaire est un bus de deux fils.
Afin de pouvoir disposer d’une puissance de calcul suffisante, et dans le but de rendre le système le plus générique possible, nous avons décidé de déporter tous les algorithmes en dehors du robot. Pour cela, une transmission radio relie chaque robot à un ou plusieurs postes qui peuvent les commander. La tâche de chaque robot se réduit donc à récupérer les données de ses capteurs, les envoyer au serveur distant, et exécuter les ordres transmis par ce dernier.
Les postes communicant avec les robots peuvent être autonomes, ou être reliés à un réseau. Dans ce dernier cas, ils peuvent accepter des connexions sur le réseau et servir de relais. Cette architecture permet en effet à un client situé sur une machine quelconque du réseau de piloter n’importe quel robot. Le client n’a aucune contrainte tant qu’il respecte le protocole de discussion avec le serveur. Ainsi, un client utilisant le langage C sous Solaris peut travailler avec les capteurs et les effecteurs d’un robot donné sans se soucier des modalités techniques sous-jacentes, même si le serveur est écrit en Java sous Windows et que le robot est un système propriétaire écrit en langage d’assemblage.
Avec cette optique de commande déportée, il est donc très facile de mettre en œuvre un algorithme. Cependant, chacun de nos robots est doté d’une caméra. L’avantage de ce capteur est sa richesse. Son inconvénient tient dans la taille des données fournies. En effet, chaque image correspond à un grand nombre de pixels, et de nombreuses images sont transmises chaque seconde. Pour palier à ces inconvénients, nous avons doté chaque robot d’un système de transmission indépendant, afin de ne pas surcharger le canal partagé sur lequel les robots communiquent. Ce système est commercial, et chaque caméra émet sur un canal de la bande de fréquences allant de 1285 à 1340 MHz. Le récepteur est alors branché sur une carte d’acquisition vidéo standard, et le flux d’images est mis à disposition sur le réseau. Pour limiter le débit sur ce dernier, il est possible d’extraire et d’envoyer des informations pertinentes en lieu et place des images brutes. Des travaux sont en cours à ce sujet.
Le robot est construit sur la base d’un microcontrôleur embarqué de référence P51XAS3. Cette puce, de marque Philips, est dérivée du processeur 8051 inventé par Intel, mais revue et améliorée. Voici rapidement ses caractéristiques :
La carte que j’ai conçue autour de ce processeur utilise 16 des lignes d’adressage pour alimenter 32Ko de mémoire vive additionnelle et 16Ko de mémoire morte. Ces 16Ko permettent de stocker largement le code nécessaire au fonctionnement du robot. Cela inclut aussi bien la configuration des divers modules du robot que la communication avec le poste serveur. Cette communication, à travers un port série RS232 standard, permet par ailleurs de télécharger des modules additionnels permettant de gérer diverses fonctions.
Le chien de garde est une sécurité qui assure que le robot reste sous contrôle. En d’autres termes, si le robot perd le contact avec le serveur distant pendant plus de deux secondes, il se réinitialise et s’arrête d’urgence. Ce protocole garantit donc que le client garde le contrôle absolu sur le robot tout au long de l’expérience.
La communication est basée sur un principe inspiré des trames Ethernet. Actuellement, le processeur communique avec un PC portable que le robot transporte. Ce PC héberge un serveur qui relaie les informations sur un réseau sans fil compatible avec celui équipant le laboratoire. Cette solution temporaire permet au robot d’évoluer librement presque dans tout le bâtiment.
Une fois que nous avons retiré toutes les broches nécessaires au fonctionnement de fonctions déjà citées, il reste donc 20 lignes d’entrées-sorties configurables à volonté. Le premier prototype utilise 8 de ces broches pour commander les moteurs, et 9 pour interroger les divers capteurs. Les versions suivantes seront plus modulaires, en délégant au moins les fonctions motrices à une carte spécialisée.
L’autonomie électrique du robot est assurée par trois batteries indépendantes : un bloc standard, issu des modèles réduits, alimente le processeur et les moteurs. Un bloc est réservé pour la caméra et son transmetteur, et le portable dispose de sa batterie personnelle. Cette configuration permet au robot de fonctionner pendant 2 heures, au-delà desquelles le portable doit être rechargé.
La partie motrice de Simplet est constituée de deux moteurs pas à pas situés de chaque côté du robot. La stabilité est assurée par deux paires de roues libres situées à l’avant et à l’arrière du robot. Cette configuration lui permet donc de se déplacer en ligne droite, de tourner sur place, ou de se déplacer en arc de cercle. Néanmoins, cela nécessite une grande force de la part des moteurs. Cela explique pourquoi la structure du robot a été modifiée cette année. En effet, les moteurs sont suffisamment robustes pour faire avancer Simplet en ligne droite, mais les virages entraînent des frottements importants. C’est pourquoi la première version tournait difficilement sur une table, et était incapable de tourner sur la moquette.
La deuxième coque a donc été usinée par Matthieu Menard à partir de matériaux de récupération qui semblaient moins lourds que le métal de la première version. Cette nouvelle coque dispose de la place suffisante pour intégrer un réducteur à courroies qui démultiplie par trois la puissance des moteurs.
En définitive, Simplet dispose donc d’une propulsion d’une grande précision, capable de déplacer le robot à une vitesse raisonnable (20 cm/s). Néanmoins, puisque toutes les commandes sont envoyées par le processeur lui-même, en plus de la gestion des communications et des capteurs, la vitesse n’est pas très stable. En particulier, on observe que le robot zigzague légèrement lorsqu’il avance. En effet, la vitesse des moteurs est régie par la fréquence des impulsions envoyées à ces derniers. Il arrive alors que le processeur soit occupé à une autre tâche au moment d’envoyer cette impulsion. Cette dernière va donc être envoyée avec un peu de retard, ce qui va réduire localement la vitesse du moteur. Il est fort probable que le fait de déporter cette tâche hors du processeur permettra d’améliorer la qualité de ces signaux, et donc du mouvement. En attendant, cet aléa est très largement compensé par les modèles de décision markoviens que nous utilisons ; cela n’empêche donc pas le robot de fonctionner.
Outre la caméra, Simplet dispose de capteurs de proximité et de capteurs de contact. Ces derniers sont situés à l’avant du robot, et déclenchent un comportement réflexe lorsqu’ils sont activés. Par sécurité, ces capteurs permettent de détecter cet obstacle à 10 cm du robot. En effet, si le robot avance et que les moustaches détectent un obstacle, il y a un fort risque de collision imminente. A ce moment, le robot stoppe brutalement et effectue une marche arrière sur environ 5 cm. Vu la faible vitesse du robot, ces mesures devraient suffire à empêcher Simplet de heurter un mur.
Les capteurs de proximités sont des GP2D02 de marque Sharp. Ils permettent de mesurer avec une grande précision des distances comprises entre 10 et 70 centimètres. Au dehors de cette plage, la précision de la mesure dépend fortement de chaque capteur. D’après leur documentation technique, la mesure est basée sur l’angle entre un rayon infrarouge envoyé par le capteur et le rayon réfléchi par l’obstacle. L’expérience montre une bonne stabilité, avec toutefois quelques mesures aberrantes. La mesure est également assez robuste vis-à-vis de la lumière ambiante, à l’exception du rayonnement solaire direct.
En définitive, ces capteurs semblent largement suffisants pour permettre une navigation locale du robot. Cependant, pour se repérer dans un environnement de grande taille, ils sont clairement insuffisants.
Afin de parfaire notre robot, de nombreuses extensions sont prévues, voire en cours d’étude ou de réalisation.
Au niveau de la communication avec le serveur, nous travaillons actuellement avec un portable et une liaison Ethernet sans fil. Pour remplacer cette connexion, j’étudie une transmission RS232 par ondes radio. Nous projetons d’utiliser la bande de fréquences située autour de 433,92 MHz. En effet, cette plage est disponible sans nécessiter de licence particulière, sous réserve de limiter la puissance d’émission. De nombreux modules existent, et particulièrement chez Radiometrix. Le débit attendu est de 40 kilobits par seconde, ce qui nous permettrait de créer une liaison à 19200 bauds avec un codage Manchester. Cependant, la portée reste très en deçà de nos espérances.
Au niveau de la propulsion, j’ai déjà parlé d’un module de commande de moteurs pas à pas autonome, commandé par I²C. Un autre module a été réalisé par des étudiants dans le cadre d’un stage. Ce module devait nous permettre de commander des moteurs à courant continu, mais le travail n’a pas été terminé dans les temps. Eric Lucchese travaille actuellement à finir cette carte et à la monter sur un autre robot. Finalement, un troisième module est en cours de conception. Ce dernier vise au pilotage des servomoteurs de notre robot hexapode. Cette commande est plus ardue, car la position absolue de chaque moteur est commandée par une largeur d’impulsion bien définie. Il faut donc assurer une stabilité parfaite de cette impulsion, et ce pour les 12 moteurs nécessaires à déplacer Atchoum.
Au niveau des capteurs, Eric Lucchese travaille sur un SIC. Ce module est un système de cartographie utilisant un balayage laser. Il est trop lourd pour pouvoir être embarqué sur nos robots, mais pourra facilement équiper Gaston, un robot de taille plus imposante, ou le Cycab, voiture électrique développée par l’INRIA. J’ai travaillé pour ma part sur un capteur d’accélération, mais les résultats étaient trop bruités pour être utilisables rapidement. J’envisage l’emploi d’un montage intégrateur pour passer d’une mesure instantanée à une mesure sur une période plus longue. Ainsi, on devrait pouvoir éliminer les vibrations, accélérations fortes mais brèves, des accélérations dues au mouvement du robot.
Page Créée par Laurent JEANPIERRE.
Dernière modification : mardi 5 octobre 2004