CONTRIBUTORS.md

@@ -31,9 +31,10 @@ Guidelines for modifications:
 
 ## Contributors
 
-* Anton Bjørndahl Mortensen
 * Alice Zhou
+* Amr Mousa
 * Andrej Orsula
+* Anton Bjørndahl Mortensen
 * Antonio Serrano-Muñoz
 * Arjun Bhardwaj
 * Brayden Zhang

docs/index.rst

@@ -23,7 +23,7 @@ and support for running in the cloud.
 
 Additionally, Isaac Lab provides over 26 environments, and we are actively working on adding more environments
 to the list. These include classic control tasks, fixed-arm and dexterous manipulation tasks, legged locomotion tasks,
-and navigation tasks. A complete list is in available in the `environments <source/overview/environments>`_ section.
+and navigation tasks. A complete list is available in the `environments <source/overview/environments>`_ section.
 
 The framework also includes over 16 robots. If you are looking to add a new robot, please refer to the
 :ref:`how-to` section. The current list of robots includes:
@@ -88,7 +88,7 @@ Table of Contents
    source/overview/reinforcement-learning/index
    source/overview/teleop_imitation
    source/overview/showroom
-   source/overview/basic_agents
+   source/overview/simple_agents
 
 .. toctree::
    :maxdepth: 2

docs/source/deployment/run_docker_example.rst

@@ -1,7 +1,7 @@
 Running an example with Docker
 ==============================
 
-From the root of the ``Isaac Lab`` repository,  the ``docker`` directory contains all the Docker relevant files. These include the three files
+From the root of the Isaac Lab repository,  the ``docker`` directory contains all the Docker relevant files. These include the three files
 (**Dockerfile**, **docker-compose.yaml**, **.env**) which are used by Docker, and an additional script that we use to interface with them,
 **container.py**.
 

docs/source/features/hydra.rst

@@ -10,13 +10,10 @@ Any parameter of the environment can be modified by adding one or multiple eleme
 to the command line input, where ``a.b.param1`` reflects the parameter's hierarchy, for example ``env.actions.joint_effort.scale=10.0``.
 Similarly, the agent's parameters can be modified by using the ``agent`` prefix, for example ``agent.seed=2024``.
 
-.. note::
-
-    The way these command line arguments are set follow the exact structure of the configuration files. Since the different
-    RL frameworks use different conventions, there might be differences in the way the parameters are set. For example,
-    with `rl_games` the seed will be set with ``agent.params.seed``, while with `rsl_rl`, `skrl` and `sb3` it will be set with
-    ``agent.seed``.
-
+The way these command line arguments are set follow the exact structure of the configuration files. Since the different
+RL frameworks use different conventions, there might be differences in the way the parameters are set. For example,
+with *rl_games* the seed will be set with ``agent.params.seed``, while with *rsl_rl*, *skrl* and *sb3* it will be set with
+``agent.seed``.
 
 As a result, training with hydra arguments can be run with the following syntax:
 
@@ -60,33 +57,6 @@ The above command will run the training script with the task ``Isaac-Cartpole-v0
     of the form ``--param``, for example ``--num_envs``, ``--seed``, ``--max_iterations``. These arguments have precedence
     over the hydra arguments, and will overwrite the values set by the hydra arguments.
 
-.. attention::
-
-    Particular care should be taken when modifying the parameters using command line arguments. Some of the configurations
-    perform intermediate computations based on other parameters. These computations will not be updated when the parameters
-    are modified.
-
-    For example, for the configuration of the Cartpole camera depth environment:
-
-    .. literalinclude:: ../../../source/extensions/omni.isaac.lab_tasks/omni/isaac/lab_tasks/direct/cartpole/cartpole_camera_env.py
-        :language: python
-        :start-at: class CartpoleDepthCameraEnvCfg
-        :end-at: tiled_camera.width
-        :emphasize-lines: 16
-
-    If the user were to modify the width of the camera, i.e. ``env.tiled_camera.width=128``, then the parameter
-    ``env.num_observations=10240`` (1*80*128) must be updated and given as input as well.
-
-    Similarly, the ``__post_init__`` method is not updated with the command line inputs. In the ``LocomotionVelocityRoughEnvCfg``, for example,
-    the post init update is as follows:
-
-    .. literalinclude:: ../../../source/extensions/omni.isaac.lab_tasks/omni/isaac/lab_tasks/manager_based/locomotion/velocity/velocity_env_cfg.py
-        :language: python
-        :start-at: class LocomotionVelocityRoughEnvCfg
-        :emphasize-lines: 23, 29, 31
-
-    Here, when modifying ``env.decimation`` or ``env.sim.dt``, the user would have to give the updated ``env.sim.render_interval``,
-    ``env.scene.height_scanner.update_period``, and ``env.scene.contact_forces.update_period`` as input as well.
 
 Modifying advanced parameters
 -----------------------------
