Skip to content
PPHYSICAL AI GUIDESTART HERE →

Field guide

The Embodiment Gap in Robot Foundation Models: What Still Changes on the Target Robot

A practical guide to cross-embodiment robot claims, including strict versus pretrain-exposed zero-shot transfer, target data, calibration, control, safety, recovery, and evaluation.

By Physical AI Guide Editorial TeamPublished Updated

The short answer

A robot foundation model does not reach a new robot when its checkpoint loads. It reaches the robot when reusable knowledge has been connected to that robot’s sensors, geometry, action interface, controller, contact behavior, safety controls, and recovery process, then validated in physical trials.

That remaining work is the embodiment gap. An August 2026 survey accepted by Transactions on Machine Learning Research defines it as the gap between models, representations, or data reused across robots and their execution on a particular target robot (paper).

The concept changes how cross-embodiment claims should be read. Instead of asking only, “Did the robot succeed?”, ask:

  1. What was actually shared across robots?
  2. What had to change on the target robot?
  3. How much target-robot data, calibration, physical testing, and human work were required?
  4. Where did failures occur?
  5. What safety and recovery functions remained outside the learned model?

A broad model can reduce one part of this work without eliminating the rest.

Generalization is not the same as execution

A model may recognize a cup, understand “put it on the shelf,” and generate a plausible motion representation across several robots. The target robot still has a specific reach, joint structure, gripper, payload, camera placement, control rate, latency, force capability, and safe operating envelope.

Even a nominally shared Cartesian displacement can produce different physical behavior on two systems. A mobile manipulator may reposition its base. A fixed arm cannot. A parallel gripper, anthropomorphic hand, and suction tool make contact in different ways. The same object path may be reachable for one body and impossible for another.

The survey separates shared structure from the work that remains. That produces two practical axes.

Axis 1: what is shared?

Shared layer What may transfer What it does not settle
Semantics and tasks Goals, language, plans, task decomposition Which target-robot skill can execute each step
Perception and affordances Object identity, regions, grasp or interaction cues Reachability, command mapping, stable contact
Object interaction Desired object motion or scene change Whether this body can reproduce that change
Actions and skills Action tokens, trajectories, skill representations Controller alignment, rate, limits, contact dynamics
Morphology-aware structure Body metadata, kinematic relationships, embodiment-conditioned actions Sensor calibration, force, safety, and recovery

Axis 2: where does target-robot work remain?

  1. Skill or API connection, turning an abstract plan into callable robot behavior.
  2. Calibration and control-interface alignment, making model outputs mean the intended motion on this controller.
  3. Contact and force execution, preserving stable physical interaction through friction, compliance, slip, and disturbance.
  4. Safety and recovery, stopping safely, handing control over, retrying, and returning to operation after failure.

This is not a leaderboard. Moving closer to execution on one axis does not prove that less total work remains. It shows where the hidden work is likely to appear.

Three ways researchers try to reduce the gap

The survey organizes current work into three overlapping directions. Each one scales a different reusable layer.

1. Share semantics and perception

Language and vision models can transfer broad knowledge about objects, instructions, spatial relationships, and plans. This is useful because those signals are easier to scale than physical action trajectories.

The limitation is distance from execution. A plan such as “grasp the handle, open the drawer, retrieve the item” does not define reachable poses, collision-free motion, grip force, controller timing, or recovery after the drawer sticks. A perception model can identify an affordance that sits outside the target robot’s workspace.

This layer is valuable, but it should be evaluated as planning or perception unless the result also shows how it becomes closed-loop physical action.

2. Share robot data and interfaces

Robot datasets and common schemas attempt to make trajectories reusable across hardware. Normalized observations, actions, timestamps, metadata, and control conventions can reduce repeated tooling work and allow mixed-robot training.

The remaining gap lies in what normalization hides. Two datasets may both call a field “end-effector delta” while using different coordinate frames, rates, gripper semantics, latency, filtering, and low-level controllers. A shared file format is not a shared physical response.

