Robot foundation models: what transfers across robots?

A robot foundation model promises a reusable starting point. The useful question is what survives a change of task, room, or robot body.

A policy might handle a new object on a familiar arm. Moving that policy to another arm can require new command mappings and training examples. Those experiments support different claims.

This guide uses three dated research examples and an original scoring exercise. It is a reading snapshot prepared on October 12, 2026, using the specified original paper versions. It is a selected comparison of transfer evidence, with no claim to cover every model or rank current systems.

Define robot foundation models through reuse

Here, a robot foundation model means a model pretrained on broad data to support reuse across robot tasks or setups. This is a working definition. The label alone gives no fixed minimum dataset size, capability guarantee, or test protocol.

This guide focuses on models that produce robot actions, often called generalist robot policies. A shared visual encoder or learned world model can also support a larger robot system. The world-model experiment fits a predictor, uses its predictions to choose actions, and checks the resulting motion against a separate toy reference.

A vision-language-action model is one policy design: it connects visual and language inputs to actions. The foundation-model question concerns the breadth and reuse of learned behavior. Architecture, training method, and demonstrated transfer each describe a different part of the system.

Name the thing that changes

A robot embodiment includes the physical body and its sensing and action capabilities. Two arms can share a manufacturer while differing in gripper, camera placement, controller, or working area. Record both the body and the full setup.

Change under test	Concrete example	Claim it can support
Object or initial state	Move a familiar cup to a new starting position	Generalization within the stated scene and task
Scene	Keep the arm and task, change the background or room	Transfer across those visual or physical conditions
Task	Ask for a held-out behavior or task composition	Transfer to that task, subject to what training already covered
Robot setup	Change cameras, gripper, command rate, or controller	Transfer to that setup with its reported interface changes
Embodiment	Move from one arm design to another	Transfer across those bodies under the stated adaptation budget

A new scene can contain a familiar task. A new task can use a familiar robot. Robot-learning generalization makes these changes explicit in the split between training and evaluation.

Follow data, adaptation, and evaluation

Follow the evidence for transfer

From shared data to a tested robot policy

Read each panel downward. Every stage has its own record: training mixture, target adaptation, and evaluation conditions.

1. Pretrain a shared policy

2. Prepare one target setup

3. Test a stated transfer claim

This is a conceptual workflow. The diagrams do not run or benchmark a robot foundation model.

Read the workflow as three records you should be able to inspect. The training record identifies the examples and weights used to fit a checkpoint. The adaptation record identifies target data, interface changes, and weight updates.

The evaluation record then names what changed and how success counts. Its final test outcomes stay separate from checkpoint selection. Each record answers a different question about the resulting policy.

Separate a dataset from a checkpoint

Open X-Embodiment names a shared data resource. RT-X names models trained on a selected mixture. The original paper describes over one million trajectories across 22 embodiments; its RT-X experiments train on nine manipulators. The counts measure different scopes. Open X-Embodiment and RT-X, v1, sections III–IV.

A checkpoint stores a particular set of learned parameters. Record the checkpoint version together with its data mixture, filtering rules, and training procedure. A repository can grow after a checkpoint finishes training.

Data volume also needs a unit. An episode, a frame, and an action label count different things. Repeating frames from a long episode can increase the sample count without adding another environment or independent trial.

Compare three dated research examples

The rows below describe the cited first arXiv versions. Dates identify those versions, and the dataset counts belong to them. The table compares scope; the papers use different tasks and evaluation conditions.

Published version	Robot training data	Embodiment and task scope	Adaptation and evaluation scope
RT-X, v1, October 13, 2023	Selected mixture from nine manipulators; distinct from the full Open X-Embodiment repository	Manipulation across robots, including pick/place and other skills; RT-1-X and RT-2-X share the robot mixture	Tests transfer into represented robot domains and some unseen tasks. The paper reports 3,600 trials across six robots. This does not establish operation on an arbitrary unseen body.
Octo, v1, May 20, 2024	800,000 trajectories curated from 25 Open X-Embodiment datasets	Language or goal-image conditioning; single-arm and bimanual manipulation	Nine evaluation setups across direct use and fine-tuning. Direct-use setups match pretraining interfaces; six fine-tuning setups use about 100 target demonstrations each, including changed inputs, action spaces, and bodies.
OpenVLA, v1, June 13, 2024	970,000 robot demonstrations, plus a pretrained vision-language backbone	A 7B-parameter VLA; image and language inputs for manipulation	Direct evaluation on WidowX and Google robots includes familiar and changed conditions. Separate adaptation experiments fine-tune on seven tasks across two Franka setups, using 10–150 demonstrations per task.

