Il est en bois, rien d’original. Le bois est très simple à usiner avec des outils standards et peu cher : perceuse, scie sauteuse, et papier de verre. J’ai utilisé deux types de bois différents. Du contreplaqué de 8mm comme support, et un autre, plus fin, qui sert habituellement aux fonds de meubles, pour relier les deux planchettes de contreplaqué. Coupé en petite dimensions, ce bois est plutôt rigide.
La structure du robot est en fait organisée en deux étages, chaque étage possède deux « surfaces » pour fixer des composants. La surface inférieure, celle qui se trouve face au sol, supporte les quatre moteurs et les accus du robot (huit accus AA). La face opposée supporte elle une protoboard et la carte Arduino (je reviendrais la dessus plus bas). L’autre étage supporte lui sur sa surface inférieur l’AlixBoard (qui prend toute la place), ainsi que sur sa surface supérieur les capteurs comme le radar, la caméra, le capteur de luminosité etc. Bien sur, les surfaces verticales sont aussi utilisées, pour fixer l’antenne, des boutons, un écran, les capteurs d’obstacle etc. L’alimentation électrique utilise huit accus AA de 1.2V ce qui me donne donc une tension de 9.5V. L’AlixBoard doit être alimentée entre 7 et 20V, donc pas de problèmes avec elle, l’Arduino (et tous les capteurs qui passent par son alimentation) est alimentée par l’USB connecté à l’AlixBoard, donc pas non plus de problème à ce niveau. Les moteurs eux, sont alimentés en 6V, j’ai donc du utiliser un régulateur 7806 pour obtenir cette tension de 6V. Le 7806 supporte une intensité de 1.5A seulement, heureusement, mes moteurs sont bien en dessous de ce seuil avec une consommation de 200mA environ par moteur.Marvin utilise un micro-contrôleur ATmega1280 de la carte Arduino Mega. Ce micro-contrôleur sert pour toutes les opérations bas niveau comme interrogation des capteurs, la gestion des moteurs, et elle possède peu de logique. En fait, la seule opération de décision qu’elle doit faire c’est de stopper les moteurs en cas d’obstacle. Elle gère cette opération elle même car le temps entre la détection de l’obstacle et l’arrêt des moteurs doit être très court.
Sur ce micro-contrôleur est connecté tout une tripotée de capteurs et autre gadgets électroniques : capteur d’obstacle, radar, sonde température, sonde luminosité, écran LCD etc. Ils servent majoritairement à la prise de décision du robot (comme je l’ai dit plus haut). Des codeurs sont aussi installés sur les roues, ils observent les mouvement de la roue pour coder un mouvement. Ces capteurs servent à mesurer la distance parcourue par les moteurs et a les arrêter une fois l’objectif atteint. Tout ceci est géré directement par le micro-contrôleur ainsi les messages à lui envoyer pour faire avancer les moteurs sont du type « avance de 100 unités à la vitesse maximum ».
Le micro-contrôleur contrôle aussi trois servomoteurs. Pour ceux qui ne connaissent pas, un servomoteur est un moteur qui permet d’assurer un mouvement très précis. Il comporte un moteur (logique), un capteur de position du moteur et un jeu d’engrenages pour augmenter le couple du moteur (au détriment de la vitesse donc). Il suffit de donner un ordre au moteur (une position) pour qu’il s’y rende et la maintienne. Si on force, il forcera dans le sens inverse en retour. Ce genre de moteur est très utilisé en modélisme, pour la direction par exemple. Dans mon cas, j’en utilise un pour contrôler l’angle du radar, et deux autres pour la « visée » de la caméra (un pour le pan, l’autre pour le tilt). Le micro-contrôleur est directement interfacé avec l’AlixBoard par USB, et plus précisément du Serial over USB. Le composant intégré à la carte Arduino simule un simple port série. Du coté de l’AlixBoard, qui tourne sous Linux, on a l’impression d’avoir affaire à un simple port série. J’utilise d’ailleurs la bibliothèque pySerial pour communiquer avec le port. J’ai bien sûr dû définir un protocole pour la communication des deux cartes. L’USB étant un protocole fiable, mon protocole ne s’occupe pas du tout de la détection et de la correction d’erreurs. Il est donc extrêmement simple et ne possède que deux (en plus des données) champs : le type de la trame envoyée, et la longueur de ses données. Et éventuellement, un champ data de la taille de la valeur du champ précédant (qui peut être de zéro). Un petit schéma pour mieux se représenter la chose :
Chaque trame est analysée et correspond à un morceau de code en fonction du type. Les données transmissent peuvent être n’importe quoi. Ce morceau de code leur donnent ensuite un sens. Concernant les moteurs, ils sont drivés par une carte a part. Celle-ci communique avec l’Arduino par port Série aussi (le protocole est lui propre à la carte). J’ai choisi d’utiliser un driver tout fait pour éviter les prises de tête « électroniques », ce domaine n’étant pas vraiment ce qu’on pourrait appeler une spécialité pour moi (surtout l’électronique analogique). Il gère donc l’énergie envoyée aux moteurs et permet de moduler leur vitesse.
L’AlixBoard s’occupe de la partie logique du robot. Bon, pour l’instant la logique concise simplement à suivre les ordres de l’utilisateur, mais j’envisage plus tard de faire de la vision par ordinateur. L’AlixBoard gère aussi les communications WiFi qui servent à commander le robot à distance, ainsi que la webcam qui permettra de faire du pilotage en immersion. Elle tourne sous Linux Debian Lenny stocké sur une simple carte compact flash de un giga. On peut accéder au système par SSH pour la configuration et autres tâches de compilation du firmware de l’Arduino, mais toute la partie robotique est gérée par un daemon en Python sobrement appelé « marvind ».
Le daemon fait le pont entre les ordres de l’utilisateur (via WiFi) et la carte Arduino (via l’USB). Il peut aussi faire de la prise de décision. La communication avec le daemon du point de vue de l’utilisateur se fait via un protocole de RPC maison. En fait, j’ai d’abord commencé par définir un protocole de communication très simple (encore une fois) à base de données JSON encapsulées dans du TCP. Une trame de ce protocole ressemble à ceci :
Je pouvais difficilement faire plus simple :-). Cela me permit de converser facilement en communiquant des structures typées complexes. La bibliothèque qui implémente ce protocole s’appelle « zaphod ». Je la releaserais peut être un jour… Au dessus de ça, j’ai créé mon protocole de RPC, « zaphodrpc ». Il permet au serveur de publier des fonctions distantes (je parle bien de fonction, on récupère une valeur de sortie), mais aussi une communication bidirectionnelle d’envoi de notification. Le serveur peut donc « pusher » des informations aux clients connectés (genre, attention, j’ai faillis me manger un mur, mais je me suis arrêté). Je ne détaille pas plus sur ce RPC car même si il est assez simple comparé aux autres, il y a quand même beaucoup à dire la dessus. Reste ensuite le client, je n’ai pas encore décidé ce à quoi il aurait l’air pour le moment. Le projet à pas mal avancé depuis le dernier billet. L’AlixBoard est intégrée, et je suis en train de programmer l’API du robot au travers le RPC. Il manque encore la caméra et beaucoup de code à terminer avant de rendre le robot utilisable, mais ça ne serais tarder… Cela dit, il est déjà capable de fonctionner en autonomie (c-à-d sur batterie) et d’être contrôlé à distance via le WiFi, donc on peut dire que le plus gros est fait :-).