Our guide to how robot training data is made explains why source hardware, retargeting, synchronization, quality control, and downstream policy gain must remain visible. The Ego2Robot evidence audit provides a concrete case where human video is rendered into multiple robot morphologies, but target-specific physical validation remains essential.

The same boundary applies to reconstructing the body itself. Our open-source humanoid reproducibility audit uses Bridge to show why CAD, actuator curves, robot descriptions, calibration, controller versions, and matched outside tests must remain attached to a morphology-control claim.

3. Learn correspondence across embodiments

Correspondence methods try to model how different bodies can produce a related object motion, action, or interaction. They can use object trajectories, retargeting, morphology descriptions, shared latent actions, tactile signals, or learned action translators. Our latent actions evidence guide tests the boundary between a video-derived transition representation and executable target-robot control.

This direction comes closest to the central problem, but correspondence is not execution. A kinematically valid mapping can still slip, collide, exceed a force limit, saturate a controller, or fail after a disturbance. Modeling links and joints does not automatically model sensor placement, compliance, backlash, wear, or safe recovery.

The durable question is not whether correspondence exists. It is which parts of the target-robot stack no longer need to be rebuilt, and what evidence demonstrates that reduction.

RoboEdit: scaling correspondence in the data layer

RoboEdit is a useful current example because it explicitly transforms human manipulation video into target-robot video and 3D hand-state supervision (paper). The authors report 174,000 aligned human-to-robot video pairs, 14 million frames, and seven robot embodiments.

Its automatic data curation pipeline reconstructs human hand and object interaction, retargets motion to a selected robot, refines depth and physical consistency, renders the robot, and composites the result into the source scene. Its editing model then learns cross-embodiment appearance, kinematics, motion, and contact cues. A 3D state decoder recovers per-frame robot-hand states.

That is a data-generation and correspondence result. It does not turn 14 million frames into 14 million frames of physical robot operation.

The authors also run downstream physical manipulation experiments. Those tests matter because they ask whether edited video and recovered states help control, not only whether the frames look plausible. The evidence remains author-run and bounded. Before treating RoboEdit as a general bridge to a new robot, a reader still needs:

  • artifact and dataset availability;
  • source-video selection and filtering rules;
  • per-embodiment reconstruction and retargeting error;
  • collision, penetration, floating-contact, and temporal-artifact rates;
  • target-robot policy architecture and training budget;
  • physical trial counts by task and embodiment;
  • comparisons against matched real-robot and simpler synthetic data;
  • failures caused by geometry, contact, viewpoint, and controller mismatch.

RoboEdit may reduce the cost of producing embodiment-specific visual and motion supervision. It does not remove the need to prove that the target robot can execute the represented interaction reliably.

ADEPT: shared recipe, embodiment-specific execution

ADEPT illustrates a different boundary. It pretrains dexterous arm-hand behavior in simulation, post-trains task specialists, distills them into perception-based students, and transfers those students to physical hardware (paper, project page).

The authors demonstrate two systems:

  • a 23-degree-of-freedom Kuka-Allegro using two RGB cameras;
  • a 29-degree-of-freedom Flexiv-Sharpa using two RGB cameras and five vision-based tactile sensors.

The framework shares an engineering and learning recipe, but the paper states that each task and embodiment is trained independently, using pretrained policies specific to that embodiment. That is meaningful multi-embodiment evidence. It is not one unchanged policy transferred between the two bodies.

ADEPT also makes hidden embodiment work visible:

  1. an embodiment-specific simulation and reposing policy;
  2. a structured post-training process using actor distillation, critic warm-up, and conservative policy updates;
  3. a joint-space geometric control layer that mediates policy output and hardware constraints;
  4. an embodiment-specific sensor configuration;
  5. teacher-student distillation into a deployable visual or visual-tactile policy;
  6. physical calibration and evaluation on each system.

