Download Latest Version v2.2.0 source code.tar.gz (32.7 MB)
Email in envelope

Get an email when there's a new version of NVIDIA Isaac Lab

Home / v2.0.2
Name Modified Size InfoDownloads / Week
Parent folder
README.md 2025-03-05 9.5 kB
0
v2.0.2 source code.tar.gz 2025-03-05 28.2 MB
0
v2.0.2 source code.zip 2025-03-05 29.1 MB
0
Totals: 3 Items   57.3 MB 0

👀 Overview

This patch release focuses on improving actuator configuration and fixing key bugs while reverting unintended behavioral changes from v2.0.1. We strongly recommend switching to this new version if you're migrating from a pre-2.0 release of Isaac Lab.

Key Changes:

  • Actuator limit handling: Introduced velocity_limit_sim and effort_limit_sim to clearly distinguish simulation solver limits from actuator model constraints. Reverted implicit actuator velocity limits to pre-v2.0 behavior
  • Simulation configuration update: Removed disable_contact_processing flag to simplify behavior
  • Rendering configuration update: Reverted to pre-2.0 configuration to improve the quality of the render product
  • Tiled camera fixes: Fixed motion vector processing and added a hotfix for retrieving semantic images from the TiledCamera
  • WebRTC support: Added IP specification for live-streaming

Full Changelog: https://github.com/isaac-sim/IsaacLab/compare/v2.0.1...v2.0.2

✨ New Features

🔧 Improvements

🐛 Bug Fixes

💔 Breaking Changes

✈️ Migration Guide

[!WARNING]
We strongly recommend reviewing the details to fully understand the change in behavior, as it may impact the deployment of learned policies. Please open an issue on GitHub if you face any problems.

Introduction of simulation's effort and velocity limits parameters in ActuatorBaseCfg

Related MRs: https://github.com/isaac-sim/IsaacLab/pull/1654, https://github.com/isaac-sim/IsaacLab/pull/1873

Details We have introduced the configuration variables `velocity_limit_sim` and `effort_limit_sim` to the `isaaclab.actuators.ActuatorBaseCfg` to allow users to set the **simulation** joint velocity and effort limits through the actuator configuration class. Previously, we were overusing the attributes `velocity_limit` and `effort_limit` inside the actuator configuration. A series of changes in-between led to a regression from v1.4.0 to v2.0.1 release of IsaacLab. To make this clearer to understand, we note the change in their behavior in a tabular form: Actuator Type | Attribute | v1.4.0 Behavior | v2.0.1 Behavior -- | -- | -- | -- Implicit | `velocity_limit` | Ignored, not set into simulation | Set into simulation Implicit | `effort_limit` | Set into simulation | Set into simulation Explicit | `velocity_limit` | Used by actuator models (e.g., DC Motor), not set into simulation | Used by actuator models (e.g., DC Motor), set into simulation Explicit | `effort_limit` | Used by actuator models, not set into simulation | Used by actuator models, set into simulation Setting the limits from the configuration into the simulation directly affects the behavior of the underlying physics engine solver. This impact is particularly noticeable when velocity limits are too restrictive, especially in joints with high stiffness, where it becomes easier to reach these limits. As a result, the change in behavior caused previously trained policies to not function correctly in IsaacLab v2.0.1. Consequently, we have reverted back to the prior behavior and added `velocity_limit_sim` and `effort_limit_sim` attributes to make it clear that setting those parameters means changing solver's configuration. The new behavior is as follows: Attribute | Implicit Actuator | Explicit Actuator -- | -- | -- `velocity_limit` | Ignored, not set into simulation | Used by the model (e.g., DC Motor), not set into simulation `effort_limit` | Set into simulation (same as `effort_limit_sim`) | Used by the models, not set into simulation `velocity_limit_sim` | Set into simulation | Set into simulation `effort_limit_sim` | Set into simulation (same as `effort_limit`) | Set into simulation Users are advised to use the `xxx_sim` flag if they want to directly modify the solver limits.

Removal of disable_contact_processing flag in SimulationCfg

Related MRs: https://github.com/isaac-sim/IsaacLab/pull/1861

Details We have now removed the `disable_contact_processing` flag from the `SimulationCfg` to not have the user worry about these intricacies of the simulator. The flag is always True by default unless a contact sensor is created (which will internally set this flag to False). Previously, the flag `disable_contact_processing` led to confusion about its behavior. As the name suggests, the flag controls the contact reporting from the underlying physics engine, PhysX. Disabling this flag (note the double negation) means that PhysX collects the contact information from its solver and allows reporting them to the user. Enabling this flag means this operation is not performed and the overhead of it is avoided. Many of our examples (for instance, the locomotion environments) were setting this flag to True which meant the contacts should **not** get reported. However, this issue was not noticed earlier since GPU simulation bypasses this flag, and only CPU simulation gets affected. Running the same examples on CPU device led to different behaviors because of this reason. Existing users, who currently set this flag themselves, should receive a deprecated warning mentioning the removal of this flag and the switch to the new default behavior.

Switch to older rendering settings to improve render quality

Related MRs: https://github.com/isaac-sim/IsaacLab/pull/1855

Details With the IsaacLab 2.0.0 release, we switched to new render settings aimed at improving tiled-rendering performance, but at the cost of reduced rendering quality. This change particularly affected dome lighting in the scene, which is the default in many of our examples. As reported by several users, this change negatively impacted render quality, even in cases where it wasn’t necessary (such as when recording videos of the simulation). In response to this feedback, we have reverted to the previous render settings by default to restore the quality users expected. For users who are looking to trade render quality for speed, we will provide guidelines in the future.

🤗 New Contributors

Source: README.md, updated 2025-03-05