Motphys · TATP-233 · Sep 15, 2026 · Sep 15, 2026
@@ -2,12 +2,13 @@
 
 Concrete RL tasks split by family:
 
-- **locomotion** — A2, Go1, Go2, Go2w, Go2 + Airbot, and Unitree G1
+- **locomotion** — Go2 and Unitree G1 reference owners
 - **manipulation** — Allegro in-hand cube and Stewart balance
 - **motion_tracking** — G1 and X2 whole-body motion tracking
 
 Every task is registered into the task `Registry` so it can be selected via
 `uv run train --algo <algo> --task <name> --sim <backend>`.
+Unitree production variants are documented in `unitree_rl_unilab`.
 
 ```{toctree}
 :maxdepth: 2

@@ -6,10 +6,7 @@
    :template: autosummary/module.rst
    :recursive:
 
-   unilab.tasks.locomotion.a2
    unilab.tasks.locomotion.common
    unilab.tasks.locomotion.g1
-   unilab.tasks.locomotion.go1
    unilab.tasks.locomotion.go2
-   unilab.tasks.locomotion.go2w
 ```
@@ -153,12 +153,13 @@ committed benchmark manifest or separate recommendation metadata.
 
 | Robot / task family | Algorithm paths with repo evidence | Backend evidence |
 | --- | --- | --- |
-| Go1 joystick | PPO, APPO, TD3 | PPO has tested MuJoCo and Motrix rows. APPO has tested MuJoCo rows and Motrix registered rows. TD3 has a Motrix owner YAML for `go1_joystick_flat`. |
 | Go2 joystick | PPO, FlashSAC, TD3 | PPO has tested MuJoCo and Motrix rows. FlashSAC has MuJoCo owner YAMLs for `go2_joystick_flat`; TD3 has a Motrix owner YAML for `go2_joystick_flat`. |
-| Go2W joystick | PPO | PPO owner YAMLs exist for MuJoCo and Motrix flat/rough variants under `src/unilab/conf/ppo/task/go2w_joystick_*`. |
-| G1 locomotion / tracking | PPO, APPO, SAC, TD3 | PPO, APPO, and SAC include committed MuJoCo and Motrix owner YAMLs for G1 tasks; TD3 has a `g1_walk_flat` MuJoCo owner. |
+| G1 reference locomotion / tracking | PPO, APPO, SAC, TD3 | PPO, APPO, and SAC include committed MuJoCo and Motrix owner YAMLs for retained G1 tasks; TD3 has a `g1_walk_flat` MuJoCo owner. |
 | Allegro in-hand | PPO, APPO | PPO and APPO have committed MuJoCo and Motrix owner YAMLs for Allegro in-hand tasks. |
 
+Unitree production task families are maintained in `unitree_rl_unilab` and are
+not counted as core repository evidence.
+
 ```{toctree}
 :hidden:
 :caption: Documentation

@@ -63,8 +63,8 @@ The support matrix is generated from registry, owner YAML, and tests; use it as
 the current evidence source: {doc}`../../5-reference/5-support_matrix`.
 
 ```bash
-uv run train --algo ppo --task go1_joystick_flat --sim mujoco
-uv run train --algo ppo --task go1_joystick_flat --sim motrix
+uv run train --algo ppo --task go2_joystick_flat --sim mujoco
+uv run train --algo ppo --task go2_joystick_flat --sim motrix
 uv run train --algo ppo --task g1_walk_flat --sim isaacsim
 ```
 
@@ -92,8 +92,8 @@ The selected owner YAML sets `training.sim_backend` as an identity field.
 - `--render-mode none` disables playback.
 
 ```bash
-uv run eval --algo ppo --task go1_joystick_flat --sim mujoco --load-run -1
-uv run eval --algo ppo --task go1_joystick_flat --sim motrix --load-run -1 \
+uv run eval --algo ppo --task go2_joystick_flat --sim mujoco --load-run -1
+uv run eval --algo ppo --task go2_joystick_flat --sim motrix --load-run -1 \
   --render-mode record
 ```
 

@@ -19,7 +19,7 @@ default version pinned by the committed `uv.lock`) plus the
 
 ```bash
 uv run train --algo ppo --task go2_joystick_flat --sim mujoco