Dataset breadth, interface flexibility, and target-data efficiency are separate comparison axes. A result from a fine-tuned policy answers a different question from direct use of a frozen checkpoint. Keep that distinction when comparing even two rows from the same paper.

Distinguish task instructions from training

Conditioning gives the policy information for its current decision. An instruction such as “put the cup in the bowl” can change the predicted action while all learned weights stay fixed. A goal image can specify a desired visual outcome.

Octo's published design accepts language or goal images and predicts action chunks through a diffusion head. This combines a task interface with an action model. It also illustrates why generalist robot policies need not all use the same language-model action decoder. Octo, v1, section III.

Fine-tuning updates learned parameters using target data and a training objective. Imitation learning explains how demonstrations can supply that objective. Giving a frozen policy a new sentence is a different operation from updating its weights on new demonstrations.

Match the target robot interface

The receiving robot needs an explicit meaning for every output. Check these fields before interpreting an action vector:

• Which command does each component represent: joint angle, pose change, velocity, or gripper state?
• What units, coordinate frame, and normalization apply?
• What camera views and observation history does the policy expect?
• How often does the controller accept commands, and how long does each command act?
• Which local controller turns the policy output into physical motion?

The original RT-X paper uses coarse action alignment and dataset-specific normalization. It allows different coordinate frames and action meanings across datasets. A shared vector format therefore does not imply identical physical motion. RT-X, v1, section IV-A.

The VLA interface example works through decoding and command conventions. Controller discretization explains why command timing also changes a closed loop. Neither a larger policy nor more training records removes those interface requirements.

State what zero-shot and fine-tuning allow

Zero-shot needs a stated target and protocol. In a no-fine-tuning evaluation, the policy uses no target-specific weight updates. That still leaves questions about pretraining overlap, prompts, calibration, interface configuration, and any target trials used to choose them.

Octo's direct-use tests include setups matching pretraining data. Its separate fine-tuning tests change observations, actions, or embodiments. This is a useful reminder that “zero-shot” alone does not mean “a completely new robot body.” Octo, v1, section IV.

Few-shot adaptation describes learning from a small target dataset, but “few” has no universal count. State the number of demonstrations, their duration, collection conditions, and whether updates change all weights or only part of the model. Report validation trials used to select the final policy separately.

A familiar robot type in a new setup remains a useful test. It should keep that description. For example, the cited OpenVLA adaptation experiments use two Franka setups; the robot's brand alone does not describe their cameras, tasks, or control rates. OpenVLA, v1, section 5.2.

Test the transfer claim you actually made

Write a claim that an experiment could reject. For example: “After fine-tuning on 50 demonstrations, this checkpoint can place the specified objects on this arm in two held-out rooms.” This hypothetical claim identifies the adaptation budget, task, robot, and scene split.

A useful evaluation record includes:

• The exact checkpoint and all target adaptation data.
• Training, validation, and final test conditions, including any known overlap.
• Success rules, time limits, resets, and human interventions.
• Trial counts and results for each task, scene, and robot group.
• Command timing, hardware limits, and the policy's observation/action interface.

Use the same protocol when comparing candidates within an experiment. A manual rescue changes the outcome record; ignoring it can turn assisted completion into an autonomy claim. Robot policy evaluation examines these choices with success counts and uncertainty.

A training corpus can contain many near-duplicate scenes. An aggregate score can hide one weak robot group. Test evidence should support the particular transfer claim, with no extension to untested bodies or environments.

Calculate how evaluation weights change a ranking

Consider two invented candidate policies, A and B. Each runs 20 evaluation episodes on Robot 1 and 20 on Robot 2, using the same conditions and success rule within each group. These counts are a teaching example, unrelated to the published models above.

Candidate	Robot 1 successes	Robot 2 successes	Equal-robot macro score
A	18/20 = 90%	8/20 = 40%	(90% + 40%)/2 = 65%
B	15/20 = 75%	14/20 = 70%	(75% + 70%)/2 = 72.5%

The macro score gives each robot equal weight. With equal trial counts here, pooling successes across all 40 episodes gives the same answer. That equality need not hold when group trial counts differ.

