‹ papers
GR00T N1  ·  learning to drink from the ocean of action-less video

Paper explainer Robot learning arXiv 2503.14734

GR00T N1

NVIDIA  ·  arXiv 2503.14734  ·  March 2025 (large author list, attributed to NVIDIA)

GR00T N1 is a dual-system vision-language-action model: an Eagle-2 vision-language module as the deliberate System 2 (its language model kept frozen, the rest fine-tuned on robot data), and a diffusion-transformer action module with flow matching as the reflexive System 1, linked by cross-attention. But the architecture is the lesser story. Its real contribution is data: it turns action-less video into training signal two different ways, a latent-action code that says what kind of motion that was, and an inverse-dynamics model that invents pseudo-actions, and it multiplies roughly 88 hours of real robot teleoperation into about 827 hours of generated "neural trajectories". This is a paper about manufacturing data, not about building a cleverer network.

GR00T N1 generalist humanoid foundation model
Figure 1. GR00T N1 is NVIDIA's open foundation model for generalist humanoid robots, deployed on platforms like the Fourier GR-1 and 1X humanoids for language-conditioned bimanual manipulation. The interesting engineering is upstream of the robot: how you get enough training data to make a generalist behave.

01The real-robot-data bottleneck, and GR00T's bet

Every robot foundation model runs into the same wall: real robot data is tiny and precious. Teleoperating a humanoid through thousands of bimanual, contact-rich tasks is slow, expensive, and hard on the hardware. Models like π₀ establish that you can train a single vision-language-action policy with flow matching, but they all still need robot-specific and task-specific post-training, and more of it is always better.

Meanwhile there is an ocean of humans on video doing exactly the useful things we want robots to do: wet-lab work, assembling, cooking, folding, pouring. The catch is brutal. Those videos do not come with action labels. You can see the cup get picked up; you do not know the joint angles, the gripper torques, the per-step motor commands that produced the motion. To a policy that outputs actions, an unlabeled video is a sentence with the verbs deleted.

◆ the core bet

GR00T N1's wager is that the bottleneck is not architecture, it is actionable data. So rather than design a fancier network, NVIDIA designs ways to recover the missing verbs from action-less video, and to manufacture realistic robot video at scale. The model is a competent dual-system VLA; the cleverness is the data pipeline that feeds it.

02The dual system: a slow brain and a fast hand

GR00T N1 follows the "System 2 / System 1" framing, two networks doing two different jobs at two different speeds.

System 2: a partially-frozen vision-language module that understands the scene

The deliberate, slow module is Eagle-2, NVIDIA's vision-language model. It reads the camera images and the language instruction and forms a semantic understanding of the scene: what objects are present, what the task is asking for. The key choice is what stays fixed. As the paper puts it, "we keep the language component of the VL backbone frozen and fine-tune the rest of the model": the language model is held frozen to preserve its pretrained world knowledge, while the vision encoder and the rest of the network are fine-tuned on robot data.

System 1: a diffusion transformer that produces motion

