Where you are. You have taken apart the one frontier design whose weights you can download. This lesson does the same for the two biggest closed-ish alternatives, and uses them to show that the interesting decision in a VLA is not where you cut but what you send across.
Two robots, one of which leaves a log
Two robots are asked to put the ketchup away. Both do it correctly. Watch them again with a debugger attached.
Inside the first, at the moment it starts to move, is a vector of a few thousand floating-point numbers. It is a perfectly good vector. It is also not about anything you can name: no dimension in it means “ketchup”, no slice of it means “the fridge”. It means what it means because two halves of one network were trained together until it did.
Inside the second, at the same moment, is a line of text: open the fridge and put it on the middle shelf.
Now break both robots. Put the ketchup somewhere unusual, or put a second bottle on the counter, and let them fail. The first hands you a video. The second hands you a video and a sentence, and the sentence tells you immediately whether the failure was thinking or moving.
The idea in one paragraph
GR00T N1.7 and Gemini Robotics both split the slow half from the fast half, and they put the boundary in different places. GR00T keeps everything inside one model: a vision-language backbone hands a hidden state to a diffusion action head, and what crosses is a tensor nobody will ever read. Gemini splits the halves into separate models on separate machines: an embodied-reasoning model plans in language and emits a natural-language subtask instruction, and a vision-language-action model turns that instruction into motion. Architecturally they are close cousins. The interface is the real difference, and it decides three practical things: what you can see when it fails, what you can retrain without touching the other half, and whether you can put your own planner or your own robot on the other side of the line.
Wider than the screen; scroll it sideways.
GR00T N1.7: one model, one tensor
NVIDIA’s GR00T is a 3-billion-parameter model, current as GR00T N1.7 when this was checked on 9 August 2026. I could not pin the N1.7 release date to a primary artifact, so treat “since about April 2026” as approximate and read the release history off the repository.
Wider than the screen; scroll it sideways.
The backbone is Cosmos-Reason2-2B, a vision-language model NVIDIA describes as reaching it “via Qwen3-VL”, which processes image and language tokens. It feeds a 16-layer diffusion transformer trained with flow matching, which produces motor commands. NVIDIA frames this as a dual-system design explicitly: a slow reasoning backbone and a fast action head, with the boundary drawn between the two networks rather than inside a shared stack the way π₀ does it.
The published speed figure is 35.9 Hz on an H100 80GB with TensorRT, at four integration steps, a single camera view, batch size 1 and bf16. Every clause in that sentence is load-bearing, which is the habit worth building: four steps rather than the dozens a diffusion sampler might want, one camera rather than three, an H100 rather than the machine you own, and a compiled inference runtime rather than plain PyTorch. The same table on the same model card lists 2.9 Hz on a Jetson Orin in eager PyTorch, which is a factor of twelve and the number nobody quotes.
What is genuinely open is substantial: code, weights, a LeRobot integration with groot as a policy type, fine-tuning scripts, and embodiment configurations for adapting to a new robot. What is not open is the training data. NVIDIA’s repository states that N1.7 “is pretrained on 20K hours of EgoScale human video data alongside diverse robot demonstrations”. None of that corpus is released.
On hardware, GR00T is friendlier than π₀ at inference and harsher at training. Inference runs on a single GPU with 16 GB or more, and NVIDIA lists Jetson AGX Thor and Orin among the targets, which means it is genuinely deployable on a robot rather than only in a rack. Fine-tuning wants 40 GB or more, which rules out every consumer card and pushes you to rented L40, A100 or H100 time.
Gemini Robotics: two models, one sentence
Google DeepMind’s line splits the halves apart entirely.
The pattern was set with Gemini Robotics 1.5 and ER 1.5 in September 2025. ER, for embodied reasoning, is a vision-language model acting as orchestrator: it searches for information it does not have, plans a multi-step mission, decomposes it, and emits natural-language subtask instructions. The VLA takes those instructions and produces motor commands.
Wider than the screen; scroll it sideways.
Two additions from that release are worth carrying forward. The first is thinking before acting: the VLA generates an internal natural-language reasoning trace before it emits any action. Asked to sort laundry by colour, it reasons about what the instruction means, which bin each item belongs in, and only then produces motion. The second is motion transfer: skills trained only on one platform reportedly transferred to others, in both directions, across an ALOHA 2 bimanual rig, an Apptronik Apollo humanoid and a bi-arm Franka.
The current family, announced 30 July 2026, has three members: Gemini Robotics 2, the VLA, covering full humanoid and bi-arm control with multi-finger hands and parallel grippers; Gemini Robotics ER 2, the reasoning half, planning multi-step missions lasting minutes and coordinating multiple robots; and Gemini Robotics On-Device 2, which runs locally on the robot with no network round trip.
The number in that release most relevant to you is on your own arm. Google reports that on the SO-101, Gemini Robotics On-Device 2 reaches 53.3% success against the previous version’s 6.7%, and on a Dexmate platform 75.6% against 33.3%. I could not open the On-Device 2 model card to verify those four figures at the time of writing, so carry them as second-hand vendor numbers with no trial count attached, not as measurements. They are Google-internal evaluations either way, and if they hold they are a striking result on a two-hundred-dollar arm from a model you cannot run.
More useful than the wins are the limitations Google states itself: that the model struggles with out-of-distribution tasks and with controlling robots with many degrees of freedom, and that it is optimised for standing bi-arm manipulation. A vendor telling you where its model breaks is doing you a favour, and it is worth more attention than the success table above it. Go and read that card yourself - it is a fifteen-minute exercise and it is the one in this lesson I most want you to actually do.
Openness is four switches, not one
“Is it open” is the wrong question, and this module has now produced enough counterexamples to replace it with a better one. Four things vary independently.
| Model | Code | Weights | Training data | Who ran the evaluation |
|---|---|---|---|---|
| π₀.₅ | Apache-2.0 | downloadable, licence worth checking yourself | not released | authors, plus outside labs on SO-101 |
| GR00T N1.7 | Apache-2.0 | downloadable, NVIDIA Open Model License | not released | NVIDIA, internally |
| Gemini Robotics 2 | not released | Trusted Testers only | not released | Google, internally |
| SmolVLA | Apache-2.0 | downloadable, tagged Apache-2.0 | 481 public community datasets | authors, plus outside labs |
Read a row left to right and you get a much sharper picture than any adjective. GR00T hands you almost everything except the thing that actually took the money to build. Gemini hands you the reasoning half through an API and keeps the acting half. SmolVLA is the only row where you could, in principle, reconstruct the whole artefact.
Check yourself
1. Both designs split slow from fast. Name the single most important practical difference and why it matters.
What crosses the boundary. GR00T passes a hidden-state tensor, which is fast and lossless but invisible; Gemini passes a natural-language instruction, which is lossier and slower but appears in a log. When the robot does the wrong thing, the readable interface tells you immediately whether the slow half misunderstood the task or the fast half fumbled the execution. The tensor interface leaves you with a video.
2. “GR00T N1.7 is Apache-2.0.” What is wrong with that sentence?
It conflates code with weights. The repository’s LICENSE is Apache-2.0 and covers the code; the weights are under the NVIDIA Open Model License Agreement, a bespoke licence that allows commercial use but is not OSI-approved. If your reason for asking was legal, only the weights licence answers your question.
3. GR00T reports 35.9 Hz. Which qualifying details change what that number means for you?
Four steps of denoising, a single camera view, an H100, and TensorRT rather than plain PyTorch. Change any one of those toward what you actually own and the number falls. It is a real measurement of a favourable configuration, which is the normal way vendors report speed, and the fix is to reproduce it on your own setup before planning around it.
4. “+61% on one DROID split.” Why is that unhelpful on its own?
Because a relative improvement with no absolute endpoints describes a huge range of realities. Five per cent to eight per cent and fifty per cent to eighty per cent are both “+61%”, and only one of them is a usable policy. Ask for the two numbers the percentage was computed from, and if they are not published, treat the claim as directional at most.
5. Gemini Robotics On-Device 2 reports 53.3% on the SO-101 against 6.7% for the previous version. What can you actually do with that?
Almost nothing operationally, because the model is distributed only to Trusted Testers, so you cannot run it. What it is good for is calibration: it tells you that a cheap arm is not the limiting factor in these results, and it gives you a rough sense of what a frontier model achieves on hardware like yours, against which your own fine-tune numbers later in this module can be read.
6. Which of the four openness switches would you check first if you were choosing a model for a commercial project?
The weights licence, because it is the one that can end the project outright, and it is the switch most often misreported. Then availability, since a Trusted Tester programme is an announcement rather than a tool. Data and evaluation independence matter for how much you believe the numbers, but they will not get you a call from legal.
Do this
About forty minutes, mostly reading.
1. Do the licence archaeology. Open the GR00T N1.7 model card and the repository, and find two things: the exact name of the licence covering the weights, and the exact name of the licence covering the code. Then search for a blog post or summary describing GR00T’s licensing and note whether it gets the distinction right. Keep the URLs and the date. You are building the reflex, not the answer.
2. Check what you can actually call. Open Google AI Studio and find which Gemini Robotics models are available to you today. Write one sentence about what that means for a project plan that assumed you could use the VLA.
3. Draw both from a blank page. No references. Draw GR00T: two inputs, backbone, action head, what crosses between them, what comes out. Then draw the Gemini split: two models, the sentence between them, which side runs where. Then check against the two figures above and note what you got wrong; what you get wrong is the part you have not understood yet.
4. Fill in the fifth row. Take any model this module has not covered and add a row to the four-switch table: code, weights, data, evaluator. If you cannot fill a cell in ten minutes of looking, write “could not determine” rather than guessing, and notice how often that happens.
What you can now do
You can draw GR00T N1.7 and the Gemini Robotics split from memory, and say what crosses the boundary in each. You can explain why a readable interface is worth real performance to a team that has to operate the system. You can separate a model’s code licence from its weights licence and know which one your lawyer cares about. And you can read a release through four independent switches rather than the single word “open”, which is the difference between reading the announcement and reading the artefact.