@@ -127,3 +97,33 @@ This example shows two noteworthy points:
 
 - The parameter we set has a space, so it must be enclosed in quotes.
 - The parameter is a list while it is a tuple in the config. This is due to the fact that Hydra does not support tuples.
+
+
+Modifying inter-dependent parameters
+------------------------------------
+
+Particular care should be taken when modifying the parameters using command line arguments. Some of the configurations
+perform intermediate computations based on other parameters. These computations will not be updated when the parameters
+are modified.
+
+For example, for the configuration of the Cartpole camera depth environment:
+
+.. literalinclude:: ../../../source/extensions/omni.isaac.lab_tasks/omni/isaac/lab_tasks/direct/cartpole/cartpole_camera_env.py
+    :language: python
+    :start-at: class CartpoleDepthCameraEnvCfg
+    :end-at: tiled_camera.width
+    :emphasize-lines: 16
+
+If the user were to modify the width of the camera, i.e. ``env.tiled_camera.width=128``, then the parameter
+``env.num_observations=10240`` (1*80*128) must be updated and given as input as well.
+
+Similarly, the ``__post_init__`` method is not updated with the command line inputs. In the ``LocomotionVelocityRoughEnvCfg``, for example,
+the post init update is as follows:
+
+.. literalinclude:: ../../../source/extensions/omni.isaac.lab_tasks/omni/isaac/lab_tasks/manager_based/locomotion/velocity/velocity_env_cfg.py
+    :language: python
+    :start-at: class LocomotionVelocityRoughEnvCfg
+    :emphasize-lines: 23, 29, 31
+
+Here, when modifying ``env.decimation`` or ``env.sim.dt``, the user needs to give the updated ``env.sim.render_interval``,
+``env.scene.height_scanner.update_period``, and ``env.scene.contact_forces.update_period`` as input as well.

docs/source/overview/developer-guide/extensions.rst → docs/source/overview/developer-guide/development.rst

@@ -1,3 +1,6 @@
+Application Development
+=======================
+
 Extensions
 ~~~~~~~~~~
 
@@ -8,9 +11,7 @@ standalone applications. A folder is recognized as an extension if it contains
 an ``extension.toml`` file in the ``config`` directory. More information on extensions can be found in the
 `Omniverse documentation <https://docs.omniverse.nvidia.com/kit/docs/kit-manual/latest/guide/extensions_basic.html>`__.
 
-Isaac Lab in itself provides extensions for robot learning. These are written into the
-``source/extensions`` directory. Each extension is written as a python package and
-follows the following structure:
+Each extension in Isaac Lab is written as a python package and follows the following structure:
 
 .. code:: bash
 
@@ -79,8 +80,8 @@ important to note that Omniverse also provides a similar
 However, it requires going through the build process and does not support testing of the python module in
 standalone applications.
 
-Extension Dependency Management
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Custom Extension Dependency Management
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Certain extensions may have dependencies which require installation of additional packages before the extension
 can be used. While Python dependencies are handled by the `setuptools <https://setuptools.readthedocs.io/en/latest/>`__
@@ -129,12 +130,15 @@ Standalone applications
 
 In a typical Omniverse workflow, the simulator is launched first, after which the extensions are
 enabled that load the python module and run the python application. While this is a recommended
-workflow, it is not always possible to use this workflow. For example, for robot learning, it is
-essential to have complete control over simulation stepping and all the other functionalities
-instead of asynchronously waiting for the simulator to step. In such cases, it is necessary to
-write a standalone application that launches the simulator using :class:`~omni.isaac.lab.app.AppLauncher`
-and allows complete control over the simulation through the :class:`~omni.isaac.lab.sim.SimulationContext`
-class.
+workflow, it is not always possible to use this workflow.
+
+For example, for robot learning, it is essential to have complete control over simulation stepping
+and all the other functionalities instead of asynchronously waiting for the simulator to step. In
+such cases, it is necessary to write a standalone application that launches the simulator using
+:class:`~omni.isaac.lab.app.AppLauncher` and allows complete control over the simulation through
+the :class:`~omni.isaac.lab.sim.SimulationContext` class.
+
+The following snippet shows how to write a standalone application:
 
 .. code:: python
 
@@ -165,14 +169,8 @@ class.
       simulation_app.close()
 
 
