Chapter 19
Adapt a current VLA through explicit data, action, and release contracts
Choose a current vision-language-action path by verified capability rather than model fame, then build the evidence needed to adapt and deploy it responsibly. This chapter distinguishes a robot-learning toolkit, downloadable action policy, and API-hosted embodied reasoner; aligns cross-embodiment data without mixing action meanings; pins checkpoints and processors; scopes parameter-efficient adaptation to implementations that actually support it; round-trips every normalized action into a guarded robot command; freezes a generalization suite; and closes with an evidence-backed deploy, revise, or reject record.
Before you start
- Complete Week 14's episode, multimodal schema, timestamp, action-space, split, quality, and dataset-card work, plus Week 15's behavior-cloning, chunking, rollout-evaluation, latency, fallback, and policy-comparison work.
- Complete Week 18's distinction among a VLM, a VLA, and an embodied-reasoning model, and be able to trace pixels and task text through a model output to a robot-specific action interface.
- Bring a small non-sensitive LeRobot-format or synthetic dataset, a documented observation/action contract, a frozen simulator or paper evaluation set, and enough Python familiarity to inspect dictionaries, tensor shapes, configuration files, and saved metrics.
- Keep every exercise offline, simulated, unpowered, or on an already commissioned robot under qualified supervision. A model checkpoint, API response, normalized action, or successful demo is not a safety-rated motion authority.
By the end
- Classify LeRobot 0.6, OpenVLA, Isaac GR00T N1.7, Gemini Robotics-ER 1.6, openpi π0.5, and SmolVLA by artifact, input/output, adaptation path, embodiment support, runtime, license/access, and evidence boundary without treating unlike products as interchangeable.
- Version a cross-embodiment training manifest that preserves task language, feature schema, camera order, state/action meaning, units, frames, rates, provenance, sampling weights, and a separate adapter for each physical body.
- Load a pinned base checkpoint with its exact configuration and processor artifacts, validate a golden observation and decoded output offline, and fail closed on missing, renamed, reordered, or incompatible fields.
- Plan or execute a supported parameter-efficient adaptation while keeping the base policy immutable, recording target modules and trainable parameters, isolating the adapter, and comparing both artifacts on one predeclared suite.
- Implement field-specific normalization and de-normalization whose output then passes finite-value, dimension, unit, frame, freshness, absolute-limit, rate-limit, collision, controller, and authority checks before any command path.
- Measure familiar and held-out objects, scenes, viewpoints, prompts, and compatible embodiments separately, preserving interventions, abstentions, wrong actions, latency, and failures instead of hiding them in one average.
- Publish an adaptation report that ties versions, data, compute, cost or energy where measured, latency, generalization, regressions, safety wrappers, licenses, evidence artifacts, and an explicit deploy, revise, or reject gate.
The field story
Policy Passport Review
A robotics team has inherited six impressive model names and one uncomfortable question: which artifact can actually enter its simulator? You join the Policy Passport Review, where every candidate must declare its inputs, outputs, processor, action meaning, embodiment, adaptation path, and evidence boundary before anyone downloads a checkpoint. The recurring mission is not to crown a fashionable model. It is to assemble one reviewable passport for a bounded policy candidate, preserve an untouched baseline, and expose every translation between camera pixels, language, normalized actions, and the robot-specific command contract.
During the week, the passport moves across seven desks. The ecosystem desk separates frameworks, downloadable policies, and hosted reasoners. Data review checks that two robot bodies do not share a column whose physical meaning differs. Release engineering pins the processor and checkpoint. Adaptation records only the supported trainable change. A decoder then round-trips normalized values through independent guards, and the evaluation desk challenges unfamiliar objects, scenes, prompts, and embodiments. The final budget includes measured data, compute, latency, regressions, and uncertainty, leaving Week 20 a typed policy output it can safely treat as a proposal rather than a motor command.
- Why this chapter now
Earlier weeks established robot data, policy evaluation, and model-to-action boundaries. This is the moment to select and adapt one candidate while distinguishing system identification, deliberate domain randomization, and evidence that would actually support transfer.
- Ignore for now
Do not train a foundation model, rank vendors from marketing claims, use randomization as a substitute for system identification, or infer physical compatibility or sim-to-real success from a model load or simulator result.
- This unlocks
A versioned, bounded policy proposal that Week 20 can wrap in typed skills and that Week 21 can challenge through independent safety and release gates.
- Proof you will leave with
A dated ecosystem matrix, immutable baseline identity, processor/configuration hashes, feature and action contracts, system-identification ledger, justified randomization ranges, golden fixtures, adapter manifest, generalization rows, latency observations, explicit sim-to-real boundary, and a signed decision note with failures retained.
Environment contractrepository-supported Node.js 22.13.0 or newer and this repository are sufficient for the contract starter; use synthetic observations and keep model downloads, cloud APIs, GPUs, and powered robots outside the baseline.
- Compatibility boundary
The starter uses dependency-free JavaScript. Any real LeRobot, OpenVLA, GR00T, openpi, SmolVLA, or hosted-model path must be checked separately against its pinned repository, processor, license/access terms, hardware, and supported embodiment; simulator randomization alone does not establish sim-to-real compatibility.
- Smoke check
Run
node week-19-policy-passport.mjs; confirm the golden passport is accepted, the camera-order fault is rejected, and the release remains held for full evaluation.- Contract reviewed
2026-07-25
- Runtime evidence
The dependency-free starter is executed by repository tests on the supported Node.js baseline. Chapter-specific ROS 2, Gazebo, model, dataset, checkpoint, and hardware environments are learner-created unless the repository supplies an explicit asset; run the smoke check and preserve its versions and output before claiming runtime compatibility.
- Drift risk
high
Today in the field story
One problem, then the next
The first Policy Passport meeting begins with six labels on a whiteboard and no assumption that they describe equivalent products. You classify each item as a framework, downloadable action policy, hosted embodied reasoner, or supporting implementation, then record declared inputs, outputs, adaptation route, embodiment evidence, and access boundary. The passport advances only when comparison columns describe the same layer; fame, parameter count, or a polished demo cannot substitute for an executable contract.
- Why now
Selection errors contaminate every later data, adaptation, and deployment decision.
- Ignore today
Ignore winner rankings, unsupported release claims, and large downloads.
- Unlocks next
One defensible candidate and one explicit alternative for the passport.
Understand
Build the physical picture first
The VLA ecosystem is a parts counter, not a horse race: first identify whether an item is a toolkit, action policy, hosted reasoner, processor, dataset contract, or robot adapter.
A useful comparison begins by separating product layers. LeRobot 0.6 is an open robot-learning framework that standardizes datasets, policies, training, evaluation, rollout, processors, and supported hardware integrations; it is not one VLA architecture. OpenVLA is an open 7B-class manipulation policy whose original path predicts discrete action tokens and whose repository documents LoRA and full fine-tuning. SmolVLA is a smaller LeRobot policy with a vision-language backbone and continuous action expert. Their commands, checkpoints, and hardware assumptions are not interchangeable merely because all appear in one ecosystem list.
Isaac GR00T N1.7 is an early-access 3B generalist robot policy with a reasoning VLM backbone and flow-matching action head. Its embodiment tag and modality configuration tell the software how to interpret state, action, and video fields. Physical Intelligence's openpi publishes π0, π0-FAST, and π0.5 base and task-specific checkpoints, with π0.5 using a flow-matching path in the maintained implementation. Both families offer fine-tuning workflows, yet a checkpoint trained for a published embodiment remains a candidate to evaluate, not proof that an unlisted robot can use it zero-shot.
Gemini Robotics-ER 1.6 belongs in a different row. Its official model card describes multimodal input and text output, and its release material positions it as high-level embodied reasoning that can plan, point, detect success, and call a VLA or another typed tool. It may help choose an object or decide whether a stage completed, but its API text is not a joint command. A system using it still needs a separately validated perception-to-entity contract, bounded robot skills or VLA, timeouts, and an independent command guard.
Choose from the physical requirement backward. Record task, robot, camera and state fields, action representation and horizon, target rate, available GPU memory, measured tail latency, supported training format, access and license, processor ownership, evaluation harness, and recovery path. Then mark each candidate supported, convertible with named work, or unknown. A current version number, parameter count, benchmark headline, successful import, or polished video cannot replace an end-to-end trial on the declared conditions.
Words you need
Name each idea precisely
- Robot-learning framework
A collection of dataset, policy, training, evaluation, rollout, processor, and hardware interfaces that can host several different model families.
Physical example:LeRobot can train or evaluate ACT, SmolVLA, π0-family, and GR00T integrations while each policy retains its own architecture and requirements.
- Action policy
A model that consumes a declared observation and task context and produces a robot action or action chunk through a specific representation.
Physical example:A manipulation checkpoint receives two camera images, joint state, and “place the cup,” then proposes a seven-value Cartesian-and-gripper action chunk.
- Embodied reasoner
A high-level multimodal model used for spatial reasoning, planning, tool selection, or success detection rather than direct low-level command generation.
Physical example:Robotics-ER identifies the correct gauge and calls a typed inspection skill, whose controller—not the reasoner's text—owns robot motion.
- VLA action head
The model component that converts internal multimodal features into a declared action distribution, token sequence, or continuous trajectory.
Physical example:A flow-matching head iteratively produces a continuous action chunk, while original OpenVLA decodes predicted action tokens through robot-specific statistics.
- Supported embodiment
A robot body and observation/action configuration for which the project publishes a matching contract, checkpoint, adapter, or reproducible workflow.
Physical example:A GR00T embodiment tag names the state and action modality expected for one body; spelling a new robot name in configuration does not create support.
Math, one line at a time
Work through today’s relationship
Prerequisite rescue · optionalFine-tuning size, normalization, and evidence
Model adaptation must fit compute limits and improve frozen physical trials.
- P_train
- parameters updated during tuningUnit: parameters
- GB
- memory footprintUnit: gigabytes
- Δsuccess
- new minus baseline success rateUnit: percentage points
A baseline succeeds 12/20 = 60%; adaptation succeeds 16/20 = 80%.
Improvement is 80%−60% = 20 percentage points, not 20 percent.
Report parameter count, memory, latency, and the same frozen scenarios before claiming improvement.
Treat a policy release like a mobile release: same acceptance suite, device budget, rollback path, and versioned artifact.
A metric rises from 50% to 65%. What is the percentage-point gain?
15 percentage points.
Memory demand is
leaving headroom on an device. At ,
Reduce a six-family field guide to one defensible first experiment
A team has an existing LeRobot-format tabletop dataset, one 24 GB GPU, a 10 Hz supervisory action requirement, and no authorized powered-robot test this week.
Write non-negotiable columns before naming models: downloadable or API artifact, action-producing or reasoning-only output, dataset conversion, processor availability, estimated memory, offline evaluation path, license/access, and robot adapter status.
Place LeRobot in the toolkit row, then place OpenVLA, SmolVLA, GR00T N1.7, and openpi π0.5 in policy rows with their distinct data and action contracts; place Robotics-ER 1.6 in the hosted reasoner row.
Reject any candidate whose minimum documented memory or required embodiment work cannot fit the current experiment, and mark unknown values unknown rather than replacing them with parameter-count guesses.
Prefer the candidate that can consume the existing data with the least semantic conversion and has a maintained offline inference or benchmark path; retain one smaller baseline so model size is not confused with task fitness.
Freeze five golden observations and a simulator task suite, then measure processor validity, output shape, de-normalized range, p50 and p95 latency, and task outcome without connecting a motor driver.
Record the choice as “first candidate for offline evaluation,” not “best VLA,” because no equal real-task evaluation, deployment soak, or safety acceptance has yet occurred.
The team selects a runnable policy-baseline pair for a bounded offline experiment and preserves Robotics-ER as a separately measured reasoning component rather than forcing it into a low-level policy benchmark.
A fair ecosystem map compares contracts and evidence at the same layer; it does not rank a framework, hosted reasoner, and robot checkpoint as though they were equivalent executables.
Physical examples
Where this appears in real life
One SO-101 task, six unlike candidates
A lab wants a small arm to move colored blocks at 15 Hz with two cameras and limited GPU memory, while also explaining failures to an operator.
A compact supported policy and LeRobot rollout path can be benchmarked for actions; an API reasoner may assist inspection, but it is scored separately and cannot satisfy the motor-rate requirement.
Gauge inspection beside a humanoid stack
A humanoid must locate an analog gauge, interpret its reading, walk to a panel, and operate a bounded control under site rules.
High-level visual reasoning, whole-body policy, controller, equipment skill, and protective system have separate owners, outputs, rates, and acceptance evidence.
Hands-on exercise
Make the idea observable
Use the five chapter sources and one spreadsheet or Markdown table. Do not download multi-gigabyte checkpoints until the compatibility and resource columns justify the cost.
Create dated rows for LeRobot 0.6, OpenVLA, SmolVLA, GR00T N1.7, Robotics-ER 1.6, and openpi π0.5; attach one official URL and access date to every factual row.
Fill artifact type, inputs, outputs, action representation, dataset format, adaptation path, embodiment mechanism, published checkpoint, runtime path, access/license note, and maintainer warning.
Add local requirement columns for camera count and order, state/action dimension, rate, memory, operating system, robot interface, evaluation suite, fallback, and allowed test surface.
Use only supported, conversion-required, incompatible, or unknown as compatibility labels, with one evidence sentence behind every non-unknown label.
Select one candidate and one baseline for offline work, then list the exact missing evidence that would change the selection.
Have a peer find any row that mixes high-level reasoning results with physical action results, repair the layer classification, and freeze the matrix version.
The most famous model may leave critical local cells unknown, while a smaller maintained policy can offer a shorter and more inspectable path from dataset to measured action.
Every candidate has a verified layer and artifact type, the selected experiment follows from declared constraints, and no unsupported benchmark, latency, memory, license, or safety claim remains.
Build today
Benchmark a supported LeRobot/OpenVLA policy, trace its processors and normalized actions, then design or run a LoRA adaptation with a frozen baseline.
Evidence to save
DONE when the learning log explains “2026 practical VLA map: LeRobot 0.6, GR00T 1.7, Gemini Robotics ER 1.6, π0.5, OpenVLA, and SmolVLA” in five precise points and a checked example produces the predicted output.
Common mistakes
Catch the wrong mental model
Calling every item in the ecosystem a directly deployable VLA checkpoint.
Classify frameworks, downloadable action policies, hosted reasoners, processors, and adapters separately, then compare only evidence produced at the same system layer.
Choosing the largest or newest model before writing the robot contract.
Start from observation fields, action semantics, rate, resources, embodiment support, evaluation, and recovery; version recency becomes one maintenance signal rather than the decision rule.
Treating an official benchmark result as expected performance on a new robot.
Preserve the benchmark's robot, data, tasks, resets, metrics, and runtime scope, and label local performance unknown until the frozen local suite is executed.
Job connection
How this becomes employable evidence
Own a dated VLA selection review that translates a robot task into data, action, compute, runtime, integration, evaluation, and recovery constraints, then recommends one bounded experiment with explicit unknowns.
Relevant target roles
- Robot Learning Deployment / Physical AI Integration Engineer
- Robotics Deployment, Integration & Validation Engineer
- Robotics Application / ROS 2 Integration Engineer
Chapter 19 interview drill
Interview questions: 2026 practical VLA map: LeRobot 0.6, GR00T 1.7, Gemini Robotics ER 1.6, π0.5, OpenVLA, and SmolVLA
Practise a 60–90 second answer: define the idea, connect it to a physical robot, state assumptions, frames, and units when relevant, then finish with the failure signal or evidence you would inspect.
Primary interview scenario
Compare LeRobot, OpenVLA, GR00T N1.7, Gemini Robotics-ER 1.6, π0.5, and SmolVLA without giving a popularity ranking. Classify each layer, identify the first compatibility gates, and state what you would measure before hardware.
Answer shape: clarify the situation → trace the physical and software path → test the most likely boundaries → name the evidence that would confirm the result.
Technical follow-up questions
Q1Why is LeRobot 0.6 not directly comparable with one OpenVLA checkpoint?
LeRobot is a framework spanning data, policies, training, evaluation, rollout, and hardware integration, while an OpenVLA checkpoint is one model artifact with a particular processor and action contract.
Q2What output boundary prevents Robotics-ER 1.6 from being treated as a low-level controller?
Its official model card declares text output; any physical action must pass through a separately typed and validated VLA or robot-skill interface.
Q3What label should a matrix cell receive when official material does not establish local GPU memory?
Unknown, followed by a measurement plan; parameter count or a third-party anecdote should not be silently substituted.
Chapter references
- Hugging Face — LeRobot v0.6.0 releaseMaintainer record of the July 2026 release, including the expanded policy ecosystem, unified simulation evaluation, rollout and human-correction workflows, FSDP and cloud training, and the distinction between framework capabilities and any one model.
- OpenVLA — official repository and adaptation guideProject-owned checkpoint, processor, discrete-action, RLDS/OXE data, LoRA, full-fine-tuning, evaluation, and serving contracts, including the project's newer recommendation to consider OpenVLA-OFT.
- NVIDIA Isaac GR00T N1.7 — official repositoryMaintainer source for the early-access 3B checkpoint, embodiment tags, modality configuration, LeRobot-derived data layout, fine-tuning, evaluation, policy-server deployment, and published support boundaries.
- Google DeepMind — Gemini Robotics-ER 1.6 model cardPrimary classification of Robotics-ER 1.6 as an API-accessed vision-language model with multimodal inputs and text output for spatial reasoning, planning, and success detection rather than a downloadable low-level action checkpoint.
- Physical Intelligence — openpiProject-owned π0, π0-FAST, and π0.5 checkpoints, LeRobot dataset conversion, normalization-statistics computation, JAX and partial PyTorch paths, fine-tuning, inference, and policy-server guidance with explicit generalization cautions.