This chapter argues that humanoid robotics needs a shared mission profile: a time-resolved, manufacturer-neutral workload that makes energy, thermal, runtime, actuator, battery, compute, and semiconductor results reproducible. The proposed DXresearch Humanoid Mission Profile, or DHMP, begins with a five-minute reference family containing 300 one-second records. It does not declare a finished international standard. It provides an open engineering proposition that can be tested, criticized, measured, and eventually transferred into consensus standardization.
The central thesis is simple: without a common workload, published runtime, efficiency, thermal performance, and component value remain fundamentally incomparable.
The Missing Measurement Language
A humanoid robot is not a single machine load. It is a moving network of actuators, inverters, sensors, processors, communications links, safety functions, converters, and thermal paths. During one minute it may stand quietly while camera pipelines and world models consume most of the electrical power. During the next it may accelerate its full body, carry a payload, arrest a fall, or hold an awkward posture that produces little mechanical motion but substantial RMS current and copper loss.
Manufacturers commonly publish mass, battery capacity, payload, degrees of freedom, joint torque, speed, and nominal operating time. These specifications are useful, but their engineering meaning is incomplete unless the associated workload and boundary conditions are disclosed. Four hours of “typical use” cannot be compared with three hours measured under another manufacturer’s undisclosed sequence. A low average power may reflect efficient actuation, but it may also reflect long idle intervals, a small payload, reduced compute, or conservative motion.
Automotive engineering faced a related problem. The Worldwide Harmonized Light Vehicles Test Procedure does not claim to reproduce every possible journey. It creates a controlled demand history and associated test conditions so that vehicles, batteries, powertrains, and control strategies can be evaluated on a common basis. The analogy is methodological, not literal. A humanoid needs more than a speed trace because zero translational speed can describe both low-load standing and high-load manipulation.
A common mission does not make robots identical. It makes the consequences of their differences measurable.
What Existing Benchmarks Already Solve—and What They Do Not
The proposed framework starts from a mature body of robotics test work and from the source DHMP methodology. DXresearch DHMP manuscript v0.2 The ISO 18646 series provides performance criteria and related test methods for service-robot navigation, manipulation, and legged locomotion. ISO 18646-5:2026 addresses complete-machine locomotion performance for legged robots. ISO 18646-2:2024 and ISO 18646-3:2021 address navigation and manipulation. These standards establish terminology, apparatuses, metrics, and repeatable capability tests. They do not prescribe a combined second-by-second workload spanning walking, payload handling, perception, compute, recovery, and auxiliaries.
NIST and ASTM response-robot methods offer another strong precedent. NIST test-method catalogue The NIST response-robot programme separates elemental capability testing from increasingly realistic operational scenarios and covers mobility, manipulation, sensing, energy, communications, logistics, endurance, and safety. More than fifty ground, aerial, and maritime methods have been developed and replicated. Their procedural discipline is directly relevant to humanoids, even though their target systems and operational context differ.
EUROBENCH advanced reproducibility for bipedal and wearable robots through shared facilities, protocols, performance indicators, and structured experiment data. EUROBENCH data format HumanoidBench provides 27 simulated whole-body locomotion and manipulation tasks for algorithm research. Fraunhofer IPA’s 2026 benchmark adds application-relevant assessment of humanoid capabilities, energy efficiency, safety, cybersecurity, and other deployment criteria. Fraunhofer IPA humanoid benchmark These initiatives solve important pieces of the evaluation problem. None yet functions as a broadly adopted equivalent of an integrated humanoid system duty cycle.
| Approach | Primary question | Strength | Remaining gap |
|---|---|---|---|
| Capability standard | Can the robot perform a defined function? | Controlled apparatus and metric | No integrated workload sequence |
| Task benchmark | Can a policy solve a task? | Algorithm comparison and repeatability | Often omits battery and electrothermal realism |
| Deployment profile | Can the robot work at one specific site? | High operational relevance | Not portable across customers and platforms |
| Reference mission | How does the complete system behave under shared demand? | Cross-platform energy, thermal, and runtime comparison | Requires community validation and governance |
DHMP: Standardize the Workload, Not the Robot
DHMP uses a layered architecture. The first layer states what the robot must do and when. The second translates that mission into robot-specific motion. The third derives torque, speed, contact, current, and power. The fourth propagates electrical losses into battery and thermal states. The final layer reports comparable outcomes such as energy per cycle, runtime, peak power, thermal margin, and completed tasks.
This separation is essential. A manufacturer may use high-ratio geared actuators; another may use lower-ratio, more backdrivable joints. One robot may use a 72 V battery with distributed inverters, while another uses a higher-voltage backbone. One may execute the same walking segment with long strides; another with short, frequent steps. DHMP does not suppress those differences. It exposes how each choice changes the system result.
The framework assigns an evidence class to every material input. Values may be verified from a primary source, derived from verified data, calibrated against measurement, assumed for concept work, defined as an engineering envelope, or left unknown. This prevents a polished simulation from implying confidence that its inputs do not justify.
The Five-Minute Reference Family
The first implementation, DHMP-5, contains exactly 300 one-second records. Five minutes is long enough to combine system initialization, standing, walking, approach, manipulation, loaded movement, placement, recovery, and inspection, while remaining practical for simulation and laboratory execution. The cycle is repeated with continuous battery and thermal states until a defined termination condition is reached.
| Time | Phase | Representative activity | Dominant system demand |
|---|---|---|---|
| 0–19 s | Boot and self-check | Initialize control, perception, and safety | Compute, sensing, system readiness |
| 20–49 s | Idle perception | Stand and scan environment | Perception, compute, standing control |
| 50–89 s | Transit | Walk to workstation at 0.8 m/s | Locomotion, balance, communications |
| 90–119 s | Approach | Slow approach and alignment | Planning, balance, precision positioning |
| 120–149 s | Pick | Reach and grasp a 5 kg payload | Upper-body actuation, grip, perception |
| 150–189 s | Loaded transit | Carry payload at 0.55 m/s | Locomotion, payload support, stability |
| 190–219 s | Place | Align and place payload | Arm actuation, waist, precision control |
| 220–249 s | Recovery transit | Walk unloaded with turn | Lower body, lateral control, timing |
| 250–269 s | Dynamic event | Step-over and disturbance recovery | Peak power, current, balance response |
| 270–289 s | Inspection | Stand and inspect | Perception, inference, static holding |
| 290–299 s | Safe stop | Return to controlled idle | State transition, diagnostics, reporting |
Three additional profiles retain the same duration and data structure. DHMP-5L emphasizes logistics and loaded walking. DHMP-5A emphasizes bimanual assembly, posture holding, tool exchange, and compute-intensive inspection. DHMP-5M emphasizes ramps, stairs, uneven terrain, fast walking, and recovery. The composite profile is the general comparison baseline; the application profiles reveal how architecture choices shift when the dominant work changes.
One-second resolution is suitable for mission states, energy integration, battery state of charge, and slow thermal networks. It is not sufficient for motor current control, impact, inverter switching, or balance-loop dynamics. The required solution is multirate reporting: higher-frequency simulation or measurement produces average, RMS, minimum, and peak descriptors for each one-second record.
Reference Robots Without Inventing a Universal Humanoid
DHMP requires a workload definition, not a mandatory reference body. Nevertheless, transparent reference classes are useful when proprietary robot data are unavailable. The source study uses Boston Dynamics Atlas as a high-capability industrial boundary and Unitree H2 as a public parameter anchor.
Boston Dynamics publishes Atlas at 1.9 m, 90 kg, 56 degrees of freedom, 2.3 m reach, 30 kg sustained payload, 50 kg instantaneous capacity, IP67, and an operating range from −20°C to +40°C. Its specification sheet states four hours of battery life under typical use, two hours with heavy lifting, and autonomous battery swap in approximately three minutes. These are manufacturer claims tied to the product configuration and not a standardized DHMP result. Atlas product page Atlas specification sheet
Unitree publishes H2 at approximately 70 kg including battery, 1.82 m height, and 31 motorized joints. It lists 120 N·m maximum arm-joint torque, 360 N·m maximum leg-joint torque, approximately 7 kg rated and 15 kg peak arm payload, a 15 Ah/0.972 kWh battery, 75.6 V maximum voltage, local air cooling, and approximately three hours of battery life. The company explicitly notes that parameters vary by configuration and scenario. Unitree H2 specifications
An intermediate H80 class is therefore defined as a modelling construct: 80 kg total mass, 1.85 m height, 31 primary body joints, 10 kg nominal payload, 72 V nominal battery architecture, and 1.5 kWh installed battery energy. H70 and H90 classes provide sensitivity boundaries. None reconstructs a proprietary platform.
From Motion to Silicon
The industrial value of a mission profile appears when system behaviour is translated into component requirements. A motion segment becomes a joint torque-speed trajectory. The actuator model converts torque into motor current. The inverter model converts current and voltage into conduction and switching loss. The thermal model converts loss into winding, housing, and junction temperature. The battery model integrates bus power and regeneration into SOC, voltage sag, and temperature.
For joint j, mechanical power is the product of torque and angular velocity:
P_mech,j(t) = τ_j(t) · ω_j(t)
Positive power represents actuator work. Negative power indicates mechanical energy flowing toward the actuator, but it does not guarantee battery recovery. Regeneration depends on transmission backdrivability, inverter operation, simultaneous bus loads, battery charge acceptance, SOC, and protection limits. DHMP therefore distinguishes negative mechanical energy from recovered electrical energy.
A geared permanent-magnet motor can be approximated by:
τ_joint,j = K_t,j · I_q,j · N_j · η_g,j
Copper loss depends on RMS current and temperature-dependent phase resistance:
P_Cu,j = 3 · I_ph,rms,j² · R_ph,j(T)
The complete DC-link demand adds joint electrical power, compute, sensing, communications, cooling, safety, and auxiliary rails. This is where the mission profile connects behaviour to semiconductor selection.
Motor-control microcontrollers
The dynamic-event and precision-manipulation phases place different requirements on real-time controllers. Disturbance recovery demands deterministic current loops, synchronized sampling, fast protection, and coordinated multi-axis control. Precision placement requires low-noise sensing, high-resolution position feedback, and stable torque at low speed. A common mission allows MCU and control-software teams to report processor loading, control latency, missed deadlines, and energy against the same operational sequence.
Power semiconductors and gate drivers
Inverter technology should be compared under identical bus voltage, current history, switching frequency, cooling, and modulation assumptions. Silicon MOSFETs, gallium-nitride devices, and other technologies may trade conduction loss, switching loss, electromagnetic emissions, cost, packaging, and fault ruggedness differently. The relevant output is not a catalogue figure of merit; it is energy and temperature under the mission's torque-speed envelope.
Current, position, and temperature sensing
Joint current sensors must capture RMS loading and fast overcurrent events. Magnetic and inductive position sensors must maintain accuracy near high-current switching nodes. Temperature sensing and model-based observers determine available thermal margin and permit controlled thermal derating rather than abrupt shutdown. DHMP can identify which phases should be used to validate sensor bandwidth, drift, immunity, and diagnostic coverage.
Compute and memory
Perception and inference are not negligible auxiliaries. Inspection and approach phases may shift the power balance from actuation toward cameras, accelerators, memory bandwidth, and cooling. A lighter robot does not automatically consume proportionally less power because compute, sensing, safety, and communications create a mass-independent floor. Mission-level measurement therefore reveals the energy value of neural-network optimization, dynamic power management, and memory architecture.
Connectivity, synchronization, and diagnostics
A distributed humanoid requires synchronized sensor sampling, coordinated motor control, deterministic safety communication, and high-volume perception data. The mission provides event markers against which timing error, packet latency, bus utilization, diagnostic coverage, and fault recovery can be measured. Loaded transit and disturbance recovery are particularly useful for observing how communication and control margins behave under simultaneous system stress.
Functional safety and cybersecurity
DHMP is not a safety certification procedure. It can, however, define repeatable operational contexts for testing safety functions and cyber-resilience. The safe-stop phase can verify controlled transition, diagnostic reporting, and energy isolation. The boot phase can exercise secure startup and identity. Networked update, fleet, and teleoperation functions create cybersecurity requirements whose computational and timing cost belongs in the system workload. The ISO/TC 299 work programme includes dynamically stable mobile-robot safety and broader robotics safety activities, reinforcing the need to align benchmark evolution with formal safety work rather than substitute for it. ISO/TC 299 work programme
Battery Runtime Is a Result, Not a Specification
The simplest runtime relationship is usable battery energy divided by average battery power. Yet both terms depend on definitions. Installed energy is reduced by SOC limits, ageing, reserve, temperature, and power capability. Average power depends on mission, payload, mass, control, actuators, compute, cooling, and regeneration.
The source workbook separates a fixed power floor from mass-dependent mechanical demand. DHMP workbook v0.2 For an illustrative 55 kg robot, 3.0 kWh installed battery, 90% usable energy, and 300 W fixed load, the 80 kg profile values are scaled by the mass ratio 55/80. This is an engineering illustration rather than a validated physical model.
| Profile | H80 mean power | 55 kg scaled power | Energy per cycle | Idealized runtime |
|---|---|---|---|---|
| Composite | 591.2 W | 500 W | 41.7 Wh | 5.4 h |
| Logistics | 702.1 W | 576 W | 48.0 Wh | 4.7 h |
| Assembly | 518.9 W | 451 W | 37.6 Wh | 6.0 h |
| Mobility | 699.9 W | 575 W | 47.9 Wh | 4.7 h |
The range is more informative than a single runtime claim. Assembly reduces locomotion energy but may produce sustained shoulder, elbow, hand, and compute loading. Mobility increases hip, knee, ankle, and peak bus demand. Logistics stresses repeated loaded transport. A future joint-level model may change the numbers, but the structure of the comparison remains valid.
Energy may not be the first limit. A large battery can keep SOC high while a knee motor, inverter, gearbox, battery cell, or AI module reaches its thermal threshold. A repeated-cycle simulation must carry every thermal state forward. Resetting temperatures every five minutes would invalidate the prediction.
Conformance, Validation, and the Difference Between a Benchmark and a Score
DHMP should initially define conformance to execution and reporting, not a minimum performance grade. A robot can conform while consuming high energy or failing a phase, provided the failure and deviation are disclosed. This avoids collapsing unlike system objectives into one opaque score.
| Level | Scope | Minimum evidence |
|---|---|---|
| 0 | Mission execution | Profile, configuration, completion, timing, deviations |
| 1 | System energy | Battery power, energy per cycle, SOC, estimated runtime |
| 2 | Subsystem energy | Actuation, compute, sensing, cooling, communications, auxiliaries |
| 3 | Joint electrothermal | Torque, speed, current, loss, actuator and semiconductor temperature |
| 4 | Validated digital twin | Measured-to-simulated correlation, error, uncertainty, validity range |
Validation should progress from formula and file checks to independent simulation implementations, one instrumented robot, multiple robot classes, multiple laboratories, and field correlation. The most important measurements are battery voltage and current, joint position and speed, measured or estimated torque, phase current, compute and auxiliary rail power, relevant temperatures, payload position, ambient conditions, and synchronized mission events.
Repeatability asks whether one laboratory obtains stable results from repeated execution. Reproducibility asks whether independent laboratories interpret the mission and reporting rules similarly. Field correlation asks whether DHMP trends align with real applications even though the reference cycle is not a literal copy of one customer site.
Governance: From Reference Proposal to Industry Standard
The initiative should be explicit about maturity. DHMP is currently a public reference proposal. A validated industry benchmark would require multi-platform evidence, controlled revision, and independent replication. A consensus standard would require a recognized standards process.
DXresearch can initiate the package, maintain the repository, curate evidence, and convene contributors. It should not claim sole authority. A durable governance model needs robot OEMs, industrial users, universities, test laboratories, actuator and battery suppliers, semiconductor companies, simulation vendors, and safety experts.
Changes to phase timing, payload, environment, or required signals should follow documented proposals, evidence, public review, and version control. Frozen revisions must remain available so that historical results stay interpretable. New profiles should inherit the same data schema and evidence rules to prevent fragmentation.
Formal engagement with ISO, IEEE, ASTM, or other organizations should occur after physical validation and community participation. The objective is to contribute a working method, datasets, and lessons learned—not to pre-empt consensus.
What Must Improve Next
The present proposal is deliberately incomplete. The profiles are engineering constructs rather than statistically derived field cycles. H80 is not a reconstruction of Atlas, H2, or another product. The workbook uses normalized joint-group utilization and generic power coefficients rather than complete 31-joint torque-speed-current traces. Payload position, turn geometry, friction, stair fixtures, disturbance magnitude, and manipulation geometry need more precise definitions.
The next technical release should add a reference URDF or morphology-neutral joint mapping, higher-frequency trajectories, actuator maps, inverter loss interfaces, battery voltage and thermal models, and repeated-cycle electrothermal simulation. The next experimental release should publish an instrumented execution with uncertainty and measurement synchronization.
These limitations are not reasons to postpone a shared mission. They are reasons to publish the assumptions openly and improve them through use.
Strategic Synthesis
Humanoid robotics is moving from capability theatre toward industrial engineering. That transition requires a change in the questions the industry asks. “Can the robot lift this object?” must be followed by “How many times can it lift, carry, and place the object before energy, temperature, reliability, or availability becomes limiting?”
A shared mission profile provides the missing bridge. It connects human-scale work to joint trajectories; joint trajectories to current and losses; losses to temperatures and battery demand; and those states to runtime, reliability, and economics. For semiconductor developers, it turns vague claims about the value of faster control, lower loss, better sensing, deterministic connectivity, and robust diagnostics into testable system outcomes.
DHMP should not become a rigid definition of the “correct” humanoid. Its purpose is narrower and more powerful: to establish what was tested, under which conditions, with which assumptions, and with what result. That is the foundation on which credible comparison, efficient co-design, and eventual standardization can be built.
Conclusion
The absence of a common humanoid workload leaves runtime, energy, thermal, and subsystem claims difficult to compare. Existing standards and benchmarks provide strong capability methods, but they do not yet supply one broadly adopted integrated mission trace. DHMP proposes a five-minute, one-second-resolution family that separates mission definition from robot implementation and connects behaviour to mechanical, electrical, thermal, battery, compute, safety, and semiconductor consequences.
The framework is not a finished standard and the illustrative values are not product claims. Its value is transparency. A common workload makes assumptions visible, enables repeatable simulation and measurement, and gives the industry a shared language for improving the complete Physical AI system.
References
- United Nations Economic Commission for Europe, “UN Global Technical Regulation No. 15: Worldwide harmonized Light vehicles Test Procedures.” https://unece.org/sites/default/files/2022-06/ECE-TRANS-180a15am6e.pdf
- International Organization for Standardization, “ISO/TC 299 Robotics — Standards catalogue and work programme.” https://www.iso.org/committee/5915511/x/catalogue/
- International Organization for Standardization, “ISO 18646-5:2026 Robotics — Performance criteria and related test methods for service robots — Part 5: Locomotion for legged robots.” https://www.iso.org/standard/86850.html
- International Organization for Standardization, “ISO 18646-2:2024 Robotics — Performance criteria and related test methods for service robots — Part 2: Navigation.” https://www.iso.org/standard/76545.html
- International Organization for Standardization, “ISO 18646-3:2021 Robotics — Performance criteria and related test methods for service robots — Part 3: Manipulation.” https://www.iso.org/standard/69058.html
- National Institute of Standards and Technology, “Standard Test Methods for Response Robots.” https://www.nist.gov/el/intelligent-systems-division-73500/standard-test-methods-response-robots
- National Institute of Standards and Technology, “Response Robot Test Methods.” https://www.nist.gov/el/intelligent-systems-division-73500/test-methods
- European Commission CORDIS, “EUROBENCH — European Robotic Framework for Bipedal Locomotion Benchmarking.” https://cordis.europa.eu/project/id/779963/results
- EUROBENCH Consortium, “EUROBENCH Software Documentation and Data Format.” https://eurobench.github.io/sofware_documentation/latest/data_format.html
- Fraunhofer IPA, “Fraunhofer IPA develops standardized analyses for application-relevant criteria of humanoid robots.” https://www.ipa.fraunhofer.de/en/press-media/press_releases/benchmark-for-humanoid-robots.html
- University of California, Berkeley and Yonsei University, “HumanoidBench: Simulated Humanoid Benchmark for Whole-Body Locomotion and Manipulation.” https://humanoid-bench.github.io/
- Boston Dynamics, “Atlas Humanoid Robot.” https://bostondynamics.com/products/atlas/
- Boston Dynamics, “Atlas Specification Sheet.” https://bostondynamics.com/wp-content/uploads/2026/01/atlas-spec-sheet.pdf
- Unitree Robotics, “Unitree H2 Destiny Awakening — Product Parameters.” https://www.unitree.com/mobile/H2/
- DXresearch, “An Open Reference Mission Profile for Humanoid Robots: A Framework for System-Level Energy, Thermal, Electrical, and Runtime Evaluation.” DXresearch source document.
- DXresearch, “Humanoid Mission Cycle 5 min v0.2 — Atlas, H2, and H80.” DXresearch source document.