-uv run train --algo appo --task go1_joystick_flat --sim mujoco training.no_play=true
+uv run train --algo appo --task go2_joystick_flat --sim mujoco training.no_play=true
 uv run train --algo sac --task g1_walk_flat --sim mujoco
 ```
 

@@ -97,7 +97,7 @@ export UNILAB_BENCHMARK_HSGYM_LIB="$UNILAB_BENCHMARK_HOLOSOMA_DEPS/miniconda3/en
 
 Validate the environment with the benchmark script. The benchmark loads robot
 models from URDF, so you must provide your own URDF model tree
-(`go1_description/`, `g1_description/`, ...) and point `--models-root` or
+(`go2_description/`, `g1_description/`, ...) and point `--models-root` or
 `UNILAB_BENCHMARK_MODELS_ROOT` at its root directory:
 
 ```bash

@@ -9,13 +9,13 @@ owner YAMLs under `src/unilab/conf/` and summarized in {doc}`../../5-reference/5
 :::{grid-item-card} Locomotion
 :link: 1-locomotion
 :link-type: doc
-Go1, Go2, Go2W, and G1 walking owners.
+Go2 and G1 core reference owners; Unitree production variants are downstream.
 :::
 
 :::{grid-item-card} Motion tracking
 :link: 2-motion_tracking
 :link-type: doc
-G1 motion tracking, flips, climbs, wall flips, and box tracking.
+G1/X2 motion-tracking reference profiles.
 :::
 
 :::{grid-item-card} Manipulation

@@ -1,117 +1,28 @@
 # Locomotion
 
-Locomotion tasks are registered in `src/unilab/tasks/locomotion/` and
-`src/unilab/tasks/motion_tracking/`. The available owner YAMLs under `src/unilab/conf/`
-define which algorithm and backend combinations are runnable.
+UniLab keeps a small reference/conformance locomotion set and the shared
+Manager-Based runtime. Unitree production variants live in the downstream
+`unitree_rl_unilab` package.
 
-## Families
+## Core reference tasks
 
-- Go1: `go1_joystick_flat`, `go1_joystick_rough`
-- Go2: `go2_joystick_flat`, `go2_joystick_rough`, `go2_footstand`
-- Go2W: `go2w_joystick_flat`, `go2w_joystick_rough`
+- Go2 joystick: `go2_joystick_flat`
 - G1 walking: `g1_walk_flat`, `g1_walk_rough`
-- G1 motion tracking: `g1_motion_tracking`, `g1_flip_tracking`,
-  `g1_wall_flip_tracking`, `g1_climb_tracking`, `g1_box_tracking`
-
-## Examples
+- G1 motion tracking reference profiles: see {doc}`2-motion_tracking`
 
 ```bash
 uv run train --algo ppo --task go2_joystick_flat --sim mujoco
