Studio 360 pour Sirius (Studio 360) est un projet indépendant d'explorations360, sans lien ni affiliation avec Hengbot. Sirius et Hengbot sont des marques de leurs propriétaires respectifs. Ce kit est le fruit d'un travail de rétro-ingénierie de l'API du robot : il n'est ni fourni, ni approuvé, ni soutenu par le constructeur.
16 septembre 2026 · le robot qui chauffe, et l'alimentation qui chante
Version de l'outil au terme de la séance : v2.9.2.
Le constat de départ n'est pas celui d'un ingénieur, c'est celui d'un propriétaire : allumé, ce robot est chaud. Tout le temps. Pas après une heure de marche — tout le temps, y compris couché sans rien faire.
La première chose à défaire était le mot « couché ». Dans son animation d'attente au sol, les quatorze moteurs travaillent, avec des charges de 10 à 172 ‰ selon les canaux et un pic à 307 ‰. Le robot y tient ses deux pattes avant en l'air : ce n'est pas une pose de repos, c'est une pose activement tenue. Et la chaleur est aux épaules arrière, celles qui portent.
Nous avons ensuite cherché à mesurer ce qu'il consomme, et nous avons trouvé quatre portes fermées. Les sondes de température des moteurs renvoient zéro ; il n'existe qu'un seul thermomètre sur toute la machine, celui du processeur. La « charge moteur » que nous affichons depuis des mois n'est pas une mesure, c'est une consigne de puissance. Les topics par moteur que documentait le firmware 2.3.6 n'existent plus en 2.5.5. Et la batterie publie un message d'état complet dont chaque champ vaut zéro, avec la mention « absente ».
Le levier, lui, existe : un service de couple moteur, échelle 0 à 2047. Le chiffre 2047 est celui que l'application du constructeur envoie dans chacune de ses commandes de mouvement — ce qui veut dire que le chemin du retour était écrit d'avance, et donc éprouvable avant même de couper quoi que ce soit. Mesuré, la charge commandée tombe de 307 ‰ à 5 ‰. Mais la preuve qui compte n'est pas ce chiffre : au couple zéro, les pattes avant retombent doucement, et à la restitution, le robot les relève.
Deux choses ont failli faire échouer l'opération, et toutes deux sont instructives.
La première est une boucle. Depuis la station debout, la mise au repos partait en couché / debout / couché / debout, et une fois au sol le robot jouait une animation d'attente. Le mécanisme est net une fois vu : l'application envoie la consigne de couple maximal dans chaque commande de mouvement. Chaque animation spontanée réarme donc le couple qu'on vient de couper. Il faut faire taire le comportement autonome avant de coucher le robot, et le lui rendre au réveil — après le couple, jamais avant.
La seconde est une déduction de notre part, et elle était fausse.
Restait à savoir si la consommation s'arrêtait vraiment, sur une machine qui n'a aucun ampèremètre. C'est le robot lui-même qui a fourni l'instrument. Il émet depuis toujours un sifflement très aigu, que les oreilles jeunes trouvent pénible et que les autres n'entendent plus. L'épreuve n'a donc pas été un silence, mais un aller-retour, fait par les oreilles qui l'entendent : arrêt d'une action, bruit ; mise au repos, silence ; couple rendu, bruit. Deux fois, dans les deux sens. Et il vient de l'avant, entre les deux épaules — donc du corps et non des moteurs : la signature d'une alimentation à découpage, qui chante d'autant plus fort qu'on lui tire du courant. Cette machine n'a pas de sonde de courant, mais elle dit sa consommation à voix haute.
Un témoignage à l'oreille dépend de l'âge de l'oreille. Nous avons donc écrit une page de mesure, puis tenté l'enregistrement avec le micro du robot — l'instrument le mieux placé qui soit. Il a fallu trois tentatives, et chaque échec a laissé un garde-fou dans le script : le réseau de micros principal est tenu en permanence par le lecteur audio du robot ; le second codec s'ouvre bien à 48 kHz mais ses broches d'entrée ne sont reliées à rien, ce qui donne une capture parfaitement ouverte et parfaitement muette ; et la posture ne se demande pas à l'opérateur, elle se lit sur le robot.
Le résultat est un négatif, et il est propre : sous 8 kHz, aucune raie tenue n'apparaît quand le couple revient. Au seuil relâché, la meilleure candidate plafonne à 34 % du temps contre 9 % au repos, là où un sifflement donnerait 100 contre 0. La raison est simple et elle ne contredit pas l'oreille : l'enregistreur du robot tourne à 16 kHz, il est donc aveugle au-dessus de 8 kHz — précisément là où vit un sifflement que les adultes n'entendent plus. Le négatif ne réfute pas le témoignage, il resserre le domaine où il faudra chercher.
Le reste de la journée a été de l'entretien, et il a produit son lot de surprises. L'orgue à LED, écrit quatre jours plus tôt, n'avait jamais tourné que contre le simulateur : il portait deux pannes parfaitement silencieuses. Le flux du micro était rangé dans une propriété en lecture seule, si bien que le mode micro n'avait jamais démarré une seule fois ; et la boucle d'animation reposait sur un mécanisme du navigateur qui ne s'exécute pas dans un onglet caché. Aucune des deux ne produisait d'erreur. Réparé, vérifié sur le robot : douze LED de tête et six de corps, une par une.
Et six pages du kit n'étaient atteignables qu'en tapant leur adresse à la main. Elles s'ouvrent désormais dans un cadre posé par-dessus l'interface, sans rien faire naviguer.
Il reste à dire comment l'enquête s'est terminée, et c'est la mesure la plus simple de toutes.
La règle que cette journée a le plus chèrement payée n'est pas une règle de raisonnement. Trois fois, une déduction plausible a mené au faux, et trois fois c'est une épreuve physique qui a corrigé le tir — les pattes qui pendent, le sifflement qui revient, la main sur le dos du robot. Le bon réflexe n'est pas de mieux raisonner : c'est de chercher l'épreuve qui sépare les cas.
23 septembre 2026 · le geste humain rejoué, et mesuré
Version publiée au terme de la séance : v2.9.1. La v2.9.2 s'écrivait, sans être figée.
La journée a commencé par une phrase de Phil, dite de mémoire de sa machine et non d'un fichier : « si je le mets sur le flanc, il se relève seul ». Un robot qui se redresse seul sait qu'il est tombé. Notre affirmation de la veille — rien dans cette API ne signale une chute — était donc fausse.
Cette centrale rend mesurable ce qui n'était jugeable qu'à l'œil : le tangage et le roulis. Trois réserves l'accompagnent, écrites avant les mesures et non après. L'inclinaison au repos vaut environ 4° et non zéro. Toutes les lectures sont quasi statiques : en geste vif, l'accélération propre du robot fausse l'inclinaison déduite de la pesanteur. Et une lecture coûte un aller-retour réseau, soit environ neuf par seconde, pas cent. Le lacet, lui, reste à l'œil : sans magnétomètre, le cap dérive.
Elle a aussi tranché une question que nous traînions. Le registre de posture que nous prenions pour une télémétrie n'en est pas une : robot incliné, poussé, soulevé, la centrale suit trois fois sur trois et le registre ne bouge pas d'un millième. C'est un registre de consignes. Il dit ce qu'on a demandé, pas ce qui arrive.
Le gros de la journée est allé au squelette — le flux de vision qui permettrait d'apprendre un geste à la machine en le faisant devant elle. Deux séances d'enregistrement, et entre les deux, une seule chose a changé : le point de vue.
Le seuil de confiance que nous cherchions depuis la veille s'est fixé tout seul : le tronc se tient entre 0,82 et 0,92, les extrémités devinées entre 0,48 et 0,63, et 0,70 est le milieu de ce fossé. Nous l'écrivons pour ce qu'il est — un fossé observé une fois, pas une constante mesurée.
Le soir, la chaîne complète a été bouclée. Un humain devant le robot, un enregistrement, une action écrite par nos outils, déposée sur la machine, et jouée par le lecteur natif à partir du seul conteneur, sans compilation. Dix-sept secondes. La courbe écrite ressemble à la chorégraphie enregistrée : immobile, penché d'un côté, droit, penché de l'autre, accroupi tête basse, relevé.
Il a fallu quatre passages, et chacun a appris quelque chose de différent.
Le premier annonçait « 34 % de mesures utilisables », ce qui ressemblait à un défaut de prise de vue. C'était notre propre rapport qui comparait huit secondes tronquées à vingt-trois secondes de séance.
Le deuxième bridait un axe à 35 % sans que le lissage n'y change rien — signe que le problème n'était pas la vivacité du geste. Toutes les grandeurs étaient normalisées par la largeur d'épaules de l'image courante, environ 43 pixels tremblant de 7 %, au lieu de celle de la pose neutre. Le bruit ainsi injecté dans l'axe vertical valait 121 % de sa pleine échelle : l'axe était promené d'une butée à l'autre par le tremblement du squelette. Après correction il passe de 78,6 à 12,2 %, le tangage de 44,7 à 13,6 %, et le roulis ne bouge pas — 21,4 puis 21,6 %. Exactement ce que l'explication prédisait.
Le troisième démarrait l'action à 100 % de son amplitude : l'étalonnage sur la pose neutre avait été relevé pendant que la personne revenait encore se placer.
Restait la question qui compte : le robot rejoue-t-il vraiment le geste ? L'œil dira toujours oui, parce qu'il veut y voir une ressemblance. Nous avons donc mesuré, en lisant la centrale pendant la lecture et en comparant la courbe relevée à celle qui est écrite dans le fichier — nous connaissons les deux.
Le roulis écrit valait 0,254 radian, mesuré 0,210, corrélation +0,910. Le tangage 0,247 écrit, 0,230 mesuré, corrélation +0,867. Et le témoin de non-relation — la même courbe lue à l'envers du temps, même forme, aucun lien causal possible — donne +0,046. Deux contrôles pouvaient tout faire tomber : les deux axes, alignés indépendamment l'un de l'autre, culminent au même décalage de 200 millisecondes. Une latence physique, pas un ajustement heureux.
Un résultat est arrivé sans qu'on le cherche, et c'est le plus intéressant de la journée. Une action qui ne bouge qu'un seul axe fait répondre la centrale sur les deux : un fichier de tangage pur fait varier le roulis lu de 0,148 radian, soit plus que le tangage lui-même. Le mélange est systématique, les deux réponses étant orthogonales à 94°, donc c'est une relation stable et non du bruit. Et une sonde qui n'envoie aucune commande a écarté la moitié des hypothèses : une inclinaison imposée à la main, purement en tangage, se lit à 2 % près sur le bon axe. La centrale lit juste. Le mélange vient donc de la façon dont le robot exécute une consigne d'axe pur, ou de ce que les noms d'axes du fichier ne désignent pas les axes du corps. Propriété de la machine, documentée nulle part.
La séance s'est terminée sur un contrôle, et sur ce qu'il a révélé. Toute page servie par le kit doit avoir un point d'entrée dans l'interface — sinon elle existe sans être atteignable. Écrit, il a immédiatement signalé que l'interface principale ne connaissait ni la boîte noire, ni l'orgue, ni même la page qui liste les outils. Trois pages livrées, aucune joignable autrement qu'en tapant son adresse. C'est ce qui a bloqué la publication de la version pendant trois jours, et c'est un contrôle qui l'a dit, pas un essai.
32 septembre 2026 · le robot joue nos actions, et une conclusion trop large
Version publiée au terme de la séance : v2.9.1. La v2.9.2 s'écrivait ; nous avons décidé de la garder au chaud et d'empiler encore avant de figer.
Nous voulions savoir si nous pouvions écrire une action pour ce robot — un de ces fichiers que le constructeur produit avec son propre outil et que le robot joue. La réponse est oui, et elle est allée plus loin que ce que nous espérions.
Le premier essai est un aller-retour : démonter deux actions officielles, les remonter, et comparer octet pour octet. Les deux ressortent identiques. Puis un conteneur écrit de zéro, que la bibliothèque dont dépend l'outil du constructeur démultiplexe sans réserve. Puis l'outil du constructeur lui-même, qui compile notre conteneur et produit un fichier binaire identique au sien.
Et enfin la question que nous n'avions pas osé poser : que se passe-t-il si on dépose le conteneur sans le fichier compilé à côté ? Il est lu, démultiplexé et joué. Le témoin — six secondes de vert, puis bleu, puis magenta purs — a rendu la suite exacte, identique avec et sans compilation. Le chemin lent est vivant, et le fichier compilé est bien ce que le constructeur en dit : une optimisation, pas une condition.
Deux corrections au passage, au document que nous avions écrit la veille : le remplissage du format est fait d'espaces et non de zéros, et l'en-tête est celui d'une bibliothèque connue, constant, donc reproductible à l'octet.
Une troisième correction porte sur notre propre argumentaire, et celle-là méritait d'être écrite avant qu'elle ne parte sur le site. Nous répétions que cet outil était le chemin restant vers les yeux du robot. C'est faux : le calque des yeux est orphelin depuis une version antérieure, et une piste d'interface impeccable n'y changera rien. Ce que l'outil débloque réellement, c'est le mouvement, les LED et le son. C'est déjà beaucoup, et il n'y avait aucune raison de le vendre pour ce qu'il n'est pas.
L'après-midi a produit une erreur de méthode dont nous avons fait une règle.
L'essai a été fait le soir même, et en aveugle, parce qu'une commande dont on attend un effet subtil est exactement le cas où l'on voit ce qu'on espère. Quatre vraies commandes et quatre commandes nulles, mélangées : quatre détectées sur quatre, aucun faux positif. Puis six essais sur le signe, tous justes. La tête répond elle aussi, mais à 0,30 radian — imperceptible à 0,20, ce qui met en cause le bridage par défaut de notre kit plutôt que la commande.
Le reste de la journée est allé à ce qui allait devenir la v2.9.2. Une boîte noire qui enregistre les flux poussés par le robot au point exact où ils arrivent au navigateur, les rejoue sans jamais parler au robot, et permet d'en découper un extrait dans un nouveau fichier sans réécrire l'original. Et un orgue à LED qui fait suivre le son par les dix-huit diodes.
Deux mesures amusantes en sont sorties. Le canal des LED n'accepte que la tête et le corps : aucun moteur n'est joignable par là, ce qui est une bonne nouvelle pour la sûreté. Et le robot déduplique les images de LED identiques — 291 images donnant 285 événements sur une action du constructeur, et 600 images donnant trois événements sur notre témoin de trois couleurs pures. Le même mécanisme, mesuré à ses deux extrêmes.
Une dernière mesure, pour l'outil qui devait apprendre un geste humain au robot : sur ses propres actions, l'axe le plus rapide que le constructeur s'autorise bouge de 0,012 par image. Notre premier essai filait à 0,061, cinq fois plus — non par excès de zèle, mais simplement parce qu'un geste humain rééchantillonné à cent images par seconde demande aux servos une vitesse que le constructeur ne leur demande jamais. L'outil bride donc chaque axe au maximum relevé chez lui, et compte les images bridées.
41er septembre 2026 · le capteur éteint, et le visage qui s'allume
Version de l'outil au terme de la séance : v2.9.1.
La séance commence par une mauvaise nouvelle. La Déambulation ne fonctionne plus, et ce n'est pas notre code : le firmware 2.5.5 éteint le télémètre au démarrage. Nous avons remonté la chaîne maillon par maillon avant de l'admettre, parce qu'un capteur muet ressemble d'abord à un bug de lecture. Chaque maillon était innocent : le pont réseau abonné au bon topic, le nœud publiant à 245 Hz sans une erreur, la liaison série à 250 trames par seconde. La cause était écrite en clair dans le binaire du pilote bas niveau, en chinois.
Décision prise : on ne répare pas, on détecte. L'onglet Déambulation interroge le robot au chargement et affiche un bandeau daté quand les seize canaux reviennent invalides, puis désactive « Démarrer ». Le code de marche reste intact. Et le mot retenu est « suspendue », pas « obsolète » : la fonction n'est pas périmée, elle remarcherait telle quelle si le constructeur rallumait le capteur. On ne réécrit pas l'histoire d'une fonction qui a marché.
La bonne nouvelle est arrivée du côté opposé, celui que nous avions classé sans suite. Nous avions publié, preuve à l'appui, que les yeux ne sont pas pilotables par le canal UDP. Ce résultat reste vrai. Mais l'écran expose deux services ROS non documentés qui acceptent un chemin absolu arbitraire : un GIF fabriqué sur le PC, déposé dans le dossier temporaire du robot, s'affiche en boucle sur son visage. Essai réussi le soir même.
Une confirmation, aussi, qui fait plaisir : les douze LED de tête que notre outil adresse depuis la v2.8.5, là où l'éditeur public du constructeur n'en pilote que deux, sont décrites à l'identique dans sa documentation interne. Nous n'étions pas seulement en avance sur son outil public, nous étions au niveau de son outil interne.
Et un piège, pour finir, qui nous a pris : la route de mise en pause du comportement, appelée sans le champ attendu, met le robot en pause. Une clé inconnue est ignorée, et la valeur par défaut est « en pause ». Nous voulions relancer le comportement, nous l'avons arrêté.
531 août 2026 · le robot suit la main, et une leçon de méthode
Version de l'outil au terme de la séance : v2.8.7.
Le nœud que nous appelions face_tracker ne suit pas que les visages. Il gère deux cibles, et bascule de l'une à l'autre par une commande interne sur son topic de contrôle. Le robot suit donc la main avec sa propre cinématique, calculée à bord : c'est fluide et sans latence, ce qu'aucun suivi piloté depuis le PC ne peut égaler, puisque la boucle ne traverse pas le réseau.
L'outil expose la bascule sous forme de deux interrupteurs dans l'onglet Vision, sous le maître Détection. La main est prioritaire, le visage reprend la main quand elle sort du champ. Côté machine, la commande passe par un petit nœud ROS persistant tenu à bord par une seule connexion SSH : les bascules sont instantanées et rien n'est installé à demeure sur le robot. Il faut en revanche une clé SSH sans mot de passe.
Nous avons donc retiré l'avertissement « commande non éprouvée » de l'interface et de cette documentation, et posé le doute là où il doit être : toute affirmation d'absence de nœud issue de l'ancien relevé est à revérifier avant d'être reprise.
630 août 2026 · le passage en 2.5.5, et une erreur de notre côté
Version de l'outil au terme de la séance : v2.8.6.
Le robot passe en firmware 2.5.5. Trois choses en sont sorties, dont une correction qui nous concerne directement.
La température du processeur existe. La pastille de la barre du haut affichait un tiret parce qu'elle lisait les sondes des moteurs, muettes sur ce firmware. Le robot publie en réalité sa température système sur son flux de télémétrie, autour de 57 °C en fonctionnement. L'onglet Système, lui, la déclarait « non disponible ». C'était faux, et c'est corrigé dans les deux endroits.
Le suivi de visage est confirmé, et il fonctionne indépendamment de la Détection. C'était la dernière commande de vision dont nous n'osions pas garantir l'effet.
Le kit a été retesté de bout en bout sur 2.5.5 : pilotage, LED, API et commandes réseau intacts, aucune régression. C'est la vérification qui autorise à publier la compatibilité plutôt qu'à la supposer.
Le journal de version du constructeur gagne au passage six bêtas, de la 2.5.1 à la 2.5.5, plus une 2.4.10. La plus lourde de conséquences est la 2.5.4, qui ouvre le robot à l'accès distant par MQTT et WebRTC : il cesse d'être une machine strictement locale.
729 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.
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.
829 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.
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.
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.
927 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.
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.
1027 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.
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é.
1127 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.
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.
1226 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.
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.