How to use Isaac Sim

Isaac Sim is NVIDIA's robotics simulator, and it is best understood as a set of extensions layered on Omniverse Kit rather than as a simulator in the way Gazebo is one. Kit supplies the application framework, the USD scene runtime, and a ray-traced renderer. Isaac Sim supplies the robot-shaped parts on top, which are importers, articulation and actuator models, sensor models that are simulated in the ray tracer itself, a ROS 2 bridge, and synthetic data tooling. Physics is PhysX by default, with experimental Newton support added in the 6.0 line. The thing worth internalising before anything else is that rendering is not an optional subsystem you can switch off. It is load bearing, and that single fact decides which machines can run Isaac Sim at all.

Placed against the neighbours, Isaac Sim is not a drop-in replacement for any of them. MuJoCo is a physics library with a soft, always-solvable contact model, it runs on a CPU or on any CUDA device, and it is the right tool when you want fast contact-rich dynamics and do not care about pixels. Gazebo is the ROS-native workhorse, cheap to run in continuous integration, honest about being a functional rather than photoreal simulator. Unreal, and by extension the AirSim lineage, gives you photorealism and a game engine's asset pipeline but leaves you to build the robotics on top. Isaac Sim sits where photorealism and robot modelling meet, and it charges for that position in hardware. The one-sentence identity: Isaac Sim is a USD scene graph with PhysX bolted to one side and a production ray tracer bolted to the other, and the ray tracer is what simulates your cameras and lidar.

This page is the platform half of a pair. The training half, covering massively parallel reinforcement learning environments, lives in the companion guide to Isaac Lab. The two have different licences, which is worth knowing up front. Isaac Lab is BSD-3-Clause source you can read at isaac-sim/IsaacLab, and Isaac Sim has been Apache-2.0 at isaac-sim/IsaacSim since the 5.0.0 release in August 2025, though a large part of what it depends on, Omniverse Kit, is not. Unless a sentence says otherwise, everything below describes Isaac Sim 6.0.1, which was published on 2026-06-22, with the 5.1.0 line noted where it differs because that is what the current stable Isaac Lab still pairs with.

The hardware gate, read this before installing anything

Isaac Sim requires an NVIDIA GPU with RT cores. This is not a performance recommendation and it is not a rendering nicety you can opt out of. The official requirements page carries the sentence verbatim, and it has carried it unchanged across the 4.5, 5.0, 5.1 and 6.0 documentation sets.

"GPUs without RT Cores (A100, H100) are not supported."
    -- Isaac Sim system requirements, 4.5.0 / 5.0.0 / 5.1.0 / 6.0.1

If you have a headless node with two H100s, that node cannot run Isaac Sim. Neither can an A100 node, nor any other datacentre part that ships without RT cores. Hopper and datacentre Ampere are compute silicon. They have no RT cores, so the RTX renderer has nothing to render with, and every sensor that is simulated by tracing rays against the scene has no path to a result. NVIDIA's documentation declares the configuration unsupported, and I would not plan around anything beyond that statement. Whether Kit will physically start a process on such a card is beside the point and is not something I have tested.

The follow-up question is always whether --headless or --no-window rescues it. It does not. What headless removes is the window and the presentable Vulkan swapchain, which is why headless plus livestreaming is the documented way to run on a machine with no monitor attached. What it does not remove is the RTX renderer. Kit's renderer is Vulkan-based and initialises regardless of whether a window exists, and an Isaac Sim maintainer has stated in a public discussion that Isaac Sim does not support plugging in an alternative Hydra renderer and that sensor simulation is tightly coupled to the RTX renderer. I want to be precise about the epistemic status here, because it matters. There is no single official sentence reading "Vulkan is required even in headless mode". The conclusion is assembled from three things, which are the renderer coupling just described, the container documentation stating that headless plus livestreaming is the remote-host path rather than a rendering-free path, and reported failures where a fully headless container run dies during Vulkan initialisation and takes physics down with it. Treat it as a well-supported conclusion, not as a quotation.

