Robot Config Training

July 13, 2026 ยท View on GitHub

UFO now has an experimental --robot-config training entry point. The goal is to let a robot-specific MuJoCo XML, curated robot YAML, and adapted RobotState motion data enter the training initialization path without editing the core training code.

The default robot is still Unitree G1:

./run_train.sh --agent fb --data-manifest configs/data/example_mix.yaml --gpu-ids single --smoke

Old G1 commands that do not pass --robot-config remain supported. If a data manifest declares robot_config and the CLI does not pass --robot-config, the manifest robot config is used automatically. If both are provided, UFO checks that they refer to the same resolved robot config or the same robot name and XML path.

For a new robot, provide:

  • a MuJoCo XML describing the robot;
  • a Robot YAML generated by the import wizard and manually curated;
  • RobotState motion data adapted to that robot joint order;
  • training.hydra_robot, training.init_state, training.control, and training.actuator fields in the Robot YAML.

XML-derived Draft Generation

robot_inspect can generate a draft RobotTrainingSpec YAML and a matching Hydra robot config draft from a MuJoCo XML:

uv run python -m humanoidverse.tools.robot_inspect \
  --xml /path/to/robot.xml \
  --name my_robot \
  --out configs/robots/my_robot.yaml \
  --hydra-out humanoidverse/config/robot/my_robot/my_robot_auto.yaml

--hydra-out automatically enables --with-training and writes training.hydra_robot to the inferred Hydra group path, such as my_robot/my_robot_auto. Structural fields including body names, actuated joints, action dimensions, joint ranges, and base body are extracted from XML. The result is marked metadata.review_status: draft; review semantic body groups, contact bodies, default pose, PD gains, actuator parameters, and reward/termination-related fields before formal training.

If a matching URDF is available, pass it as optional auxiliary input:

uv run python -m humanoidverse.tools.robot_inspect \
  --xml /path/to/robot.xml \
  --urdf /path/to/robot.urdf \
  --name my_robot \
  --out configs/robots/my_robot.yaml \
  --hydra-out humanoidverse/config/robot/my_robot/my_robot_auto.yaml

The MuJoCo XML remains the source of truth for qpos/qvel layout, actuator order, action dimension, control joint names, and body names. URDF is used only to enrich the draft with hardware limits and dynamics that are often absent or less explicit in MJCF: effort, velocity, joint dynamics damping/friction, semantic name hints, and a left/right symmetric DOF pair draft stored under metadata. When XML and URDF joint position limits differ, XML limits are kept by default and a warning is emitted. --prefer-urdf-limits true can override that policy for draft generation, but the resulting config still needs manual review.

Use --urdf-joint-name-map path.yaml or .json when XML control joint names do not exactly match URDF joint names. The mapping direction is XML joint name to URDF joint name. The generated symmetric_dofs_idx_draft is metadata only; the current training and inference path does not consume it automatically.

Example smoke command:

./run_train.sh \
  --agent fb \
  --robot-config configs/robots/my_robot.yaml \
  --data-manifest configs/data/my_robot_motion.yaml \
  --gpu-ids single \
  --smoke

Current limitations:

  • The first version still requires training.hydra_robot to select a base Hydra robot config for composing the training environment.
  • UFO does not perform retargeting. Motion data must already match the robot joint order and RobotState schema.
  • This is not a guarantee that arbitrary robots will train with zero additional environment tuning or achieve high-quality behavior.
  • This is not cross-robot shared-policy training. Each robot config defines the training initialization path for that robot.
  • robot_inspect output is a draft. Semantic fields such as base_body, feet, hands, key_bodies, contact bodies, and actuator parameters should be checked before formal training.