How to Compare Humanoid Speed, Payload and Strength Claims

Speed and strength claims for humanoids often use incompatible tests. A short straight-line run is different from sustained walking through a factory, while arm payload, total carried load and grip force measure different capabilities. This article records only named robots, dated demonstrations and official specifications. It separates measured or demonstrated results from targets and avoids combining static and dynamic lifts.

For speed, the method records surface, distance, tether status, duration and whether the robot turns or avoids obstacles. For strength, it records load location, lift height, duration, support posture and whether the task is repeated.

In a practical fastest humanoid robot deployment, every action is followed by measurement and a confidence check. The system then continues, adjusts its plan or falls back to a safe state.

Unitree publishes speed figures for H1 and G1 variants, Boston Dynamics shows dynamic Atlas motions, and industrial humanoid makers publish payload targets. Public protocols remain inconsistent. The systems are not treated as interchangeable.

The current table uses a timed competition result and a manufacturer payload specification as separate examples. They answer different engineering questions and are not combined into a composite score.

Video can confirm that an action occurred, but usually cannot verify calibrated speed, load mass, control mode or repeatability without supporting documentation. Real-system evidence is separated from simulation, internal testing, controlled public demonstrations, pilots and commercial deployment.

A reproducible speed or strength result needs the robot version, measurement method, distance or load, surface, support conditions, trial count and whether a tether or external assistance was used. Missing fields keep the claim in a bounded demonstration category.

The comparison keeps timed race results, manufacturer speed claims, sustained payload, instantaneous payload and one-handed capacity in separate fields. A shared ranking would require the same protocol, surface, load definition and trial rules.

For procurement, reproduce the intended route, payload, duty cycle and safety envelope and record all attempts rather than the fastest successful clip.

Failure modes include sped-up footage, hidden tethers, favorable surfaces, unverified object masses, one successful attempt and robots operating outside sustained thermal limits.

A race time from one robot version does not establish sustained factory speed, and an arm payload specification does not establish whole-body carrying performance. Version, test setup and measurement method remain attached to every claim.

The records are useful for narrowing research questions, not for declaring a universal winner. Procurement tests should reproduce the intended load, route, duty cycle and safety envelope. These uses are credible only within the documented task, robot and environment.

A useful deployment test repeats the intended route or lift many times and reports thermal limits, balance failures, dropped loads, interventions and recovery time. Peak speed or one successful lift is not a reliability metric.

Open questions include whether common humanoid performance protocols will emerge, how dynamic balance should be included in payload ratings and which future records will use third-party timing or calibrated loads.

Future record claims should publish the robot version, measurement equipment, surface or load, assistance or tether status, trial count and failed attempts. Those fields are more useful than a composite 'fastest and strongest' label.