The energy problem hides between tasks
At 02:13 the robot was still standing beside the line. Nothing in the production log called it active. No part was moving through its hands, no tote was being carried, and no useful motion appeared on the task trace. Yet the battery telemetry declined with the calm regularity of a machine that was working. Joint drives held posture. Cameras streamed. The perception computer continued to classify a scene that had barely changed. Network links maintained their timing, fans removed heat produced by computation, and the safety chain watched a body that had nowhere to go.
This is the overlooked energy regime of Physical AI. Walking, lifting and manipulation attract attention because mechanical work is visible. Industrial missions also contain queueing, handovers, blocked stations, charging coordination, supervision, human intervention and transitions between tasks. Electrical energy accumulates across all of them. A robot that is efficient during motion but electrically indiscriminate while waiting may deliver poor energy per productive hour.
Fraunhofer IPA's 2026 humanoid benchmark makes the distinction measurable. For the tested Unitree G1 EDU-4, with the stated hardware and firmware configuration, the institute reported average power of about 154 W while standing, about 272 W while walking on level ground, about 283 W on a ten-percent incline and about 239 W in its defined one-hour standard scenario. The same work reported maximum operating times of 2 hours 49 minutes while standing and 1 hour 49 minutes in the typical mixed scenario. These values describe one tested configuration, not a universal humanoid. Their architectural meaning is nevertheless sharp: standing is an operating condition, not an approximation of off. (Fraunhofer IPA, 2026)
Mission energy can be expressed simply as the integral of power over the complete mission, including transitions: Emission = Σ(Pstate · tstate) + ΣEtransition. The formula is uncomplicated; choosing meaningful states is not. Motors, perception, networking, compute, thermal management and safety do not share the same duty cycle or the same acceptable wake latency. Reducing their energy coherently requires a robot-wide readiness architecture, not a collection of unrelated component sleep settings.
Visual pending: Systems concept
Idle is not one state
A robot waiting five seconds for a conveyor release faces a different obligation from one waiting twenty minutes for the next production batch. The first may need active balance, current scene understanding and sub-second resumption. The second may be docked, mechanically supported and able to tolerate a longer reconstruction of perception and task context. Calling both situations idle hides the decision that matters: which capabilities must remain trustworthy, and how quickly must the rest return?
Computer platforms and microcontrollers already expose multiple low-power mechanisms, but their labels belong to devices, not to the whole robot. NVIDIA's Jetson Thor documentation, for example, describes configurable platform power modes and controls through nvpmodel. It also warns that an unconstrained MAXN mode does not guarantee best performance because hardware throttling can occur when module power exceeds its thermal design power budget. Some mode changes may require a reboot because the GPU power-gating mask can be fixed after context creation. (NVIDIA, Jetson Linux r39.2.1) A compute power mode is therefore a useful actuator inside a policy; it is not the policy itself.
The same distinction applies at the control edge. PSOC Control C3 documentation separates Active, Sleep, several Deep Sleep variants and Hibernate. These modes differ in clocks, available peripherals, memory retention, wake sources and whether wake resumes execution, performs a warm reboot or performs a cold reboot. (Infineon, PSOC Control C3 architecture reference manual) Mapping a humanoid's “standby” directly to a microcontroller's “Deep Sleep” would confuse two abstraction levels. A robot state must coordinate many device states while preserving a single physical promise.
That promise is a readiness contract. It names the capability that remains available, the maximum acceptable response time, the permitted energy cost, the valid wake sources, the state that is retained, and the safety conditions that constrain entry and exit. Without such a contract, energy optimisation becomes local: a processor sleeps while a camera continues streaming, a limb inverter is disabled while its network node still terminates a bus, or a fan remains active because no domain owns the cooling transition.
Five states for one physical machine
A practical robot-wide model can begin with five states: Full Active, Task Active, Attentive Idle, Safe Standby and Deep Sleep. These are proposed architectural names, not standardized humanoid modes. Their value is the discipline they impose across subsystems.
Full Active makes the maximum currently required motion, perception, compute and communication capability available. It is appropriate for demanding whole-body behaviour, rapid navigation or recovery from disturbances. It should not become the default merely because it is easiest to validate.
Task Active powers what the current job needs and reduces unused capacity. A stationary manipulation task may keep arms, torso, close-range perception, deterministic networking and safety supervision active while locomotion zones operate at reduced readiness. Compute can run an application-specific power profile rather than a maximum envelope. The transition from Full Active to Task Active should be routine enough to occur inside a mission, not only during maintenance.
Attentive Idle preserves immediate or near-immediate awareness. Posture may still be controlled; selected sensing continues at lower rate; a local safety controller remains authoritative; and the compute stack retains enough context for a fast return. The robot is waiting, but it has not withdrawn from the shared workspace. This state will often determine practical energy savings because short pauses are frequent and deep sleep would impose excessive transition cost.
Safe Standby shuts down major motion and compute domains while preserving an independently powered supervisory path. Entry may require a stable pose, brakes, support or docking. Wake can originate from authenticated communication, a scheduled event, a safety input, a charger, a low-power sensor or a human interface. Safe Standby is not “motion disabled” alone; it is a controlled condition in which the robot can remain safe despite losing most of its active intelligence.
Deep Sleep is the lowest planned energy condition short of full shutdown. It tolerates greater wake latency and broader reconstruction. Only essential monitoring, timekeeping, battery protection, physical tamper or selected wake logic remains active. Deep Sleep may be permitted only while docked or mechanically supported. A robot that can fall, roll or release stored energy cannot claim a safe deep state merely because its electronics reached a low current.
Each state should be specified across the same dimensions: powered domains, motion authority, sensing coverage and sample rate, compute availability, communication presence, thermal behaviour, retained state, wake sources, maximum wake latency, transition energy, physical entry guards and required requalification. The resulting matrix turns “save power” into an engineering interface.
Visual pending: Systems concept
The small controller with authority over the large machine
The lowest-power domain may carry the greatest responsibility. An always-on controller must observe approved events, decide whether a wake request is credible, sequence power rails, monitor voltage and current, supervise time, preserve selected records and prevent motion until the larger system is qualified. It should be small enough to remain economical, independent enough to remain trustworthy and constrained enough to be verifiable.
Current microcontroller architectures show the relevant mechanisms. PSOC Control C3 Deep Sleep turns off high-frequency clocks and peripherals while leaving low-frequency clocks and low-power analog and digital functions available as wake sources. Documented sources include GPIO, a low-power comparator, a serial communication block, watchdog and real-time-clock alarms. Deep Sleep RAM can retain programmable SRAM for a warm reboot, whereas Deep Sleep OFF causes a cold reboot. (Infineon AN240613) These are device capabilities; a robot architect must decide which physical events they represent and whether each is sufficient to restore a particular readiness level.
AURIX TC3xx provides another pattern: multiple standby power domains, wake from real-time clock, wake-up timer, pin events and supply ramp events, with standby RAM availability depending on the product variant. Its Standby Controller includes timers, serial interfaces, comparator capability and a real-time clock for periodic wake-up. (Infineon AURIX TC3xx PMS; Infineon AURIX TC3xx SCR) The architectural lesson is not that one device fits every humanoid. It is that supervision, wake evaluation and retained context can live in a deliberately bounded domain rather than on the main AI computer.
Authority must be narrow. The always-on controller may permit power restoration; it should not invent a task or directly command torque based on a single wake edge. It can authenticate a network wake request, debounce a button, check charger state, verify that the battery permits an inrush event and record the cause. A second stage then establishes the conditions for useful activity. Separating detection from authorization reduces false wake-ups and limits the consequences of a compromised or noisy source.
That separation also gives cybersecurity a tractable boundary. A receiver that accepts any packet as a wake command creates an energy-denial path: an attacker, misconfigured service or noisy network can repeatedly restore expensive compute and cooling domains. The first-stage controller should distinguish detection from authorization, rate-limit repeated requests, preserve a protected cause record and apply a defined fallback when identity services are unavailable. Safety-originated wake sources may need priority over normal authentication, but priority does not remove plausibility checking.
Clock ownership deserves similar care. When the main time base stops, the always-on domain becomes the bridge across the interval. Its real-time clock can schedule maintenance, age retained observations, expire permissions and measure whether a forecasted pause was correct. Time discontinuity after wake can corrupt logs, control deadlines and distributed synchronization. The wake contract should define the trusted clock, acceptable drift, resynchronization method and the point at which time-sensitive communication is again valid.
Battery supervision cannot simply sleep with the application. Cell protection usually remains independent, but the robot-level supervisor still needs enough information to reject a high-current wake under adverse state of charge, temperature or fault conditions. It may choose a restricted wake that restores diagnostics and communication without energizing motion. Readiness is negotiated with the available energy rather than assumed from the requested task.
Wake-up is a controlled requalification
The dangerous moment is not sleep. It is the instant a sleeping digital model regains authority over a physical body. Retained memory may contain exactly the bits written before entry, yet those bits may no longer describe the world. Someone may have moved the robot. A tool may have been removed. A payload may have shifted. The battery may have cooled below a discharge limit. Authentication may have expired. A camera image can be retained perfectly and still be false as current evidence.
A robust wake path proceeds in stages. First, the always-on domain validates and records the source. Second, it restores power domains in a defined order while observing rail health, inrush and isolation boundaries. Third, processors resume or boot, memory is checked and required software services start. Fourth, communication and time synchronization return. Fifth, sensing establishes current evidence; localization, calibration, contacts and payload assumptions are requalified where necessary. Sixth, the safety architecture verifies its channels and present constraints. Only then can motion authority pass to the operational controller.
This sequence creates a state-integrity contract. Retained information belongs in at least three classes: retained and valid; retained but requiring requalification; or reconstructed after wake. Static calibration constants protected by integrity checks may remain valid. A joint encoder offset may remain valid only if its power and mechanical assumptions persisted. Localization is often retained but requalified. Perception of people, obstacles and workpieces is reconstructed. Security keys may remain protected while sessions and permissions are renewed.
Warm resume is consequently not synonymous with immediate torque. TRAVEO T2G documentation illustrates the device-level restoration problem: in DeepSleep, high-frequency clocks stop, I/O cells freeze, retention is enabled and the active regulator is disabled; wake restores configuration, clocks and retained logic before the processor handles the interrupt. Hibernate wake occurs through reset. (Infineon AN220222) At robot scale, the equivalent restoration also includes physical truth. The software may be ready before the machine is justified in moving.
Visual pending: Systems concept
Gravity does not enter sleep mode
A humanoid is not a server with joints attached. Gravity, contact forces, hydraulic or elastic storage, payloads and unstable configurations remain present when clocks stop. If standing requires continuous torque, removing inverter power can cause collapse. If a gripper holds a component through motor current, sleeping the hand can release it. If a brake requires power to disengage, the transition sequence differs from a joint that is back-drivable.
Mechanical design therefore determines the reachable electrical states. Safe Standby while freestanding may retain balance control, inertial sensing and selected joint power, making it closer to Attentive Idle in energy terms. Deep Sleep may require sitting, kneeling, docking, a structural rest, counterbalance or normally engaged brakes. The pose and contact estimator becomes part of the transition guard: “enter Deep Sleep” is rejected until support is verified and stored energy is bounded.
The reverse path is equally constrained. A joint drive should not energize merely because its local controller booted. The system must know whether the limb moved while unpowered, whether brakes released as commanded, whether encoder references remain credible and whether a human entered the swept volume. A staged torque-enable process can energize control electronics, read sensors, establish position and current plausibility, release brakes under supervision and then grant limited torque before normal motion.
This coupling changes hardware choices. Low-leakage electronics matter, but mechanical latching, efficient brakes, absolute position sensing, domain-level current measurement and safe power switching may create larger system savings. A design review that treats power management as a board-level feature will miss the energy locked inside posture and contact strategy.
Zonal power control and hidden dependencies
Humanoids distribute electronics through the torso, limbs, hands and head. That topology creates a natural opportunity for zonal power: switch or reduce domains that are not required by the current task. It also creates dependency traps. A disabled limb controller may contain a communication bridge, terminator, clock consumer or safety participant required by another zone. A powered-down sensor may be the only source used to validate a wake. A shared DC/DC converter may prevent one branch from sleeping independently.
The power tree, communication architecture and safety concept must therefore be co-designed. Useful domain boundaries require independent switching or converter enable, controlled discharge, back-powering prevention, isolation-state definition and diagnostic feedback. High-side switches, e-fuses, gate drivers, voltage supervisors, current monitors and sequenced converters become part of the state machine. Their quiescent consumption matters because they remain multiplied across many zones, but their diagnostic coverage and failure behaviour matter more than the last microamp.
Networking needs explicit sleep semantics. A link that carries the only wake path cannot disappear without an alternate low-power receiver or local event source. Conversely, keeping every switch, PHY and endpoint active defeats zonal savings. Architectures can preserve a low-rate management or wake channel while suspending high-bandwidth paths, but the permitted latency and cybersecurity model must be defined. Remote wake is an authority boundary: an authenticated service request is different from arbitrary network traffic.
Cooling also follows domains. If high-performance compute is reduced, fans and pumps may continue until stored heat falls below a safe threshold. If actuators were hot, a thermal sensor and limited cooling path may remain active after motion stops. Immediate fan shutdown can reduce instantaneous power while increasing component temperature, restart delay or lifetime stress. Energy policy must therefore consider thermal state and forecast, not only present workload.
Power sequencing is itself a distributed control problem. Large input capacitors create inrush, converters may require stable upstream rails, and communication devices can back-power an unpowered controller through signal pins. A valid sequence defines enable order, discharge time, isolation state and diagnostic checkpoints. It also defines what happens when one rail misses its deadline. Continuing with a partially restored zone can be worse than returning to standby because software may see devices that are electrically present but not behaviourally qualified.
Diagnostics must survive the boundary they supervise. A current monitor placed behind the switch it is meant to verify disappears when the domain is off. A fault flag stored only in volatile local memory vanishes during recovery. Critical evidence therefore belongs on the always-on side or in nonvolatile event storage, with enough context to distinguish a commanded shutdown, protection trip and loss of supply. This detail turns field failures from folklore into analyzable transitions.
Hand and head zones illustrate the trade. A dexterous hand may contain many local controllers and sensors, but a waiting robot may require only grasp retention and slip detection. A head may reduce image processing while retaining low-power acoustic, proximity or human-interface detection. These are application decisions, not universal recipes. The required capability is stated first; electronics, mechanics and software then implement the cheapest credible readiness.
The practical test is simple: when one zone sleeps, can every other required capability still meet its readiness contract? If the answer depends on undocumented behaviour, the architecture does not yet own its low-power state.
Visual pending: Systems concept
The break-even mathematics of readiness
Deeper sleep is not always cheaper. Entering and leaving a state consumes energy, takes time and may impose wear or operational risk. If the power difference between two states is ΔP and the combined entry and exit energy is Etr, the energy-only break-even time is approximately tbe = Etr/ΔP. A rational controller chooses the deeper state only when the expected pause exceeds that interval, adjusted for readiness, uncertainty and safety.
The decision resembles a forecast under asymmetric consequences. Remaining too awake wastes energy. Sleeping too deeply can miss a task, lose context, delay a safety response or require expensive re-localization. Inputs include predicted idle duration, probability and urgency of interruption, current battery state, thermal condition, physical support, transition history, network availability and the confidence of the forecast. The policy should also include hysteresis so uncertain workloads do not cause rapid cycling between states.
A mission profile makes the opportunity visible. It records productive tasks and the intervals around them at sufficient resolution, then assigns readiness requirements rather than simplistic activity labels. Simulation can compare a fixed always-active baseline with state-aware policies, including transition energy and lost productive time. Sensitivity analysis reveals whether savings depend mainly on compute, posture power, network duty cycle, cooling or the duration of blocked intervals.
Fraunhofer's standing measurement offers an illustrative boundary, not a universal model. If a future architecture reduced a comparable standing interval by 100 W for four hours, the arithmetic saving would be 0.4 kWh before transition costs. Whether that is achievable depends on the robot, task, pose and domains; the calculation is deliberately conditional. Its purpose is to show why nonproductive duration can compete with visible motion as a design lever.
Policy must remain inspectable. Operators need to know why a robot entered a state, what woke it, how long restoration took and which requalification blocked motion. Event logs should connect energy telemetry, wake sources, state transitions and safety outcomes. Otherwise a false wake appears only as unexplained battery loss, while a failed resume appears as an intermittent robot fault.
Measure useful readiness, not a headline sleep current
A component sleep-current figure is necessary for budgeting and insufficient for judging the machine. A controller may consume microamps while joint electronics, a network switch, cameras and cooling remain awake. The system KPI must relate energy to productive output and the readiness contract.
Useful measures include mission energy; energy per productive hour or completed task; nonproductive-energy fraction; occupancy and average power of each state; transition energy; average, percentile and worst-case wake latency; false-wake rate; failed-transition rate; and the fraction of resumes that require localization, calibration or security requalification. Thermal recovery time and unplanned fallback to a higher-power state expose policies that look efficient in a static budget but fail in operation.
Verification should attack transitions, not only stable states. Tests need brownouts during wake, contradictory wake sources, expired credentials, moved robots, missing tools, hot actuators, network loss, sensor disagreement and batteries near protection thresholds. Fault injection should demonstrate that no sequence grants motion before the required evidence exists. Energy instrumentation needs enough bandwidth and domain resolution to capture inrush and short transitions that average telemetry can hide.
A useful validation campaign begins with a state-transition table rather than a demonstration script. Every permitted edge has preconditions, command ownership, maximum duration, expected telemetry, abort behaviour and a destination safe state. Every forbidden edge is tested as well. Full Active should not jump directly to Deep Sleep while a payload is suspended. Deep Sleep should not jump directly to unrestricted motion. A failed sensor requalification should lead to a bounded diagnostic state, not an improvised mixture of powered domains.
Latency needs a distribution, not one laboratory average. Scheduled wake from a stable dock can be predictable; network wake may wait for authentication and reconnection; perception wake depends on lighting, scene complexity and accelerator initialization. The contract should specify percentiles and worst-case conditions that the application can plan around. If a production cell requires a guaranteed response, the orchestration system may wake the robot before material arrives rather than demanding an impossible instant resume.
Energy measurement needs the same discipline. Domain rails should be observed with synchronized timestamps so that savings are not displaced into an upstream converter or cooling loop. Transition energy must include the period until useful work resumes, not merely the boot pulse. A policy that saves watt-hours but adds repeated seconds of production delay may be unattractive even when its electrical result is positive. Energy, readiness and throughput belong in the same dataset.
Semiconductor selection follows the contract. The always-on domain values low quiescent current, deterministic wake, retained memory, secure key handling, monitoring and independent clocking. Zonal domains value efficient conversion across their load range, controllable power switches, current and voltage diagnostics, safe-state behaviour and predictable sequencing. Compute values scalable performance, telemetry and software-controlled power profiles. Sensors value low-power event detection. Networking values wake capability, topology independence and bounded reconnection. No single device creates the architecture; compatible behaviours across devices do.
Ownership is the final technical requirement. A cross-functional power-state specification must be maintained like a safety or network architecture. Mechanical, electrical, embedded, AI, cybersecurity, thermal and application teams each control conditions that can invalidate a transition. When responsibility is fragmented, the robot remains fully awake because full activity is the only state everyone has tested.
Sleep is a system capability
The question “Is the robot ready?” has no binary answer. It may be ready to balance, ready to observe, ready to receive an authenticated task, ready to resume manipulation, or ready only to protect its battery and record a wake event. Each level has an energy price and an obligation.
A five-state architecture gives those obligations a common language. Full Active and Task Active align capability with the job. Attentive Idle protects response during short uncertainty. Safe Standby withdraws major domains under independent supervision. Deep Sleep accepts longer reconstruction when the physical machine is secured. Wake contracts, retained-state rules and mechanical transition guards connect the states into a safe operating system for the whole body.
The most important design decision is not the minimum current of the deepest mode. It is whether the robot can repeatedly descend to the lowest state consistent with its present duty, then return with digital and physical truth re-established before motion. That capability converts waiting time into usable runtime without trading away trust.
Physical AI becomes more intelligent when it knows how much of itself must remain awake.