Gemini 4 Argon and Humanoid Robots: From Human Video to Real-World Motion

What Google published on 13 October 2026

Two Google pages and a model card carry the public record. The Google Blog post reports an 87% score on the Embodied Reasoning (ERQA) benchmark and an internal trial in which Apptronik's Apollo humanoid sank seven consecutive cornhole shots. The Google Developers Blog, written the same day, describes other robotics examples: a Spot quadruped disposing of cans, simulation scenes built from camera video or a sketch, labels on manipulation video, and extra simulation data later used on a physical robot. The model card lists general limits, including possible hallucinations and a knowledge cutoff of March 2026. It does not publish a humanoid hardware success rate. [1] [2] [3]

Primary technical write-up: Gemini 4 Argon for Robotics.

Model limits and intended use: Gemini 4 Argon model card.

Physical and spatial reasoning

ERQA asks whether a model can reason about physical and spatial problems in 3D environments. Google reports 87% for Argon using reasoning alone, and says that score is higher than the other frontier models in its comparison. A benchmark score and a success rate on hardware are different measurements. The first does not include actuator delay, sensor noise, foot slip or a joint that hits its stop. [1]

A model that can reason about objects, geometry, movement and contact can still help an engineer read a task: which object to grasp, which order of contacts is plausible, and whether a reach crosses the torso. On a humanoid that reading still has to pass through a controller that enforces balance and joint limits. The 87% figure does not measure those constraints.

Video-to-sim-to-real

The Google Blog describes a workflow it calls video-to-sim-to-real. In the cornhole account, Argon watched a raw video of a person playing, mapped spatial coordinates of the scene, calculated whole-body joint movements and wrote simulation code. Google says that result was then transferred onto Apollo. The company also says the pipeline compresses weeks of manual simulation modeling into a few hours. That duration is Google's description of its internal test, not a timed saving on an outside humanoid program. [1] [4]

If the scene is accurate, the engineering use is specific. A human recording can supply the order of a movement instead of a hand-built script. Balance and contact with the object can be checked in simulation before the first hardware trial. A trajectory can be revised there, then compared with camera footage from the physical robot. The pages do not say that every video becomes a reliable policy. Friction, actuator response and camera calibration still have to be fitted to the robot that will run the motion.

Whole-body humanoid control

Throwing, reaching and placing use the torso, shoulders, hips, knees, ankles, arms and hands in one motion. A throw shifts the center of mass. The stance has to keep that mass over the feet while the arm accelerates. Joint limits, contact force at the feet and at the hand, and the balance constraint all change together. If the arm swing is late, any torso correction is late with it.

The reported Apollo cornhole trial

Google's concrete humanoid case is the cornhole trial. The company says Argon analyzed a human video, generated simulation code, and that Apollo then sank seven consecutive shots on hardware. A second, different Apollo 2 example sits in the developers post: a hand-drawn sketch of the humanoid throwing a ball along an arc to topple a stack of boxes. There Argon builds a MuJoCo scene and a 76-degree-of-freedom whole-body throw, then records 6 of 6 knockdowns inside the simulator. [1] [2]

Seven consecutive shots is a reported streak. Google does not publish how many attempts came before it, which controller ran on Apollo, which calibration steps were used, or which hardware stops stayed active. The account does not show that Apollo performed the task without robot-specific integration.

Dexterous manipulation and robot hands

The developers post describes retargeting a human hand path from an egocentric video onto a 76-DoF bimanual humanoid with 22-DoF five-fingered hands, using MuJoCo contact. That simulation covers grasping, reorienting an object, placing it, and coordinating two hands when the source video uses both. [2]

Finger contact is a small patch. Slip starts when friction force is below the load. A narrow opening leaves little room for a wrist-angle error. Fingertip force is not the same number as motor current if the transmission has compliance. Simulated friction is a chosen parameter. Physical friction depends on the skin, the object surface, moisture and wear. Whether the grasp holds depends on the hand hardware, the sensors, the control stack and the data used to tune contact. A simulated contact is not proof the physical fingers kept the object.