There is a related trap in the other direction. Running headless with viewport updates disabled is a genuine and recommended performance technique, because it removes rendering overhead you are not using. That is advice for someone who already owns an RTX GPU. It is not a route to running on a GPU that has no RT cores.

For the reader who prompted this page, the practical answer is that the RTX 4090 is above the documented minimum and is a perfectly good Isaac Sim machine, the RTX 5090 is Blackwell and works provided you stay on Isaac Sim 5.0 or newer with a recent driver, and the 2xH100 node is for training, not for simulation. That split is not a defeat. It is the normal shape of an Isaac workflow, where an RTX workstation or an L40S-class server generates the experience and the datacentre fleet consumes it. My own aerial autonomy lab write-up documents hitting exactly this wall on a Hopper machine that has no ray tracing cores, no display engine, and no Vulkan userspace at all.

Isaac Sim 6.0.1 requirements

Three footnotes on that table matter more than the table does. The documented VRAM caveat is that GPUs with less than 16 GB may be insufficient for a complex scene rendering more than 16 megapixels per frame, and that workflows using a large number of sensors are the ones that suffer first. Operating system support for 6.0 is Ubuntu 22.04 or 24.04 and Windows 11, with Windows 10 called out as not supported, which is a real tightening from 4.5 where the table listed Ubuntu 20.04 and Windows 10. And driver floors move every release, so pin them to the version you are installing rather than quoting one number forever.

The 6.0 documentation phrases those numbers as the versions Isaac Sim was tested on rather than as a hard floor, and defers to the Omniverse technical requirements page for the per-branch detail. In practice treat 595.58.03 on Linux as the safe target for 6.0.1 and do not assume an older driver in the same branch is fine until it runs.

One more Blackwell note, worded carefully. Isaac Sim 5.0.0 is the first release whose requirements table lists Blackwell parts, with the RTX 5080 in the Good row and the RTX PRO 6000 Blackwell in the Ideal row, where the 4.5.0 table topped out at RTX Ada 6000. I am describing a change in the published table. NVIDIA never published a statement of the form "Blackwell support was added in 5.0", so do not repeat one. What is separately documented is that users on 4.5 with RTX 50-series cards hit compute capability 12.0 errors, and that some sm_120 rough edges persist into the 5.1 and 6.0 known-issues pages, including a Franka Open Drawer example that needs the physics rate raised to 600 to behave.

Installing

The first thing to know is what is gone. The Omniverse Launcher, Nucleus Workstation and Nucleus Cache were deprecated and became unavailable on 2025-10-01. Any tutorial that tells you to install Isaac Sim through the Launcher is stale, including, as of this writing, one stale cross-reference inside NVIDIA's own container documentation. Nucleus and Live Sync are now served by Enterprise Nucleus Server, and Nucleus Cache is replaced by Hub Workstation Cache. None of that is needed to run Isaac Sim, which pulls assets over HTTPS by default.

Four install paths are live. Those are pip into a virtual environment, the NGC container, the workstation zip, and building from source now that the repository is Apache-2.0. For a single RTX workstation, pip is the path I would take, because it puts Isaac Sim in the same interpreter as your own code and makes the Python API the primary interface rather than an afterthought.

Check first

compat.sh# Isaac Sim 6.0.1 requires Python 3.12 exactly. This is a change from 5.1.0, which
# required 3.11, and it is one of the most common upgrade breaks.
python3.12 -m venv env_isaacsim
source env_isaacsim/bin/activate
pip install --upgrade pip

# The compatibility checker is a small extra, not the full install.
pip install 'isaacsim[compatibility-check]==6.0.1.0' --extra-index-url https://pypi.nvidia.com

export OMNI_KIT_ACCEPT_EULA=YES
isaacsim isaacsim.exp.compatibility_check

# On a machine without RT cores, the RTX-capable GPU row is the one that fails.

