Humanoid Robotics as Embodied Systems Science from Software, Hardware, and Environment

Bodies in the Loop

A humanoid robot carries a tray across a room. Its steps look smooth, and the object stays upright. What made the task possible, and what would happen if the floor, payload, or observation delay changed?

The visible result belongs to a coupled system. The controller matters, but so do the body’s geometry and mass distribution, the actuators, the contact surfaces, the available observations, and the conditions of the test. A successful clip can establish that a particular task was completed. It leaves further questions about causes, limits, and repeated operation.

Last week, Week 13, Evidence in Practice, defined STEAM Intelligence as a working framework for connecting disciplinary contributions through evidence and revision. Week 14 turns that discipline toward humanoid robotics. The intellectual step is to follow the evidence through a body acting on its surroundings.

My central claim is practical: evaluate humanoid performance as a property of the body, controller, and environment together. Before extending a task result, identify which interactions were tested and which remain assumed.

The body changes the problem

A humanoid is a robot with broadly human-like physical organization. That organization can make some human environments and interfaces relevant, but its suitability remains a task question. A wheeled base, fixed arm or different legged structure may be the stronger design for a particular purpose.

Embodiment means the computation operates through a material body that senses and changes its surroundings. This is more specific than an animated human appearance. Joint arrangements affect reach; mass distribution affects motion; contact surfaces affect available forces. Mechanical design can help produce behavior that would otherwise need additional control.

Passive-walking research makes this point concrete: appropriately constructed mechanisms can exhibit downhill gait through their dynamics. Gravity supplies energy as they descend.2 Such behavior shows a contribution from mechanics. It does not establish human reasoning, and it does not make learned control unnecessary for more demanding tasks.

For a tray task, the body also couples several goals. Motion at the feet can disturb the upper body and payload. A faster route may change how the object moves. The useful question is which design and control choices meet the whole task under stated conditions.

Contact makes claims conditional

A foot can support and redirect the body only through forces compatible with its contact. Ground contact is generally unilateral: the foot can push into the ground, while ordinary support does not let it pull upward on the ground. Friction constrains horizontal forces.1 Contact loss or slipping changes the problem the controller must solve.

Position alone also leaves out motion. Imagine two systems initially upright in the same place, one stationary and one already moving forward. They need not have the same recovery possibilities.

An ideal planar balance model makes the distinction inspectable. At a fixed center-of-mass height h, its divergent component is ξ = x + v/ω, where x is horizontal position, v is horizontal velocity, and ω = √(g/h). The expression combines position and motion in meters. Its assumptions include flat, maintained contact and negligible angular-momentum change; it is not a complete humanoid model.1,3

In the companion illustration, chosen inputs place ξ at approximately 0.057 m initially. After a chosen 0.2 s delay with pressure held at the support center, it reaches approximately 0.115 m, outside the chosen support half-width of 0.1 m. Those numbers are ideal-model calculations. Stepping or other physical strategies change the assumptions. The lesson is to ask what motion and corrective action the posture conceals.

Learning deserves bounded credit

Learning-based control has substantial physical achievements. Radosavovic and colleagues report humanoid locomotion tests on a physical platform.4 Later whole-body research investigates alignment between simulated and physical dynamics, while recent tray-transport work addresses the interaction between walking and payload stabilization.5,6

These results deserve precise credit. They do not require us to treat every demonstration as unrestricted autonomy. A comparison performed in simulation remains a simulation comparison even when the same paper includes physical trials. Physical outcomes also depend on the platform, tasks, sensing, and assistance described in the methods.

The tray study is especially instructive for evaluation: keeping a robot moving and keeping its payload stable are different objectives. Its inspected setup includes specialized tray end-effectors and tagged-object perception.6 Those conditions are part of the result rather than incidental details.

An equally serious caution concerns physical cost. Research on agile motion explicitly reports hardware stress and limitations.5 A movement can be achievable while repeated execution remains a separate reliability question. A capable controller can compensate for some mismatches, but that compensation has a domain to investigate.

Give the task several records

For a bounded tray task, begin with distinct questions. Did the robot finish the route? Did the object remain on the tray and satisfy its stated stability criterion? Were interventions required? What physical costs and failures occurred? What conditions were tested?

