Split View: Gemini Robotics 2와 로봇 파운데이션 모델 — 전신 제어가 실제로 바꾸는 것

Gemini Robotics 2 and the Robot Foundation Model — What Whole-Body Control Actually Changes

• Introduction — July 30: 92 Percent to Unscrew a Lightbulb, 36 Percent to Screw One In
• What a Vision-Language-Action Model Actually Is
• Why Whole-Body Control Is Genuinely Hard
• Reading the Published Numbers as They Are
• Embodiment Generalization — the Actually Hard Part
• What Evaluation Even Means in Robotics
• What's Cherry-Picking and What's a Measurement
• Conclusion — What's Left Isn't Data, It's the Observability of Failure

Introduction — July 30: 92 Percent to Unscrew a Lightbulb, 36 Percent to Screw One In

On July 30, 2026, Google DeepMind unveiled Gemini Robotics 2. Where the previous generation mostly stayed confined to the upper body and tabletop tasks, the headline claim this time is that a single policy now controls an entire humanoid — walking, bending, reaching, and manipulating objects.

The part of the announcement materials most worth studying isn't the demo reel — it's the table. On a configuration pairing an Apptronik Apollo 2 with a SharpaWave multi-fingered hand, the success rate for unscrewing a lightbulb is 92%, while screwing one in is 36%. Same hand, same bulb, same socket — only the direction is reversed. Tying a trash bag: 44%. Sealing a zip-top bag: 40%. Using a dustpan: 32%.

This asymmetry summarizes the current state of the field. Unscrewing generally just requires applying force in one direction, with no accumulating error. Screwing in requires aligning the threads, sensing resistance, and backing off and re-aligning when it binds. The moment contact enters the picture, difficulty climbs in steps.

This post reads the published numbers as they stand, but separates what's a measurement from what's a video, and how far any of it has actually been verified.

What a Vision-Language-Action Model Actually Is

The traditional robotics software stack was layered. Perception (estimating object identity and pose from camera images), planning (generating a path to a target pose), and control (converting that path into joint torques). Each layer was developed and tuned separately, and the interface between layers was a human-designed representation — a 6-DOF object pose, a list of waypoints, a joint trajectory.

A VLA folds these layers into a single network. The inputs are camera images, a natural-language instruction, and proprioception (joint angles, force sensors); the output is a chunk of action for the next time step. The explicit intermediate representation disappears. Instead of the concept "watering can" existing somewhere as an explicit 6-DOF pose, it's distributed across the weights.

The advantage of this structure is that there's no interface loss. Perception no longer discards information — by approximating an object as a cylinder, say — that control later needs back. And because language is an input, a new task can be specified as a sentence instead of code.

The disadvantage shows up at exactly the same spot. When something fails, you can't tell which layer got it wrong. Whether the model failed to see the object, chose the wrong grasp pose, or applied the wrong force all collapses into a single number: success or failure. This observability problem comes back later in this post.

This release splits the model into three.

• Gemini Robotics 2 — the VLA proper. Converts vision and language into motor control, and drives both the humanoid's whole body and bimanual arm robots.
• Gemini Robotics ER 2 — the embodied-reasoning model. Acts as the "brain" handling higher-level planning — it plans multi-step tasks, converses with people, and coordinates collaboration across multiple robots. Per MarkTechPost's technical writeup, it's built on Gemini 3.5 Flash, with a 128k context and up to 64K output tokens.
• Gemini Robotics On-Device 2 — a lightweight VLA that runs locally on the robot's own hardware. Built on top of Gemini Robotics 1.5 and the Gemma family.

This split matters in practice. Planning can afford to run in the cloud on a scale of seconds, but control has to run on the robot itself on a scale of milliseconds. If the network drops, planning is allowed to stall — control is not.

Why Whole-Body Control Is Genuinely Hard

The sentence "now it controls the legs too" is easy to underrate. Moving from upper-body manipulation to whole-body control changes the nature of the problem.

The base is no longer fixed. On a stationary bimanual robot bolted to a table, the gripper's positional error is just the sum of the arm joint errors. On a humanoid, you now add foot-to-floor contact, torso posture, and center-of-mass shift on top of that. The very act of reaching an arm out to grab a watering can shifts the center of mass, and the legs have to absorb that reaction. In other words, a command to the arm becomes a control problem for the legs.

