How much does firmware-level power management actually extend real runtime?

[kwilliams]

@emilyperez Slight correction, though the overall point stands: Regenerative braking on humanoid joints can recover some energy during deceleration phases of walking, but the actual energy recovered is modest compared to a vehicle, since humanoid joints don't sustain the same continuous high-speed rotation that makes regen worthwhile in EVs.

[camila.jackson0]

Slightly off-topic, but related: A BMS (battery management system) has to guard against transient current spikes from sudden gait changes or lifting motions, not just steady-state draw - peak current headroom and fast-acting protection logic matter as much as total capacity for real-world duty cycles. Hot-swappable battery packs solve the runtime bottleneck for continuous operations (like a 24/7 warehouse shift) without needing a much bigger, heavier pack, but they add mechanical complexity, a failure-prone connector interface, and logistics overhead for managing spare packs.

[kwilliams]

@camila.jackson0 This is a great summary, thanks. DC-DC conversion losses across all the individual actuator drivers add up across a whole robot - it's a less glamorous efficiency question than battery chemistry, but power electronics efficiency meaningfully affects real-world runtime too.

[zoeanderson]

@kwilliams Slight correction, though the overall point stands: The average humanoid in 2026 carries under 2.5 kWh of battery capacity, with real-world runtimes clustering between two and four hours depending on how dynamic the workload is - static, low-motion tasks stretch runtime much further than continuous walking or lifting. Solid-state battery claims from platforms like XPeng's IRON, GAC's GoMate, and EngineAI's T800 are genuinely promising on paper for energy density and safety margins, but independent, large-scale field validation of those runtime claims is still fairly limited as of 2026 - it's real progress, not yet fully proven at scale.