Humanoid robots: what the demos never show you

Humanoid robot demos show 90 seconds of tight framing and promise mass production. They never show what a test bench sees: the heat, the electromagnetic noise, the harnesses and the certification file. At AESTECHNO, an electronics design firm in Montpellier, France, we qualify the dense electronics these machines are made of, from NVIDIA Jetson compute modules to multi-axis motor controllers. Here is what the demo hides. Published July 2026.

What a humanoid robot demo actually shows

A demo is a controlled presentation of a point capability, edited under optimal conditions: fresh battery, managed environment, task repeated until successful. A product is the same machine proving its endurance over a realistic usage profile, without stopping, for dozens of minutes. This distinction defines industrialisation.

A humanoid robot demo is a short, edited sequence shot under chosen conditions: fresh battery, temperate room, flat floor, a task repeated until the successful take. It proves an instantaneous capability, not a product. The difference between the two is exactly what this trade calls industrialisation.

Three pieces of information are systematically missing. Time first: the video says neither how long the robot has been running nor how long it can continue. Heat next: a machine that just started and the same machine after 45 minutes of sustained load are two different thermal objects. Cables last: the camera never lingers on the harnesses crossing the joints, nor on any control infrastructure off-frame that might exist.

The real product is not the robot in the demo: it is the robot 45 minutes later, once everything has heated up. Everything below follows from that sentence.

The power budget the video never shows

A power budget quantifies the total electrical draw between two full recharges: all actuators, all compute modules, all sensors and all power conversion stages, measured over a realistic mission profile. This metric determines real autonomy and battery sizing.

The power budget of a humanoid robot is the sum of everything that draws current between two charges: dozens of actuators, one or more inference computers, the sensors, the power conversion stages, all served by a battery the machine itself must carry. A watts-per-kilogram problem before it is an algorithms problem.

Physics is stubborn. A Li-ion NMC cell stores about 250 Wh/kg: every watt-hour on board adds mass the legs must then carry, which draws more power. Unlike an electric vehicle, the machine spends energy even standing still, because holding a bipedal posture demands permanent holding torque in many joints. According to NVIDIA, a Jetson Orin NX delivers 70 to 100 TOPS of edge AI inference within 10 to 25 W: the brain alone draws as much as a light bulb before the first step, and the PyTorch, TensorFlow or ONNX perception models claim that whole envelope.

Then comes conversion: every power stage between the battery and the dozens of rails dissipates its losses inside a sealed volume. In our practice of embedded power management, we spend weeks winning back microamps; a humanoid plays the same game, four orders of magnitude up, with no ventilated wall.

Why does the robot's brain cook inside a sealed box?

Thermal throttling is the automatic frequency reduction of a processor when its temperature exceeds a critical threshold, to prevent thermal destruction. This reduction degrades real-time performance and transforms a nominal computer into a degraded one.

The thermal problem of a humanoid means evacuating the heat of an inference computer and dozens of motor drivers out of sealed volumes, with no fixed cold surface and with vents limited by aesthetics and ingress protection. The least spectacular wall, and the most frequent one.

The perception computers, NVIDIA's Jetson family first among them, are sized for precise thermal budgets (10 to 25 W for an Orin NX). In Q1 2026 we delivered a Jetson Orin NX project with a fully custom Board Support Package (BSP), built under Yocto for an industrial customer: a significant share of the work was not software but thermal, because a SoC of this class in a sealed enclosure drops its frequencies as soon as dissipation falls behind. A 90-second demo never throttles. A 45-minute mission does.

Contrary to the common assumption, a fan fixes nothing: cooling is decided at PCB layout time (thermal vias, copper planes), then verified in a climate chamber from -40 °C to +85 °C per IEC 60068-2-1 and 60068-2-2, on a realistic mission profile, down to the exact point where the machine starts lying about its performance.

The EMC war inside the skeleton

Internal electromagnetic compatibility (internal EMC) is the ability of electronic systems to coexist without interference in a sealed volume: noise generators (PWM drivers, power supplies) must not pollute sensitive sensors (IMUs, encoders) through radiation or conduction.

