Power and battery
A Vector sitting on his charger doing nothing runs about 1.2 of his four cores. A third of that is the four-microphone beamformer, listening for a wake word that is not coming. This page is what a read-only investigation of a docked robot found, and what EmberOS changed as a result.
The measurements were taken on one robot, docked and awake, on the Regular CPU profile — a 533 MHz ceiling. Everything was read from the robot’s own process accounting and system files or from the firmware source; nothing was installed or restarted to produce it.
Where the time goes
Section titled “Where the time goes”Per-thread CPU over a twenty-second window, as a percentage of one core:
| Process | Thread | % of a core | What it is |
|---|---|---|---|
| Animation | Raw mic processing | 32.5 | Four-microphone beamforming |
| Animation | Main | 5.6 | The 33 ms animation tick |
| Animation | Wake-word trigger | 2.0 | The recogniser, gated by voice activity |
| Animation | Face draw | 1.5 | Pushing frames to the LCD |
| Animation | Audio engine | 1.8 | The sound engine’s tick |
| Animation total | 43.4 | ||
| Robot | Main | 10.6 | The 200 Hz loop to the body board |
| Robot | IMU | 5.0 | Reading the accelerometer at 200 Hz |
| Robot total | 15.6 | ||
| Camera daemon | 5.8 | Frames flowing | |
| Cloud/gateway | 3.2 | ||
| Engine | 2.0 | The 60 ms tick, vision idle | |
| Bluetooth, wifi supplicant | 0.0 |
Overall about 31% of four cores was busy. The processes above account for about 0.72 of a core; the rest is kernel work — wireless, camera image pipeline, the serial link to the body.
Die temperatures in the head sat at 63–66 °C. The battery pack’s own temperature is only logged above 50 °C and never was, so the pack stayed cool throughout.
Time at each clock over a 25-minute boot: 54 seconds at 200 MHz, 664 at 400 MHz, 742 at 533 MHz, and about 20 seconds above that during boot. Wireless power save was on.
Calm power mode, and why it never came back
Section titled “Calm power mode, and why it never came back”The robot has a low-power state. It is requested by behaviours, not by anything global, and exactly one component grants it. When it is on, five things change: calm mode goes to the body board, the camera is paused, the LCD backlight drops to 5 mA, the CPU governor is pinned low, and the proximity-based navigation map is switched off.
What it actually throttles:
- The body board loop stretches its state report from 33 Hz to 4 Hz. That alone is worth over 10% of that process, by the original authors’ own note. The body board’s own quiet mode is deliberately not used any more: it already cuts encoder power when the motors are idle, and forcing it caused motor recalibration.
- The microphone front end switches from four-microphone beamforming to a single microphone with a DC-removal filter and a gain stage. The beat detector stops. The wake-word thread keeps running on the processed single channel, still gated by voice activity.
- The engine slows its battery-voltage filter.
- A button press lifts calm for one second so the pairing screens still work, and the animation process only relays it while the face screen is idle.
The problem is who asks for it. The requesters in the behaviour tree are sleeping, the quiet-mode coordinator, asking for help, and one onboarding step. Being docked and awake is not one of them. A robot sitting on his pod all day runs the full microphone pipeline.
Worse, the request is dropped as soon as the requesting behaviour deactivates, and taking behaviour control over the SDK interrupts whatever is running — including sleep. So every time a server grants itself control, calm mode goes off, and re-entry is then gated by a minimum active period and, for sleep, by a ten-minute “woke recently” window. While a client holds control there is nothing that requests power save at all, however idle the robot is.
In the observed session: calm mode was enabled once and disabled again within three minutes, then stayed off for more than 75 minutes of being docked, while the server was granted behaviour control twenty times.
What EmberOS changes
Section titled “What EmberOS changes”The power manager gets an automatic requester of its own. After 45 seconds on the charger contacts with no motion, no engine-driven animation, an empty action queue, no wake word or pending intent, no camera feed and no client request or action completion in the last 20 seconds, it requests a light profile: calm mode, CPU throttle and the navigation map off. The camera and the LCD stay on.
The important part is that holding behaviour control is not activity by itself — that is precisely the case that kept calm mode off. A client can idle with control held and the robot will still settle. Any behaviour request, such as sleeping or quiet mode, still gets the full profile, and a profile change while already in power save is applied as a difference rather than a restart.
The expected saving while docked and idle: raw mic processing from 32.5% to around 1–2% of a core, the beat detector off, the body loop from 33 Hz to 4 Hz, and the clock at 400 or 200 MHz rather than 533. Roughly a third of a core less work at a lower clock.
Opting the camera into the profile as well removes another 6–7%, but it breaks face and motion reactions on the dock and makes the server’s periodic camera glance re-initialise the camera every time. It is off by default.
The microphone front end
Section titled “The microphone front end”The body board ships a microphone message every 5 ms — four channels at 16 kHz. Raw processing is pinned to one core with a 35 ms budget per pass; the trigger loop is pinned to another and only runs the recogniser while voice activity is detected, or within a second of it.
The beamformed path costs the 32.5% measured. The single-microphone path used in calm mode is expected to cost 1–2%; that has not been measured. The recogniser is already down to 2% at idle thanks to the activity gate.
There is no lower-rate or duty-cycled option. Both the beamformer and the recogniser are fixed at 16 kHz, and the beamformer must see every chunk because it carries direction-search state, so “run it one chunk in N” is not available without its source. The single-microphone path is the only cheap supported option, which is why the docked-idle profile is effectively a microphone change.
The trade-off to watch for: no beamforming means no direction of arrival and possibly a weaker far-field wake word while docked. If that shows up, the profile can keep the CPU throttle and drop the calm-mode part.
What the server does to him
Section titled “What the server does to him”None of this was changed; it is a list of the things a server does that keep a docked robot awake.
| What | How often | Cost on the robot |
|---|---|---|
| A persistent robot-state event stream | every state message: 33 Hz, 4 Hz in calm | protocol encode and a TLS write per event; keeps the radio busy. Worth keeping — it is the only source of docked state — and cheap once calm returns |
| The periodic camera glance | every 3 minutes | a new TLS connection, image streaming on, capture, off. Counts as client activity, so it resets the docked-idle timer: 20 seconds of grace plus a 45-second timeout means roughly 65 seconds of every 180 spent out of power save |
| The greeting probe | every 2 minutes | a new connection and a six-second face stream |
| Ambient reactions | on novelty | takes behaviour control and speaks, then releases; each grant interrupts everything and drops power save with a lockout |
| Dashboard polling | while a page is open | battery, cube status, vision polls and keep-alives; page-scoped, and should pause on a hidden tab |
The recommendations that came out of it: back the camera glance off to ten or fifteen minutes while docked, or skip it entirely while the robot’s status says it is in calm mode and nothing has changed; make the greeting probe event-driven off the face events rather than polled; and audit every caller that takes behaviour control so nothing ever holds it without a pending action.
The 63–66 °C readings are the system-on-chip in the head. The charger circuitry and the pack are in the body, and the pack stayed below 50 °C. Head temperature tracks CPU work directly: the Regular profile alone took this robot from 87 °C at 1.27 GHz to about 67 °C at 533 MHz.
That 1.27 GHz figure is not hypothetical. It is what the robot runs at if anything sets the performance profile and does not put it back, and it is the single most important thing to re-check after any firmware change.
What was not done
Section titled “What was not done”- The body board’s own calm mode, and a lower rate on the link to it. It is the motor-safety path, and the original note says the saving is small.
- Suspending the audio engine during silence, and skipping unchanged frames on the face draw.
- Measuring the cheaper microphone paths directly, which needs a state change on a working robot.
- A Bluetooth advertising audit — whether he advertises when not pairing was never measured.
- The gateway process’s 3.2% at idle.