129 July 2026 · the LEDs, diode by diode

Tool version at the end of the session: v2.8.5.

We thought we were done with the LEDs: eight points, two on the head, six on the back. Pushing the control further, it turned out that each of the two head points is in fact an ear of six mini-LEDs in a ring, addressable one by one. The head therefore goes from 2 to 12 channels, and the real count is eighteen, not eight. Marker 1 sits at twelve o'clock, then you go clockwise.

To work out which diode carries which number, an Identify mode lights only one at a time. It is the only reliable way to map a ring whose order you cannot see from the outside.

The LED panel once fully interfaced: both ears drawn as circles of six numbered mini-LEDs, and the row of six back LEDs — The outcome of the session: the **twelve ear mini-LEDs** finally addressable one by one, drawn as circles in their real order, with the six back LEDs below. Every diode is set separately.

Second fix of the session, and a more embarrassing one: the mood plot had been wrong from the start. Valence, arousal and satiety are published by the robot on a 0 to 100 scale, which our cursor interpreted differently. As a result it stayed stuck at the top of the plot whatever the machine's real state. Fixed, it finally drops to the bottom when the robot is lying down and quiet.

Third point, a confusion that cost us a few attempts: the Reset and Recovery buttons did the same thing. These are two distinct mechanisms in the robot, standing up on one side, post-fall recovery on the other. They now sit on two separate calls, and we finally understand why a robot fallen on its side would not get up when asked to stand.

On the roaming side, the avoidance node moves to v16: it stops as soon as a void is merely suspected, and detects a sharp edge on a single zone, which catches the diagonal approaches the previous version let through.

229 July 2026 · seven tabs, and the screen solved

Tool version at the end of the session: v2.8.4. Two days of work on the real machine, condensed here.

The tools built along the way stop being separate pages: they become the seven tabs of a single interface. This is the moment the tinkering turns into a tool.

Three findings verified on the machine

Volume is a ROS parameter of the audio node, set through a parameter command we captured on the vendor's official interface. The LEDs are reachable only through the UDP 8768 channel, the only known route, neither WebSocket nor REST. The head screen is driven by ROS services dedicated to animations and messages.

All three results now live in the developer documentation, section "Volume, LEDs, screen". They do not need to be read here to be used.

A negative result, but a demonstrated one: the eyes will not answer

We tried to drive the eyes. The UDP server does understand the matching keys and republishes them onto a dedicated topic, but nobody consumes that topic any more: the subscriber count is zero. The eye layer is handled inside the display node, and the screen service parameters confirm it.

What "Robot life" gathered at that point

The tab brings together what the machine says about itself: its mood as its own emotion engine computes it, and those are the values that explain why it eventually lies down on its own; the audio volume; the LEDs, at that point in two groups only, head and body, with a palette per group; the head screen; battery, network, the load of all 14 motors, touch interactions received, logs, and the dialogue memory.

The Robot life tab in v2.8.4: the robot's mood on a pleasure and arousal plane, battery, network, touch interactions received, audio volume, LED palettes in two groups and the head screen — **Period screenshot, v2.8.4**, on a real Sirius: the LED panel is still in two groups, head and body, before v2.8.5 broke it out diode by diode. The mood is the one the robot computes itself, state "sleeping", satiety at 100 %, fatigue at 0 %. Volume reads "?" because **reading** it is not supported on this firmware, only setting it is. The Network block was neutralised before publication, every other value is real. The interface is shown in French here.

Sequences appears in the same version: a behaviour editor where you line up animations, randomly drawn groups, pauses and roaming blocks. The new idea is the group: you describe a behaviour, not a fixed list.

The Sequences editor: a two-block sequence, one animation and one group named Arret holding three animations, with playback and looping controls — A two-block sequence: one animation, then a **group** named "Arret" which will draw one of its three animations at random.

The Roaming tab reorganised into three columns: the camera view on the left, the grid of the sixteen sensor distances in the middle, step-by-step walking and avoidance animations on the right — Roaming redesigned into three columns, what it sees, what it measures, what it does, with the **on-board node running**. **Demonstration screenshot**: the camera frame carries an illustration instead of the real feed, and the sixteen distances were matched to that scene so it reads. The colours themselves are the page's real ramp.