Mobile manipulation

The developers post shows Boston Dynamics Spot, a quadruped with 12-DoF legs and a 6-DoF arm, disposing of soda cans by stepping on a foot-pedal bin. Argon builds a MuJoCo model of the pedal bin, practices, then runs the physical robot: pick up the can, check the wrist camera, place the foot on the pedal and drop the can. Foot placement and hand alignment are both part of that sequence. [2]

A similar split, locomotion and then the arm, could apply to a humanoid that walks to an object, keeps its balance, manipulates the object and checks the result with a camera. Spot is a quadruped example, not a humanoid trial. A biped has a smaller support area and a different set of joint limits, so the walking half of the plan is not the Spot plan.

Real2Sim from a camera, a human video or a sketch

The developers post reports three ways to build a scene. From a robot teleoperation video, Argon reconstructs a MuJoCo scene and iterates until the visuals and contact events line up with the recording. From an egocentric human video, it identifies objects, replaces bounding boxes with convex-decomposed meshes for concave containers, and retargets the hand motion. From a sketch of an Apollo 2 throw, it constructs a GPU-accelerated MuJoCo scene. [2]

A simulator needs object geometry, which joints move, where contact occurs and how the motion evolves. If the mesh is wrong, the friction coefficient is a guess, the camera is poorly calibrated, or the actuator model misses torque and delay, the simulated contact diverges from the hardware. The post describes an iterative visual match. It does not publish a residual error measured on a physical humanoid.

Video annotation and robot learning data

Synchronized cameras can mark stages of a task: approach, contact, a failed grasp, a pause, a retry, and whether the task moved forward. On a 136-second ALOHA 2 origami fold, Google says Argon produced an episode goal, semantic subtasks, atomic primitives, and a quality weight that withholds progress credit during fumbles. On a bimanual ring-sorting clip it split the trajectory into 28 segments with positive, neutral or negative progress slopes. [2]

An engineer can use those labels to choose training clips and to see where retries cluster. An automatic label and an estimated progress score are not a physical measurement. Ground truth is still an independent check that the object was grasped, or that a placement met a tolerance. The same post reports a separate tabletop result: after Argon built a MuJoCo twin from one photo and synthesized more than 4,500 simulation episodes, a physical robot's success moved from 56% to 75% and completion time from 35 seconds to 24 seconds. The post does not identify that robot as a humanoid. [2]

Closed-loop visual feedback

A robot should look at the result of an action before it chooses the next one. In the published examples that includes checking whether a can is centered over an open bin, reading a wrist camera after a grasp, and revising the next command after looking at intermediate frames. A placement can be corrected only if the camera shows the error before the next motion commits. [2]

Camera latency, an occluded hand, a bad calibration and a wrong detection all break that loop. Joint limits, collision checks and an emergency stop have to keep running if the vision update is late. On a separate 6-DoF arm, Google reports three iterations of a visual pick-and-place, with times of 58.9 seconds, 22.9 seconds and 17.4 seconds. That is an arm result, not a humanoid result. Neither the developers post nor the model card says that Argon by itself provides real-time control or safe unattended operation. [2] [3]

What Gemini 4 Argon Still Needs Before It Can Run a Humanoid Reliably

The public pages leave the integration questions open. How much latency do inference and the network add before a joint command is issued? Which loops, such as balance and current control, must keep running without waiting for the model? Where are joint limits, collision checks and emergency stops enforced? How many physical trials follow a simulation that already looks correct? How do results change with a new object, different light, a moved camera or a different floor friction? What is the recovery when a grasp slips or the object is nudged? Across repeated trials, what are the success rate, completion time, recovery rate and the count of safety incidents? Where Google has not published a number, the item stays an evaluation requirement.