Note the four-part version. The pip wheels are versioned 6.0.1.0 while the container tag and the zip are versioned 6.0.1, and mixing the two up produces a confusing resolver error rather than a helpful one.

The pip path

install-isaacsim.sh# Linux additionally needs GLIBC 2.35 or newer, because the wheels are tagged
# manylinux_2_35_x86_64 and pip will simply not find them otherwise.
ldd --version | head -1

python3.12 -m venv env_isaacsim
source env_isaacsim/bin/activate
pip install --upgrade pip

# PyTorch first, CUDA enabled. Pick one index.
pip install torch==2.11.0 --index-url https://download.pytorch.org/whl/cu128
# pip install torch==2.11.0 --index-url https://download.pytorch.org/whl/cu130

pip install 'isaacsim[all,extscache]==6.0.1.0' --extra-index-url https://pypi.nvidia.com

# Without this you get an interactive EULA prompt, and declining it terminates the run.
# YES, Y and 1 are all accepted, case insensitive.
export OMNI_KIT_ACCEPT_EULA=YES

isaacsim                                          # same as isaacsim isaacsim.exp.full
isaacsim isaacsim.exp.full.streaming --no-window  # headless with WebRTC livestream

# Editor support for the extension modules, which are not ordinary site-packages.
python -m isaacsim --generate-vscode-settings

If you are targeting the current stable Isaac Lab rather than Isaac Sim on its own, the pairing changes and so does the interpreter. Isaac Lab 2.3.x wants Isaac Sim 5.1.0 on Python 3.11 with torch 2.7.0, which is documented on the Isaac Lab page in full. Do not try to satisfy both in one environment.

The container path

On a server, the container is the honest choice, and there are two details that break more first runs than everything else combined. The 6.0 image runs rootless as uid 1234, so the host directories you mount have to be chowned to that uid. And host networking is required for livestreaming, because the streaming SDK binds its UDP media socket to a real interface inside the container, which Docker bridge networking with published ports cannot provide. Signalling will connect and no video will ever arrive.

run-container.shsudo nvidia-ctk runtime configure --runtime=docker && sudo systemctl restart docker
docker run --rm --runtime=nvidia --gpus all nvcr.io/nvidia/cuda:12.8.0-base-ubuntu24.04 nvidia-smi

docker pull nvcr.io/nvidia/isaac-sim:6.0.1

mkdir -p ~/docker/isaac-sim/{cache/main,cache/computecache,config,data,logs,pkg}
mkdir -p ~/.cache/ov/hub
sudo chown -R 1234:1234 ~/docker/isaac-sim ~/.cache/ov/hub

docker run --name isaac-sim --entrypoint bash -it --gpus all --rm --network=host \
  -e "ACCEPT_EULA=Y" -e "PRIVACY_CONSENT=Y" -u 1234:1234 \
  -v ~/docker/isaac-sim/cache/main:/isaac-sim/.cache:rw \
  -v ~/docker/isaac-sim/cache/computecache:/isaac-sim/.nv/ComputeCache:rw \
  -v ~/docker/isaac-sim/logs:/isaac-sim/.nvidia-omniverse/logs:rw \
  -v ~/docker/isaac-sim/config:/isaac-sim/.nvidia-omniverse/config:rw \
  -v ~/docker/isaac-sim/data:/isaac-sim/.local/share/ov/data:rw \
  -v ~/docker/isaac-sim/pkg:/isaac-sim/.local/share/ov/pkg:rw \
  -v ~/.cache/ov/hub:/var/cache/hub:rw \
  nvcr.io/nvidia/isaac-sim:6.0.1

# Inside the container
./warmup.sh           # precompile shaders, otherwise the first real run stalls
./runheadless.sh -v   # -v shows shader cache warmup progress
# Wait for: "Isaac Sim Full Streaming App is loaded."

# Open on the host firewall: 49100/tcp signalling, 47998/udp media,
# 8210/tcp web viewer when using the Docker Compose flow.

