129 juillet 2026 · les LED, diode par diode

Version de l'outil au terme de la séance : v2.8.5.

Nous pensions avoir fait le tour des LED : huit points, deux à la tête, six sur le dos. En poussant le pilotage plus loin, il s'est avéré que chacun des deux points de tête est en réalité une oreille de six mini-LED en couronne, adressables une par une. La tête passe donc de 2 à 12 canaux, et le décompte réel est de dix-huit, pas huit. Le repère 1 est à midi, puis on tourne dans le sens horaire.

Pour retrouver quelle diode porte quel numéro, un mode Identifier n'en allume qu'une à la fois. C'est la seule façon fiable de cartographier une couronne dont on ne voit pas l'ordre depuis l'extérieur.

Le panneau LED après interfaçage complet : les deux oreilles affichées en cercles de six mini-LED numérotées, et la rangée des six LED de dos — Le résultat de la séance : les **douze mini-LED des oreilles** enfin adressables une par une, affichées en cercles dans leur ordre réel, avec les six LED du dos en dessous. Chaque diode se règle séparément.

Deuxième correction de la séance, plus embarrassante : le plan Humeur était faux depuis le début. Valence, éveil et satiété sont publiés par le robot sur une échelle de 0 à 100, que notre curseur interprétait autrement. Résultat, il restait collé en haut du plan quel que soit l'état réel de la machine. Corrigé, il tombe enfin en bas quand le robot est couché et tranquille.

Troisième point, une confusion qui nous a coûté des essais : les boutons Reset et Recovery faisaient la même chose. Ce sont deux mécaniques distinctes du robot, la remise debout d'un côté, le relevage après chute de l'autre. Elles sont désormais sur deux appels séparés, et on comprend enfin pourquoi un robot tombé sur le flanc ne se relevait pas quand on lui demandait de se mettre debout.

Côté déambulation, le nœud d'évitement passe en v16 : il s'arrête dès qu'un vide est seulement suspecté, et détecte un bord franc sur une seule zone, ce qui rattrape les approches en diagonale que la version précédente laissait passer.

229 juillet 2026 · sept onglets, et l'écran élucidé

Version de l'outil au terme de la séance : v2.8.4. Deux journées de travail sur la machine réelle, condensées ici.

Les outils construits au fil des essais cessent d'être des pages séparées : ils deviennent les sept onglets d'une interface unique. C'est le moment où le bricolage devient un outil.

Trois découvertes vérifiées sur la machine

Le volume est un paramètre ROS du nœud audio, réglé par une commande de paramètre que nous avons capturée sur l'interface officielle du constructeur. Les LED ne sont accessibles que par le canal UDP 8768, seule voie connue, ni WebSocket ni REST. L'écran de la tête se pilote par des services ROS dédiés aux animations et aux messages.

Ces trois résultats sont désormais consignés dans la documentation développeur, section « Le volume, les LED, l'écran ». Ils n'ont pas besoin d'être relus ici pour être utilisés.

Un résultat négatif, mais démontré : les yeux ne répondent pas

Nous avons cherché à piloter les yeux. Le serveur UDP comprend bien les clés correspondantes et les republie sur un topic dédié, mais plus personne ne consomme ce topic : le compteur d'abonnés est à zéro. La couche des yeux est gérée à l'intérieur du nœud d'affichage, et les paramètres des services d'écran le confirment.

Ce que « Vie du robot » regroupait alors

L'onglet réunit ce que la machine dit d'elle-même : son humeur telle que son propre moteur émotionnel la calcule, et ce sont ces valeurs qui expliquent qu'elle finisse par se coucher seule ; le volume audio ; les LED, à ce stade en deux groupes seulement, tête et corps, avec une palette par groupe ; l'écran de la tête ; la batterie, le réseau, la charge des 14 moteurs, les interactions tactiles reçues, les journaux et la mémoire du dialogue.

L'onglet Vie du robot en v2.8.4 : l'humeur du robot sur un plan plaisir et éveil, la batterie, le réseau, les interactions tactiles reçues, le volume audio, les palettes de LED en deux groupes et l'écran de la tête — **Capture d'époque, v2.8.4**, sur un Sirius réel : le panneau LED y est encore en deux groupes tête et corps, avant que la v2.8.5 ne l'éclate diode par diode. L'humeur est celle que le robot calcule lui-même, état « sleeping », satiété à 100 %, fatigue à 0 %. Le volume affiche « ? » parce que sa **lecture** n'est pas possible sur ce firmware, seul le réglage l'est. Le bloc Réseau a été neutralisé avant publication, le reste des valeurs est réel.

Enchaînements apparaît dans la même version : un éditeur de comportement où l'on met bout à bout des animations, des groupes à tirage aléatoire, des pauses et des blocs d'errance. L'idée neuve tient dans le groupe : on décrit un comportement, pas une suite figée.

L'éditeur Enchaînements : une séquence de deux blocs, une animation et un groupe nommé Arret contenant trois animations, avec les commandes de lecture et de bouclage — Une séquence de deux blocs : une animation, puis un **groupe** nommé « Arret » qui tirera au hasard l'une de ses trois animations.

L'onglet Déambulation réorganisé en trois colonnes : la vue caméra à gauche, la grille des seize distances du capteur au centre, la marche pas-à-pas et les animations d'évitement à droite — La déambulation refondue en trois colonnes, ce qu'il voit, ce qu'il mesure, ce qu'il fait, avec le **nœud embarqué lancé**. **Capture de démonstration** : le cadre caméra reçoit une vue d'illustration à la place du flux réel, et les seize distances ont été accordées à cette scène pour qu'elle se lise. Les couleurs, elles, sont celles de la vraie rampe.