-The ``source/standalone`` directory contains various standalone applications designed using the extensions
-provided by ``Isaac Lab``. These applications are written in python and are structured as follows:
-
-* **demos**: Contains various demo applications that showcase the core framework ``omni.isaac.lab``.
-* **environments**: Contains applications for running environments defined in ``omni.isaac.lab_tasks`` with different agents.
-  These include a random policy, zero-action policy, teleoperation or scripted state machines.
-* **tools**: Contains applications for using the tools provided by the framework. These include converting assets, generating
-  datasets, etc.
-* **tutorials**: Contains step-by-step tutorials for using the APIs provided by the framework.
-* **workflows**: Contains applications for using environments with various learning-based frameworks. These include different
-  reinforcement learning or imitation learning libraries.
+It is necessary to launch the simulator before running any other code because extensions are hot-loaded
+when the simulator starts. Many Omniverse modules become available only after the simulator is launched.
+To do this, use the :class:~omni.isaac.lab.app.AppLauncher class to start the simulator. After that,
+the :class:~omni.isaac.lab.sim.SimulationContext class can be used to control the simulation. For further
+details, we recommend exploring the Isaac Lab tutorials.

docs/source/overview/developer-guide/index.rst

@@ -12,5 +12,5 @@ using VSCode.
 
   vs_code
   repo_structure
-  extensions
+  development
   template

docs/source/overview/developer-guide/repo_structure.rst

@@ -1,7 +1,7 @@
 Repository organization
 -----------------------
 
-The ``Isaac Lab`` repository is structured as follows:
+The Isaac Lab repository is structured as follows:
 
 .. code-block:: bash
 
@@ -16,6 +16,7 @@ The ``Isaac Lab`` repository is structured as follows:
    ├── pyproject.toml
    ├── README.md
    ├── docs
+   ├── docker
    ├── source
    │   ├── extensions
    │   │   ├── omni.isaac.lab
@@ -27,9 +28,43 @@ The ``Isaac Lab`` repository is structured as follows:
    │   │   ├── tools
    │   │   ├── tutorials
    │   │   └── workflows
+   ├── tools
    └── VERSION
 
-The ``source`` directory contains the source code for all ``Isaac Lab`` *extensions*
+The ``source`` directory contains the source code for all Isaac Lab *extensions*
 and *standalone applications*. The two are the different development workflows
 supported in `Isaac Sim <https://docs.omniverse.nvidia.com/isaacsim/latest/introductory_tutorials/tutorial_intro_workflows.html>`__.
-These are described in the following sections.
+
+
+Extensions
+~~~~~~~~~~
+
+Extensions are modularized packages that formulate the Omniverse ecosystem. In Isaac Lab. these are written
+into the ``source/extensions`` directory. To simplify the build process, Isaac Lab directly use the
+`setuptools <https://setuptools.readthedocs.io/en/latest/>`__ python package to build the python module
+provided by the extensions. This is done by the ``setup.py`` file in the extension directory.
+
+The extensions are organized as follows:
+
+* **omni.isaac.lab**: Contains the core interface extension for Isaac Lab. This provides the main modules for actuators,
+  objects, robots and sensors.
+* **omni.isaac.lab_assets**: Contains the extension with pre-configured assets for Isaac Lab.
+* **omni.isaac.lab_tasks**: Contains the extension with pre-configured environments for Isaac Lab. It also includes
+  wrappers for using these environments with different agents.
+
+
+Standalone
+~~~~~~~~~~
+
+The ``source/standalone`` directory contains various standalone applications written in python.
+They are structured as follows:
+
+* **benchmarks**: Contains scripts for benchmarking different framework components.
+* **demos**: Contains various demo applications that showcase the core framework :mod:`omni.isaac.lab`.
+* **environments**: Contains applications for running environments defined in :mod:`omni.isaac.lab_tasks` with
+  different agents. These include a random policy, zero-action policy, teleoperation or scripted state machines.
+* **tools**: Contains applications for using the tools provided by the framework. These include converting assets,
+  generating datasets, etc.
+* **tutorials**: Contains step-by-step tutorials for using the APIs provided by the framework.
+* **workflows**: Contains applications for using environments with various learning-based frameworks. These include different
+  reinforcement learning or imitation learning libraries.

docs/source/overview/developer-guide/vs_code.rst

@@ -2,7 +2,7 @@ Setting up Visual Studio Code
 -----------------------------
 
 The following is only applicable for Isaac Sim installed via the Omniverse Launcher.
-The ``Isaac Lab`` repository includes the VSCode settings to easily allow setting
+The Isaac Lab repository includes the VSCode settings to easily allow setting
 up your development environment. These are included in the ``.vscode`` directory
 and include the following files:
 
@@ -21,7 +21,7 @@ and include the following files:
 
 To setup the IDE, please follow these instructions:
 
