Add a robot#
Every robot is a registered entity: its model, actuators, body names and tasks plug into the shared MDP without touching it. There are two ways to register one.
Upload the MJCF / URDF in the Studio. Wiring and PD gains are suggested, checked on a
floor and saved per user; tasks Wbc-<Id>, -SE and -Terrain-Scan appear at
once.
Best for trying a robot, research across embodiments.
A Python package calling register_wbc_extension: full control over actuator
models, symmetry for mirroring, any task table; ships with your platform.
Best for a robot you maintain and deploy.
Both paths give a robot that every command and the Studio treat like the built-in G1.
Starting with the Studio and moving to a package later is common — the saved robot.yaml
holds the numbers the package’s constants need.
Walkthrough: extension → data → train#
The extension path end to end, for a robot my_robot with clips my_data.
Create the package following wbc-mjlab-extension-h2 (Example: H2 extension walks through it) and install it next to wbc-mjlab:
uv pip install -e ../my-robot-wbc uv run wbc-mjlab-list-envs # lists Wbc-MyRobot
Retarget clips to the robot (e.g. with GMR) and put them in the extension’s data tree:
<project_root>/data/my_robot/my_data/*.csv.Check and train (the clips are read as they are — check them in the Studio’s Data):
uv run wbc-mjlab-train --task Wbc-MyRobot --dataset my_data
Checklist#
Before publishing an extension or opening a PR:
No MDP forks — rewards, sampling and terminations stay in
env/mdp/; use presetsRegistered —
register_wbc_extensionruns at import, from amjlab.tasksentry pointNames explicit — anchor, keybodies and end-effectors as constants
Motion wired — a
RobotMotionSpec(feet for--debias-z, the scene forwbc-mjlab-data-to-npz --robot <id>)Tasks —
WbcTaskConfigentries with the matchingrobot_id
See also
Robots and extensions — why robots register
Extension API —
WbcRobotSpec,register_wbc_extension,RobotMotionSpec