NVIDIA Isaac Sim and Isaac Lab for Humanoid Robot Training

Start with the version pair

This guide examines Isaac Sim 6.1.0 and Isaac Lab v3.0.0-EA as of 8 October 2026. Lab 3.0 is Early Access. The release notes target a final release later in October; that target is not evidence that it has shipped. The full Sim integration uses Python 3.12. [1] [2] [3]

Older instructions pair Lab 2.3.2 with Sim 5.1 and Python 3.11. NVIDIA now marks Sim 5.1 unsupported. Do not combine a 2.x tutorial, current Sim packages and a 3.0 task name in one environment. Existing experiments should retain their exact dependencies when reproducing an older result. [4]

Scene simulation and robot learning

[5] [6] [2]

Lab grew around Isaac Sim, but version 3.0 also supports workflows without launching Sim. Newton and optional OV backends are separate choices. The examples here explicitly choose isaacsim_physx so the backend matches the article. A bare Lab 3.0 command can select a different physics stack. [2] [3]

Check the machine before installation

[7]

The listed drivers are tested versions. Integrated graphics alone do not meet these requirements. Sim needs RT cores; NVIDIA specifically excludes A100 and H100 for this application. Containers are supported on Linux only. Parallel training or multiple cameras can need more memory than this minimum column. Run the supplied compatibility checker before committing to a large installation. [7]

For a computer without suitable local graphics, NVIDIA documents remote workstation and cloud deployment, including Brev, AWS, Azure and Google Cloud. The simulation runs on the remote GPU. Confirm that the selected instance supports the application and account for storage, GPU time and streaming costs. No cloud price was verified for this guide. [8]

Prepare the humanoid before training

• Import a supported robot description or load a versioned USD asset. Keep the asset source and licence with the experiment.
• Use a mobile root for a walking robot. A fixed root can conceal balance failures.
• Inspect joint order, axes, limits, mass, inertia and collision geometry. Mesh appearance does not validate these values.
• Check the drive type and its gains. Verify that position, velocity and effort commands mean what the controller expects.
• Give the feet a collision surface and documented contact material. Set gravity and the physics timestep.
• Place sensors in recorded coordinate frames, then exercise small commands and compare requested and observed joint motion.

[9]

The importer does not make every actuator representation equivalent. USD drive properties and MJCF general actuator gain/bias definitions have different semantics. A model moved between engines needs an interface and response check, even when the robot looks identical. [9]

The tagged G1 task uses G1_MINIMAL_CFG and g1_minimal.usd. The asset definition says collision meshes were removed to reduce simulation cost. That choice can be suitable for its training task while leaving contacts needed for manipulation or self-collision experiments unrepresented. [10]

Select measurements the task actually uses

[11]

NVIDIA’s camera guide distinguishes scene depth from a full replica of a physical stereo pipeline. Its RealSense-style pseudo-depth example does not run the sensor firmware’s stereo reconstruction. A visually convincing rendered scene therefore does not establish matching depth errors. [12]

The ROS 2 interface exchanges messages with other robot software. Sim 6.1 documents Humble and Jazzy, recommending Jazzy on Ubuntu 24.04. Custom interfaces loaded into Sim must match its Python 3.12 environment. Message transport does not train a policy or prove that physical control deadlines are met. [13]

For camera frames and geometric measurements, Read the perception and calibration guide

Read the G1 task’s input and output contract

Isaac-Velocity-Flat-G1 and Isaac-Velocity-Rough-G1 are the task identifiers at the inspected tag. They no longer have the old -v0 suffix. The common environment takes a physics step every 0.005 s and applies a new action every four steps, giving a 0.020 s action interval. Its episode limit is 20 s. These are simulation settings, not physical control recommendations. [14] [15]

The policy observes motion, projected gravity, commanded velocity, relative joint positions and velocities, and its previous action. The rough-ground task adds terrain height observations. The flat task removes that scanner. Actions become joint-position targets with a 0.5 scale and a default-pose offset; they are not raw motor currents. [15] [16]

Reward terms score velocity tracking and foot behavior while penalizing sliding, excessive joint motion and abrupt action changes. The flat and rough tasks use different weights. The torso-contact termination and the timeout also serve different purposes. Training increases the reward it was given, so retain component logs rather than treating a rising total as proof of useful walking. [16] [17]

At this tag, reset states, torso mass and periodic pushes vary. The material event exists, but its friction ranges are fixed at their configured values. Describing that unmodified task as broad friction randomization would be inaccurate. Playback also disables pushes by default, so a playback video is not a disturbance test. [15] [17]

A tagged training reference

Install Git and uv, satisfy the GPU and driver requirements, and follow the Lab installation guide for package terms and asset access. This Linux shell reference chooses 1,024 training environments as an example resource setting. It is not a measured optimum or a guarantee that a particular scene fits the GPU. [3]

git clone --branch v3.0.0-EA --depth 1 https://github.com/isaac-sim/IsaacLab.git
cd IsaacLab
uv run --extra isaacsim isaaclab train --rl_library rsl_rl --task Isaac-Velocity-Flat-G1 --num_envs 1024 --seed 42 physics=isaacsim_physx

The unified train command is headless by default. RSL-RL outputs checkpoints and TensorBoard records under logs/rsl_rl/. Preserve the resolved configuration, seed, backend and checkpoint file. To inspect a recent run with Kit, the documented CLI can use the following command. For a measured comparison, replace latest with the explicit checkpoint argument for the intended run. [18] [19]

uv run --extra isaacsim isaaclab play --rl_library rsl_rl --task Isaac-Velocity-Flat-G1 --checkpoint latest --num_envs 16 physics=isaacsim_physx --viz kit

Changing the physics backend, observation layout or joint order between training and playback changes the experiment. Lab 3.0 also changes quaternion order to XYZW. An older adapter that assumes WXYZ can silently feed an invalid orientation interpretation into the policy. [2]

For held-out conditions and the trial log, Build the walking evaluation protocol

When this stack fits the experiment

Choose the full Sim workflow when the work needs USD scene composition, supported rendered sensors or the Sim ROS integration. A small joint-dynamics exercise can start with a CPU MuJoCo model and a short script. These are task-based choices, not a claim that one engine is faster. A matched performance comparison would need the same bodies, contacts, solver accuracy, sensors and hardware.

Run the executed MuJoCo example

Successful simulation still leaves a physical validation task. Read the limits of transfer to hardware