Are Humanoid Robots Being Designed for Simulators? A Veteran’s Warning

Humanoid robot design is showing a paradox: before robots can walk farther, their designs are already bowing to simulators. Engineers are removing mechanically superior structures—parallel joints, linear drives, remote transmissions, tendon‑based hands—because they are hard to simulate.

Scott Walter , a robotics veteran with over 40 years of experience and director of RoboStrategy, asks why humanoid robot design has become “S.T.U.P.P.I.D.” (Simulation Throttled Underperforming Product Integration Design).

He notes that engineers traditionally follow DFx principles (DFM, DFA, DFQ) that ask how design should adapt to downstream constraints. Last year, NVIDIA’s Jim Fan introduced DFS (Design for Simulation), stating that if a robot’s technology stack cannot be simulated, reinforcement learning is essentially impossible.

Simulation is indeed difficult; the Sim2Real gap is real. Leading teams need to run physics simulation many times faster than real time and randomize domains across millions of environments to train policies at scale.

However, turning DFS from a training guideline into a design rule is dangerous. Parallel joint mechanisms, which are mechanically compact and torque‑sharing, are being discarded simply because they are cumbersome to model. Rotary actuators are favored over linear drives not for performance but for modeling ease. Remote drives lose favor, and serial motion chains win because they are easier for simulators, not because they offer mechanical benefits.

Walter shares his own 40‑year experience: early in his career he suggested simplifying robot designs to aid simulation, only to be laughed at—because the real issue was the simulation team’s capability, not the hardware. As simulation tools improve, they should serve design, helping engineers explore the full design space and validate before manufacturing.

The deeper problem is computational cost. Accurate modeling of actuator dynamics, kinematics, reflected inertia, and system identification demands huge compute. Teams resort to shortcuts: estimating inertia, fixing center‑of‑mass data, guessing reflected inertia, and using domain randomization as a band‑aid. Some even modify the robot to fit the simulation, such as limiting motor output for linear response or redesigning Unitree’s H2 ankle from a parallel to a serial structure to accommodate reinforcement learning.

While the KISS principle (Keep It Simple, Stupid) is sound, removing mechanical advantages solely because simulation teams cannot handle complexity is not KISS but S.T.U.P.P.I.D. Simulation should be a tool, not the design driver.

Robotics researchers like Chris Paxton (Agility Robotics) and entrepreneur Matt Freed echo Walter’s concerns, noting that many hand designs are optimized for simulation rather than real‑world deployment, and that hardware and model teams must be tightly coupled to close the feedback loop.

The core warning is that simulation must remain an engineering aid, not a boundary that forces designers to sacrifice performance for ease of modeling. The best humanoid robot designs should start from actual robot needs, not from what the simulator can handle.