The pretrained policy could handle much of a peg reposing path before post-training, but reported zero-shot success fell to zero or near zero at the final insertion target where new contact occurred. This is a direct example of shared dexterity reaching the contact boundary. Precise insertion still required downstream task training.

ADEPT’s physical results support the authors’ bounded sim-to-real claim on selected dexterous tasks. They do not establish that a new hand can be added without building its simulator, policy, controller interface, sensor setup, post-training process, and safety validation.

A minimum cross-embodiment report card

The survey proposes a report card for the adaptation work hidden by final success rates. The following version turns it into a buyer, researcher, and reviewer checklist.

Field Minimum disclosure Question it answers
Source setting Robots, sensors, controllers, tasks, and pretraining conditions Where did the reusable structure come from?
Target robot Body, end effector, sensors, controller, task, and environment What had to execute physically?
Shared structure Model, representation, data, plan, action, skill, or body encoding What was actually reused?
Modified components Heads, adapters, decoders, policies, controllers, prompts, and safety layers What changed for the target?
Target-robot data Demonstrations, teleoperation, adaptation trials, failures, and recovery data How much new experience was required?
Model updates Frozen modules, adapter training, full fine-tuning, RL, and compute How extensive was learning on the target?
Calibration and setup Frames, cameras, force or tactile sensors, gripper, timing, and limits What preparation preceded execution?
Physical adaptation Robot hours, attempts, resets, interventions, reruns, and discarded runs How much hardware work preceded evaluation?
Safety and recovery Stops, unsafe contact, protective actions, handoffs, retries, and recovery rules Can the system fail and resume acceptably?
Evaluation Held-out tasks, rollouts, seeds, criteria, speed, uncertainty, and exclusions What does the final result cover?
Failure causes Perception, interface, correspondence, contact, safety, and recovery Where does the gap remain?

“Not publicly disclosed” is a valid answer. It is more useful than silently treating missing work as zero.

Plot performance against adaptation effort

A final success rate is an endpoint without a path. The survey proposes an Embodiment Adaptation Curve, which plots performance against one comparable measure of target-robot effort.

Possible horizontal axes include:

  • number of target-robot demonstrations;
  • physical adaptation attempts;
  • robot hours;
  • human interventions;
  • resets or recovery episodes;
  • task-specific training compute.

A method that reaches 80% after ten demonstrations is operationally different from one that reaches 80% after 1,000 demonstrations and several days of physical tuning. A curve also shows whether performance rises steadily, plateaus, or regresses as adaptation increases.

Do not combine unlike effort into one invented score. Publish several curves or a table when demonstration count, robot time, intervention, and compute tell different parts of the story.

Separate failure causes before changing the model

Cross-embodiment failure can enter through at least four layers.

Semantics and perception

The system misunderstands the instruction, selects the wrong object, or predicts an unsuitable interaction point.

Data and interface

The action representation does not match the target controller, coordinate frame, rate, gripper command, or observation timing.

Embodiment correspondence

The intended motion is unreachable, poorly retargeted, or incompatible with the target body’s geometry and capability.

Physical execution

Contact slips, force is wrong, the controller saturates, a collision occurs, or the system cannot stop and recover.

The primary and contributing causes should both be retained. If a gripper slips after receiving the correct object trajectory, the immediate failure is physical execution. A correspondence method that ignored contact capability may be a contributing cause. Calling both cases “policy failure” discards information needed to improve the system.

Our robot benchmark evidence guide explains how to preserve task scope and denominators. The robot intervention guide adds handoff, operator time, and recovery measures. The adaptive robot safety case guide separates useful task completion from safe completion and change control.

Zero-shot claims need a declared boundary

“Zero-shot” is meaningful only when the shot and target are named.

A result can be:

  • zero-shot to a new object on the same robot;
  • zero-shot to a new task with a fixed controller;
  • zero-shot from simulation to physical hardware;
  • zero-shot to a new robot body;
  • zero-shot at deployment after embodiment-specific training elsewhere.