The internal electromagnetic compatibility of a humanoid means the cohabitation, within a few litres, of dozens of pulse-width modulation (PWM) motor drivers switching tens of amps and the machine's most sensitive sensors: inertial measurement units (IMU), encoders, microphones. Every joint is both an aggressor and a victim.

A modern motor driver is a switching converter: sharp edges, high currents, radiating loops. Multiply by the number of joints, enclose everything in a metal skeleton that behaves like a cavity, and add inertial sensors whose precision conditions balance. On our vibration sensing projects, we used the IIS3DWB, sampled according to STMicroelectronics at up to 26 kHz: its noise floor degrades fast if the power supply, the ground plane and the routing are neglected. A humanoid is that problem repeated at every joint, plus external EMC: the same emissions and immunity tests as any equipment, swept from 30 MHz to 6 GHz (CISPR 32 for emissions, IEC 61000-4-2 and IEC 61000-4-3 for immunity). In our EMC practice, first-pass failures almost always come from EMC discovered at the lab rather than decided at the schematic.

The nervous system: harnesses that flex millions of times

An electrical harness is the assembly of power and data cables routed through a mechanical structure. Its engineering management covers bend-radius selection, fatigue protection, shielding and error-free series-production assembly.

The nervous system of a humanoid robot means the power and data harnesses that cross its joints: power to every actuator, encoder feedback, sensor buses, video links. Everyone watches the robot's brain; we watch its nervous system, because that is what breaks.

A cable crossing a knee is flexed at every step, inside a sealed volume, with a bend radius imposed by the mechanics rather than by the cable maker. The failure modes are known to every integrator: conductors that fatigue, shields that open, connectors that micro-cut under vibration, ground returns that degrade. Every harness failure first presents as an intermittent software bug, which makes these the most expensive faults to diagnose.

It is also a manufacturing problem: routing those harnesses through sealed limbs, making them assemblable in series and replaceable in maintenance is Design for Manufacturing at its most demanding. A demo gets cabled once; a product, thousands of times, without error.

Field report: qualifying a robot's brain before the robot

On a recent embedded-computer project, in our AESTECHNO lab in Montpellier, we built under Yocto a fully custom BSP for a Jetson Orin NX module, including custom layers and kernel configuration, then qualified the platform on an industrial mission profile. Our qualification methodology stays constant on every computer of this class: signal-integrity characterisation on the Tektronix TekExpress bench for the fast memory interfaces (stack-up and controlled impedance validated upstream), thermal qualification in a climate chamber from -40 °C to +85 °C per IEC 60068-2-1 and IEC 60068-2-2, power profiling with the Nordic PPK2 on the critical rails, and a pre-compliance EMC sweep in the chamber. Contrary to the common assumption that a robot's difficulty lives in its software, we found that the weeks are lost in the triangle of heat, power and signal integrity, well before the first line of intelligence.

The same lesson on the actuator side

The field report from our multi-axis motor control projects confirms the same pattern on the actuator side: we designed a multi-axis stepper board with jerk-limited profiles for very-low-vibration applications, and most of the effort went into vibration, noise and thermal, not into the control law. In our practice across dense mechatronic systems, we have observed that every subsystem taken in isolation is a solved problem; their cohabitation in a sealed volume is not. Despite the legitimate excitement around embedded AI, we recommend instrumenting the thermal budget and the power budget first: they decide whether the demo becomes a product.

Can you certify a machine that falls?

Certifying a humanoid robot means bringing it under the European machinery framework: CE marking under the Machinery Regulation (EU) 2023/1230, which replaces Directive 2006/42/EC and becomes applicable on 20 January 2027, with explicit requirements for autonomous machines and AI-driven safety functions.

So the framework exists. The difficulty lies elsewhere: according to DEKRA, a notified body, the transition to Regulation 2023/1230 should be prepared now; but the robot-safety references, carried notably by the IEEE and ISO, were built for machines that do not fall. The force and pressure limits of collaborative robotics (ISO/TS 15066, complementing ISO 10218) assume a fixed base and reduced speeds near humans. A biped introduces the failure mode those grids do not model: the fall. We know how to certify an arm bolted to the floor; a machine whose failure mode is falling on someone is another story.