As degrees of freedom increase, the data requirement grows non-linearly. Going from 14 DOF on a bimanual arm setup to 30–40 DOF on a humanoid, the search space explodes. DeepMind's own published model card for On-Device 2 names this limitation explicitly — it states the model "has limitations generalizing to out-of-distribution tasks and controlling robots with high degrees of freedom," and that evaluation was conducted mostly on stationary bimanual manipulation tasks, with the risks of mobile platforms or whole-body control falling outside the current evaluation scope (model card).

The cost of failure is different. Fail on a tabletop and an object drops. Fail while a human-sized robot is walking and it falls over. Set a large safety margin and the success rate drops; tighten it and the risk rises. Where this trade-off was actually set for the published success rates isn't disclosed.

Reading the Published Numbers as They Are

Translating the figures confirmed in the DeepMind announcement and the MarkTechPost writeup:

A few notes on how to read this.

First, 45.7% on picking from the floor is the real state of whole-body control. Shelf (76.3%) and table (68.4%) don't require bending the torso much, but the floor requires posture transitions and balance maintenance at the same time. The order of the three numbers matches this hypothesis exactly.

Second, 89.6% for precision insertion with a gripper against 36% for screwing in a lightbulb with a multi-finger hand is the reality of dexterity. A parallel gripper has low degrees of freedom, so control is easier, and insertion is often forgiving because the hole itself acts as a jig that absorbs error. A multi-finger hand has many contact points, and the force distribution across each finger determines the outcome. The announcement materials themselves state plainly that multi-finger manipulation remains hard.

Third, the number of trials isn't disclosed. Whether 92% is 23 out of 25 or 184 out of 200 completely changes the confidence interval. The criterion for judging success isn't disclosed either — does the bulb have to light up, or does making contact with the threads count? Within the sources I had access to, I could not find either piece of information.

The ER 2 numbers were released alongside these. Five-stage progress classification accuracy of 57.4%, moment-finding accuracy of 91.3% with a mean absolute error of 0.96 seconds, and tool orchestration exceeding ER 1.6 across all three control modes (real VLA, simulated VLA, and human teleoperation). A progress-classification accuracy of 57.4% means the ability to judge "how far along is the task right now" is still barely past half, and that capability is directly tied to autonomous recovery.

Embodiment Generalization — the Actually Hard Part

This is exactly where robot foundation models diverge decisively from language models. A single token means the same thing everywhere in text, but a robot's action space differs by body. Joint count, link length, torque limits, camera placement, and gripper type all differ, so an "action" learned on one robot can't simply be transferred to another.

This is precisely what On-Device 2 claims — that it adapts to a new bimanual embodiment in a few hours, typically with fewer than 200 examples. Numbers introduced only at the post-training stage, on new platforms, were published alongside this claim.

• SO101: 6.7% before adaptation, 53.3% after. The prior generation (On-Device 1) went from 0.0% to 6.7%.
• Dexmate: 24.4% before adaptation, 75.6% after. The prior generation went from 13.3% to 33.3%.

How should you read these numbers? The absolute performance (53.3%, 75.6%) isn't production-grade. But the comparison point is the prior generation, and going from 6.7% to 53.3% under the same conditions is fair to read as an improvement in sample efficiency. In other words, this isn't a claim of "it's good" — it's a claim of "it climbs faster with less data."

One thing to watch: both platforms are bimanual arm robots. As the model card itself states, this model has limitations controlling high-DOF robots and was evaluated mostly on stationary bimanual manipulation. So there's no evidence in the published material that this adaptation speed carries over to a full humanoid body.

Multi-robot collaboration should be read the same way. There was a demonstration in which the Apollo 2 and the Franka F3 Duo — different classes of robot — exchanged sub-tasks through a shared semantic understanding. This is conceptually significant — if the interface for collaboration is language rather than a hardware protocol, the cost of mixing different robots drops sharply. That said, this is a demonstration, and no separate success-rate figure is attached to it.

What Evaluation Even Means in Robotics

For someone coming from language models, evaluation is the most confusing part of reading robotics results. Three things make it easier to read.

The definition of success rate differs paper to paper. How many trials were run, whether the initial object placement was randomized each time, whether retries were allowed after a failure, whether a human intervened partway through, whether success was judged by a human or automatically — all of it varies. Entirely different experiments can be filed under the exact same task name.

The definition of "unseen task" also differs. Difficulty differs depending on whether it's an object not in the training data, an arrangement not in the training data, an instruction sentence not in the training data, or a motion not in the training data. Generally, difficulty rises in the order of scene generalization (new objects/backgrounds), instruction generalization (new sentences), and behavior generalization (new motions), and comparison becomes impossible if a paper doesn't state which axis it evaluated. The On-Device model card states all three axes were evaluated, but doesn't publish per-axis numbers.