These are different claims. Zero real-world fine-tuning does not mean zero embodiment-specific work. Simulation construction, reward design, morphology modeling, camera placement, controller integration, calibration, domain randomization, protective limits, and physical evaluation can all remain.

A complete sentence looks like this:

The policy received no real-world gradient updates after simulation, but used an embodiment-specific simulator, controller, sensor layout, calibration procedure, and physical validation protocol.

That statement is more informative than “zero-shot sim-to-real” alone.

ZETA: strict transfer is not pretrain-exposed transfer

A September 2026 study called ZETA turns one ambiguity in that list into a controlled experimental variable. It proposes two labels:

  • Strict zero-shot transfer: the target embodiment is absent from all training data.
  • Pretrain-exposed zero-shot transfer: the target embodiment appears during pretraining, but its downstream target tasks are absent from post-training.

This distinction is useful because both protocols can be described informally as zero-shot. They do not ask equally difficult questions. Strict transfer tests whether training on other bodies produced a representation that reaches a previously unseen body. Pretrain-exposed transfer tests whether prior experience with the target body can carry into target tasks that were withheld later.

ZETA evaluates stationary tabletop manipulation with two-finger grippers. Its controlled simulation uses seven held-out target embodiments across appearance-only, gripper-only, arm-only, and full-embodiment changes. The primary simulation protocol evaluates three tasks, 100 rollouts per task and target, and three training runs, for 6,300 rollouts per model. A separate physical evaluation uses seven held-out targets, two tasks, and ten trials per task and target, for 140 target-robot rollouts per model.

The paper scores task progress from 0 to 100 rather than reporting only binary completion. Partial credit corresponds to necessary subgoals, such as reaching and contacting an air-fryer handle before opening it. That metric makes transfer failures more visible, but it is not interchangeable with a full task-success rate.

Four factors changed the reported transfer result

The controlled comparisons identify four effects within this test bed.

Factor Reported comparison What the result supports What it does not establish
State and action frame In simulation, local end-effector delta state and action reached 75.7% average progress, compared with 60.3% for absolute end-effector state and world-frame delta action A local end-effector representation transferred better across the tested arm and full-body changes One coordinate choice is best for every robot, controller, or task
Source embodiment diversity Under a fixed 640,000-trajectory pretraining budget, the 512-source setting beat the single-source setting by about 18 percentage points on average Broad variation within the generated Franka-style source pool can improve transfer More embodiments always help monotonically or regardless of data budget
Auxiliary co-training Simulation objectives raised average progress from 75.7% without co-training to between 77.7% and 82.3% Language-action, subgoal, and grounding supervision can add useful transfer structure The gain has been reproduced on physical hardware for these objectives
Target embodiment exposure Replacing 5% of the fixed pretraining budget with target-embodiment data raised mean progress across two targets by 13.4 percentage points Limited target exposure materially changes evaluation difficulty Target exposure eliminates the need for target-task adaptation

The source-diversity result needs its budget qualifier. With total trajectories held fixed, each of 512 generated source embodiments contributes far fewer trajectories than the single source. Physical results also dip at the intermediate eight-source setting on some larger shifts before recovering at 512 sources. In a separate fixed-per-embodiment sweep, total data rises with source count and average progress increases over the tested 32, 128, and 512 source settings. Diversity and data volume are therefore coupled variables, not one universal scaling law.

Five percent target exposure is a large protocol change

For the exposure experiment, ZETA replaces part of a fixed 640,000-trajectory pretraining set with data from either UR5e plus UMI or Google Robot. Their downstream target tasks remain excluded from training.

At 5% target exposure, reported progress rises from 69.3% to 78.6% on UR5e plus UMI and from 51.4% to 68.9% on Google Robot. The average gain is 13.4 percentage points. Both remain below the study’s target-post-training reference.

