Dernières améliorations

Plusieurs idées d’améliorations sont apparues au fil des utilisations de Taxibot lors d’événements publics.

Elles sont présentées ici, non pas parce qu’elles relèvent d’un pur génie, mais parce qu’elles sont utilisables dans n’importe quel autre contexte.

La climatisation de la valise

Nous savons tous qu’une Raspberry Pi ça chauffe, même les modèles 3. C’est d’autant plus vrai lorsqu’on la fait travailler intensivement, comme ici avec le traitement d’image.

La nôtre est de plus enfermée dans un des compartiments de la valise, sous le plateau de "programmation", et donc avec une ventilation quasi inexistante. Anticipant le problème de la montée en température, j’avais équipé les puces impliquées (CPU, contrôleur USB, mémoire,...) des habituels dissipateurs adhésifs qu’on peut facilement trouver partout et à tous les prix.

Pour surveiller la bête, l’indication de température du CPU (par lecture du pseudo-fichier /sys/class/thermal/thermal_zone0/temp) est également affichée dans la page des informations système de l’interface utilisateur.

Ceci étant, lors de l’inauguration du bâtiment de Terra Numerica le 11 juin dernier, la région était en plaine vague de chaleur (pas très original cette année-là) et l’âge du bâtiment et de sa climatisation ont conduit à des températures de locaux dignes d’un hammam. Notre pauvre Raspberry n’était pas vraiment à la fête elle, et bien qu’aucune incidence notable sur le fonctionnement n’ait pu être remarquée, de telles conditions ne sont pas compatible avec la longévité du dispositif.

Il a donc été décidé de climatiser la valise, en perçant la paroi pour y installer un petit ventilateur destiné à injecter de l’air "frais" dans le compartiment de la carte, et en direction des dissipateurs. La fouille dans la caisse des pièces de récupération a permis d’en isoler quelques uns dont les dimensions convenaient et à sélectionner l’exemplaire qui fonctionnait le mieux sous une alimentation 5V. Il faut savoir que tous les ventilateurs issus de PC ou semblables fonctionnent en 12V et qu’ils ont des comportements très différents (rotation, consommation,...) selon le modèle lorsqu’on les alimente avec une tension plus basse.

Quelques découpes et perçages plus tard, notre Raspberry disposait d’une chambre climatisée.

Pour l’alimentation, rien de bien compliqué : le ventilateur est tout simplement alimenté par l’une des broches du header (2 ou 4) qui sont connectées au 5V régulé.

Tout fonctionne parfaitement, si ce n’est que le ventilateur étant alimenté en permanence, il faut en supporter le bruit de fond. Mais on peut faire mieux et ne le faire fonctionner que lorsque la température des cores du processeur dépasse un certain seuil.

La modification consiste à alimenter l’alimenter non plus depuis le 5V permanent mais depuis celui d’un des ports USB, dont on peut contrôler l’activation via le pseudo fichier /sys/bus/usb/drivers/usb/bind et unbind/ correspondant au port.

Aucune crainte à avoir concernant la consommation en courant du ventilateur, celle-ci étant de quelques dizaines de milliampères, soit bien en-dessous de la limite d’un port USB.

On déconnecte donc le ventilateur du 5V piqué sur le header, et on le relie à une prise USB mâle à souder. On trouve ce genre de pièce détachée dans des coffrets de prises mâles et femelles à assembler pour réaliser des câbles ad-hoc, disponibles pour quelques Euros sur votre site de vente en ligne préféré.

Le contrôle de l’activation du ventilateur est ajouté au monitoring de la température des core qui permettait déjà d’en afficher la valeur sur l’interface HTML.

Tout est pour le mieux maintenant, et même dans les conditions les plus chaudes qui ont suivi, la température du core n’est pas montée au-delà de 35°C.

Remarque : on aurait pu se passer du port USB et commuter le 5V permanent via un petit MOSFET contrôlé par une GPIO disponible. Cela aurait marché tout aussi bien mais aurait juste nécessité d’ajouter un petit PCB (e.g. plaque proto) quelque part. Disons que l’option USB était plus pratique, sachant que le tout est enfermé dans la valise.

Signalisation de fin de shutdown

Cette modification a été réalisée plusieurs mois après celle présentée ci-dessus.

Comme vous le savez bien, couper brutalement l’alimentation d’un Raspberry est mauvais pour la santé de sa carte SD (c’est pareil pour votre PC desktop et ses disques).

Pour éviter toute mésaventure, tous nos démonstrateurs à base de Raspberry sont dotés d’une fonction permettant de déclencher le shutdown system (i.e. la séquence initiée par la commande poweroff), soit via l’interface utilisateur lorsqu’il y en a une comme ici, soit via une action spécifique sur les contrôles physiques, par exemple l’appui prolongé sur un des boutons, comme décrit dans cet article.

Le problème c’est qu’il n’y a rien de facile à repérer qui indique que la procédure est terminée et qu’on peut couper l’alimentation sans risque. Il y a certes la manière dont les LEDs rouge et verte de la carte clignotent, mais encore faut il qu’on sache quelle est la configuration qui indique l’état attendu, et surtout qu’on puisse voir ces LEDs. Or ce n’est pas le cas ici.

Ayant constaté que le voyant d’alimentation des petites enceintes audio de CyberP4 s’éteint en fin de séquence, j’ai effectué quelques recherches sur la gestion de l’alimentation des ports USB par le système. Il en ressort que sur les modèles 3, celle-ci est contrôlée par le pilote USB. Elle est activée lorsqu’il s’initialise et est coupée lors de sa procédure d’arrêt. Je ne sais pas si ça fonctionne de la même manière sur les modèles 4, n’ayant pas encore eu l’occasion d’en utiliser dans mes projets. J’ai cru comprendre que ce n’était pas forcément le cas, mais c’est sous réserve.

On peut donc tirer parti de ce fonctionnement pour signaler de manière claire que la séquence de shutdown est arrivée à son terme. La première idée qui vient à l’esprit est de connecter une LED sur l’alimentation d’un des ports USB et de l’installer à un endroit bien visible.

Mais dans notre cas, il y a plus simple : utiliser le ventilateur en guise de signalisation. Etant donné que suite à la modification faite précédemment pour en asservir le fonctionnement à la température du core, il est connecté à un port USB, il se met en route quelques secondes après la mise sous tension et s’arrête tout seul en fin de shutdown. On sait qu’on peut alors couper l’alimentation sans risque.

A noter que, du fait qu’il puisse ne pas être en marche à ce moment-là car la température du processeur est en-dessous de son seuil d’activation, on force sa mise en route en tout début de procédure de shutdown.

Le mot de la fin

Avec ces petites modifications sans prétention, TaxiBot devient encore plus simple à mettre en oeuvre, y compris par des utilisateurs autres que son créateur (ce qui était le but du jeu).

L’utilisation de l’alimentation du port USB comme signalisation de l’avancement du démarrage ou de l’arrêt de la Raspberry est de plus applicable à n’importe quelle autre situation et peut rendre service.