The sim-to-real gap remains. Simulators approximate rigid-body contact, and friction, slippage, and deformation still don't match well. So the gap between simulated and real-world performance is largest for contact-heavy tasks — handling clothing, managing cables, pouring viscous liquid. Within what I could confirm, I found no explicit statement about sim-to-real in this announcement's materials. The On-Device evaluation is only stated to have been conducted "across both simulation and real-robot benchmarks."

To read a single published success rate together with a confidence interval, you'd need at minimum the following disclosed alongside it. Announcements in this field that disclose all of this right now are rare.

task            "screw in a lightbulb"
embodiment      Apollo 2 + SharpaWave hand + socket jig version
n_trials        Number of trials run. Without this, even the gap between 92% and 36% can't be interpreted.
success_def     The criterion for success. Is it "threads engaged," or is it "lit up"?
judged_by       Human or automatic judgment? If human, how many, and how was agreement reached?
init_conditions Was the initial placement randomized on every trial?
retries         Were retries allowed after a failure? If so, the definition of success rate changes.
human_in_loop   Was there human intervention (other than resets)?
seen_in_train   Was this task and object present in the training data?
safety_margin   Where were speed and force limits set? A smaller margin raises the success rate.

And fundamentally, robotics has no shared benchmark. There's no baseline everyone runs under the same conditions, the way language models have several standard evals — the task set, camera placement, and even the robot differ slightly paper to paper. This fragmentation is the structural condition that enables cherry-picking.

What's Cherry-Picking and What's a Measurement

Let's be honest about the distinction.

What can be treated as a measurement: the success rates in the table above, On-Device 2's before/after adaptation figures, ER 2's progress-classification and moment-finding numbers. These were presented as numbers with the task specified. That said, without trial count or judging criteria, you can't compute a confidence interval.

What should be treated as a demonstration: the videos of cleaning up trash, moving a watering can, putting tape in a boombox, changing a lightbulb, tying a trash bag. Google described these as "fully autonomous" behavior in "real-time footage." Engadget, in its coverage, points out that these robots were specifically trained on every task shown in the videos, through human teleoperation, video examples, and simulation — pinning down that this isn't a general-purpose device. The same piece states the writer is "fairly skeptical of these things," and notes that AI can be wrong, and that on a heavy, human-sized robot, that can be dangerous.

What has been third-party verified: nothing. Within what I could confirm, not a single figure from Gemini Robotics 2 has been reproduced or verified by an independent body. Reproduction is structurally difficult, since neither the hardware (Apollo 2, Franka Duo) nor the models are freely accessible from outside. ER 2 is available through a private preview on Google AI Studio and the Gemini Enterprise Agent Platform, and the VLA and on-device models are open only to early-access partners.

There's one piece on the safety side that can actually be verified. A safety benchmark called ASIMOV-Agentic has been released on Hugging Face under CC-BY-4.0, along with a separate safety technical report. DeepMind states that ER 2 is its safest robotics model to date on benchmarks for constraint compliance and human proximity. Publishing the benchmark means that, at minimum, an outside party can score a different model on the same scale — and that's a meaningful difference.

Honestly, the fact that the announcement materials put low numbers like 36% or 32% directly into the table is itself unusual for this field — cherry-picking a success rate is far too easy here. That doesn't mean it's been verified, but it does let a reader see what doesn't work.

Conclusion — What's Left Isn't Data, It's the Observability of Failure

I'd say this announcement actually changes three things. Locomotion and manipulation have come under a single policy, the cost of adapting to a new body has dropped to a matter of hours, and it's been demonstrated that different classes of robot can collaborate using language as an interface. All three point in the right direction.

What hasn't changed is this.

• The moment contact enters the picture, success rate collapses. The 56-percentage-point gap between unscrewing and screwing in a lightbulb is the summary of that. Whether this is a problem more data solves, or a problem in tactile sensing and impedance control, isn't settled yet.
• There's no way to debug a failure. A VLA folds perception, planning, and control into one, and the price of that is losing the ability to decompose a failure by layer. ER 2's progress-classification accuracy of 57.4% means the robot's own ability to judge "something is going wrong right now" is still around half, and autonomous recovery has to be built on top of that.
• Evaluation is fragmented. As long as there's no shared benchmark, a published success rate can't be used to compare across vendors. Until the practice of publishing trial count and judging criteria together becomes standard, the numbers in a table only mean something when compared against the same team's previous version.

Robot foundation models look, right now, close to where language models sat around 2020. The capability curve is clearly pointing up — there's just no shared ruler yet for everyone to measure it with.