That is why a zero-shot claim should state more than “no target demonstrations.” A complete disclosure should answer:

  1. Was the target body absent from pretraining, post-training, and every auxiliary dataset?
  2. If it appeared, what fraction of trajectories, episodes, frames, or tokens came from it?
  3. Were the target evaluation tasks absent, or only the exact demonstrations?
  4. Were target images, calibration data, controller traces, or morphology metadata used?
  5. Did model selection or hyperparameter tuning inspect target-robot outcomes?

The physical result is controlled, not operational

The physical comparison is stronger than a simulation-only result because it uses two tasks, seven held-out targets, and ten trials per task-target cell. ZETA reports the same broad representation and source-diversity trends in that setup. For the representation comparison, local end-effector delta state and action average 89.9% task progress, while the other three variants range from 56.0% to 61.6%.

The boundary is equally important. The tasks are opening an air fryer and watering a flower in standardized tabletop scenes. Cameras are aligned to keep gripper image position comparable, objects match those used in post-training, and the study controls lighting, layout, workspace, and initial pose region. These choices help isolate embodiment change. They do not test new objects, new environments, mobile-base control, dexterous hands, long-horizon work, production reliability, or independent reproduction.

The paper gives a clear trial denominator, but it does not establish an operational intervention ledger. A deployment-oriented follow-up should publish resets, excluded attempts, protective stops, human takeovers, calibration time, control failures, recovery outcomes, and wall-clock robot time beside progress.

A zero-shot cross-embodiment disclosure block

Use this compact block when publishing or comparing a transfer result:

Disclosure Required detail
Protocol label strict zero-shot, pretrain-exposed zero-shot, or target-post-trained
Target exposure every training stage, dataset, fraction, and target task included or excluded
Embodiment shift appearance, gripper, arm, full body, mobility, sensing, and controller changes
Shared representation state frame, action frame, history, observation views, and action horizon
Budget controls total trajectories, trajectories per embodiment, training steps, and compute
Physical evidence tasks, target bodies, trials per cell, progress and completion, variance, and failures
Human and setup work calibration, resets, intervention, exclusions, safety stops, recovery, and robot time
Scope boundary objects, scenes, contact, mobility, horizon, outside reproduction, and deployment status

This block complements the broader robot benchmark evidence guide. It prevents target exposure and budget allocation from disappearing behind one transfer percentage.

What buyers should request before a pilot

When a vendor says one model supports many robots, request evidence at the robot and task level.

  1. List every supported body and whether support is demonstrated, piloting, commercially available, or production deployed.
  2. Identify whether one checkpoint, one architecture, or one training recipe is shared.
  3. Separate pretraining from target-robot demonstrations, fine-tuning, RL, and controller engineering.
  4. Report installation, calibration, safety validation, and task-teaching time.
  5. Count physical attempts, resets, interventions, stops, and recovery outcomes before held-out evaluation.
  6. Evaluate the intended payloads, tools, layouts, rates, contact conditions, and people exposure.
  7. Record task success, cycle time, intervention, safe success, and recovery separately.
  8. Repeat after wear, drift, software updates, and representative environmental change.

A multi-robot model may still offer substantial value. The value should appear as less target data, shorter integration, fewer physical attempts, stronger transfer, or better recovery, not only as a larger embodiment count in the training corpus.

Evidence boundaries