-uv run train --algo ppo --task go2_joystick_rough --sim motrix training.no_play=true
-uv run train --algo ppo --task go2_footstand --sim mujoco training.no_play=true
-uv run train --algo appo --task g1_motion_tracking --sim mujoco training.no_play=true
+uv run train --algo ppo --task g1_walk_flat --sim mujoco
 uv run train --algo sac --task g1_walk_flat --sim mujoco
 ```
 
-Check the support matrix for evidence grade by entrypoint, task owner, and
+Check the core support matrix for evidence grade by entrypoint, task owner, and
 backend: {doc}`../../5-reference/5-support_matrix`.
 
-## Go2 FootStand
-
-`go2_footstand` is the Go2 front-feet-stand task. Its PPO owner YAMLs
-register MuJoCo, Motrix, and Drake; the SAC owner currently targets Drake.
-
-- Canonical PPO task config: `src/unilab/conf/ppo/task/go2_footstand/base.yaml`
-- Backend owners: `src/unilab/conf/ppo/task/go2_footstand/{mujoco,motrix,drake}.yaml`
-- Registered env: `Go2FootStand` (MuJoCo, Motrix, and Drake)
-- Implementation: `src/unilab/tasks/locomotion/go2/footstand.py`
-  (task-owned NumPy manager terms on the generic Manager-Based runtime)
-- Go2 model XML: `src/unilab/assets/robots/go2/go2.xml`
-
-```bash
-uv run train --algo ppo --task go2_footstand --sim mujoco training.no_play=true
-uv run eval --algo ppo --task go2_footstand --sim mujoco --load-run -1
-```
-
-### Teacher-Student Pipeline
-
-The full FootStand recipe is a three-stage teacher-student pipeline; the shipped
-`go2_footstand` config corresponds to stage 1 (the teacher PPO entry point):
-
-1. **Teacher PPO (privileged obs).** The teacher uses privileged observations
-   (e.g. base linear velocity) that are available in simulation but should not be
-   relied on directly during real-robot deployment. A power curriculum first lets
-   the policy learn the front-feet stand under a loose power budget (~400 W), then
-   gradually tightens it toward ~200 W, so early exploration is not crushed by a
-   low power limit and the final policy stays near a deployable energy envelope.
-2. **Distillation to a deployable student.** The trained teacher is distilled into
-   a student policy whose inputs keep only on-robot observations (no privileged
-   information). The goal is to reproduce the teacher's behavior without privileged
-   obs.
-3. **Student RL fine-tune.** The distilled student is fine-tuned with a combined
-   objective: a reward term similar to the teacher's, plus a teacher-regularization
-   term that keeps the student from drifting away from the teacher too quickly.
-   This preserves the stable motion while letting the student adapt to its own
-   observation inputs and deployment constraints.
-
-### Observation Layout
-
-The `Go2FootStand` policy (actor) observation uses 15 history frames of 45 dims
-each (`FRAME_OBS_DIM = 45`):
-
-```text
-linvel(3) + gyro(3) + gravity(3) + joint_position_delta(12) + joint_velocity(12) + last_action(12)
-```
-
-So the policy observation is `45 * 15 = 675`. The value (critic) observation
-appends the current-step privileged tail (`PRIVILEGED_OBS_DIM = 49`)
-after that history:
+## Unitree ecosystem tasks
 
-```text
-gyro(3) + accelerometer(3) + linvel(3) + global_angvel(3) + dof_pos(12) + dof_vel(12) + torques(12) + height(1)
-```
-
-The value observation is therefore `675 + 49 = 724`.
-
-### Rewards And Terminations
-
-Defaults come from `src/unilab/conf/ppo/task/go2_footstand/base.yaml`; backend leaves only
-override backend-specific terms and tuning. The reward scales
-include stand `height`, `orientation`, `rear_feet_contact`, target front-leg angle
-(`tar`), `action_rate`, `dof_pos_limits`, `front_leg_motion`, `rear_leg_symmetry`,
-`knee_clearance`, `upright_stability`, `stay_still`, `pose`, plus `energy` and
-`dof_acc` penalties; `termination` and `penalty_contact` drive the termination /
-penalty paths (front-leg / front-body contact, low height, bad orientation, and a
-high-energy cutoff in the `footstand` termination term).
-
-### Tuning Keys
-
-- `env.observations.policy.terms.frame.history_length`: policy history length
-  (default `15`).
-- `env.terminations.footstand.params.energy_threshold`: high-energy cutoff
-  (default `200.0`).
-- `env.events`: reset and domain-randomization terms. Backend owners explicitly
-  set unsupported model-field terms to `null`.
-- `reward.footstand.params.scales`: stand, contact, motion, and energy weights.
-
-### Near-Risk Validation
-
-```bash
-uv run pytest tests/envs/locomotion/test_go2_footstand.py tests/config/test_locomotion_params.py -q
-```
-
-If the Go2 XML changed, at minimum confirm MuJoCo can load the model:
-
-```bash
-uv run python -c "import mujoco; m=mujoco.MjModel.from_xml_path('src/unilab/assets/robots/go2/go2.xml'); print(m.nq, m.nv, m.nu, m.nsensor)"
-```
+Unitree production variants are maintained in
+[unitree_rl_unilab](https://github.com/unilabsim/unitree_rl_unilab), which
+depends only on the published UniLab/UniRL distributions. Its support evidence
+and task documentation are owned by that repository and are not part of
+UniLab's core support matrix.
@@ -21,28 +21,25 @@ configuration entry point; the selected owner is materialized into the shared
 | --- | --- | --- | --- |
 | `g1_motion_tracking` | `G1MotionTracking` | `dance1_subject2_part.npz` | `src/unilab/conf/ppo/task/g1_motion_tracking/`, `src/unilab/conf/appo/task/g1_motion_tracking/` |
 | `g1_flip_tracking` | `G1FlipTracking` | `flip_360_001__A304.npz` | `src/unilab/conf/ppo/task/g1_flip_tracking/`, `src/unilab/conf/appo/task/g1_flip_tracking/` |
-| `g1_wall_flip_tracking` | `G1WallFlipTracking` | `flip_from_wall_104__A304.npz` | `src/unilab/conf/ppo/task/g1_wall_flip_tracking/`, `src/unilab/conf/appo/task/g1_wall_flip_tracking/` |
 | `x2_wall_flip_tracking` | `X2WallFlipTracking` | `tictacflip_6-3_g1format.npz` | `src/unilab/conf/ppo/task/x2_wall_flip_tracking/` |
-| `g1_climb_tracking` | `G1ClimbTracking` | `climb_20_z_scale_1.0.npz` | `src/unilab/conf/ppo/task/g1_climb_tracking/`, `src/unilab/conf/appo/task/g1_climb_tracking/` |
 | `g1_box_tracking` | `G1BoxTracking` | `sub3_largebox_003_boxconverted.npz` | `src/unilab/conf/ppo/task/g1_box_tracking/` |
 | `g1_wbt_obs` | `G1WBTObs` | `dance1_subject2_part.npz` | `src/unilab/conf/sac/task/g1_wbt_obs/mujoco.yaml` |
 
-The 23-DoF task-owner directories select their matching 23-DoF scene, motion,
-entity, and action declarations. Profile differences remain in Hydra. The G1
-identities use the shared manager factory; X2 adds only a cold-path mesh resolver
-before delegating to that factory.
+Profile differences remain in Hydra. The retained G1 identities use the shared
+manager factory; X2 adds only a cold-path mesh resolver before delegating to
+that factory. Unitree production wall-flip, climb, deploy, and 23-DoF motion
+profiles now live in `unitree_rl_unilab`.
 
 ## PPO And APPO
 
 PPO owner iteration budgets (the `--sim mujoco` owner YAMLs): `g1_motion_tracking`
-runs `algo.max_iterations=15000`; `g1_flip_tracking` and `g1_wall_flip_tracking`
-run `20000`; `x2_wall_flip_tracking` runs `9500`. (The Motrix owner YAML for
+runs `algo.max_iterations=15000`; `g1_flip_tracking` runs `20000`; and
+`x2_wall_flip_tracking` runs `9500`. (The Motrix owner YAML for
 `g1_flip_tracking` raises this to `30000`.)
 
 ```bash
 uv run train --algo ppo --task g1_motion_tracking --sim mujoco
 uv run train --algo ppo --task g1_flip_tracking --sim mujoco
