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

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.

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.

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

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.

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. 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 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.