La valise de TaxiBot

La valise de TaxiBot a plusieurs fonctions :

• servir d’interface utilisateur
• contenir la Raspberry Pi qui est le centre de contrôle du dispositif, ainsi que ses accessoires
• servir à ranger et transporter le matériel en toute sécurité, ce qui est la fonction première de toute valise  🙂

Principe de fonctionnement

Comme indiqué dans la présentation, l’objectif de base de TaxiBot est de permettre aux utilisateurs de programmer les déplacements d’un robot, mais sans toucher à aucun dispositif numérique que ce soit, c’est à dire clavier, souris, tablette ou écran tactile et consorts.

En lieu et place de ces objets high-tech, on utilise de simples cartes sur lesquelles figurent les symboles graphiques représentant les actions possibles.

Aucune électronique, aucun tag RFID ou autre derrière tout cela, rien que du carton (récupéré sur des calendriers muraux) et du papier imprimé et collé dessus.

La magie est assurée par une caméra (une simple Raspi Cam, modèle de base), installée sur un bras qui se déplie au-dessus du plateau de "programmation" :

Le plateau est pris en photo, l’image est ensuite traitée à l’aide d’OpenCV de manière à identifier les symboles utilisés et leur disposition et les convertir en séquence de déplacement du robot si le programme est valide.

Cette séquence est ensuite communiquée au robot par radio et celui-ci l’exécute de manière autonome sur la piste.

L’interface utilisateur pour l’animation

Si les apprenti(e)s informaticien(ne)s n’utilisent aucune interface numérique, il y en a quand même une pour l’animateur, afin qu’il puisse déclencher le processus d’analyse du programme, et également expliquer au public les différentes étapes du traitement d’image.

Cette interface utilisateur est une application Web, dont le serveur n’est autre que la Raspberry Pi elle-même. L’animateur s’y connecte avec un simple ordinateur portable et accède à l’interface via son navigateur Internet.

Into the Rabbit Hole

Pour s’acquitter de ses tâches, la Raspberry Pi utilise la version "Lite" de Raspbian (aka Raspberry Pi OS), étant donné qu’elle fonctionne en mode serveur et que nous n’avons besoin ni du bureau graphique ni de toutes les applications installées par défaut.

L’application Web qui assure les fonctions d’interface utilisateur pour l’animateur, mais aussi de traitement d’image et de communication avec le robot, est développé intégralement en Python (3.7), épaulé par les librairies suivantes :

• OpenCV qu’on ne présente plus pour le traitement d’image
• Tornado, un serveur HTTP extrêmement performant et léger

La partie front-end de l’interface utilisateur est propulsée par du Javascript avec un zeste de jQuery, le look-and-feel étant basé sur Bootstrap.

Et c’est tout. Rien d’autre si ce n’est du jus de cerveau.

Concernant le serveur Web, je me suis fait un petit plaisir en jouant avec les Web sockets pour avoir un feedback en temps réel des messages de progression envoyés par le robot et de l’état de ses capteurs. Tornado gère cela parfaitement et sans douleur.

Pour ce qui est du traitement d’image, il fait l’objet d’un article dédié.

Au niveau système

Le démonstrateur devant se mettre en route tout seul à la mise sous tension, le serveur applicatif est installé sous forme de service systemd. Grâce à cela, il est démarré automatiquement lors du boot de la machine.

Pour ce qui est du shutdown, il se fait pour le moment via connexion ssh et saisie de la commande manuellement. J’avais bien pensé ajouter le dispositif hardware avec bouton poussoir utilisé sur d’autres démonstrateurs, mais il sera plus simple ici d’intégrer la commande dans l’interface utilisateur, dans une page dédiée aux fonctions utilitaires, éventuellement avec protection d’accès pour éviter que des petits plaisantins ne s’amusent à éteindre le dispositif profitant que nous avons le dos tourné 😉. Ce sera fait pour la prochaine mise à jour du logiciel.

Quelques commentaires

D’aucuns pourraient faire la remarque que jQuery c’est has-been de nos jours, mais :

• ça ne l’était pas tant que cela à l’époque de la réalisation de TaxiBot
• je n’avais alors pas encore fait la connaissance de VueJS et consorts
• même si j’aime beaucoup VueJS maintenant, je ne suis pas certain qu’il aurait eu une réelle valeur ajoutée au regard du poids qu’il représente

Car il ne faut pas oublier une chose : TaxiBot ne doit dépendre d’aucune connexion Internet et a donc la contrainte de servir toutes les ressources statiques nécessaires.

Je sais que des esprits chagrins vont critiquer le choix de Python, qu’ils considèrent comme lent. A ces mauvaises langues je rétorquerai que :