A mistake caught after the fact

The delivery announced the right version in its heading, but the kit sheet just below still described the previous one: name, size, hash and file count. Five other places carried the same stale version, including the download button. The automated check had seen nothing, because it only looked at one shape of line.

327 July 2026 · roaming, then on board

Tool versions: v2.8.2 then v2.8.3.

v2.8.2 adds a Roaming tab: the robot walks around on its own, avoiding obstacles, while the screen shows what it perceives. You see the distance sensor field live, a 4 × 4 grid, sixteen distances in millimetres coloured from nearest to farthest, and the zones shouting "obstacle" or "void" ringed with a halo. Next to it, the robot's decision and its reason, in plain words.

The Roaming tab in v2.8.2: on the left the robot camera view in a living room at floor level, on the right the grid of the sixteen sensor distances in millimetres, and below the robot's decision — **Period screenshot, v2.8.2**, running against a real Sirius: on the left what it sees, on the right what it measures. The sixteen distances are genuine, 204 mm in front of the legs, around 500 mm at horizon height. The "v12" badge in the header is the version of the **on-board node** at the time of the screenshot, not that of the tool. The interface is shown in French here.

The point that took the most fumbling: the distance sensor only exists on the on-board ROS graph, never on the WebSocket channel. The avoidance loop therefore has to run on the robot, not on the PC. That is an architectural constraint, not a choice.

v2.8.3 draws the consequence: the node ships with the kit, one copy command drops it onto the machine, and the tab becomes fully usable by a third party. Until it is deployed, the tab explains what to do rather than staying silent.

427 July 2026 · mobile, and the flaw worth telling

Tool versions: v2.8 then v2.8.1.

v2.8 makes the tool fit in your hand: the interface installs on a phone like an app, with its manifest, its icons and iOS full screen. Driving the robot while following it around the room becomes possible. The bridge itself stays on the machine; the phone is just one more screen opened onto it.

v2.8.1 therefore adds a network mode: the bridge listens on the local network, the console window prints the address to type on the phone, and the interface derives its address from the page it was served from instead of hard-coding it.

Studio 360 v2.8.1 on a phone: the robot camera view at floor level in a living room, speed overlaid, the tracking counters and the translation joystick — **Period screenshot, v2.8.1**, on a real Sirius. Here, unlike the desktop screenshots, **the camera view is genuine**: this is what the robot sees from the floor, thirty centimetres up. No detection was running, hence the tracking counters at zero.

One deliberate difference from the vendor's official client dates from this session: it disables zoom, we do not. Buying a tidier look by killing pinch-to-zoom costs accessibility.

527 July 2026 · the System tab, and the honest gaps

Tool version: v2.7. This is also the version where the tool is renamed and becomes Studio 360 for Sirius.

The System tab is a diagnostics view: live vision counters, the load of all 14 motors and the state of the cut-off, machine metrics, and a thermal panel that set a writing rule for the rest of the project.

The thermal panel: battery temperature at 30.1 °C, four leg probes declared silent, CPU temperature unavailable with its reason — The thermal panel, and perhaps the screenshot that best sums up how this tool is written. **A single temperature is displayed because a single one is actually measured**: the battery. The four leg probes read "silent probe", the CPU reads "not available on this firmware", and the reason sits right below it.

Another fix from this session: the "autonomous" switch in the top bar had only ever changed what was displayed. It is finally wired to the bridge's real route.

626 July 2026 · early days

Tool versions: up to v2.6.

The first sessions went into mapping the protocol and building something to question it with: the two joysticks, the camera view, the robot's action library with names translated from Chinese, motor telemetry and the cut-off.

The live tracking panel, with a counter per class detected by the on-board model — The tool of those early sessions: one counter per detected class, which **automatically reveals any unknown class** that shows up. That is how we found out what the on-board model can recognise, in the absence of any documentation saying so.

v2.6 brings a subtlety that took time: the posture selector reflects the robot's actual state, including when autonomous behaviour acts on its own. The posture is inferred from the action being played, flagged as inferred, and nothing lights up until it is known.

Logbook