Skip to content

Technology

NVIDIA GR00T 2 Reports Robot Adaptation Results

Why the cost of teaching a robot and the cost of dependable work need separate scorecards.

By Cara Voss · November 10, 2026

Unitree G1 at a 2024 exhibition, not NVIDIA’s GR00T 2 experimental setup.

Licensed image · Sayanesy / Wikimedia Commons (CC0). Archival G1 photograph, UAV Expo 2024; not NVIDIA’s experimental setup. · Image source

NVIDIA introduced GR00T 2 on November 9 with a 50-task Dexter evaluation. Its selected tasks are ones the model learns at 80% success or better after five demonstrations; the resulting average is 95%. Dexter is a two-arm platform with dexterous hands, not a walking humanoid.

That selection rule narrows the claim: this is not an arbitrary sample of everything a robot might be asked to do. Separate experiments on a walking Unitree G1 show why adaptation and operational dependability still need different scorecards.

Key Stats: Company-Reported Tests

40%

Dexter zero-shot average success

71%

Dexter average after one demonstration

95%

Dexter average after five demonstrations

How GR00T 2 Connects Seeing and Doing

The project describes a world-action model: GR00T 2 predicts video and actions together from observations, instructions and robot state, with robot-specific outputs.

A useful way to understand the ambition is to separate knowledge of a task from knowledge of a body. Recognizing that a drawer must open before an object can go inside does not specify the wrist position, grip force or balance correction a particular robot needs. Shared learning is valuable only if that remaining translation becomes manageable.

These tasks had human or other-robot training examples, but none from Dexter. Zero-shot here means no target-platform examples.

Selection does not erase the improvement measured within the chosen set. It changes what the result predicts. A team bringing a new job should first establish whether that job belongs to the learnable set, rather than assuming the headline average will apply before any testing.

This is a more specific claim than general intelligence. It asks how much previous experience can substitute for collecting a fresh robot dataset. For developers, the important resource is not merely training compute; it is also the time spent arranging scenes, operating hardware and collecting usable examples.

Under the Hood: Two Evaluations, Different Questions

Zero-shot, 40 tasks succeeded at least once. That breadth is not an 80% success rate across attempts. Occasional ability and dependable execution are different measures.

NVIDIA's whitepaper separately reports task-post-trained GR00T 2-Turbo results on G1. These are not the Dexter experiment repeated on legs:

G1 taskSuccessful trialsReported rate
Popcorn scooping and serving48 / 48100%
Table clean-up28 / 3093.3%
Ground pickup25 / 3083.3%
Spill clean-up14 / 3046.7%

Source: whitepaper, Table 25. Popcorn and spill clean-up use separate single-task policies. These small controlled samples describe tested behavior, not long-run customer reliability.

These experiments should not be turned into a league table against unrelated robots. A controlled comparison needs the same starting conditions, allowed assistance, completion criteria and time limits. Even identical task names can conceal different difficulty: picking up an easy-to-grip object is not the same test as retrieving a slippery or partly hidden one.

The spread is more informative than a blended headline. A buyer does not purchase the average of popcorn preparation and spill removal. It purchases a particular service under particular conditions. Strong results on one workflow cannot compensate for failures in another workflow that the same customer needs.

The G1 stack also divides control by timescale. Figure 9 places Turbo planning at roughly 1 Hz, with 1.6-second action chunks, above a SONIC motion controller running at 50 Hz. Higher-level reasoning is excluded from the project's claim that the system runs onboard.

Planning an action and keeping a machine stable are different responsibilities. A fast low-level controller does not make a slow high-level decision instantaneous. Conversely, an occasional planning update need not mean the robot pauses between decisions. Evaluation should examine the combined behavior rather than treating either frequency as a standalone measure of intelligence.

Who's Building the Learning Stack

NVIDIA supplies the model and computing platform; Unitree Robotics supplies the G1 body used in the humanoid experiments. The SONIC model card describes a reusable lower-level controller that can receive high-level commands as well as keyboard, gamepad and VR input. Its code and weights have separate licenses; neither establishes licensing terms for GR00T 2.