The workstation zip is the third path and behaves the way you would expect. Unzip it, run ./post_install.sh to link the tutorial examples, run ./warmup.sh, then ./isaac-sim.sh. The package root also carries ./python.sh, which is the bundled interpreter you must use for standalone scripts against that install, plus ./clear_caches.sh and the --reset-user flag that you will meet again in the failure modes section.

The mental model

Four ideas carry almost all of the load. Get these and the API stops feeling arbitrary.

The stage is USD, and everything is a prim

There is no Isaac Sim scene format. The scene is a USD stage, and every object in it is a prim at a path such as /World/Cube. Physics is expressed as USD schemas applied to prims, so a rigid body is a prim carrying the rigid body API and a physics scene is a prim of type UsdPhysics.Scene. This has three consequences worth planning around. Composition is real, so you can reference a robot asset into many stages and layer overrides on top without copying it. Anything that reads or writes USD, including plain pxr Python, can manipulate your scene. And the path strings are the API, which is why regex patterns over prim paths, such as one path per cloned environment, show up everywhere once you move to parallel simulation.

SimulationApp comes first, always

This is the rule that breaks every newcomer exactly once. You must construct SimulationApp before importing anything from isaacsim.* or omni.*. The reason is not stylistic. Those modules are supplied by Kit extensions, and the extensions do not exist as importable Python modules until SimulationApp has booted the Kit application, loaded the .kit experience file, started the extension system, and initialised the renderer and the USD runtime. Put an isaacsim import above the constructor and you get a ModuleNotFoundError that looks like a broken install and is not one. The documentation phrases it as the default first two lines in any standalone application, which is exactly how you should treat it.

Extensions are the unit of everything

Kit is the framework and Isaac Sim is a collection of extensions plus a few .kit experience files that decide which of them load. Isaac Sim 6.0.0 ships Kit SDK 110.1.1 and 6.0.1 ships 110.1.2, where 5.0.0 shipped 107.3.1. This is why the experience name is a command line argument, why the camera API and the physics sensor API live in separately versioned namespaces, and why Python extensions hot reload, which means you can edit an extension while the application is running and see the change on save. It is also why the API churns. In 6.0 the entire sensor surface moved, with isaacsim.sensors.camera, isaacsim.sensors.rtx and isaacsim.sensors.physics all deprecated in favour of isaacsim.sensors.experimental.rtx and isaacsim.sensors.experimental.physics, and the old omni.isaac.* compatibility shims removed outright. Pin your Isaac Sim version in your repository and read the release notes before upgrading.

PhysX is the default, Newton is experimental

PhysX remains the default solver. Isaac Sim 6.0 added experimental support for the Newton physics engine, currently limited to Newton's MJWarp solver, with engine-agnostic access through the isaacsim.core.experimental APIs and URDF and MJCF importers that emit Newton schemas as well. If you care about how a contact solver's choices shape what your policy learns, the advanced manipulation notes contrast soft convex contact against the complementarity formulation properly, and animation and simulation covers the GPU-parallel rigid body lineage that Isaac belongs to.

A minimal headless run

The script below starts Isaac Sim headless, defines a physics scene, drops a ground plane and a falling cube, steps for two hundred frames, and shuts down cleanly. It uses the 6.0 isaacsim.core.experimental surface. That namespace is labelled experimental for a reason, so expect it to move between releases and check it against the version you installed.

minimal.py"""Minimal Isaac Sim 6.0.1 standalone script.

Run with the pip install active:      python minimal.py
Run against a workstation install:    ~/isaacsim/python.sh minimal.py
"""

# RULE: SimulationApp is constructed before any isaacsim.* or omni.* import.
# The Kit extensions that provide those modules do not exist until it boots.
from isaacsim import SimulationApp

simulation_app = SimulationApp({"headless": True})

