GUIDE · 7 MIN READ
Isaac Sim for humanoids
How humanoid teams use NVIDIA Isaac Sim and Isaac Lab: robot assets, maker models, policy training, sim-to-sim validation and rendering.
REVIEWED BY WBH · · DRAFTED WITH AI ASSISTANCE FROM THE CITED SOURCES
For: People who build, program or evaluate humanoid robots.
What Isaac Sim and Isaac Lab do
Isaac Sim is NVIDIA's robotics simulator. Its documentation describes a loop in which you import robots and scenes from URDF, MJCF, Onshape CAD or USD, simulate them with the PhysX or Newton physics backends, add RTX and physics-based sensors, and connect the result to training pipelines or to an external robot stack [1]. The whole loop works on one USD scene representation, from asset import to deployment, and NVIDIA states that the simulator is open source, with Apache 2.0 licensing for the simulator stack [1].
Isaac Lab is built on Isaac Sim and handles robot learning: its documentation describes a unified and modular framework for workflows such as reinforcement learning, learning from demonstrations and motion planning [2]. Its listed features include PhysX physics simulation, tiled rendering APIs for vectorised rendering, domain randomisation and support for running in the cloud, and the humanoids it includes as ready-to-use assets are the Unitree H1 and the Unitree G1 [2]. The framework is released under the BSD-3-Clause licence, with certain parts under Apache-2.0 [2].
NVIDIA's workflow overview describes a loop of four stages, import, configure, simulate, and connect or deploy, and stresses that each stage stays reusable because all of them operate on the shared Isaac Sim scene [1]. In its view of the wider ecosystem, Isaac Sim builds the scene and rigs the robot at the start of a software-in-the-loop workflow, and runs the software-in-the-loop test with a ROS 2 or Isaac ROS robot stack at the end [1]. Two optional steps sit in between: training reinforcement-learning or imitation-learning policies with parallel environments in Isaac Lab, and benchmarking trained policies across many scenes and seeds with Lab - Arena [1].
Humanoid models in the asset library
Isaac Sim's documentation lists simulation-ready humanoid robots by manufacturer; each entry has a USD path, the physics APIs it uses and its licence, and most entries also give the numbers of joints, links and DOFs [3]. The list includes entries from Unitree, Agility, Agibot, 1X, Booster Robotics, Fourier, IHMC, RobotEra, Sanctuary AI, X-Humanoid and XiaoPeng [3].
Read the details before you pick an entry. NVIDIA's Unitree G1 asset lists 43 DOFs and its Unitree H1 asset 19, and Unitree also has a second G1 entry, in two variants, for which the page gives the joint counts as N/A [3]. The Booster T1 entry, stored as T1_locomotion.usd, lists 23 DOFs [3].
Check the licence of the exact file you load, because licences differ per asset: the Unitree entries are listed under BSD-3, the Booster T1 and IHMC Valkyrie entries under Apache 2.0, and the remaining humanoid entries under a 3D Content Sharing Agreement [3].
If your robot is not in the library, the documentation covers importers for URDF and MJCF, an Onshape importer and a CAD converter, and its robot-setup section has pages on setting up a legged robot, tuning joint drive gains and system identification [3].
Models from makers and labs
- Tokyo Robotics: the torobo_usd_models repository holds USD models of the Torobo for NVIDIA Isaac Sim, and its example opens torobo2_hand.usd in Isaac Sim and starts the simulation [5].
- Walker S2: the WalkerS2 model repository provides URDF files with STL meshes for ROS and ROS 2, and a USD file of the Walker S2 for NVIDIA Omniverse and Isaac Sim [8]. Its README states that the model applies to the Walker S2 EDU and is the official simulation model of the Global Humanoid Robot Challenge 2026, and that the model parameters are for reference only and must be adjusted to the physical robot in real applications [8].
- Dexmate: the dexmate-urdf repository contains URDF and SRDF models of the Dexmate Vega, with the corresponding USD files in its releases, and Dexmate says the models are tested with Isaac Sim, Isaac Lab and Isaac Gym for simulation and RL training [7].
- Berkeley Humanoid Lite: its documentation links its robot description assets in URDF, MJCF and USD, in the HybridRobotics berkeley-humanoid-lite-assets repository [9].
The Dexmate repository ships three representations of the robot: a visual model for rendering, a collision model built from convex decomposition meshes for physical simulation, and a collision model made of spheres as an alternative when speed matters more [7]. Dexmate warns that the spheres are larger than the real robot and are not suited to high-fidelity simulation [7].
Training policies in Isaac Lab
Robot-specific training code can live in its own extension. Tokyo Robotics' torobo_isaac_lab is such an extension project: it lets you develop in an isolated environment, outside the core Isaac Lab repository [6]. Its README installs Isaac Sim 4.2.0 and Isaac Lab 1.2.0, installs the extension with pip, and verifies the installation by training a flat-ground velocity task for the Torobo Leg v1 model with 4 environments; Tokyo Robotics adds that the Leg v1 model is under research and development and not scheduled for sale [6].
The HOVER repository is an Isaac Lab extension for training neural whole-body controllers for humanoids, following the OmniH2O and HOVER papers [4]. Training runs in two steps: first a teacher policy, then a student policy trained against a saved teacher checkpoint [4]. The README says HOVER has been tested with Isaac Lab 2.0.0 and that training needs a single GPU, and it recommends at least 4096 environments for good results, where its examples use 1024 [4].
HOVER trains on the AMASS motion-capture dataset, which has to be retargeted to the robot; the repository provides a script that retargets it for the Unitree H1, but does not distribute the retargeted data because of the AMASS licence [4]. Retargeting the whole dataset could take up to 4 days on a 32-core CPU machine, and the README suggests trial training on a small retargeted subset [4].
Noetix Robotics publishes its own training frameworks: its repositories include reinforcement-learning frameworks for training its Noetix E1 and Noetix Bumi humanoids in Isaac Lab, while its framework for the Noetix N2 targets Isaac Gym and includes sim2sim tools [10].
Validating before hardware
HOVER's README describes two ways to validate a policy trained in Isaac Lab: sim-to-sim and sim-to-real [4]. For sim-to-sim it provides a MuJoCo environment, which supports only one environment at a time; for sim-to-real it provides a hardware environment for the Unitree H1, the only robot its deployment wrapper currently supports [4]. Other robots need their own implementation of the hardware wrapper interface [4].
Tokyo Robotics' torobo_isaac_lab README points to a separate torobo_mujoco repository for running a trained policy in MuJoCo [6].
The Isaac Sim documentation also has a humanoid workflow for training locomotion in AGILE and deploying the policy in Isaac Sim, in five stages: preparing the humanoid USD; creating a custom humanoid task in AGILE; configuring and validating the locomotion MDP; training, evaluating and exporting the policy; and deploying it [3].
The AGILE paper argues that in many real deployments the bottleneck is no longer simulation throughput or algorithm design, but the lack of infrastructure that links environment verification, training, evaluation and deployment [13]. Its workflow has four stages, interactive environment verification, reproducible training, unified evaluation and descriptor-driven deployment, and the authors report consistent sim-to-real transfer for five humanoid skills on the Unitree G1 and Booster T1 [13].
Rendering, perception and hybrid set-ups
Isaac Sim can serve as the renderer alongside another physics engine. SIMPLE, a simulation testbed for humanoid loco-manipulation from USC's PSI Lab, couples the contact-rich dynamics of MuJoCo with the photorealistic rendering of Isaac Sim [11]. The SIMPLE authors list rendering throughput as a limitation: the ray-tracing pipeline renders about 4 frames per second on a single GPU, which makes large-scale dataset generation time-intensive [11]. To keep latency down, they disable Isaac Sim rendering during VR teleoperation [11].
HumanoidVLN, a simulator and benchmark for vision-language navigation, is built on Isaac Sim and demonstrated on four robots, including the Unitree G1 and Unitree H1 [12]. It combines a reinforcement-learning locomotion policy with interchangeable PD or MPC path trackers, and draws its environments from artist-designed scenes and 3D Gaussian Splatting reconstructions [12]. Its authors point out that egocentric observations on a humanoid are distorted by the camera motion that walking causes, one of the challenges they say existing benchmarks fail to address [12].
VIRAL, a visual sim-to-real framework for humanoid loco-manipulation, distils an RGB student policy from a privileged teacher through large-scale simulation with tiled rendering, and its authors report that compute scale is critical: scaling to tens of GPUs, up to 64, made training reliable, while low-compute regimes often failed [14].
For perception training data, Isaac Sim's Replicator framework scripts randomisation, captures sensor outputs and writes labelled datasets, and NuRec loads Gaussian-splat reconstructions of real environments as USD assets [1].
A practical checklist
- Look in the Isaac Sim asset library before you import your own URDF or MJCF model with the importers [3].
- Check each asset's DOF count, variant and licence against what you plan to train and publish [3].
- Treat model parameters as a starting point: the Walker S2 model README says its parameters must be adjusted to the physical robot [8].
- Use the Isaac Sim and Isaac Lab versions a repository was tested with: HOVER names Isaac Lab 2.0.0 [4].
- Size the number of environments to your GPU: HOVER's evaluation with 1024 environments needs approximately 13GB of GPU memory [4].
- Validate in a second simulator before hardware: HOVER provides a MuJoCo environment for sim-to-sim validation [4].