SONIC's current release documentation also requires matching the motion encoder, action decoder and observation configuration from the same controller variant. Those components respectively translate a movement reference, produce joint actions and define the inputs the controller expects. The listed variants include the original controller, a lower-latency option and version 1.1; they are not interchangeable bundles.

That is a concrete integration constraint, not just a licensing footnote. A model name on a demonstration is insufficient to reproduce the behavior. Developers need the compatible configuration of the entire control chain, and should not assume every publicly listed SONIC variant was used in these experiments.

The distinction matters when comparing demonstrations. A shared robot body does not imply shared software, sensors, training or performance. The archival G1 photograph accompanying this article identifies the platform family, not NVIDIA's modified experimental setup.

NVIDIA's CoRL announcement names Nexuni testing laundry applications, Foxconn applying the model to server manufacturing, and Siemens evaluating industrial uses. These statements establish partner activity, not a measured fleet of commercially dependable humanoids.

For an integrator, the practical question is where responsibility sits when a trial fails. Model adaptation, robot maintenance and workflow design can belong to different teams. A convincing adoption case must show that their combined support burden is acceptable, rather than counting each layer's progress separately.

What Human Data Changes for Robot Developers

The accompanying Human-1M dataset releases 100,000 hours under CC BY 4.0, from a larger million-hour collection. Its episodes connect first-person video, head and hand motion, overall goals and timed actions. The public subset is not a claim that every hour used to train GR00T 2 is available.

The data card distinguishes an episode's overall goal from timed action segments. Video, language and motion align through timestamps; motion records include head-camera pose, hand keypoints and tracking confidence. Its stated quality checks cover annotations, task visibility, diversity and tracking consistency. Those fields make it possible to examine what an example actually contains, rather than treating every recorded hour as equivalent.

A larger dataset and a more independent test are different achievements. Researchers should describe which activities, scenes and robot configurations appeared during training, and which changed during evaluation. “Unseen” is useful only when its boundary is explicit. That distinction is especially important when human and robot examples describe the same activity.

For a research team, that organization provides more than a pile of footage. It creates a way to ask whether a model learns the intended operation, the order of its steps or merely visual regularities. A useful test would hold the physical outcome fixed while changing the background, object arrangement and demonstrator.

For a business, cheaper adaptation would change which tasks are worth automating. A short-lived product line cannot absorb the same setup effort as a long-running standardized process. But demonstration count is only one setup cost. Calibration, fixture design, safety assessment and recovery procedures still belong in the calculation.

Consider a hypothetical trial that delivers 90 acceptable items from 100 attempts but needs 40 minutes of operator help. Reporting only a 90% completion rate would omit the resource that may determine whether the service is economical. Counting assistance separately also avoids pretending that a rescued attempt was an unaided success. These are illustrative numbers, not GR00T results.

A sensible acceptance trial would record completed work, rejected output, intervention minutes and total elapsed time. It would also separate initial setup from repeated operation. Otherwise, a demonstration that looks inexpensive to teach can conceal an expensive job to keep running.

What's Coming Next

The project lists code for December, not an already-completed release. Outside teams need enough information to reproduce the relevant task definitions and distinguish model improvements from changes to hardware or evaluation conditions.

Reproduction should preserve unsuccessful attempts, not just successful demonstrations. Then testing can move from repeating familiar scenes to handling altered layouts, missing objects and interruptions. Those are separate milestones: matching a laboratory result comes before establishing dependable performance elsewhere.

Frequently Asked Questions

Does a benchmark percentage describe a whole robot?

No. It describes a defined evaluation. Hardware, task selection, training and scoring rules determine what the number can support.

What should a customer measure beyond task success?

Measure accepted output and the time people spend helping, alongside total elapsed time. Include failures and recovery in the same operating window.

Does human demonstration data remove the need for robot testing?

No. Learning from human activity and safely executing it on different hardware are separate requirements. A target robot still needs evaluation in its intended environment.

A Learning Result, Not a Deployment Shortcut

For developers, the useful commercial question is whether easier adaptation produces repeatable work without moving the saved effort into supervision and troubleshooting. Customers should judge that trade using their own task mix, not the most flattering demonstration.

The Bottom Line: Evaluate the cost of teaching a task and the cost of delivering it separately; a better learning curve does not automatically settle both.