# Only now is the rest importable.
import numpy as np
import omni.usd
from isaacsim.core.experimental.objects import Cube, GroundPlane
from isaacsim.core.experimental.prims import GeomPrim, RigidPrim
from pxr import UsdPhysics

stage = omni.usd.get_context().get_stage()

# Physics is a USD schema applied to a prim, not a separate world object.
UsdPhysics.Scene.Define(stage, "/World/PhysicsScene")

GroundPlane("/World/groundPlane", sizes=10, colors=np.array([0.5, 0.5, 0.5]))

Cube(
    "/World/Cube",
    positions=np.array([-0.5, -0.2, 1.0]),
    scales=np.array([0.5, 0.5, 0.5]),
    colors=np.array([0.2, 0.3, 0.0]),
)

# Two more schemas on the same prim: one makes it dynamic, one gives it collision.
RigidPrim("/World/Cube")
GeomPrim("/World/Cube", apply_collision_apis=True)

for _ in range(200):
    simulation_app.update()

# Always close. Skipping this leaves Kit processes and file locks behind.
simulation_app.close()

Two habits to build from that script. First, simulation_app.update() advances the whole application, which includes physics and rendering. When you want explicit control over the physics rate separately from the render rate, that is what the standalone workflow exists for, and it is the only one of the three official workflows the documentation describes as headless capable. The other two are the GUI workflow for scene authoring and OmniGraph visual programming, and the extension workflow for asynchronous tools that run alongside a live application with hot reload. Second, always call close(). In a Jupyter kernel, calling it interrupts and kills the kernel, which is a documented behaviour rather than a bug.

Sensors

Sensors split cleanly into two families, and knowing which family a sensor belongs to tells you what it costs and what hardware it needs.

RTX sensors are simulated by the Omniverse RTX renderer through the RTX Sensor SDK. That includes cameras, lidar, radar, and the ultrasonic acoustic sensor added in 6.0. RTX lidar models returns from transparent and reflective surfaces, and RTX radar accounts for material emissivity and reflectivity in the radio spectrum. This is the concrete reason the RT core requirement is not negotiable. Physics sensors are simulated by the physics engine instead. Contact, IMU, effort, joint state and the new raycast sensor live in isaacsim.sensors.experimental.physics, they run on CPU physics after rendering finishes, and they report exact engine measurements at the physics rate rather than sampled approximations.

Attaching a camera and reading a frame

The 6.0 camera API splits authoring from runtime, which is the single most useful thing to understand about it. RtxCamera creates or wraps the USD camera prim and owns the optics, meaning focal length, aperture and clipping range. CameraSensor creates a Replicator render product at a chosen resolution, attaches annotators, and is what you call get_data() on. One is the lens, the other is the frame grabber.

camera.pyfrom isaacsim import SimulationApp

simulation_app = SimulationApp({"headless": True})

from isaacsim.sensors.experimental.rtx import RtxCamera, CameraSensor

# Authoring. tick_rate=0, the default, renders every simulation frame.
# A nonzero value renders at that rate independently of the physics step.
cam = RtxCamera(path="/World/Camera", tick_rate=30.0)

# Runtime. This is what creates the render product and attaches annotators.
sensor = CameraSensor(
    cam,
    resolution=(640, 480),
    annotators=["rgb", "distance_to_image_plane", "semantic_segmentation"],
)

for _ in range(100):
    simulation_app.update()

# get_data returns a (warp.array, info_dict) tuple, not a bare numpy array.
rgb, rgb_info = sensor.get_data("rgb")
depth, depth_info = sensor.get_data("distance_to_image_plane")
seg, seg_info = sensor.get_data("semantic_segmentation")

print(rgb_info)

simulation_app.close()

The annotator names the camera documentation lists explicitly are rgb, distance_to_camera, distance_to_image_plane, semantic_segmentation and motion_vectors, followed by an unhelpful "and so on". The standard Replicator instance segmentation and bounding box annotators are widely used, but I have not confirmed their exact spelling against the 6.0 camera surface, so check the annotator reference for your version before writing them into a data generation script.