-1. Open the ``Isaac Lab`` directory on Visual Studio Code IDE
+1. Open the ``IsaacLab`` directory on Visual Studio Code IDE
 2. Run VSCode `Tasks <https://code.visualstudio.com/docs/editor/tasks>`__, by
    pressing ``Ctrl+Shift+P``, selecting ``Tasks: Run Task`` and running the
    ``setup_python_env`` in the drop down menu.

docs/source/overview/environments.rst

@@ -116,7 +116,7 @@ for the reach environment:
     |                    |                         |                                                                             |
     |                    | |cube-shadow-lstm-link| |                                                                             |
     +--------------------+-------------------------+-----------------------------------------------------------------------------+
-    | |cube-shadow|      | |cube-shadow-vis-link|  | In-hand reorientation of a cube using Shadow hand and perceptive inputs     |
+    | |cube-shadow|      | |cube-shadow-vis-link|  | In-hand reorientation of a cube using Shadow hand using perceptive inputs   |
     +--------------------+-------------------------+-----------------------------------------------------------------------------+
 
 .. |reach-franka| image:: ../_static/tasks/manipulation/franka_reach.jpg

docs/source/overview/basic_agents.rst → docs/source/overview/simple_agents.rst

@@ -31,7 +31,7 @@ The list of environments available registered with OpenAI Gym can be found by ru
 Dummy agents
 ~~~~~~~~~~~~
 
-These include basic agents that output zero or random agents. They are
+These include dummy agents that output zero or random agents. They are
 useful to ensure that the environments are configured correctly.
 
 -  Zero-action agent on the Cart-pole example

docs/source/refs/issues.rst

@@ -35,11 +35,17 @@ We have made a feature request to the respective Omniverse teams to have complet
 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
+    :attr:`~omni.isaac.lab.assets.ArticulationData.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 :class:`omni.isaac.lab.sensors.Camera` sensor in standalone scripts, the first few frames
+When using the :class:`~omni.isaac.lab.sensors.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.
 
@@ -79,7 +85,7 @@ When exiting a process with ``Ctrl+C``, occasionally the below error may appear:
 
 .. code-block:: bash
 
-	[Error] [omni.physx.plugin] Subscribtion cannot be changed during the event call.
+	[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

docs/source/setup/installation/pip_installation.rst

@@ -49,9 +49,9 @@ compatibility issues with some Linux distributions. If you encounter any issues,
 
                .. code-block:: bash
 
-                  # create a conda environment named isaaclab with python3.10
+                  # create a virtual environment named isaaclab with python3.10
                   python3.10 -m venv isaaclab
-                  # activate the conda environment
+                  # activate the virtual environment
                   source isaaclab/bin/activate
 
             .. tab-item:: :icon:`fa-brands fa-windows` Windows

docs/source/tutorials/00_sim/launch_app.rst

@@ -153,8 +153,7 @@ Now, let's look at how :class:`~app.AppLauncher` handles conflicting commands:
 
 .. code-block:: console
 
-   export LIVESTREAM=0
-   ./isaaclab.sh -p source/standalone/tutorials/00_sim/launch_app.py --size 0.5 --livestream 1
+   LIVESTREAM=0 ./isaaclab.sh -p source/standalone/tutorials/00_sim/launch_app.py --size 0.5 --livestream 1
 
 This will cause the same behavior as in the previous run, because although we have set ``LIVESTREAM=0``
 in our envars, CLI args such as ``--livestream`` take precedence in determining behavior. The process can
@@ -165,8 +164,7 @@ Finally, we will examine passing arguments to :class:`~omni.isaac.kit.Simulation
 
 .. code-block:: console
 
-   export LIVESTREAM=1
-   ./isaaclab.sh -p source/standalone/tutorials/00_sim/launch_app.py --size 0.5 --width 1920 --height 1080
+   LIVESTREAM=1 ./isaaclab.sh -p source/standalone/tutorials/00_sim/launch_app.py --size 0.5 --width 1920 --height 1080
 
 This will cause the same behavior as before, but now the viewport will be rendered at 1920x1080p resolution.
 This can be useful when we want to gather high-resolution video, or we can specify a lower resolution if we

docs/source/tutorials/03_envs/create_manager_base_env.rst

@@ -196,7 +196,7 @@ right corner of the screen named ``"Isaac Lab"``. This window contains different
 can be used for debugging and visualization.
 
 
-.. figure:: ../../_static/tutorials/tutorial_create_manager_base.jpg
+.. figure:: ../../_static/tutorials/tutorial_create_manager_rl_env.jpg
     :align: center
     :figwidth: 100%
     :alt: result of create_cartpole_base_env.py