-uv run train --algo ppo --task g1_wall_flip_tracking --sim mujoco
 uv run train --algo ppo --task x2_wall_flip_tracking --sim mujoco
 uv run train --algo ppo --task g1_motion_tracking --sim motrix
 uv run train --algo appo --task g1_motion_tracking --sim mujoco training.no_play=true

@@ -5,7 +5,7 @@ This page only describes the current domain randomization status of registered t
 
 Manager-Based event terms are the only DR declaration path:
 
-- **Manager-Based (Compatible) tasks**: reset / interval randomization is declared through Hydra `events:` manager terms in the owner YAML; reset-lifecycle events sample at reset, interval-lifecycle events perturb between steps. See the `events:` block of `src/unilab/conf/ppo/task/go1_joystick_flat/base.yaml` for an example.
+- **Manager-Based (Compatible) tasks**: reset / interval randomization is declared through Hydra `events:` manager terms in the owner YAML; reset-lifecycle events sample at reset, interval-lifecycle events perturb between steps. See the `events:` block of `src/unilab/conf/ppo/task/go2_joystick_flat/base.yaml` for an example.
 
 The Manager-Based lifecycle is:
 
@@ -31,7 +31,6 @@ These three paths correspond to three lifecycle classes:
 
 | Task | Declaration path | Structured form? | reset form | interval form | Code |
 | --- | --- | --- | --- | --- | --- |