Now declare a hypothetical target mix: 90% of episodes use Robot 1 and 10% use Robot 2. This is an assumed deployment mix, not a measured distribution. Weight the same observed rates by that mix:

A weighted estimate = 0.90(0.90) + 0.10(0.40) = 0.850 = 85.0%
B weighted estimate = 0.90(0.75) + 0.10(0.70) = 0.745 = 74.5%

B leads under equal robot weights. A leads under the declared target weights, while keeping its 40% Robot 2 rate. The aggregate changes the question; it does not improve either policy.

For a Robot 1 share q, A's estimate is 0.40 + 0.50q and B's is 0.70 + 0.05q. They tie when 0.45q = 0.30, so q = 2/3. Above that share A leads; below it B leads, using these fixed toy rates.

The following standard-library Python reproduces the arithmetic. It trains no model and adds no new robot evidence.

counts = {"A": (18, 8), "B": (15, 14)}
trials = (20, 20)
weights = (0.9, 0.1)
rates = {}
for name, successes in counts.items():
    rates[name] = tuple(s / n for s, n in zip(successes, trials))
    macro = sum(rates[name]) / len(rates[name])
    weighted = sum(w * p for w, p in zip(weights, rates[name]))
    worst = min(rates[name])
    print(f"{name}: macro={macro:.3f}, weighted={weighted:.3f}, worst={worst:.3f}")

a1, a2 = rates["A"]
b1, b2 = rates["B"]
tie_share = (b2 - a2) / ((a1 - a2) - (b1 - b2))
print(f"Robot 1 share at tie: {tie_share:.6f}")
for name, (p1, p2) in rates.items():
    print(f"{name} with Robot 1 share 0.6: {0.6 * p1 + 0.4 * p2:.3f}")

A: macro=0.650, weighted=0.850, worst=0.400
B: macro=0.725, weighted=0.745, worst=0.700
Robot 1 share at tie: 0.666667
A with Robot 1 share 0.6: 0.700
B with Robot 1 share 0.6: 0.730

Twenty episodes per group still leave statistical uncertainty. The weighted estimate also assumes each group's evaluation conditions represent its target use. Publish the counts and per-group results alongside any aggregate, and state how you chose the weights.

Try it yourself

Exercise 1. Use the toy rates above and a target mix with 60% Robot 1 episodes. Compute both weighted estimates and the share where the candidates tie. Does A's higher target-weighted score at 90% Robot 1 establish that it is better on both robots?

Show the weighting solution

A scores 0.6(0.90) + 0.4(0.40) = 0.70. B scores 0.6(0.75) + 0.4(0.70) = 0.73. They tie at a Robot 1 share of 2/3.

A leads on Robot 1; B leads on Robot 2. The 90/10 weighting favors A's strength and gives its weak group little weight. It establishes no per-robot dominance, and all these scores use finite toy samples.

Exercise 2. A frozen checkpoint succeeds in a new room on an arm whose data appeared during pretraining. A second experiment changes the gripper and camera, fine-tunes on 80 target demonstrations, and tests in two held-out rooms. What transfer claim could each experiment support, and what extra evidence would support a claim about an unseen arm design?

Show the transfer-scope solution

The first experiment tests scene transfer on a represented arm, subject to the stated tasks and pretraining overlap. It uses no target weight updates. Calling it zero-shot should still disclose any calibration, prompt selection, or other target access.

The second tests adaptation to the specified gripper/camera setup after 80 demonstrations, followed by scene generalization. It does not establish no-fine-tuning transfer. Its final test rooms must stay out of fitting and checkpoint selection.

An unseen-arm claim needs an identified arm design excluded from the declared pretraining scope, a compatible interface, an explicit adaptation budget, and evaluation trials on that arm. Keep target setup changes separate from whether the underlying body is new.

Sources and further study

• Open X-Embodiment Collaboration, Open X-Embodiment: Robotic Learning Datasets and RT-X Models, v1, October 13, 2023.
• Octo Model Team, Octo: An Open-Source Generalist Robot Policy, v1, May 20, 2024.
• Kim and colleagues, OpenVLA: An Open-Source Vision-Language-Action Model, v1, June 13, 2024.

Read vision-language-action models next to examine the action interface. For a candidate checkpoint, write down one proposed transfer test: what changes, what adaptation it permits, and which result would count as failure.