Robots and extensions

A robot in wbc-mjlab is a registered entity — not a folder you drop into env/. The core ships one built-in id (g1) as a reference; every other platform must register before train or play will work.

Why registration

Registration connects four things the CLI needs:

Registered item	Used for
robot_id	--robot and data/<robot>/ paths
make_env_cfg / make_rl_cfg	Train and play env builders
motion_spec	Forward kinematics for data conversion
project_root (extensions)	Extension-owned data/<robot>/ tree

wbc-mjlab-list-envs merges tasks from core + all installed extensions.

Robot entity vs extension package

Approach	When
In-tree (robots/g1/)	Reference platform shipped with core — study, don’t copy-paste for new hardware
Added in the Studio	New robot from its MJCF / URDF, no code — ~/.config/wbc-mjlab/robots/<id>/robot.yaml, registered by the core entry point (Add a robot from model files)
Extension package	New robot — separate repo, register_wbc_extension, mjlab.tasks entry point

Extensions typically ship:

• <robot>_base_cfg() — MJCF, sensors, body tuples

• One or more WbcTaskConfig entries (often apply_wbc only)

• data/<robot_id>/ motion libraries under project_root

Tasks belong to robots

Every WbcTaskConfig sets robot_id so the CLI knows which entity and data paths to use. Task ids (Wbc-H2, Wbc-G1-Zest, …) are names for preset stacks on a specific registered robot — not global env forks.

Build your own

Fastest: upload the model in the Studio — Add a robot from model files.

End-to-end first run (retarget → check → train): Walkthrough: extension → data → train.

Layout, WbcRobotSpec, and H2 reference walkthrough:

• Add a robot

• Extension packages

• Example: H2 extension

Robot entity wiring checklist: The robot entity.