Embodiment gap: the 2026 term, defined
The embodiment gap is the work left over when a shared robot model has to run on one particular body. A ten-author survey at Japan's national lab AIST named the term in August 2026. It also pinned a test to the term. Does the problem show up only after the body changes? Lighting, a new task, or a sim-to-real move on the same robot sit outside the gap. Anything that appears only after the body changes sits inside it. Three older readings of the phrase circulate and disagree. This page settles on the 2026 one. It prints the test, the four failure groups to debug against, and the gap as numbers in real checkpoint files. There, one model ships action horizons of 50, 15, and 10, one per body.
Embodiment gap
Here is the definition, stated three times in the survey so nobody misses it. The gap is between reusable models, representations, or data on one side and their use in execution on the target robot on the other (the survey). The paper is "The Embodiment Gap in Robot Foundation Models". Every author address on it is at AIST. It went up on August 19 2026, opened for open review the same month, and is published in Transactions on Machine Learning Research.
Two words carry the weight. The first is execution. A shared model is not the gap. A shared model that never moves a real motor is not the gap either. The gap is what appears between a reusable thing and the act of running it. The second is target robot. The gap is set against one body, not against robotics in general. Ask the question again with a different body. You get a different gap, a different size, and a different bill.
The survey opens on the point that makes the term needed. Robot foundation models are sold on a scaling story. More data, bigger models, broader tests. Yet a model can generalize and still not run on a given robot. The test score and the working arm are two different things. The distance between them does not show up in the score. That distance is the subject of the term.
The term is young. Results from 2024 use the same two words for the gap between software with no body and software with one. The robot sense, meaning transfer work between bodies, is the 2026 coinage. It is the one this page uses.
Three readings of the same phrase
Search the bare phrase today and three definitions come back. Pages that rank next to each other do not agree.
The narrow reading treats the gap as the mismatch between a human body and robot hardware. Work that trains robot policies from human video uses this sense. A five-fingered hand and a rigid gripper cannot copy each other. A 2025 project that crossed exactly this divide gave it its own name, the human-robot embodiment gap (the project page).
The imitation reading defines the gap as a mismatch in shape, joints, sensing, and dynamics. The mismatch is between the agent that made the training data and the robot that runs the learned skill. This reading covers robot-to-robot transfer, which the narrow one misses. It stays quiet on the engineering work that lands on the new robot once the data question is settled.
The 2026 reading defines the gap as the leftover work, whatever caused it. The change of arm is in the gap. So is the calibration, the control hookup, the contact handling, and the safe stop. All of it is work a shared policy needs before it can run on a body it has never touched. This page uses the third reading. It is the one with a test attached, and the one that matches how the work splits. The other two are not wrong. They are narrower.
One warning about the phrase outside robotics. The bare query also returns a business podcast bit about why company AI projects stall. It returns self-help pages about living in your own body. Neither is about robots. Add "robotics" or "robot foundation models" and the noise drops away.
The inclusion test
The survey's test for what belongs in the gap is one sentence. Does the problem arise when a shared model or representation runs across different robot embodiments?
Everything that can happen without a change of body is outside the main scope. New light on the same robot is a domain shift. A new task on the same robot is task learning. Moving one robot from simulation to hardware, with nothing else changed, is a sim-to-real gap. Those problems are large. They are not this one.
What changes once the body changes is inside, even when the goal stays the same. The survey's own example is a cup. The goal is still lifting the cup. But a change in the number of fingers changes the grasp and the contact pattern needed to succeed.
| Neighbouring problem | Outside the gap | Inside the gap |
|---|---|---|
| Domain shift | only lighting, background, or object looks change on the same robot | a different robot changes looks together with reach, grasp, or control conditions |
| Task learning | the same robot learns a new procedure | the same goal needs a different grasp or motion on another body |
| Simulation to real | the same robot moves from simulation to hardware and only the physical domain changes | the change comes with a different body, control interface, or contact conditions |
| System integration | general connections, configuration, and setup | calibration, control hookup, and safety checks needed to run a shared policy on a new robot |
| Action-space mismatch | only the output format differs | the same action output produces different contact or recovery problems on another robot |
| Transfer learning | general reuse across domains or tasks | transferred things must be made runnable again under the target body and control system |
Read the table as a set of filters for your own debug work. A policy that misbehaves on a robot it has run on before is not a gap problem. A policy that misbehaves on a robot it has never touched: start here.
Shared structure
Shared structure is the survey's umbrella term for everything reused across robots. Models, maps, and data. The term matters because shared things sit at different distances from execution. The distance decides how much work is left.
The survey orders them along one axis, from far to close. Task meaning and plans travel between any two bodies. A plan that says pick up the cup does not care how many joints the arm has. Perception and affordances travel a little less freely. Object interaction is closer still. Action outputs and skills carry the assumptions of the joints they were trained on, so they travel worst. Morphology-aware sharing, where the body's own structure feeds the model, sits closest of all.
A second axis orders where the leftover work lands on the new robot. First the skill or interface hookup. Then calibration and control alignment. Then contact and force execution. Last, safety and recovery. A shared plan needs the most hookup work and the least contact work. A shared action space needs the opposite.
The map is qualitative, and the survey says so plainly. It does not predict hours. It does not rank methods. It tells you where problems are likely to appear and what a paper should report when they do.
The coding behind the map shows where it is firm and where it is soft. Three researchers placed the 21 method groups on their own. On the shared-structure axis, all three agreed on 16 of 21 groups. The agreement statistic was 0.78. On the work axis, all three agreed on 10 of 21. The statistic fell to 0.33. Ten of the eleven fights sat between neighbouring rows, mostly calibration work against contact work.
One placement deserves its own line. None of the 21 groups landed in the safety and recovery row. The survey is careful about what that means. Not that safety is solved. It means safe stopping after failure, and resuming, has not yet become a core research target for robot foundation models. A high success rate does not show whether a system can keep running when the stopping process is unclear.
Failure causes: the four groups
A shared policy fails on a new body at some stage. The stage decides whether you fix the model or fix the connection.
Group one is semantics and perception. The instruction was read wrong, or the object was picked wrong, so the system chose the wrong goal. Nothing about the body was at fault. The policy never got the problem right.
Group two is robot data and interfaces. An action output taken from training does not match the interface of the new robot. The intended motion never happens. The survey's example is a policy whose action output does not match the controller rate or the action decoder.
Group three is correspondence across embodiments. A target position is out of reach. Or an object motion cannot be reproduced with the new body. An affordance point outside the reachable workspace reads as a failure of this kind.
Group four is execution on the new robot: unstable contact, unsafe motion, and failure to resume after a stop. The survey's worked case is a model that predicts the right object flow while the gripper slips. The primary failure is execution. A secondary cause may be that the mapping between bodies never accounted for the difference in contact. A failure rate with no stage attached tells you nothing. It cannot say whether the model needs work or the hookup does.
The adaptation report card
A success rate hides the work behind it. The survey proposes a report card with eleven items. Each one is a thing a reader would otherwise have to guess. The card asks for the source robot and its pretraining setting. It asks for the target robot and its task setting, the shared things that were reused, and the parts changed for the target. It asks for the target-robot data collected and used, and the scope of the model update. It asks for calibration and setup. It asks for real-robot operation: robot time, resets, and reruns. It asks for the safety, intervention, and recovery work, the evaluation rollouts, and the failure causes.
Two items do most of the work. The model-update item separates a method that swaps an output head from one that retrains everything. The two can post the same success rate. The operation item captures work that has nothing to do with model size. Aligning a camera with the robot. Repeating trials. Stopping and recovering.
The survey applied its own card to published claims, and the result is the honest part. One general policy family fine-tunes on 10 to 150 demos per task across seven tasks, with full fine-tuning or a low-rank adapter. Another reports 100 to 1000 examples. A residual-policy method trains on 400 teleoperation runs from one robot. A few-shot method studies 1 to 50 shots. And across the general policy rows, the resets and safety counts come back as not reported. Stating what was not reported still helps a reader judge the claim. Silence is data.
Embodiment Adaptation Curve
The Embodiment Adaptation Curve, or EAC, is the survey's answer to the single end-of-project number. An EAC plots performance against one stated measure of adaptation effort. The horizontal axis can carry demos, real-robot trials, human saves, or another comparable measure. The curve separates a method that gets capable after a handful of demos from one that needs many. It also shows whether performance keeps climbing or flattens early.
The survey is honest about how rare these curves are. The one full example it reproduces is a few-shot study that reports performance at several demo counts. That is the shape a curve needs. Another study it points at reports two conditions, not a series: open-loop execution against a residual policy trained on 400 target-robot teleoperation runs. The survey calls that an endpoint, not a curve.
The practical reading for anyone buying a result: ask for the curve, or at least for the point on the axis. A success rate with no demo count, no trial count, and no save count cannot be compared with one that has them. The same score can mean ten demos or ten thousand.
Action horizon
The action horizon is how many future actions one policy output carries. It is the cleanest place to see the embodiment gap as a number. The same model ships with different horizons for different bodies.
The pi 0.5 family is the clean case. The openpi project's training config ships one model with three horizons. Fifty actions for the base config. Fifteen for the DROID config. Ten for the LIBERO config (openpi training config). The control rates come from the same project's stats document. Twenty cycles per second for the UR5e and Franka arms. Fifty for the ARX and ALOHA-family arms. Fifteen for DROID, which also uses joint velocity rather than joint angle actions in its first seven dimensions (openpi stats document).
| Model and target body | Action horizon | Body-bound facts from the publisher |
|---|---|---|
| pi05 base, many robots | 50 actions | action space runs to 16 dimensions for mobile bodies, joint angles in radians, gripper 0 to 1 |
| pi05-droid | 15 actions | joint velocity actions at 15 cycles per second on the DROID Franka setup |
| pi05-libero | 10 actions | 30,000 fine-tuning steps in the shipped config |
| smolvla base, community arms | 50 actions | six-number state vector and six-number action vector for six-motor arms |
| molmoact2-so100-101 | 10 for LIBERO, one named horizon per body | stats, prompt, camera order, and horizon all selected by a per-body tag |
Multiply and a pattern appears. Fifty actions at fifty cycles per second covers one second of motion. Fifteen at fifteen also covers one second. The horizon is set by the body's clock, not by the model. Change the arm and you change how far ahead the policy plans.
Normalization statistics
Normalization statistics are the per-body scaling numbers a policy ships beside its weights. Inputs and action targets get scaled by numbers computed over each body's own training data. Those numbers live in files that travel with the checkpoint. This is the embodiment gap as arithmetic. A stats set is a body's numbers. A policy trained on a body carries that body's numbers.
The pi family shows the size of the set. The same project publishes nine sets of pre-training stats, one per body. Its documentation tells you to try two things. Reload a matching set, or compute fresh stats from your own data. Then keep whichever works better. That instruction is the gap in one sentence. If one set fit all bodies, the instruction would not exist.
SmolVLA shows the same thing in a smaller package. Its published base config declares a six-number state vector and a six-number action vector. That is what a six-motor community arm needs. It sets a chunk of 50 actions and mean-and-spread scaling (SmolVLA base config). The vector is the body. Change the arm and you change the vector.
MolmoAct2 shows the third pattern, and it ships the sharpest example on this page. Its base checkpoint serves many bodies. Each body's fine-tune carries its own stats file, prompt sentence, camera order, and action horizon. All of it is selected by a name the docs call a normalization tag (LeRobot MolmoAct2 docs). One model, many bodies, one named choice per body.
Then there is the calibration convention. It is the shortest version of the whole story. The MolmoAct2 checkpoint for the SO-100 and SO-101 arms was trained on data that uses a different joint zero than LeRobot 0.5.0 and later. The docs say that without a frame fix the arm may move in the wrong direction. The fix is one sign flip on the shoulder lift joint, plus 90 degree shifts on two joints. The same arm. The same checkpoint. Without those numbers it drives the wrong way. That is the embodiment gap reduced to a sign.
Cross-embodiment transfer
Cross-embodiment transfer is training one policy on data from many bodies at once. Shared skills get learned once. Only the body-specific part gets relearned per robot. It is the research direction that attacks the gap from the data side.
The reference pool is Open X-Embodiment. The project pooled more than one million real robot trajectories spanning 22 robot bodies. Single arms, dual arms, and quadrupeds. It merged 60 existing datasets from 34 labs, and generalist policies were trained on the mix (the project page). The pi 0.5 family is built the same way, co-trained on mixed robot data plus web data.
A third thread inside this direction learns the mapping between bodies directly. The survey groups it as correspondence learning. One method tracks object motion instead of robot joints, then learns a small correction policy on the new body. Another feeds the body's own joint and sensor graph into the model, so action output depends on the shape it commands. These methods share the parts closest to execution. The survey's verdict on them is measured: matching joints does not keep a gripper from slipping, and contact and recovery stay outside the model.
The pool shrinks the gap. It does not erase it. The nine per-body stats sets in the previous entry exist because bodies differ. No pool turns one robot's joint conventions into another's. Transfer is real, and it runs strongest between close relatives. Community arm data transfers best to community arms of the same class.
What the gap costs on your own bench
The gap is not free. It costs demos, robot hours, resets, and the human attention that goes with them.
Our own measurement record shows the shape of the bill. A pi 0.5 class policy, fine-tuned for 15,000 steps on open LIBERO demos, was evaluated over 500 episodes across the four LIBERO suites. It scored 482 successes. The wall time was 47.18 hours. A 40-episode quick check before the long run took 3.863 hours. Most of that clock was not inference. It was scene rebuilds between episodes: about 5.8 minutes of wall per episode, against rollouts of 23 to 43 seconds. The measurement is dated October 10 2026. The full record, with every input, is the 500-episode evaluation report.
Two lines of that record are this gap in a different hat. The 15,000 fine-tuning steps are the report card's model-update item. The reset clock is the operation item, in simulation form. Both are work on one body. Neither shows up in a success rate.
The publisher of the pi family says the plain part itself. Its repository states the models were built for their own robots, which differ from the common platforms. It states the checkpoints may or may not work on your particular robot (openpi README). When the maker of a general policy tells you to expect per-body work, the term for that expectation is this one.
Money is the part most people want, and the part this page does not print. Rates for robot models here render from the model list, never typed by hand. The pricing page carries the current rate for every listed row. Why the robot-hour is the unit that matters for a robot is the job of the per-robot-hour glossary. Your own case, card against route, gets worked end to end in the local versus hosted break-even guide. And the habits that keep a metered route honest are in the bill shock guide.
Frequently asked questions
What is the embodiment gap, in one sentence?
It is the work left over when a shared robot model, map, or dataset has to become runnable on a particular body. The 2026 survey defines it as the gap between reusable things and their use in execution on the target robot.
Is the embodiment gap the same as the sim-to-real gap?
No. Moving one robot from simulation to hardware, with nothing else changed, is a sim-to-real problem. The survey puts it outside the main scope. The embodiment gap needs a change of body. When the two happen together, with a new control interface or new contact conditions, the survey treats that as inside the gap.
What makes a policy fail on a new robot?
Four stages, in the survey's grouping. The instruction or the object was read wrong. The action output did not match the robot's interface. The target or motion was out of reach for the new body. Or execution failed at contact or recovery. The stage decides whether you change the model or the connection.
How much target-robot data closes the gap?
The survey's examples run wide. A body-graph method that reports low or zero target data. One to fifty demo shots for an action-motif method. Four hundred teleoperation runs for a residual policy. Ten to 150 demos per task for a 7-billion-parameter policy on one arm. The number is a property of the method and the body, not a constant.
Does a bigger model close the embodiment gap?
No. A shared model can generalize and still leave work before it runs on a given body. That is the survey's opening line. Scaling shrinks the parts of the gap that are about data and meaning. The parts about calibration, contact, and safe recovery stay engineering work on the target robot.
Do I need my own stats file to run a shared policy on my arm?
Usually yes, or a matching one. The pi family ships nine per-body sets and says to try both a matching set and fresh stats from your own data. A mismatch is not always loud. Wrong numbers can produce smooth, confident, wrong motion. That is why the stats guides on this site exist.
Where to read next
The numbers side of this page is the per-embodiment reference. It decodes the vocabulary and documents the stats artifact field by field. The model class itself is in the VLA explainer. The failure mode that catches most people is in the normalization guide and the silent wrong-motion error family. The policy server explainer covers the split between the machine that thinks and the machine that moves. Where the two halves should sit is the Jetson versus cloud guide. A full arm end to end is the SO-101 walkthrough.
The small end of the scale is the act policy, about 80 million parameters. Its own docs say it often reaches high success with about 50 demos (LeRobot ACT docs). Fifty demos of your body, collected on your body, is the gap. The policy is cheap. The demos are not. The fine-tuned 7-billion-parameter lane is openvla-oft. Its project page credits the recipe with 25 to 50 times faster inference than the base recipe, and it ships three ways to turn one prediction into motion (OpenVLA README).
The platform note, dated October 26 2026. Robot policies run here over a published action route, metered per call against a prepaid balance. The models index is the live catalog. Every row on it carries its own rate. A robot model not on that index carries no rate here. Read the index on the day you plan to call, not this page. To try it, sign up, create a key, and the first call follows the published contract.
Last verified: 2026-10-26