Two depth distinctions are worth getting right the first time. distance_to_camera is a radial range from the camera origin, while distance_to_image_plane is the perpendicular distance that most computer vision code actually means when it says depth. If you want a depth image with realistic stereo artefacts rather than a perfect one, SingleViewDepthCameraSensor adds disparity, baseline, noise and outlier removal, and StructuredLightCamera models projected pattern depth.

For many cameras at once, do not create one render product per camera. Use TiledCameraSensor, which packs many cameras into a single tiled render product and which the documentation describes as significantly more efficient for reinforcement learning and multi-environment workflows. This is the mechanism the Isaac Lab vision environments are built on.

RTX lidar, and the flag that catches everyone

Motion BVH is disabled by default because it costs VRAM and performance. It is also required for lidar motion compensation and for radar Doppler, which the documentation puts bluntly by saying that means RTX radar entirely. Run a radar without it and you get a fatal error rather than a degraded result. Motion BVH is itself an RT-dependent Vulkan feature that is unavailable on A100, H100 and B200, which is the same hardware gate arriving from a different direction.

lidar.pyfrom isaacsim import SimulationApp

# enable_motion_bvh is off by default. Required for lidar motion compensation
# and for radar Doppler, and therefore for RTX radar at all.
simulation_app = SimulationApp({"headless": True, "enable_motion_bvh": True})

from isaacsim.sensors.experimental.rtx import Lidar, LidarSensor

# aux_output_level is one of NONE, BASIC, EXTRA, FULL.
lidar = LidarSensor(Lidar("/World/lidar", aux_output_level="FULL"))

for _ in range(100):
    simulation_app.update()

simulation_app.close()

The equivalent from the command line, for the cases where you cannot change the SimulationApp arguments, sets the renderer flags directly.

motion-bvh.sh./isaac-sim.sh \
  --/renderer/raytracingMotion/enabled=true \
  --/renderer/raytracingMotion/enableHydraEngineMasking=true \
  --/renderer/raytracingMotion/enabledForHydraEngines='0,1,2,3,4'

# Without it, radar aborts with:
#   [Fatal] Running radar without MotionBVH is disallowed, to force it use
#   --/app/sensors/nv/radar/runWithoutMBVH=true
# On Windows, enabling motion BVH also requires passing --vulkan.

IMU and contact

The physics sensors are cheaper and conceptually simpler. An IMU must be created on a path beneath the rigid body prim it measures, and it outputs accelerometer and gyroscope readings in local axes with configurable rolling-average filter widths for linear acceleration, angular velocity and orientation.

imu.pyfrom isaacsim import SimulationApp

simulation_app = SimulationApp({"headless": True})

import numpy as np
from isaacsim.sensors.experimental.physics import IMU, IMUSensor

# The path must sit under the rigid body prim being measured.
sensor = IMUSensor(
    IMU.create(
        "/World/Cube/imu_sensor",
        linear_acceleration_filter_size=10,
        angular_velocity_filter_size=10,
        orientation_filter_size=10,
        translations=np.array([[0.0, 0.0, 0.0]]),
        orientations=np.array([[1.0, 0.0, 0.0, 0.0]]),  # wxyz
    )
)

for _ in range(100):
    simulation_app.update()

reading = sensor.get_sensor_reading()
print(reading)

simulation_app.close()

The contact sensor sits in the same namespace and is built on the PhysX contact report API with per-object filtering, an optional region filter, minimum and maximum force thresholds, and a radius where minus one means use the prim's own collision geometry. I have not read its constructor signature directly, so check the 6.0 API reference rather than copying a signature from a blog post. One behavioural change in 6.0 applies to all of them, which is that these sensors now read on every physics step and the old sensorPeriod attribute is deprecated.

Failure modes and their fixes

