Original experiment footage is shared with the Japanese edition. Some on-screen labels are in Japanese; methods, results and video descriptions are provided in English below.
Face a visitor, bow and indicate a destination with one hand. We wanted G1 to express this welcoming sequence in a prototype for a reception area or showroom. Orientation, the pause during a bow and the way the hand is offered all contribute to communicating the intent.
Face the visitor so the gesture clearly addresses them.
01 / Can human motion transfer directly?
We estimated human motion from video, adapted it to G1’s body and tested it in physics simulation. The sequence is: human demonstration → body mesh and skeleton estimated with SAM 3D Body → motion adapted to G1’s structure → physics and balance testing. The original YouTube footage and audio are not reproduced here.
A pose that looks natural on a human can look different on G1. Body proportions and joint structure differ: matching arm position alone can still misalign palms, fingers and face direction. During development we compared all three representations.
02 / How did we keep it upright?
Reinforcement learning was not used for this motion controller. Pretrained AI estimates the human body; a dynamics-based whole-body controller drives G1. We prioritized executing the authored bow and guidance motion under limited simulation conditions, without claiming superiority over RL or testing a broad range of conditions.
Use the current state to compute the next forces
Target pose and motion,
and current body state
Account for contact, friction
and force limits
Apply joint torques
and step the physics simulation
Commands reduce target-pose error while accounting for foot contact, friction and available joint forces. At the end we hold the pose and adjust control to suppress oscillation. Inverse dynamics and quadratic programming (QP) compute joint torques from current pose, velocity and the target motion. Fingers use separate tracking control. A reward is not used to learn a robot control policy.
Physics tests apply commands under gravity and floor contact. We do not stand the robot up by replacing its torso pose with a target every frame. Published footage re-renders those test records. Under these conditions, G1 completed the bow and guidance without falling and held its final posture. Physical execution and robustness to changed conditions remain unverified.
03 / Small pose differences change the impression
We also revised the waiting pose. Bent-forward arms looked as though G1 was holding something ready. We lowered them beside the body and connected that pose to the start of the guidance motion. This waiting pose and transition were adjusted for filming and were not physically revalidated.
04 / What if the conditions change?
Four areas need further testing: slippery floors that affect foot contact and tracking; different mass or response, including hand mass, sensor error and delay; lateral pushes, for which recovery stepping is not implemented; and different bow depth, speed or guidance direction.
Physical deployment needs more control engineering, but does not necessarily require a newly trained RL model. Options include extending whole-body control with measured mass/motor response, state estimation and recovery steps; learning motion tracking and balance under varied friction, mass, delay and external forces; or combining learned motion/corrections with model-based control.
Whole-body MPC research has applied model-based control to physical robots, but its results do not automatically transfer to this G1 controller. Our result is motion under limited conditions. RL-based motion tracking is a promising next option for maintaining the gesture under variation.
If RL is used, the target is not merely a static pose: it is a policy that chooses the next command from current body state and target motion. Training under varied friction, mass, delay and forces could address tracking and recovery. Isaac Lab documentation describes environment randomization. Whether to train from scratch or reuse/fine-tune a G1 policy depends on compatibility with the robot, hand and control interface. No existing policy has yet been selected. RL still requires out-of-training-condition and sim-to-real validation. Adjusting timing and direction to a visitor also needs perception and action selection.
05 / The prototype in a scene
We composed a visitor-welcome scene in an office and moved the camera closer to G1 at the end. The physics test verified completion of the bow and guidance and holding afterward. Differences in face, waist and finger motion remain, as do physical testing and an assessment of whether viewers find the welcome natural.
This is the first prototype, not a system that recognizes visitors and responds to them.
06 / Before trying this on a physical G1
Physical operation remains untested. The following are considerations inferred from this configuration, not validated deployment procedures. Simulation joint angles and settings should not simply be sent unchanged to a robot.
Robot and hand configuration: check the G1 variant, waist lock state, wrist degrees of freedom and development API. Account for hand mounting angle, mass, center of mass, wiring and joint limits.
Control ownership: define the roles of the standard motion controller and custom whole-body control to avoid conflicting commands. Do not assume standard control automatically prevents a fall.
Latency and physical response: align joint axes, signs and zero points, then check pose estimation, communication delay, computation period and motor response. Handle missing state updates or computation.
Bow depth and repeated operation: slow motion can still fall when the center of mass moves outside the support region. Check floor friction, foot slip, joint force, speed and temperature, including repeated operation.
Start, finish and faults: test the transition from waiting to guidance, final holding and control handover. A stop command alone may not preserve an upright pose; stopping and protection must account for falls.
Visitor distance: consider both the arm workspace and the reach of a falling robot. Avoid finger pinch points and define access control, monitoring and responsibility for stopping. Person detection is not implemented in this prototype.
Begin in a protected test environment with robot-appropriate fall protection and supervision. Check waiting, shallow bowing, guidance and the full sequence progressively. Distinguish supported tests from independently standing tests, and establish operating bounds and abort conditions before admitting visitors.
Specification references: Unitree G1 specifications and the official low-level SDK example. The example documents joint differences and control modes. Confirm operation and stopping against manufacturer documentation for the actual robot and firmware.
LET’S BUILD TOGETHER
What are you working on?
Tell us about the software you need to implement or test. We can discuss the work, the development setup and how we could contribute.
Discuss your development needs