Isaac Sim on Antioch

The runtime pin is Isaac Sim 6.0.1 / Kit 110.1.2. Author code without a local simulator; Antioch runs it in the remote simulator service. Load Antioch platform for project and session setup; its environment guide owns engine selection and dependencies.

The domain references adapt NVIDIA's specialist guidance at the startup, import, and execution boundaries below; each names its upstream source. Upstream script links are source examples, not helpers installed in the project. Retain their native workflows and examples when adapting code. Change startup, imports, and execution for Antioch; check APIs against the runtime pin and correct specific source errors rather than dropping the surrounding explanation.

Start from the task table below. Each reference links to its prerequisites, related tasks, and upstream source. Follow those links as the task moves from asset preparation to control, sensors, and evaluation; you do not need to load the whole library.

Startup and imports

Scenarios start Kit before their body. A script or notebook calls antioch.start_simulation() first, then imports simulator modules inside functions. Keep pxr, omni, carb, isaacsim, and isaaclab* out of module-scope imports, including helper modules; TYPE_CHECKING is safe. One process has one app and stepping owner. Do not create another SimulationApp around a framework that owns one.

antioch.world() returns the classic Isaac Sim World, not an Isaac Lab handle; antioch.stage() returns the USD stage, and antioch.application() returns the app handle. Identical startup is a no-op; a conflicting configuration needs a new process. For a complete script and SimulationConfig options, read simulation code.

For types without importing the simulator during local discovery:

from typing import TYPE_CHECKING

if TYPE_CHECKING:
    from pxr import Usd


def current_stage() -> "Usd.Stage":
    import antioch

    return antioch.stage()

SimulationConfig.viewport_updates controls the default viewport independently of streaming. None follows the stream; True keeps viewport rendering enabled, and False pauses it, including any stream image. Use True for code that waits on viewport rendering, such as a Replicator orchestrator running without a stream. Kit must still receive updates from the stepping owner. See rendering and simulation configuration.

Native APIs and live state

Use research for pinned signatures, units, prerequisites, and backend support. Current surfaces include isaacsim.core.experimental.prims, isaacsim.core.experimental.utils, isaacsim.core.simulation_manager, isaacsim.sensors.experimental.rtx, isaacsim.sensors.experimental.physics, and isaacsim.storage.native; classic isaacsim.core.api.World still ships. Do not copy retired omni.isaac.* imports.

Build, initialize, reset, control, and step with the selected framework. Classic World.step(render=True) advances render_dt / physics_dt physics steps; render=False advances one. Measure progress with simulation time, not the number of render calls. Use run.sim_s in a scenario or the engine clock/callback time in a script. Read physics-backed poses for physical checks; authored USD transforms can lag writeback. Experimental RigidPrim.get_world_poses() returns batched Warp arrays, even for one body.

Isaac Sim commonly uses WXYZ quaternions; Lab 3 and scipy use XYZW. Convert at the boundary. Select a backend before stage construction, and verify coupled behavior: standalone Newton support does not prove support through Isaac's USD/tensor integration. Verify the active backend with SimulationManager.get_active_physics_engine() when it affects the result. Warp arrays and kernels can be part of the native implementation; check device, dtype, batch shape, ownership, and synchronization when exchanging them with NumPy, Torch, or physics tensors.

Evidence

Define the success check before running. Source inspection verifies an API contract; a runtime probe verifies only the behavior it exercises. A command acknowledgement, nearby objects, or a final picture does not prove physical contact or task completion. Keep live measurements, run inputs, checks, and artifacts together through scenario design, and distinguish simulation results from real-world validation.

Domain references

Start with assets to find existing content in Antioch's catalog or Isaac's native library.

For motion-generation work, load the specific step you are implementing: workflow, world binding, control loop, frames and grasping, or cuMotion setup.

For a failure, start with the run's status, first error, input, and smallest reproduction. See agentic simulation to drive that loop and scenario design for recorded checks and telemetry.