• The first launch looks frozen for five to ten minutes: it is compiling shaders, and the documentation says so in as many words. Run ./warmup.sh or warmup.bat during provisioning so the first interactive run is not the one that pays. In the container, ./runheadless.sh -v shows the warmup progress instead of silence.
• Every container run recompiles shaders: you did not mount the cache. On Linux the shader cache is ~/.cache/ov/Kit, configuration is ~/.local/share/ov/data/Kit/Isaac-Sim and logs are ~/.nvidia-omniverse/logs/Kit/Isaac-Sim. On Windows the cache is under %userprofile%\AppData\Local\ov\cache\Kit. The container's own mount points are listed in the run command earlier on this page.
• Vulkan 1.1 is not supported, or ERROR_INCOMPATIBLE_DRIVER: the Vulkan stack is genuinely broken or the driver is too old, and this kills the run headless as well as windowed. Verify with vulkaninfo and nvidia-smi before anything else. In a container this is usually a host driver and container toolkit mismatch rather than an Isaac Sim problem.
• Driver misreported as incompatible when it is fine: driver versions above 535.255 report their version incorrectly through Vulkan. The documented workaround is --/rtx/verifyDriverVersion/enabled=false. Understand what this does, which is skip the version check only. It will not repair a genuinely absent Vulkan stack, and reaching for it first will waste your afternoon.
• Failed to initialize graphics environment, vkCreateSwapchainKHR returns UNKNOWN_ERROR: you tried to run the GUI over SSH with X forwarding, over VNC or NoMachine or DCV, or on a server with no monitor attached. There is no fix for GUI mode here. The documented answer is headless plus livestreaming, which is isaacsim isaacsim.exp.full.streaming --no-window for a pip install or ./runheadless.sh in the container.
• GLFW initialization failed, and cannot acquire carb::windowing::IWindowing: ignore these. The known-issues page lists them under errors that can be ignored when running headless. They are the windowing plugin declining to start, which is the intended outcome.
• WebRTC signalling connects but no video arrives: you used -p port publishing. Use --network=host, and open 49100/tcp, 47998/udp and, for the Docker Compose web viewer, 8210/tcp.
• Strange crashes or config errors right after an upgrade: reset state before debugging anything else. ./isaac-sim.sh --reset-user restores default user configuration and ./clear_caches.sh clears local caches. For containers, delete and recreate the mount tree, then chown it back to uid 1234, because stale volume data causes both crashes and livestream failures.
• Replicator drops frames during data generation: the throttling extension flips asynchronous rendering on when the timeline stops. Launch with --/exts/isaacsim.core.throttling/enable_async=false.
• USD animations look choppy on 5.0 and newer but were fine on 4.5: the full experience enables fixed time stepping by default. Fixing it needs all three flags, which are --/app/player/useFixedTimeStepping=false, --/app/runLoops/main/manualModeEnabled=false and --/exts/isaacsim.core.throttling/enable_manualmode=false.
• Black screen on Windows: launch with --vulkan. Viewport flicker and black synthetic data images on Windows 11 are a separate issue that wants a 595 or newer driver.
• Drowning in log output: --/log/level=error --/log/fileLogLevel=error --/log/outputStreamLevel=error.

triage.sh# Triage order that saves the most time, top to bottom.
nvidia-smi                      # driver present, and which GPU is actually visible
vulkaninfo | head               # Vulkan enumerates the GPU at all
isaacsim isaacsim.exp.compatibility_check   # NVIDIA's own verdict

# Then, and only then, start changing flags.
./isaac-sim.sh --reset-user
./clear_caches.sh
./isaac-sim.sh --/renderer/activeGpu=0 --/renderer/multiGpu/maxGpuCount=1

When not to use Isaac Sim

Reaching for Isaac Sim by default is a mistake, and there are several situations where a smaller tool is strictly better.

