unitree_rl_lab for IsaacLab Robot Training

What unitree_rl_lab adds to IsaacLab

unitree_rl_lab targets engineers who want to train reinforcement learning policies for supported Unitree robots without constructing each simulator environment themselves. The repository is based on IsaacLab and currently supports Go2, H1, and G1-29dof. Its quick-start examples center on the G1-29dof velocity task, giving users a concrete locomotion configuration to inspect or modify.

The project is not an independent reinforcement learning framework. IsaacLab provides the simulation foundation, while unitree_rl_lab adds Unitree robot assets, task registrations, launch scripts, and deployment code. Based on the repository layout, `source/` contains the Python package, `scripts/rsl_rl/` contains training and play entry points, `deploy/` contains robot controller sources, and `unitree_rl_lab.sh` provides the documented installation and task commands.

The intended workflow has two stages. A policy first learns in IsaacLab. It can then be evaluated in MuJooco before deployment to a physical robot. That intermediate simulator can expose deployment problems before hardware use, but it also adds another simulator, configuration surface, and native dependency chain. For teams evaluating the project, the deployment code matters as much as the Python training package.

Installing unitree_rl_lab beside IsaacLab

The README first directs users to the Isaac Lab installation guide. Unitree RL Lab must be cloned separately and kept outside the IsaacLab directory. Install it with a Python interpreter that already has IsaacLab available.

Clone the repository with:

git clone https://github.com/unitreerobotics/unitree_rl_lab.git

Activate the documented IsaacLab environment and install the standalone environments in editable mode:

conda activate env_isaaclab
./unitree_rl_lab.sh -i
# restart your shell to activate the environment changes.

The README says to restart the shell so the environment changes become active. This is not a small pip-only setup. The Python environment must already contain IsaacLab, and the project also expects compatible robot description files.

For the recommended URDF route, clone the Unitree ROS asset repository:

git clone https://github.com/unitreerobotics/unitree_ros.git

Then edit `source/unitree_rl_lab/unitree_rl_lab/assets/robots/unitree.py` and configure `UNITREE_ROS_DIR` as documented. The example path must be changed to the actual local location. A clone can succeed while the source configuration still points at a nonexistent directory, so task verification matters after installation.

Running the G1-29dof velocity task

The README recommends verifying the installation by listing available tasks. Its wrapper command is described as faster than the IsaacLab equivalent:

./unitree_rl_lab.sh -l # This is a faster version than isaaclab

The output should include the task names registered by the installation. The complete list is not printed in the README, so users should verify that the intended robot appears rather than infer every task name from the supported-robot table.

Start training for the documented G1-29dof example with:

./unitree_rl_lab.sh -t --task Unitree-G1-29dof-Velocity # support for autocomplete task-name
# same as
python scripts/rsl_rl/train.py --headless --task Unitree-G1-29dof-Velocity

The first line invokes the wrapper, while the direct Python command is the README's equivalent training entry point. Task-name autocomplete is documented for the wrapper invocation.

After training, play or infer with a trained agent through the documented wrapper:

./unitree_rl_lab.sh -p --task Unitree-G1-29dof-Velocity # support for autocomplete task-name
# same as
python scripts/rsl_rl/play.py --task Unitree-G1-29dof-Velocity

The repository does not identify checkpoint directories or describe expected console output beyond listing and running a task. It also does not provide training duration, hardware guidance, convergence criteria, or benchmark results. Those details require inspection of the training configuration and local execution rather than assumptions based on the project name.

Choosing USD or URDF robot assets

The README documents two asset paths. The first downloads Unitree USD files from `unitree_model` while preserving the repository's folder structure:

git clone https://huggingface.co/datasets/unitreerobotics/unitree_model

After cloning, configure `UNITREE_MODEL_DIR` in `source/unitree_rl_lab/unitree_rl_lab/assets/robots/unitree.py`. The README presents an example assignment with the path `/home/user/projects/unitree_usd`. That path must be changed to the location where the asset repository was cloned.

The second route uses files from `unitree_ros`. The README recommends this method only for IsaacSim 5.0 or later. In addition to setting `UNITREE_ROS_DIR`, it says users may need to change `robot_cfg.spawn` to use URDF files. This is a meaningful configuration boundary. Downloading URDF assets does not by itself establish which representation the spawn configuration will use.

The path examples are user-specific and cannot work unchanged on another machine. The README does not provide a dedicated asset-validation command beyond task listing and task execution. Consequently, successful repository cloning should not be treated as successful configuration. Listing tasks verifies registration, while running one exercises IsaacSim's ability to load the configured robot.

MuJoCo validation and physical control path

