humanoidsdata.com

Search

Search datasets, articles, and glossary terms for humanoids and embodied AI.

← All glossary terms

Hardware & control

Robot embodiment

A robot embodiment is the particular body and sensorimotor interface through which a robot perceives and acts. It includes morphology and kinematics, actuators, end effectors, sensors, physical limits, and the observation and action conventions exposed to a controller or learned policy. Two robots can perform the same task while having different embodiments.

Also known as: robotic embodiment, robot embodiments

Updated

Embodiment is more than a model name

In robotics, embodiment identifies the body through which an agent's decisions become physical action and sensor input. Link lengths, joints, hands, cameras, tactile sensors, actuator limits and control interfaces all shape what the agent can observe and do. The embodied-intelligence view also treats morphology as a contributor to behaviour, not only a constraint around software.

A product name alone is not enough metadata. Two units of the same robot can have different hands, camera placements, firmware, payloads or controllers. Conversely, related platforms can expose a common high-level interface while producing different physical motion underneath it.

The embodiment gap changes transfer

Open X-Embodiment combines data from many robots whose cameras and action spaces differ. Its shared representation makes joint training possible, but the project notes that coordinate frames and command semantics remain unlike across source datasets.

Human-to-robot transfer creates an even larger gap. DexUMI describes differences in kinematic structure, contact surfaces, tactile information and visual appearance between human and robot hands. Retargeting can map part of a demonstration, but it cannot make those bodies physically identical.

Embodiment metadata keeps actions interpretable

A dataset should identify the robot and revision, kinematic model, joint and actuator limits, end effectors, sensor models and placement, coordinate frames, control modes, action units and update rates. Calibration and any hardware modifications should travel with the episodes.

This context determines whether a trajectory can train the target policy directly, needs an adapter or is useful only for higher-level perception and task knowledge. “Cross-embodiment” should therefore describe documented variation, not missing hardware provenance.

Sources