Une erreur rattrapée après coup

La livraison annonçait la bonne version en titre, mais la fiche du kit juste en dessous décrivait encore la précédente : nom, taille, empreinte et nombre de fichiers. Cinq autres endroits traînaient la même version périmée, dont le bouton de téléchargement. Le contrôle automatique n'avait rien vu, parce qu'il ne regardait qu'une seule forme de ligne.

327 juillet 2026 · la déambulation, puis embarquée

Versions de l'outil : v2.8.2 puis v2.8.3.

La v2.8.2 ajoute un onglet Déambulation : le robot se promène seul en évitant les obstacles, pendant que l'écran montre ce qu'il perçoit. On y voit le champ du capteur de distance en direct, une grille de 4 × 4 zones, seize distances en millimètres colorées de la plus proche à la plus lointaine, et les zones qui crient « obstacle » ou « vide » cernées d'un anneau. À côté, la décision du robot et son motif, en clair.

L'onglet Déambulation en v2.8.2 : à gauche la vue caméra du robot dans un salon au ras du sol, à droite la grille des seize distances du capteur en millimètres, et en bas la décision du robot — **Capture d'époque, v2.8.2**, en fonctionnement sur un Sirius réel : à gauche ce qu'il voit, à droite ce qu'il mesure. Les seize distances sont vraies, 204 mm devant les pattes, environ 500 mm à hauteur d'horizon. La pastille « v12 » du bandeau est la version du **nœud embarqué** au moment de la capture, pas celle de l'outil.

Le point qui a demandé le plus de tâtonnements : le capteur de distance n'existe que sur le ROS embarqué, jamais sur le canal WebSocket. La boucle d'évitement doit donc tourner à bord du robot, pas sur le PC. C'est une contrainte d'architecture, pas un choix.

La v2.8.3 en tire la conséquence : le nœud est fourni avec le kit, une ligne de copie le dépose sur la machine, et l'onglet devient pleinement utilisable par un tiers. Tant qu'il n'est pas déposé, l'onglet explique la marche à suivre au lieu de rester muet.

427 juillet 2026 · le mobile, et le défaut qu'il fallait raconter

Versions de l'outil : v2.8 puis v2.8.1.

La v2.8 fait tenir l'outil dans la main : l'interface s'installe sur un téléphone comme une application, avec son manifeste, ses icônes et le plein écran iOS. Piloter le robot en le suivant dans la pièce devient possible. Le pont, lui, reste sur la machine ; le téléphone n'est qu'un écran de plus ouvert dessus.

La v2.8.1 ajoute donc un mode réseau : le pont écoute sur le réseau local, la fenêtre affiche l'adresse à taper sur le téléphone, et l'interface déduit son adresse de la page servie au lieu de la coder en dur.

Studio 360 v2.8.1 sur un téléphone : la vue caméra du robot au ras du sol dans un salon, la vitesse en surimpression, les compteurs de suivi et le joystick de translation — **Capture d'époque, v2.8.1**, sur un Sirius réel. Ici, contrairement aux captures de bureau, **la vue caméra est authentique** : c'est ce que le robot voit depuis le sol, à trente centimètres de hauteur. Aucune détection n'était en cours, d'où les compteurs de suivi à zéro.

Une différence assumée avec le client officiel du constructeur date de cette séance : il coupe le zoom, nous non. Gagner en confort d'apparence en désactivant le pincement se paie en accessibilité.

527 juillet 2026 · l'onglet Système, et les trous assumés

Version de l'outil : v2.7. C'est aussi la version où l'outil change de nom et devient Studio 360 pour Sirius.

L'onglet Système est une vue de diagnostic : compteurs de vision en temps réel, charge des 14 moteurs et état du coupe-circuit, métriques de la machine, et un volet thermique qui a fixé une règle d'écriture pour tout le reste du projet.

Le volet thermique : température de batterie à 30,1 °C, quatre sondes de patte déclarées muettes, température processeur non disponible avec sa raison — Le volet thermique, et c'est peut-être la capture qui résume le mieux la manière dont cet outil est écrit. **Une seule température est affichée parce qu'une seule est réellement mesurée** : celle de la batterie. Les quatre sondes de patte portent la mention « sonde muette », le processeur « non disponible sur ce firmware », et la raison est écrite juste en dessous.

Autre correction de cette séance : l'interrupteur « autonome » de la barre du haut n'agissait jusque-là que sur l'affichage. Il est enfin relié à la vraie route du pont.

626 juillet 2026 · les débuts

Versions de l'outil : jusqu'à v2.6.

Les premières séances ont servi à cartographier le protocole et à construire de quoi l'interroger : les deux joysticks, la vue caméra, la bibliothèque d'actions du robot avec ses noms traduits du chinois, la télémétrie des moteurs et le coupe-circuit.

Le panneau de suivi en temps réel, avec un compteur par classe détectée par le modèle embarqué — L'outil de ces premières séances : un compteur par classe détectée, qui **révèle automatiquement toute classe inconnue** qui apparaîtrait. C'est ainsi que nous avons découvert ce que le modèle embarqué sait reconnaître, faute de documentation le disant.

La v2.6 apporte une finesse qui a demandé du temps : le sélecteur de posture reflète l'état réel du robot, y compris quand le comportement autonome agit seul. La posture est déduite de l'action jouée, signalée comme déduite, et rien ne s'allume tant qu'elle n'est pas connue.

Carnet de bord