• une des forces de Python est de disposer d’un écosystème immense, et qu’il y a toutes les librairies qu’il faut pour s’occuper des traitements exigeants en puissance de calcul, librairies qui sont écrites de manière optimisée en C/C++ par des développeurs extrêmement affûtés. Si on considère l’équation sous cet angle et qu’on utilise le bon outil au bon endroit, une solution Python n’est pas si lente qu’ils le disent. La preuve : il ne faut pas plus d’une fraction de seconde depuis le moment où on déclenche la prise de vue jusqu’à celui où les commandes partent vers le robot, feedback sur l’interface Web comprise.
• une autre de ses forces est de permettre d’écrire du code concis et lisible, ce qu’on ne peut pas vraiment mettre au crédit de Javascript par exemple (et je sais de quoi je parle vu que le front-end de TaxiBot est écrit en Javascript)
• et de toute manière, c’est mon choix et c’est comme ça 😄

Le code source

Tout est disponible sur GitLab : https://gitlab.com/tileprog/webui

A noter que le projet porte le nom que je lui avais donné au départ, mais qui est moins vendeur que TaxiBot 😉

La réalisation

Tout a été conçu pour être reproductible à très peu de frais et sans outillage complexe.

Hormis la valise (qu’on peut trouver pour moins de 20 Euros dans les GSB [1] habituelles) et les éléments électroniques (Raspberry Pi et consorts), le reste des fournitures est principalement :

• du carton fort, tel que celui des calendriers muraux (faites comme moi le tour des bureaux de vos collègues en fin d’année pour en récupérer un stock d’avance)
• du papier calque pour le diffuseur de lumière, qui s’est révélé très utile dans certaines situations avec des éclairages surplombant un peu trop intenses
• du papier pour imprimer les cartes
• deux charnières de récupération pour le le bras de la caméra et sa béquille de blocage
• un compas (charnière, pas de dessinateur) récupéré sur un vieux tréteau et qui sert à bloquer (à peu près) le couvercle de la valise en position ouverte
• de la petite visserie (genre M3)
• du scotch double-face

Question outillage, il suffit d’un bon cutter (prévoyez les sparadraps en fonction de votre adresse manuelle 😉) et d’un pistolet pour colle thermo-fusible (un pisto-colle pour faire court). Une perceuse sans fil peut également être utile pour les différents trous de fixation ainsi qu’un réglet acier pour guider le cutter.

Sur le plan électronique, les fournitures principales sont :

• une Raspberry Pi 3B+. Pas besoin d’un modèle 4 (qui n’existait pas encore à l’époque), que je vous déconseille même à cause de sa tendance à se transformer en radiateur et du fait que la ventilation dans la valise n’est pas idéale pour elle. La 3B a tenu sans problème en fonctionnement non-stop toute la journée lors des Villages des Sciences où nous l’avons utilisée.
• une PiCam standard
• un câble plat de 1m. Mon exemplaire vient de chez Adafruit via Amazon. Je n’ai d’action ni chez l’un ni chez l’autre mais le produit est de bonne qualité.
• un bloc secteur pour Raspberry Pi. Ne cherchez pas les ennuis et n’essayez pas de radiner quelques Euros en allant vous approvisionner chez les Chinois. Les blocs secteurs pas chers ont tendance à voir leur tension s’effondrer lorsqu’on commence à les solliciter, ce qui veut dire reboots intempestifs à la clé. On n’est est pas à quelques Euros près pour éviter de passer pour un guignol face à un public pendu à vos lèvres 😉
• deux transmetteurs radio (j’ai choisi des XBee 802.15.4 de base (c’est à dire pas ZigBee ni autre) en remplacement de la solution de communication intégrée au mBot. Plus d’information seront donnés dans l’article détaillant la partie mBot du dispositif.

Histoire de faire propre, j’ai utilisé un connecteur de façade pour le câble Ethernet. C’est facultatif mais ça évite de devoir connecter à chaque fois un câble sur la RPi tapie au fond de sa valise et le faire courir sous le plateau.

Ca se trouve sans difficulté chez les distributeurs de composants électroniques, comme Mouser [2] par exemple.

Rien de bien insurmontable avec un peu de patience et de soin.

Les plans

Ne les demandez pas : il n’y en a pas. Tout a été improvisé au fur et à mesure, en fonction de ce que contenaient les "boîtes à mer...veilles" (vous savez, celles qu’on appelle aussi "dernière chance avant la poubelle").

Les quelques photos vous permettront cependant de comprendre comment tout cela est réalisé, car après tout nous n’avons pas conçue une station spatiale, et surtout de l’adapter à vos ressources et selon vos propres idées.

Dans dans tous les cas nous sommes là pour répondre aux questions et vous conseiller.