Known Issues

Known Issues#

Attention

Please also refer to the Omniverse Isaac Sim documentation for known issues and workarounds.

Stale values after resetting the environment#

When resetting the environment, some of the data fields of assets and sensors are not updated. These include the poses of links in a kinematic chain, the camera images, the contact sensor readings, and the lidar point clouds. This is a known issue which has to do with the way the PhysX and rendering engines work in Omniverse.

Many physics engines do a simulation step as a two-level call: forward() and simulate(), where the kinematic and dynamic states are updated, respectively. Unfortunately, PhysX has only a single step() call where the two operations are combined. Due to computations through GPU kernels, it is not so straightforward for them to split these operations. Thus, at the moment, it is not possible to set the root and/or joint states and do a forward call to update the kinematic states of links. This affects both initialization as well as episodic resets.

Similarly for RTX rendering related sensors (such as cameras), the sensor data is not updated immediately after setting the state of the sensor. The rendering engine update is bundled with the simulator’s step() call which only gets called when the simulation is stepped forward. This means that the sensor data is not updated immediately after a reset and it will hold outdated values.

While the above is erroneous, there is currently no direct workaround for it. From our experience in using IsaacGym, the reset values affect the agent learning critically depending on how frequently the environment terminates. Eventually if the agent is learning successfully, this number drops and does not affect the performance that critically.

We have made a feature request to the respective Omniverse teams to have complete control over stepping different parts of the simulation app. However, at this point, there is no set timeline for this feature request.

Note

With Isaac Lab 1.2, we have introduced a PhysX kinematic update call inside the body_state_w attribute. This workaround ensures that the states of the links are updated when the root state or joint state of an articulation is set.

Blank initial frames from the camera#

When using the Camera sensor in standalone scripts, the first few frames may be blank. This is a known issue with the simulator where it needs a few steps to load the material textures properly and fill up the render targets.

A hack to work around this is to add the following after initializing the camera sensor and setting its pose:

from isaaclab.sim import SimulationContext

sim = SimulationContext.instance()

# note: the number of steps might vary depending on how complicated the scene is.
for _ in range(12):
    sim.render()

Using instanceable assets for markers#

When using instanceable assets for markers, the markers do not work properly, since Omniverse does not support instanceable assets when using the UsdGeom.PointInstancer schema. This is a known issue and will hopefully be fixed in a future release.

If you use an instanceable assets for markers, the marker class removes all the physics properties of the asset. This is then replicated across other references of the same asset since physics properties of instanceable assets are stored in the instanceable asset’s USD file and not in its stage reference’s USD file.

Exiting the process#

When exiting a process with Ctrl+C, occasionally the below error may appear:

[Error] [omni.physx.plugin] Subscription cannot be changed during the event call.

This is due to the termination occurring in the middle of a physics event call and should not affect the functionality of Isaac Lab. It is safe to ignore the error message and continue with terminating the process. On Windows systems, please use Ctrl+Break or Ctrl+fn+B to terminate the process.

Closed-loop articulations on Newton (e.g. Agility Digit)#

Robots whose USD encodes a closed kinematic loop – such as the achilles rod and toe push-rods on the Agility Digit – do not currently run correctly on the newton_mjwarp physics preset, even though they work on physx. This affects:

  • IsaacContrib-Velocity-Flat-Digit

  • IsaacContrib-Velocity-Rough-Digit

  • IsaacContrib-Tracking-LocoManip-Digit

The root cause sits inside Newton’s ArticulationView. When it builds its per-link axis it walks each joint in the articulation’s joint range and appends model.joint_child[joint_id] without deduplicating. A body that is the child of multiple joints (the standard closed-loop encoding) therefore occupies multiple slots on that axis, so view.link_count is larger than the number of unique physical bodies in the model. On Digit this is 49 link slots versus 43 actual bodies (the four loop-closed bodies – left/right tarsus and left/right toe_roll – account for the six extra slots).

Until the upstream fix lands in Newton, please use the physx preset for Digit-based environments.

Animated curves disappear under Isaac RTX scene partitioning#

Cables are authored as UsdGeom.BasisCurves and animated every frame. Kit RTX computes a bounding box for a curve prim once and never refreshes it while the curve deforms (OMPE-105749). The per-environment scene partition is sized from the union of the bounding boxes of the prims it contains, so that union covers the cable’s initial extent plus whatever static geometry shares the partition. Once the cable moves outside that union it is culled and vanishes from the tiled camera images – for example a cable resting on a table can disappear the moment a robot arm pushes it off the edge.

The bug is specific to the Isaac RTX (Kit) backend with enable_scene_partitioning enabled. The OVRTX backend updates animated-curve bounding boxes correctly and is unaffected.

The displacement needed to trip the cull is the distance from the curve’s spawn extent to the edge of its partition’s bounding box, so it depends on what else shares the partition. Measured on Kit 110.1.2: the cable in Isaac-Lift-Cable-Franka-Camera vanishes at 0.6 m of displacement, while a lone curve in a partition containing only itself and a camera survives to roughly 4 m. Smaller motions render normally, which is why a settled or lightly perturbed cable looks fine.

There are two workarounds:

  • Pin the partition bounds. Spawn a pair of millimetre-scale static cubes at diagonally opposite corners of a box that conservatively envelops the environment’s workspace. They enlarge the partition’s bounding-box union to that box, so the cable stays inside it wherever it moves. Isaac-Lift-Cable-Franka and Isaac-Lift-Cable-Franka-Camera ship this workaround as the partition_bounds_marker_min and partition_bounds_marker_max scene entries; copy the pattern into custom cable environments. With the markers in place, cable visibility matches an unpartitioned render exactly. The markers are static visual prims without colliders, so they do not participate in physics, and Isaac-Lift-Cable-Franka-Camera drops them when its camera renderer has scene partitioning off.

  • Disable scene partitioning. Set enable_scene_partitioning to False to opt out of partitioning entirely, at the cost of the per-environment culling.

URDF Importer: Unresolved references for fixed joints#

Starting with Isaac Sim 5.1, links connected through fixed_joint elements are no longer merged when their URDF link entries specify mass and inertia even if merge-joint set to True. This is expected behaviour—those links are treated as full bodies rather than zero-mass reference frames. However, the USD importer currently raises ReportError warnings showing unresolved references for such links when they lack visuals or colliders. This is a known bug in the importer; it creates references to visuals that do not exist. The warnings can be safely ignored until the importer is updated.

GLIBCXX errors in Conda#

In Isaac Sim 5.0, we have observed some workflows exiting with an OSError indicating version 'GLIBCXX_3.4.30' not found when running from a conda environment. The issue apperas to be stemming from importing torch or torch-related packages, such as tensorboard, prior to launching AppLauncher. As a workaround, ensure that all torch imports happen after the AppLauncher instance has been created, which should resolve the error.