A combined success label can conceal disagreement between these outcomes. Completion might include a human reset. Low average tracking error might coexist with an unacceptable individual event. Report the denominator, observation window and failure definition rather than allowing an attractive outcome to answer every question.

I propose a concise task evidence record: task and criteria; body and software configuration; contact and environmental conditions; sensor timing and uncertainty; outcomes and interventions; limitations; next test and responsible reviewer. This is an author proposal for organizing evaluation, with its incremental usefulness still untested.

The same distinction helps education. A simulation can make velocity, delay and contact assumptions visible. Learners can explain why a result changes when one input changes. Whether that exercise improves learning requires separate assessment; a completed robot task is not evidence of every learner’s understanding.

Choose the next test carefully

The strongest objection is that this sounds like good engineering under a new description. That is a fair challenge. The systems view should earn its value by making a consequential assumption visible or improving the next test. It is not a demand that every controller contain a perfect analytical model.

Start with one proposed extension of a task result. Identify the changed condition most likely to affect it, specify the comparison and retain the failed trials. A richer simulation can inform that choice; independent physical evidence is still needed for claims about a particular robot. Modeling guidance connects evaluation to intended use.10

Safety adds application-specific responsibilities. A command to stop does not by itself settle what happens to an unsupported body or load. Standards have defined scopes and versions: ISO’s service-robot replacement remained a final draft at this audit date.8,9 This feature provides no compliance judgment.

Humanoid robotics becomes embodied systems science when physical interactions are part of the explanation and evidence. The next question is how the machine estimates the state it must act on—the concern of Week 15.

Which change would most challenge your current task claim: contact, payload, timing or intervention policy, and what observation would make you revise it?

References

1. Tedrake, R. (2024). Highly-articulated legged robots. In Underactuated robotics. Massachusetts Institute of Technology. https://underactuated.mit.edu/humanoids.html

2. McGeer, T. (1990). Passive dynamic walking. The International Journal of Robotics Research, 9(2), 62–82. https://doi.org/10.1177/027836499000900206

Companion inspected: McGeer, T. (1988). Passive dynamic walking (Technical Report CSS-IS TR 88-02). Simon Fraser University. https://alliance.seas.upenn.edu/~medesign/wiki/uploads/Courses/McGeer90-IJRR-Passive.pdf

3. Pratt, J., Carff, J., Drakunov, S., & Goswami, A. (2006). Capture point: A step toward humanoid push recovery. In Proceedings of the 6th IEEE-RAS International Conference on Humanoid Robots (pp. 200–207). IEEE. https://doi.org/10.1109/ICHR.2006.321385

4. Radosavovic, I., et al. (2024). Real-world humanoid locomotion with reinforcement learning. Science Robotics, 9(89), eadi9579. https://doi.org/10.1126/scirobotics.adi9579

5. He, T., et al. (2025). ASAP: Aligning simulation and real-world physics for learning agile humanoid whole-body skills (Version 3). arXiv. https://arxiv.org/abs/2502.01143v3

6. Huang, A., Wu, Z., Atar, S., Zhi, Y., & Yip, M. (2026). SteadyTray: Learning object balancing tasks in humanoid tray transport via residual reinforcement learning (Version 1). arXiv. https://arxiv.org/abs/2603.10306v1

7. Posa, M., Koolen, T., & Tedrake, R. (2017). Balancing and step recovery capturability via sums-of-squares optimization. In Proceedings of Robotics: Science and Systems XIII. https://doi.org/10.15607/RSS.2017.XIII.032

8. International Organization for Standardization. (2014). Robots and robotic devices—Safety requirements for personal care robots (ISO 13482:2014). https://www.iso.org/standard/53820.html

9. International Organization for Standardization. (2026). Robotics—Safety requirements for service robots (ISO/FDIS 13482) [Final draft international standard; under development]. https://www.iso.org/standard/83498.html

10. National Aeronautics and Space Administration. (2024). Standard for models and simulations (NASA-STD-7009B). https://standards.nasa.gov/standard/nasa/nasa-std-7009

11. National Institute of Standards and Technology. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST AI 100-1). https://doi.org/10.6028/NIST.AI.100-1