-| `Go1JoystickFlat` | Hydra `events:` terms | Yes: owner YAML declares reset/interval events | root-state reset + base mass/COM + `pd_gains` | `push_by_setting_velocity` event | `src/unilab/conf/ppo/task/go1_joystick_flat/base.yaml` |
 | `Go2JoystickFlat` | Hydra `events:` terms | Yes: owner YAML declares reset events | root-state reset + `pd_gains` kp/kd | none | `src/unilab/conf/ppo/task/go2_joystick_flat/base.yaml` |
 | `G1WalkFlat` | Hydra `events:` terms | Yes: Hydra `EventTermCfg` + Manager-Based reset terms | root-state reset + kp/kd via `pd_gains` | none | `g1/manager_terms.py` |
 | `G1WalkRough` | Hydra `events:` terms | Yes: same Manager-Based event terms as `G1WalkFlat` | root-state reset + kp/kd via `pd_gains` | none | `g1/manager_terms.py` |
@@ -44,7 +43,6 @@ These three paths correspond to three lifecycle classes:
 
 | Task | Currently implemented reset domain randomization | Currently implemented interval domain randomization | Default state |
 | --- | --- | --- | --- |
-| `Go1JoystickFlat` | base xy/yaw and base qvel via `reset_root_state_uniform`; command sampling (`UniformVelocityCommandCfg`); base mass via `randomize_rigid_body_mass`; base COM via `randomize_rigid_body_com`; kp/kd via `pd_gains` | `push_by_setting_velocity` interval event | all listed event terms are declared and enabled by default in `src/unilab/conf/ppo/task/go1_joystick_flat/base.yaml` |
 | `Go2JoystickFlat` | base xy/yaw and base qvel via `reset_root_state_uniform`; command sampling; kp/kd via `pd_gains` | none | event terms declared and enabled by default in `src/unilab/conf/ppo/task/go2_joystick_flat/base.yaml` |
 | `G1WalkFlat` | base xy/yaw and base qvel via `reset_root_state_uniform`; command sampling with a planar dead zone; `gait_phase` sampling; kp/kd randomization via `pd_gains` | none | kp/kd enabled on mujoco owners by default; disabled on motrix/mjwarp owners |
 | `G1WalkRough` | Same as `G1WalkFlat` (shared owner bases, rough scene) | none | Same defaults as `G1WalkFlat` |
@@ -78,11 +76,11 @@ early task unlearnable.
 ## Interval push Usage
 
 Manager-Based tasks configure interval push through the `env.events.push_robot`
-term. For example, `src/unilab/conf/ppo/task/go1_joystick_flat/base.yaml` uses
-`push_by_setting_velocity` with a 15-second interval and per-axis velocity ranges.
+term. For example, the retained `g1_wbt_obs` owner uses
+`push_by_setting_velocity` with interval and per-axis velocity ranges.
 
 ```bash
-uv run train --algo ppo --task go1_joystick_flat --sim mujoco \
+uv run train --algo sac --task g1_wbt_obs --sim mujoco \
   'env.events.push_robot.interval_range_s=[10.0,10.0]'
 ```
 

@@ -24,19 +24,18 @@ term that calls `randomize_physics_scene_gravity`.
 ## Interval Push
 
 Manager-Based tasks configure interval push through the `env.events.push_robot`
-term. For example, `src/unilab/conf/ppo/task/go1_joystick_flat/base.yaml` uses
-`push_by_setting_velocity` with a 15-second interval and per-axis velocity ranges.
+term. For example, the retained `g1_wbt_obs` owner uses
+`push_by_setting_velocity` with an interval and per-axis velocity ranges.
 
 ```bash
-uv run train --algo ppo --task go1_joystick_flat --sim mujoco \
+uv run train --algo sac --task g1_wbt_obs --sim mujoco \
   'env.events.push_robot.interval_range_s=[10.0,10.0]'
 ```
 
 ## Owner-Local Defaults
 
 Keep ranges in the task owner YAML when they are part of the task contract. For
-example, the rough quadruped family's base mass, center-of-mass, kp/kd, and push
-randomization are declared as event terms in the shared base
-`src/unilab/conf/ppo/task/quadruped_joystick_rough/base.yaml`.
+example, a rough-task family can declare base mass, center-of-mass, kp/kd, and
+push randomization as event terms in its shared owner base.
 
 For the full current inventory, see {doc}`0-index`.