Une télécommande pour mon robot, dans un téléphone de 2011
Le Galaxy Note de 2011 tourne maintenant sous Linux. Première vraie mission : piloter le robot. Le réveiller, le coucher, lui faire tourner la tête, lui faire jouer une émotion, depuis le canapé, sans fil.
Pourquoi pas une page web
Le plus simple aurait été une page web. Mais un navigateur moderne met une trentaine de secondes à s’ouvrir sur ce téléphone, et rame dès que la page s’anime. J’ai donc écrit une petite application en C, qui parle directement au système d’affichage du téléphone. Elle s’ouvre instantanément et ne pèse presque rien. C’est la même recette que pour l’application de dessin du téléphone.
Sans ordinateur entre les deux
Le robot expose une interface de commande sur le réseau local : réveil, coucher, moteurs, volume, mouvements, émotions. Le téléphone s’adresse à elle directement, par le Wi-Fi. L’ordinateur peut rester éteint.
Les ordres partent d’un fil d’exécution à part. Si le robot tarde à répondre, l’écran ne gèle pas.
Le premier vrai test a été le bon : le robot s’est réveillé depuis le téléphone.
Ce qui a coincé
La tête ne bougeait pas. Les ordres partaient, le robot les acceptait, et rien ne se passait.
En cause : l’application qui anime le robot au quotidien suit mon visage, et garde donc la main sur la tête. Elle écrasait chaque ordre du téléphone dans la seconde.
La solution : dès que je touche le pavé de la tête, la télécommande met cette application en pause et prend la main. Un bouton la relance ensuite.
Un pavé qu’on comprend
Le premier pavé était un rond jaune sur une croix. Ça bougeait, mais on ne savait pas bien dans quel sens. Il montre maintenant le visage du robot vu de face : il va où va le doigt, et ses yeux regardent de ce côté. Un coin « face » le recentre.
Au passage, la barre de titre de la fenêtre a disparu. Elle ne servait à rien sur un écran de téléphone. Réduire et fermer sont deux boutons dans l’application, et l’espace gagné revient à l’image.
Des saccades à la glisse
Deuxième essai : la tête obéissait, mais par à-coups. Chaque position partait comme un petit mouvement séparé, avec un départ et un arrêt, et le suivant attendait la fin du précédent.
Le téléphone envoie maintenant vingt-cinq positions par seconde, en consigne directe. Chaque pas fait 30 % du chemin qui reste, si bien que la tête glisse vers le doigt et ralentit en arrivant. Le robot répond en 26 millisecondes : il a largement le temps.
L’image du robot
La caméra du robot diffuse une vidéo prévue pour les navigateurs, trop lourde à décoder pour ce téléphone. Il fallait un intermédiaire, un relais, qui reçoive cette vidéo et la transforme en simples photos JPEG, douze par seconde, que le téléphone affiche sans effort.
Premier essai sur l’ordinateur : ça marchait, mais l’ordinateur devait rester allumé. Le relais a donc déménagé sur un Raspberry Pi 3 qui tourne déjà en permanence à la maison.
Le chemin n’a pas été direct. Le kit du robot s’appuie sur un module vidéo que la distribution du Pi ne fournit pas. J’ai écrit à la place un petit client vidéo, qui dialogue directement avec le robot. Le décodage et la fabrication des images passent par la puce vidéo du Pi, pas par son processeur : la charge est tombée de 164 % à 62 % (sur 400 %). Le robot propose aussi des chemins de secours par Internet ; le relais les refuse, et l’image ne quitte jamais la maison.
Résultat : la première image arrive en quatre secondes, deux fois plus vite qu’avec l’ordinateur, et le téléphone en reçoit quatorze par seconde. Un bouton photo garde l’image en pleine résolution.
Et maintenant
Jusqu’ici, ma petite console de commande devait rester branchée pour piloter le robot. Le téléphone, lui, tient dans la poche, marche sur batterie, et voit ce que voit le robot.