That is why the first real deployments remain industrial, zoned and supervised: a controlled environment turns a general-safety problem into a classic risk analysis. For a manufacturer, the lesson is the same as on our CE certification files: the regulatory path is chosen together with the architecture, not after the demo.

The demo versus the product: the table

The table below summarises the gap between what a humanoid robot demo proves and what a product will have to demonstrate, domain by domain: energy, thermal, electromagnetic compatibility, harnesses and safety. Each line is a full engineering discipline with its standardised tests, its instruments and its weeks of bench time. A demo does not need to win on any of these lines; a product must win on all of them, simultaneously, inside the same mass and cost envelope. The sum of these lines, not the machine's intelligence, is what separates the video from a product you can sell, insure and maintain.

Bottom line

The gap between a humanoid robot demo and a sellable product is a gap of electronics integration and certification, not of artificial intelligence. A demo hides three things, time, heat and cables, and each one maps to a measurable engineering wall: a power budget carried by the machine itself, a 10-to-25 W computer to cool inside sealed volumes, dozens of drivers to reconcile with the sensors, harnesses flexed at every step, and a CE marking whose references were not written for machines that fall. Those walls are crossed on the bench, far from the cameras, and that is precisely the job of a design firm.

Key takeaways:

• A demo proves an instantaneous capability; a product proves endurance: the referee is the machine after 45 minutes of sustained load.
• The power budget of a carried battery and the cooling of sealed volumes are decided at architecture time, not at debug time.
• Dozens of PWM drivers next to IMUs and encoders make every joint an internal EMC case to settle at the schematic.
• Harnesses flexed at every movement are the first intermittent failure mode, and a series-manufacturing challenge in their own right.
• The Machinery Regulation (EU) 2023/1230, applicable 20 January 2027, frames autonomous machines; a biped's fall remains the failure mode today's grids model least well.

FAQ: humanoid robots seen from an electronic design firm

The questions below reflect what we answer to journalists and industrial players about the real difficulty of humanoid robots, from an electronics design company's point of view: measurable and verifiable.

Why are humanoid robots so hard to build?
Because every subsystem solved in isolation (compute, actuator, sensor, battery) must cohabit inside a sealed, carried volume. Heat, the power budget, internal electromagnetic compatibility and permanently flexed harnesses form an integration problem that artificial intelligence does not solve.

Isn't AI the main bottleneck?
No. Perception and control models progress fast and can be tested in simulation. What cannot be simulated cheaply is a SoC throttling inside a sealed torso, an encoder polluted by a motor driver, or a harness fatiguing inside a knee. Those walls are crossed on the test bench, not in the cloud.

What does a humanoid robot demo hide most often?
Time, heat and cables: the real battery runtime, the machine's thermal state after sustained load, and the off-frame infrastructure such as power cables or a prepared environment. The exact control conditions and demo limitations are rarely specified.

Can a humanoid robot get CE marking today?
The framework exists: the Machinery Regulation (EU) 2023/1230, applicable 20 January 2027, covers autonomous machines and AI-driven safety functions. But the force limits of collaborative robotics (ISO/TS 15066) assume a fixed base: a biped's fall remains a poorly covered failure mode, hence deployments that start industrial and zoned.

Which design firm skills apply to humanoid robots?
Exactly those of dense mechatronic products: thermal qualification in a climate chamber, power budgeting and consumption profiling, pre-compliance EMC, signal integrity of fast memory interfaces, multi-axis motor control and Design for Manufacturing of the harnesses and boards.

Related articles

To go deeper on the technical building blocks of this investigation:

• NVIDIA Jetson Orin for embedded AI: the inference computer and its integration constraints
• Stepper motors and drivers: torque, microstepping and low-vibration profiles
• Electromagnetic compatibility: emissions, immunity and pre-compliance in chamber
• Embedded power management: making a battery last on a real mission profile
• Why no one builds new CRT TVs: the previous investigation, quoted by TechRadar