• You have no RT cores: this is the whole ballgame. A datacentre fleet of A100s or H100s cannot run it, and no flag changes that. Use MuJoCo, which runs anywhere, or move the simulation to an RTX workstation or an L40S-class server and keep the datacentre GPUs for training.
• You need fast contact-rich dynamics with no pixels: MuJoCo is the better tool for manipulation research where the interesting behaviour is contact and friction rather than perception. It starts in milliseconds, and Isaac Sim does not.
• You want simulation in continuous integration: an Isaac Sim run costs a large image, a shader cache, an RTX runner and a first-run warmup measured in minutes. That is a heavy price for a pull request check. Gazebo or a headless physics-only harness will give you a regression signal far more cheaply.
• Your stack is ROS 1: the bridge is ROS 2, with Ubuntu 24.04 to Jazzy as the recommended pairing and Ubuntu 22.04 supporting Humble or Jazzy. If you are on ROS 1, Gazebo is where the ecosystem lives.
• You need a differentiable simulator: Isaac Sim is not one. Analytic gradients through contact are a different design point, and the tools that offer them are different tools.
• The problem is planning or estimation, not perception: a planner does not need a ray tracer to be validated. The motion planning and SLAM notes describe problems where a two-dimensional grid and a matplotlib window get you further, faster.
• Your team cannot afford API churn: 6.0 deprecated the entire previous sensor surface and removed the omni.isaac.* compatibility shims. If you need a simulator you can pin and forget for three years, budget for the upgrades or choose something more stable.

The case where it is clearly right is the mirror image of all of that. You need photoreal camera, lidar or radar data for a perception or vision-language-action model, you need domain randomised synthetic data at volume, you need many robots stepping in parallel on a GPU, or you are already inside the NVIDIA robot stack. That is the territory the robot imitation lab write-up circles, and imitation versus RL for control makes the case for why so much robot learning happens in simulation at all.

Takeaway

If you take one thing from this page, make it the hardware gate, because it is the only claim here that can render the other eight sections irrelevant before you type a command.

References

These are version-pinned deliberately. The latest path on NVIDIA's documentation currently serves 6.0.1 and will drift, so the links below point at fixed versions and stay checkable.

1. NVIDIA, Isaac Sim 6.0.1 system requirements. The source of the GPU ladder, driver floors, operating system support, and the sentence excluding GPUs without RT cores. The 4.5.0 equivalent is worth opening alongside it to see how far the table has moved.
2. NVIDIA, Python environment installation. The Python 3.12 constraint, the GLIBC floor, the four-part wheel version, and the EULA environment variable.
3. NVIDIA, Container installation. The rootless uid 1234 requirement, the host networking requirement for WebRTC, and the statement that GUI mode does not work over a remote or virtual display.
4. NVIDIA, Download and install paths. Carries the notice that the Omniverse Launcher, Nucleus Workstation and Nucleus Cache became unavailable on 2025-10-01.
5. NVIDIA, Known issues and troubleshooting. Most of the failure modes section is a compressed reading of these two pages.
6. NVIDIA, Camera sensors and RTX sensors. The authoring and runtime split, the annotator list, tiled rendering, and the motion BVH requirement for lidar and radar.
7. NVIDIA, Omniverse technical requirements. The per-architecture feature matrix showing which RT-dependent features are unavailable on Hopper and datacentre Ampere, and the per-branch driver versions.
8. NVIDIA, isaac-sim/IsaacSim, Apache-2.0 since the 5.0.0 release. The releases API is the authoritative source for the dates quoted on this page.
9. NVIDIA, isaac-sim/IsaacLab, BSD-3-Clause. The reinforcement learning framework built on Isaac Sim, covered in full in the companion Isaac Lab guide.
10. Pixar, OpenUSD documentation. Composition, layers and schemas, which are the substrate the entire Isaac Sim scene model rests on.
11. Makoviychuk et al., Isaac Gym, High Performance GPU-Based Physics Simulation For Robot Learning, 2021. The paper behind the GPU-parallel simulation idea that Isaac Lab inherited. The robot kinematics and control notes derive the batched dynamics this depends on.