update

Author: glvov-bdai

CONTRIBUTORS.md

@@ -31,10 +31,9 @@ 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 available in the `environments <source/overview/environments>`_ section.
+and navigation tasks. A complete list is in 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/simple_agents
+   source/overview/basic_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,10 +10,13 @@ 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``.
 
-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``.
+.. 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``.
+
 
 As a result, training with hydra arguments can be run with the following syntax:
 
@@ -57,6 +60,33 @@ 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
 -----------------------------
@@ -97,33 +127,3 @@ 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/core-concepts/motion_generators.rst renamed to docs/source/features/motion_generators.rst

@@ -31,7 +31,7 @@ The list of environments available registered with OpenAI Gym can be found by ru
 Dummy agents
 ~~~~~~~~~~~~
 
-These include dummy agents that output zero or random agents. They are
+These include basic 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/overview/simple_agents.rst renamed to docs/source/overview/basic_agents.rst

@@ -1,6 +1,3 @@
-Application Development
-=======================
-
 Extensions
 ~~~~~~~~~~
 
@@ -11,7 +8,9 @@ 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>`__.
 
-Each extension in Isaac Lab is written as a python package and follows the following structure:
+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:
 
 .. code:: bash
 
@@ -80,8 +79,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.
 
-Custom Extension Dependency Management
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+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/>`__
@@ -130,15 +129,12 @@ 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.
-
-The following snippet shows how to write a standalone application:
+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.
 
 .. code:: python
 
@@ -169,8 +165,14 @@ The following snippet shows how to write a standalone application:
       simulation_app.close()
 
 
-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.
+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.

docs/source/overview/developer-guide/development.rst renamed to docs/source/overview/developer-guide/extensions.rst

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

docs/source/overview/developer-guide/index.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,7 +16,6 @@ The Isaac Lab repository is structured as follows:
    ├── pyproject.toml
    ├── README.md
    ├── docs
-   ├── docker
    ├── source
    │   ├── extensions
    │   │   ├── omni.isaac.lab
@@ -28,43 +27,9 @@ 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>`__.
-
-
-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.
+These are described in the following sections.

docs/source/overview/developer-guide/repo_structure.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 ``IsaacLab`` directory on Visual Studio Code IDE
+1. Open the ``Isaac Lab`` 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.