What is Humanoid Robot Data?

A humanoid is a whole-body system. The commercial platforms from Unitree, Agility, Figure and others carry anywhere from the mid-teens to more than 40 actuated joints, and every action has to keep the robot upright, so the data includes base pose, foot contact and center-of-mass state alongside arm and hand motion: streams a fixed-base arm never produces.

Locomotion is usually learned in simulation, where a fall costs nothing and thousands of parallel environments run on one GPU. Manipulation is where real data is needed, and it is collected by teleoperation. VR controllers, or a motion-capture rig that maps the operator's arms and hands onto the robot.

Human motion is a source in its own right: AMASS aggregates over 40 hours of optical capture from more than 300 subjects into one skeleton format, and humanoid projects have learned skills by retargeting that motion onto their platforms. Two things make this category hard: falls are destructive, so collection is slow and careful, and the robots are scarce, so a commissioned project almost always runs through a partner lab, with the platform named first in the brief.

Types of humanoid data

Humanoid data separates first by skill family. Locomotion covers walking, turning, stairs and recovery from a push, and it is usually learned in simulation, where a failed attempt is free. Manipulation covers the arms and hands, and it comes from teleoperation on the real platform, because contact is where simulation is weakest. Whole-body tasks sit between the two: squatting to reach the floor, carrying a load while walking, standing from a chair.

The source is the second split. Simulated episodes are cheap and endless but approximate contact. Teleoperated episodes on the real platform carry true physics and are slow to collect. Retargeted human motion sits in between: real motion, no robot, no contact forces. Programs that work well combine the three rather than betting on one, because each covers what the others miss.

Platform variants are the third axis. A legged humanoid and a wheeled one with a humanoid upper body produce different data: the wheeled platform removes balance from every task and with it the hardest part of the stream. Joint counts, hand types and sensor suites differ across platforms, so a set collected on one machine is a reference for that machine, not a substitute for yours.

What to specify when buying

The platform comes first, named exactly, and with it the access question. Humanoid robots are scarce and expensive, so a commissioned project usually runs through a partner lab that owns one. Falls are destructive and collection is slow and careful, which shows up in the schedule. Ask who operates the robot and under what safety procedure.

The task list should state whether the robot is walking or standing. Standing tasks are cheaper, safer and transfer more cleanly across platforms; tasks that require locomotion and manipulation at once are the most expensive to collect and the least portable. If the goal is whole-body behavior, say so explicitly, because a brief that says manipulation will not produce the balance data the model needs.

Decide the source mix in the brief. If retargeted human motion is acceptable as part of the set, it buys coverage at a fraction of robot time; if every episode has to come off the physical platform, the budget and timeline follow from that. State which state streams are required, base pose and foot contact among them, since a fixed-base pipeline may drop them by default.