The fast, reflexive module is a Diffusion Transformer (DiT) trained with flow matching: it learns to denoise from a noise sample into a chunk of future actions, conditioned on the current state and on System 2's understanding. This is the same flow-matching DNA as π₀. The two systems are joined by cross-attention: the action module attends into the frozen VLM's features. (That is a deliberate contrast with π₀'s mixture-of-experts style of shared attention. Same family, different wiring.)

GR00T N1 architecture: System 2 Eagle-2 VLM and System 1 diffusion transformer action module
Figure 2. The dual-system architecture. System 2 (the Eagle-2 VLM, its language model frozen) reads images and the instruction; System 1 (a flow-matching Diffusion Transformer) produces the action chunk, attending into System 2 through cross-attention. The embodiment-specific encoders and decoders (the adapter blocks) are what let one shared core serve many different robots, and one virtual human "embodiment", from a single heterogeneous training set.

Adapters: one core, many bodies

Different robots have different joints, sensors, and action spaces, and human video has none of these at all. GR00T handles this with embodiment-specific state and action encoders and decoders, small adapter layers around the shared core. The same model can ingest a robot's proprioception and emit its joint targets, ingest a different robot, or treat human video as its own "virtual embodiment". This is what makes training on one heterogeneous mixture possible.

Two design choices: the action chunk and a detection loss

System 1 predicts an action chunk of length H = 16: sixteen future steps at once, then re-plan. (Compare π₀'s H = 50; in practice those longer chunks rarely ran to completion before re-planning, so a shorter chunk is lighter and often enough.) On top of the flow-matching objective, GR00T adds an auxiliary object-detection loss:

$$\mathcal{L} = \mathcal{L}_{\text{fm}} + \mathcal{L}_{\text{det}}$$
In words: $\mathcal{L}_{\text{fm}}$ is the flow-matching loss that teaches System 1 to generate the right actions. $\mathcal{L}_{\text{det}}$ forces the vision side to explicitly locate the object named in the instruction. Grounding the perception to the right object makes the predicted motion attach to the right thing. This mirrors how auxiliary bounding-box losses sharpen the main task in computer vision; that framing is the explainer's, the paper simply names it an auxiliary object-detection loss.
▲ why freeze the language model

Freezing the VLM's language component is a data decision in disguise. That language model already knows what a coffee cup and a drawer are from internet-scale pretraining; the scarce robot data should not be spent re-teaching language and world knowledge. So GR00T pins the language model and lets the rest, the vision encoder and the action stack, adapt to the robot. The general knowledge stays intact while the parts that must learn the embodiment get to move.

03The data pyramid, and two ways to mine its base

Picture the training data as a pyramid. At the wide base: web and human video, vast, but with no action labels. In the middle: simulation, large and cheap to scale, generated with systems like DexMimicGen. At the scarce tip: real robot teleoperation, small and expensive, and the most valuable of all because it is the only layer that is unambiguously the robot doing the real task.

The whole game is to feed the model from the layers that have no actions. GR00T does it with two distinct tricks, which the next sections unpack: latent actions (read an abstract motion code off any video pair) and an inverse-dynamics model (invent concrete pseudo-actions for generated video). Together they let the abundant, label-free layers contribute real training signal, and let a sliver of real teleoperation be amplified into something an order of magnitude larger. Drag the slider below to feel that multiplier.

★ the key insight

Real robot hours are the bottleneck, so do not try to collect your way out of it. Instead build machinery that extracts action signal from data that never had any, and machinery that generates more robot-like data than you could ever teleoperate. You buy your scale in GPU time, not in robot time.

04Trick 1, latent actions: a code for the motion, not the joints

Start with the hardest case: a human picking up a cup on video. You have no joint angles. Trying to regress the human's exact pose, or worse the robot joints that "would" produce it, is messy and probably impossible. So GR00T does not predict a concrete action at all. It predicts an abstract representation of the motion itself.

The mechanism is a VQ-VAE (vector-quantized autoencoder) trained over frame pairs. The encoder looks at frame $t$ and a future frame $t+H$ and emits a continuous embedding $e$ that captures the essence of the movement between them. That embedding is quantized to the nearest entry in a learned codebook of motion prototypes, and a decoder tries to reconstruct $t+H$ from frame $t$ plus the chosen code. Forcing the reconstruction to go through a small codebook is what structures the latent space into clean, reusable motion types.

$$z_q = c_{k^*}, \qquad k^* = \arg\min_{k} \; \lVert e - c_k \rVert$$
In words: the encoder's continuous output $e$ snaps to the closest codebook vector $c_k$. The index $k^*$ names a motion prototype ("reach", "grasp down", "lift"); the small gap between $e$ and $c_{k^*}$ is the quantization error. The reconstruction loss on $t+H$ is what teaches the codebook to carve motion space into useful pieces.

The widget below is this encode-then-quantize step, run live. Set the motion you observe between the two frames (its direction and size). The encoder maps it to a point $e$ in a 2-D latent space; quantization snaps $e$ to the nearest of the codebook's motion prototypes; the decoder reconstructs the canonical end-pose for that prototype. Watch which prototype your motion lands on, and watch the quantization gap when your motion sits between two of them.

Latent action training pipeline using a VQ-VAE over frame pairs
Figure 3. The latent-action pipeline. A VQ-VAE encoder reads $(t, t+H)$ and produces a motion embedding; a codebook quantizes it; a decoder reconstructs the future frame. Trained on a mix of human, robot, and synthetic video, the codebook learns motion prototypes that are independent of any specific robot's joints. At policy-training time, GR00T uses the continuous encoder output directly as the "latent action" label.

05Using latent actions: human video becomes a virtual robot

Here is the payoff. Once the VQ-VAE is trained, generating a training label for an action-less video is trivial: feed it the frame pair and read the continuous encoder output straight off. The codebook's only job was to structure the latent space cleanly during VQ-VAE training; the label fed to the policy is not the discrete code index but the continuous pre-quantization vector itself. That vector becomes the "latent action" for that clip. It is not joint angles; it is a point in a learned space that means something like "move the arm this way" or "grasp like that".

GR00T then trains its main policy to predict these continuous latent-action vectors for human-video inputs, treating human video as its own virtual embodiment, which the paper labels the "LAPA" embodiment after the Latent Action Pretraining method of Ye et al. (2025) that it borrows. The model learns general visual patterns and motion intentions from human video, without ever needing a single human pose label, and that knowledge transfers to the robot embodiments that share the same codebook.

◆ analogy

It is the difference between transcribing a dance move-for-move in someone else's body geometry, which is hopeless across different bodies, and writing it in choreography notation: "step left, reach, turn". The notation is body-agnostic, so a dancer with completely different limbs can read it and perform the same intent. The latent action is that notation; LAPA is the dancer learning to read it before it ever has to perform with the real instrument.

Test yourself: why predict an abstract latent action for human video instead of regressing joint angles?
Because the human video has no joint-angle labels, and even if you estimated them they would be in the human's body geometry, not the robot's, so they would not be a usable supervision target. The latent action sidesteps both problems: it is a body-agnostic motion code learned by the VQ-VAE from many embodiments at once, so the same code is meaningful for human video and for a robot. Predicting it lets human video teach the model motion intent and visual patterns (the part that transfers) without committing to pose details (the part that does not). That is exactly why human video can be treated as the LAPA virtual embodiment and still help the real robot.

06Trick 2, the inverse-dynamics model: read the actions off two frames

Latent actions are perfect for video that is far from the robot's world, like arbitrary human clips. But for video that is close to the robot's world, in particular the generated "neural trajectories" we are about to make, GR00T can do something more direct: recover the actual action chunk.

The tool is an inverse-dynamics model (IDM). Train it on data where you do know the actions (real teleoperation): show it frame $t$ and frame $t+H$, and have it output the sequence of robot actions that occurred in between. NVIDIA trains this as a separate inverse-dynamics model on real action-labeled teleoperation. Once trained, point it at action-less video and it fills in the missing actions, manufacturing the pseudo-action labels GR00T trains on, for free.

$$a_{t:t+H} = \mathrm{IDM}(o_t,\; o_{t+H})$$
In words: given the observation now and the observation $H$ steps later, the IDM infers the whole chunk of actions $a_t, a_{t+1}, \dots, a_{t+H-1}$ that bridges them. Trained on real action-labeled data, it generalizes to generated video that has no actions, and writes the labels in.

The widget below is that inference. Set where the hand ends up at frame $t+H$; the IDM infers the per-step action chunk that carries the hand from start to end, and a marker marches along it while little bars show each step's motion. Then flip the input toggle from real to generated: the same IDM, pointed at a video that came with no action label, manufactures the chunk anyway. That flip is the whole trick.

Inverse dynamics model: training on action-labeled data, then inference on action-less video
Figure 4. The IDM, training (top) and inference (bottom). It is trained on action-labeled teleoperation to map a frame pair to the chunk of actions between them, then run on action-less video, including the model's own generated neural trajectories, to produce pseudo-action labels. Those pseudo-actions become supervision for the main policy.

07Neural trajectories: turning 88 hours into roughly 827

Now the two tricks combine into the headline result. GR00T fine-tunes a video generation model on the real robot teleoperation footage, so it learns to produce video that looks like this robot, in these scenes, doing these kinds of things. Then it prompts that generator into brand-new episodes: start from a real initial frame, hand it a fresh text prompt (auto-written by a prompting VLM) to vary the scenario, and generate a new clip. The paper reports generating 81-frame, 480p episodes this way. A separate VLM judge then does quality control, throwing out clips that do not match the prompt.

Each generated clip is action-less, so the IDM from the previous section labels it with pseudo-actions, and it becomes usable training data. The arithmetic of the whole pipeline is the punchline:

88 h
of real robot teleoperation data, the scarce, precious tip of the pyramid
~827 h
of generated "neural trajectories", a ~9.4× multiplier on the real data, which the paper rounds to ~10×
H = 16
action-chunk length the policy and the IDM predict at once
81 frames
per generated episode, at 480p, prompted from real initial frames

One honest caveat the author of the source notes flags from experience: this only works because the video generator is fine-tuned on real robot footage. Off-the-shelf, general-purpose video generation does not produce anything usable for robot training. The clip below is a generic Sora attempt, included precisely to show the gap: visually plausible in the abstract, useless as robot supervision. The whole point of "neural trajectories" is that you must specialize the generator first.

Figure 5. An off-the-shelf general video-generation attempt (Sora). It looks fine and teaches a robot nothing: the dynamics and embodiment are wrong for supervision. GR00T's neural trajectories work because the generator is first fine-tuned on real robot teleoperation, which is what closes the gap between "plausible video" and "usable robot data".

08Why generated video instead of more pure simulation

It is fair to ask: if you want more robot data, why generate video at all? Why not just run more physics simulation, which is cheaper per hour and gives you ground-truth actions directly? GR00T uses simulation too (DexMimicGen), but it leans on neural trajectories for two reasons that simulation struggles with.

Closer to the real visual domain

Because the video model is fine-tuned on real robot footage, its output carries the real appearance: lighting, textures, sensor quirks, the look of the actual lab. That is exactly the visual domain the policy will eventually be deployed in, so training on it should shrink the sim-to-real visual gap that a clean rendered simulation reopens.

Hard physics, captured implicitly

Some things are genuinely hard to simulate: pouring fluids, watering plants, folding cloth. A physics engine either fakes these expensively or not at all. A video model trained on countless real clips has implicitly seen how these phenomena look, so it can generate visually plausible sequences of them, sidestepping the simulation problem entirely (even though the model is not literally solving the physics).

▮ what it costs

None of this is free. Generating the roughly 827 hours of neural trajectories took about 105k L40 GPU-hours. That is real money, but it is plausibly cheaper and faster than physically teleoperating 800-plus hours of a humanoid. The trade is explicit: you buy data scale in GPU time instead of robot time.

● honest limitations

Generated data inherits the generator's flaws. A video model can hallucinate physically impossible transitions, and the IDM will dutifully label them anyway, so the pseudo-actions are only as trustworthy as the clip and the VLM judge that screened it. Latent actions capture motion intent but discard exact dynamics, so they help with what to do, less with precise how. And the pipeline is heavy: a fine-tuned generator, a VLM prompter, a VLM judge, and an IDM all have to be built and trusted before a single neural trajectory exists.

09Where it fits, and the one-line takeaway

GR00T N1 shares π₀'s genetic material, a vision-language module plus a flow-matching action module, but it makes a different bet about where the leverage is. π₀ and its successors invest heavily in architecture and post-training recipe; GR00T invests in data manufacturing. The dual system, the cross-attention link, the embodiment adapters: all competent, none revolutionary. The revolution it is reaching for is being able to train on video that has no actions, at a scale teleoperation can never match.

That places it in a clear lineage: it carries the π₀ flow-matching family's architecture forward but, like the DreamGen / neural-trajectory line out of the same author group, treats the data problem as the real problem. Latent actions and the IDM are two complementary answers to the same question, "how do I get supervision out of a clip that came with none?", one abstract and body-agnostic, one concrete and robot-specific. Neural trajectories are the factory that turns a trickle of real data into a flood of synthetic data the IDM can label.

▲ the part to remember

If you take one thing from GR00T N1, make it this: the headline number is not a benchmark score, it is 88 hours becoming about 827. Everything in the model serves that multiplication. When real data is the bottleneck, the highest-leverage research is often not a better network, it is a better way to make data.


The one-sentence takeaway: action-less video is the ocean, and GR00T N1's real contribution is two ways to drink from it, a latent-action code that reads motion intent off any frame pair and an inverse-dynamics model that invents the missing actions, so a fine-tuned video generator can turn 88 hours of real robot time into roughly 827 hours of trainable neural trajectories.