Cross-embodiment data: what it is and why it matters

What cross-embodiment data is

When you train a policy on data captured on a Figure 02, that policy ships with assumptions baked in — the joint limits of Figure’s arms, the proportions of its torso, the kinematics of its hands. If you later want to deploy that policy on a Tesla Optimus, or Apollo, or Neo, those assumptions are wrong. The policy will fail in subtle, expensive ways.

Cross-embodiment data is the deliberate solution to this. It’s the same task, captured across multiple humanoid morphologies, with a shared semantic representation that lets a policy learn the task once and adapt to the embodiment at inference.

In practice this means: an operator demonstrates the task on Platform A (say, Figure). The trajectory is recorded both in Figure’s joint space AND in a normalized semantic space (end-effector pose, grasp state, task phase). The same task is then demonstrated on Platform B (say, Optimus) and on Platform C (say, Apollo). The semantic representation is shared across all three; the joint-space data is platform-specific.

Why it matters

Three reasons cross-embodiment data is worth its higher unit cost:

Hardware diversification reduces vendor risk. If you train only on one platform and that platform’s supplier changes spec, your dataset becomes a strict subset of useful data. Cross-embodiment hedges against this.

Policy transfer improves. A policy trained on three platforms generalizes better to a fourth than a policy trained on one. The improvement isn’t linear — it’s substantial. Recent foundation-model papers show 3–8x sample efficiency improvements from cross-embodiment training compared to single-platform.

Customer flexibility. If your product ships on Figure today but your customers want Apollo tomorrow, cross-embodiment data means you can swap platforms without rebuilding your model. That’s an asset on your balance sheet.

The capture methodology

Capturing cross-embodiment data isn’t just “do the same task on different robots.” There are three things that go wrong if you try.

Calibration drift across platforms. Each humanoid has different sensor placement and calibration drift over time. You need a calibration session per platform per capture day, with cross-checks against a ground-truth pose source.

Operator habit transfer. An operator who’s done 500 demos on Figure will move differently than an operator who’s done 500 on Optimus. Use the same operators across all platforms, or operators with no prior preference for any platform.

Task ambiguity. The task spec needs to be tight enough that all operators interpret it the same way across different platform morphologies.

Semantic representation design

The semantic layer is where cross-embodiment training lives or dies. Three approaches are common:

• End-effector frame + grasp state. Pose of each end-effector in the robot’s base frame, plus a binary or analog grasp state.
• Object-centric representation. Trajectories defined relative to the manipulated object’s pose, not the robot’s frame.
• Phase + goal annotations. Discrete labels for “approach”, “grasp”, “transport”, “place”, “release”, combined with goal-state representations.

The cost math

Cross-embodiment programs cost 1.5x to 2.5x what single-platform programs cost. Whether the premium is worth it depends on your deployment plan.

Where to start

1. Pick two platforms first, not three or more.
2. Use the same operators across both.
3. Start with 500 paired trajectories.
4. Add the third platform after 500 has validated the transfer.