The deployment section places MuJooco between IsaacLab training and physical operation. According to the README, the trained strategy should first undergo sim-to-sim evaluation in MuJooco, followed by sim-to-real deployment. This gives the workflow a second simulator, but the README does not define numerical acceptance thresholds for that transition.

The native dependency installation is:

sudo apt install -y libyaml-cpp-dev libboost-all-dev libeigen3-dev libspdlog-dev libfmt-dev

The README then documents installation of `unitree_sdk2` and compilation of the G1-29dof controller:

git clone [email protected]:unitreerobotics/unitree_sdk2.git
cd unitree_sdk2
mkdir build && cd build
cmake .. -DBUILD_EXAMPLES=OFF # Install on the /usr/local directory
sudo make install

The controller build is documented separately:

cd unitree_rl_lab/deploy/robots/g1_29dof # or other robots
mkdir build && cd build
cmake .. && make

For MuJooco simulation, the README requires `robot` to be `g1`, `domain_id` to be `0`, `enable_elastic_hand` to be `1`, and `use_joystck` to be `1`. Start the simulator with:

cd unitree_mujoco/simulate/build
./unitree_mujoco
# ./unitree_mujoco -i 0 -n eth0 -r g1 -s scene_29dof.xml # alternative

Then run the controller:

cd unitree_rl_lab/deploy/robots/g1_29dof/build
./g1_ctrl
# 1. press [L2 + Up] to set the robot to stand up
# 2. Click the mujoco window, and then press 8 to make the robot feet touch the ground.
# 3. Press [R1 + X] to run the policy.
# 4. Click the mujoco window, and then press 9 to disable the elastic band.

This is an interactive procedure rather than a one-command batch evaluation. The README's physical-control example is:

./g1_ctrl --network eth0 # eth0 is the network interface name.

The README warns that the onboard control program must be closed first. It does not document an emergency-stop procedure, actuator constraints, or a formal hardware acceptance test. Those omissions matter when assessing physical deployment.

Limits of MuJoCo in the deployment path

IsaacLab and MuJooco serve different purposes in this repository. IsaacLab is used for task execution, training, and inference through `scripts/rsl_rl/train.py` and `scripts/rsl_rl/play.py`. MuJooco is installed separately and used for sim-to-sim evaluation with a controller from `deploy/robots/g1_29dof/`.

Using both does not make the simulations interchangeable. MuJooco introduces a separate installation, `/simulate/config.yaml`, joystick input, native controller compilation, and its own model behavior. IsaacLab remains tied to IsaacSim and the Unitree asset configuration in `source/unitree_rl_lab/unitree_rl_lab/assets/robots/unitree.py`. Policy transfer therefore depends on maintaining the intended controller interface and task settings across those environments. The README describes the route but does not publish compatibility results or transfer-error measurements.

unitree_rl_lab is also unsuitable as a lightweight generic reinforcement learning package. Its installation assumes IsaacLab, its launcher operates on standalone IsaacLab environments, and its deployment directory includes a C++ control path. For a vendor-neutral proof of concept, a simpler Python package would involve fewer documented dependencies. For a Unitree policy intended for physical deployment, the MuJooco and SDK integration is the project's distinguishing feature.

Maintenance, packaging, and license scope

The repository is not archived, and its last push was on 2026-05-25. That date indicates recent repository activity, but it does not establish compatibility with every IsaacLab or IsaacSim update. The repository has no GitHub releases, so there is no release-note stream for checking migration changes.

The `pyproject.toml` file uses `setuptools`, configures Python 3.10, and targets Linux for static analysis. The README documents installation through an existing `env_isaaclab` environment and the editable installation command `./unitree_rl_lab.sh -i`. It does not provide a standalone PyPI installation command. Its badges identify IsaacSim 5.1.0 and IsaacLab 2.3.0, while the URDF route is documented for IsaacSim 5.0 or later.

The repository uses the Apache-2.0 license. IsaacLab, IsaacSim, MuJooco, `unitree_ros`, `unitree_mujoco`, and `unitree_sdk2` are separate dependencies governed by their own terms. The README does not provide a dependency lock file or upgrade matrix. After changing versions, the first project-specific check is `./unitree_rl_lab.sh -l`, followed by the intended task. That verifies task registration and loading without treating a successful package installation as sufficient evidence that deployment will work.

Editorial conclusion

Adopt unitree_rl_lab when training Unitree locomotion policies in IsaacLab and when the separate MuJooco deployment workflow fits your requirements. Do not choose it for a lightweight, simulator-independent setup or if IsaacLab, robot assets, native libraries, and `unitree_sdk2` are unacceptable. First verify the documented IsaacSim and IsaacLab versions, configure the robot asset path, then run `./unitree_rl_lab.sh -l` to confirm that the expected tasks are registered.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. unitreerobotics/unitree_rl_lab on GitHub