Claim Evidence class Confidence Boundary
Cross-embodiment execution includes work that final success rate can hide Accepted survey and reporting framework High for the framework The framework is not a measured industry-wide integration-cost study
More shared structure always means less target-robot work Not supported High Work can move into adapters, calibration, controllers, contact, safety, or recovery
RoboEdit produces 174,000 aligned pairs and 14 million frames across seven embodiments Author-reported dataset and preprint Medium-high These are edited data, not physical robot operating frames; artifact access and outside replication need review
RoboEdit data supports downstream physical control Author-run bounded experiments Medium Generality across robots, tasks, controllers, and independent teams is not established
ADEPT transfers perception-based policies from simulation on two arm-hand systems Author-run physical experiments Medium-high Each task and embodiment was trained independently with embodiment-specific pretrained policies
ADEPT proves one policy works unchanged across the two embodiments Not supported High The shared contribution is a framework and recipe, not a single universal checkpoint
Zero-shot sim-to-real means no target-specific engineering Not supported High Embodiment-specific simulation, control, sensing, calibration, and validation can remain
ZETA separates strict and pretrain-exposed cross-embodiment transfer Author-defined protocol and controlled study High for the distinction Community adoption and comparisons beyond this study remain open
ZETA’s local end-effector representation improves transfer Author-run simulation and physical comparison Medium-high Stationary tabletop tasks, two-finger grippers, standardized scenes, and no outside reproduction
Five percent target-embodiment pretraining closes the transfer gap Not supported High It raises average progress by 13.4 points on two simulated targets but remains below the target-trained reference

Verdict

The embodiment gap is a useful correction to model-first reporting. It does not argue that foundation models, shared datasets, common interfaces, or learned correspondence are ineffective. It asks what each approach actually removes from the work of making a particular robot perform a physical task.

ZETA adds a precise first question: was the target robot absent from all training, or only from downstream task training? Its controlled results show that the answer is consequential. A 5% target-embodiment share changed average progress by 13.4 percentage points on two targets, even though the evaluated target tasks remained withheld.

The strongest cross-embodiment result is therefore not the one with the broadest label. It is the one that makes reuse and adaptation auditable:

Name what is shared. Name what changes. Declare every form of target exposure. Count target-robot data and physical work. Disclose calibration and control. Separate correspondence from contact. Measure safety, intervention, and recovery. Evaluate on held-out physical trials. Report where failures occur.

That is how a claim about a general robot model becomes evidence about a real robot.

Frequently asked questions

What is the embodiment gap in robotics?

The embodiment gap is the work required to convert a reusable model, representation, skill, or dataset into executable behavior on a robot with a particular body and control system. It can include connecting plans to skills, mapping actions to controllers, calibrating sensors and frames, adapting with target-robot data, managing contact, enforcing safety, and recovering from failure.

Does cross-embodiment mean one robot policy works unchanged on every robot?

No. Cross-embodiment can describe shared pretraining, a common representation, normalized data, learned correspondence, or one architecture used with robot-specific adapters and training. A claim is incomplete unless it states what was shared, what changed, how much target-robot data and physical work were used, and which components remained robot-specific.

What is strict zero-shot cross-embodiment transfer?

Strict zero-shot transfer means the target robot embodiment was absent from every stage of training. If the target robot appeared during pretraining but not during task-specific post-training, the more precise label is pretrain-exposed zero-shot transfer. The distinction matters because even limited target-embodiment exposure can materially improve results.

What should a cross-embodiment robot result report?

Report the source and target robots, shared structure, modified components, target-robot demonstrations and trials, model updates, calibration, control interface, real-robot setup and adaptation time, interventions, stops, recovery, held-out evaluation rollouts, success criteria, and failure causes.

Is zero-shot sim-to-real the same as zero target-robot engineering?

No. Zero-shot usually means the deployed policy received no real-world fine-tuning after simulation. The system can still require an embodiment-specific simulator, reward, policy, controller, sensor layout, calibration, domain randomization, safety layer, and extensive physical evaluation.

Do more robot embodiments automatically close the embodiment gap?

No. More embodiments can improve diversity and expose reusable structure, but each target can still require its own action mapping, calibration, control, contact handling, safety validation, and recovery logic. Count embodiments together with the adaptation work and held-out target-robot evidence.

Why is final success rate insufficient for comparing robot foundation models?

Two systems can reach the same success rate after very different amounts of target-robot data, calibration, physical trials, resets, intervention, and controller engineering. Success should be reported against adaptation effort and separated by failure cause.