What is this problem
Cross-embodiment standards refer to shared data formats, action/observation schemas, and interoperability conventions that let robot data, trained policies, and software tooling move across different robot bodies (arms vs. humanoids vs. quadrupeds, different manufacturers, degrees of freedom, sensor suites, and actuator setups) instead of every lab or company building its own bespoke pipeline.
This spans everything from how a demonstration trajectory is logged and timestamped, to how joint or end-effector action spaces are represented, to how camera and proprioceptive observations are packaged, to interfaces for simulation-to-real transfer. Without such a layer, a policy or dataset built for one robot’s kinematics generally cannot be reused, even in part, on a different robot without significant re-engineering.
This is a middleware-adjacent “nerves” layer problem: it sits underneath the data and model layers, and its absence raises the cost of scaling robot learning across today’s fragmented hardware landscape.
The bottleneck and pain points
The core pain is that data and policies trained on one embodiment’s kinematics and action space are expensive and slow to port to another: nearly every new robot platform means re-collecting demonstrations, re-defining action spaces, and re-validating safety and control interfaces from scratch, even when the underlying skill (grasping, insertion, locomotion) is conceptually the same.
Proprietary, fragmented data formats across labs, OEMs, and simulators mean most collected robot data cannot be pooled or reused across projects, throttling the field’s ability to build large, general-purpose datasets the way vision and language did with open image and web-text corpora. Community efforts such as Open X-Embodiment and LeRobot, plus URDF/ROS-based conventions, have made partial progress, but adoption remains uneven and no format has become a de facto standard the way ONNX or COCO did in their domains.
Structurally this is also a business-model problem, not just a technical one: open standards are inherently hard to monetize in isolation since anyone can adopt them for free, and durable value only accrues to whoever pairs a standard with hosted data, tooling, benchmarks, or distribution. That difficulty capturing value is likely why this bottleneck remains the lowest-ranked and most thinly-evidenced on the board, with no company yet clearly positioned as owning it.