What a Push Does to the Menagerie Unitree G1 Before a Balance Policy Exists

The clip names a model, not a damaged robot

A push before any balance policy is a useful way to see what the physics engine is doing on its own. The 13 October 2026 post shows that idea on a Unitree G1 in simulation: the robot falls, and the caption says no motor is damaged. That outcome is expected in a model that has no thermal limit and no broken gear teeth. It is not evidence about a factory G1. [1]

The model named in the post is the Unitree G1 in Google DeepMind’s MuJoCo Menagerie. The Menagerie index lists that humanoid at 29 degrees of freedom under a BSD-3-Clause license. The package README requires MuJoCo 2.3.4 or later and describes the file as a simplified MJCF, not as a calibrated twin of one serial-numbered robot. [2] [3]

What the file actually contains

DeepMind derived the package from Unitree’s public g1_29dof_rev_1_0.xml. The edits extract shared properties into a default class, add a stand keyframe, and add joint-position actuators. The README says those actuators need tuning. The same edits were applied to a hands variant. A copied kinematic tree plus untuned position servos will stand only while the initial pose and the gains happen to agree. [3] [4]

Position actuators in MuJoCo apply a force that pulls each joint toward a target. If the target is a fixed stand pose and the gains are the file defaults, a hard push drives the joints off that pose. Nothing in that loop decides to take a step. The robot falls because no policy commanded a recovery, not because the solver proved that a trained G1 would fall the same way. [3]

Why the simulation does not break a motor

A physical Unitree actuator can overheat, trip a current limit, or strip a belt or gear. The Menagerie G1 does not include those failure modes. Contact forces move the bodies, and the integrator continues. “No motor was damaged” is true of the model by omission. It should not be read as a durability result. [3]

• Friction at the foot is whatever the geom and solver parameters produce, not a measured shoe on a named floor.
• Impact loads do not accumulate as plastic deformation or fastener fatigue.
• Encoder delay, communication dropouts and battery voltage sag are absent unless the user adds them.

That is still a fair first check. If the model falls through the floor or explodes under a modest push, the file is not ready for policy training. A clean fall only says the unconstrained body behaves like a body. [1]

The MJX file is a different claim

Menagerie also ships scene_mjx.xml. Relative to g1.xml, it uses hand-designed collision geoms and contact pairs, retuned solver iterations, lower PD gains described as more realistic, and extra home and knees-bent keyframes. The README says that MJX model was transferred to hardware in MuJoCo Playground. That sentence is about a tuned training stack. It is not a report of the push in the post. [3]

The publication’s MuJoCo guide covers the engine itself. MuJoCo for humanoid models

What still has to be measured on the robot

A recovery policy trained on this model can be a starting point. Before treating it as a property of the G1, the hardware log needs the robot version, the push location and magnitude, the floor, the number of trials, and whether a person caught the robot. The same log should record current limits and any fault flags. None of those fields are in the social clip. [1]

Balance on the physical machine is a separate article. How a humanoid step stays upright

The base G1 profile keeps the manufacturer’s joint count beside this model. Unitree G1 specifications