Architecture#
How a registered --task becomes a runnable ManagerBasedRlEnvCfg. For the
layer model (MDP, robot, preset, task), start with Overview.
Config pipeline#
Every task cfg is assembled in the same order:
make_base_wbc_env_cfg() # shared WBC template (env/wbc_env_cfg.py)
↓
<robot>_base_cfg() # registered robot entity
↓
apply_<preset>(...) # paper / deploy recipe (presets/*.py)
↓
[optional] apply_se_actor() # actor obs swap (wbc / zest / end_effector)
↓
WbcTaskConfig.build_env_cfg # --task id
Preset ↔ task concepts: Presets and tasks. Code examples: Choose a task.
Task registration#
WbcTaskConfig (tasks/config.py) binds:
task_id→ CLI--taskrobot_id→ registered entity +data/<robot>/experiment_name→logs/rsl_rl/<name>/build_env_cfg→ full env cfg callable
Robots added in the Studio (robots/custom.py) follow the same pipeline: their
<robot>_base_cfg is built from robot.yaml (model, PD gains, body names) and their
tasks stack apply_wbc (+ apply_se_actor for -SE). Studio presets add one more
step after build_env_cfg: modules, then the preset’s own overrides
(studio/presets.py), registered as <task>--<name>.
Play / eval mode#
Task builders accept play=True to disable training-only features: long episodes,
obs corruption, motion DR, assistive wrench, push events. Same pattern for every
registered robot.
WBC Studio#
src/wbc_mjlab/studio/ — a UI-agnostic core with services, and two frontends:
Module |
Role |
|---|---|
|
|
|
Robot catalogue, wiring, pose · add / edit robots from model files |
|
Datasets, clip index / search, raw + NPZ preview, clip QA, conversion and import |
|
Studio presets and modules (schema, apply, register, run snapshots) · training entry |
|
Detached train / convert jobs ( |
|
A checkpoint on N envs in-process: clip pinning, reference ghost, reward terms |
|
FastAPI server (JSON API + binary websocket frames) and the three.js UI |
|
The same core as a viser app |