Updates task workflow and other documentation pages (#255)

## Checklist

- [X] I have run the [`pre-commit` checks](https://pre-commit.com/) with
`./isaaclab.sh --format`
- [X] I have made corresponding changes to the documentation
- [X] My changes generate no new warnings
- [X] I have added tests that prove my fix is effective or that my
feature works
- [X] I have updated the changelog and the corresponding version in the
extension's `config/extension.toml` file
- [X] I have added my name to the `CONTRIBUTORS.md` or my name already
exists there

---------
Signed-off-by: Michael Gussert <michael@gussert.com>
Signed-off-by: Kelly Guo <kellyguo123@hotmail.com>
Co-authored-by: Kelly Guo <kellyg@nvidia.com>

docs/index.rst

-Overview
-========
+Welcome to Isaac Lab!
+==========================
 
 .. figure:: source/_static/isaaclab.jpg
    :width: 100%
    :alt: H1 Humanoid example using Isaac Lab
 
 **Isaac Lab** is a unified and modular framework for robot learning that aims to simplify common workflows
-in robotics research (such as reinforcement learning, learning from demonstrations, and motion planning). It is built upon
-`NVIDIA Isaac Sim`_ to leverage the latest simulation capabilities for photo-realistic scenes as well as fast
+in robotics research (such as reinforcement learning, learning from demonstrations, and motion planning). It is built on
+`NVIDIA Isaac Sim`_ to leverage the latest simulation capabilities for photo-realistic scenes, and fast
 and efficient simulation.
 
 The core objectives of the framework are:
@@ -15,7 +15,7 @@ The core objectives of the framework are:
 - **Modularity**: Easily customize and add new environments, robots, and sensors.
 - **Agility**: Adapt to the changing needs of the community.
 - **Openness**: Remain open-sourced to allow the community to contribute and extend the framework.
-- **Battery-included**: Include a number of environments, sensors, and tasks that are ready to use.
+- **Batteries-included**: Include a number of environments, sensors, and tasks that are ready to use.
 
 Key features available in Isaac Lab include fast and accurate physics simulation provided by PhysX,
 tiled rendering APIs for vectorized rendering, domain randomization for improving robustness and adaptability,
@@ -25,8 +25,7 @@ Additionally, Isaac Lab provides a variety of environments, and we are actively
 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.
 
-The framework also includes a collection robots. If you are looking to add a new robot, please refer to the
-:ref:`how-to` section. The current list of robots includes:
+Isaac lab is developed with specific robot assets that are now **Batteries-included** as part of the platform and are ready to learn! These robots include...
 
 - **Classic** Cartpole, Humanoid, Ant
 - **Fixed-Arm and Hands**: UR10, Franka, Allegro, Shadow Hand
@@ -34,6 +33,9 @@ The framework also includes a collection robots. If you are looking to add a new
 - **Humanoids**: Unitree H1, Unitree G1
 - **Quadcopter**: Crazyflie
 
+The platform is also designed so that you can add your own robots! please refer to the
+:ref:`how-to` section for details.
+
 For more information about the framework, please refer to the `paper <https://arxiv.org/abs/2301.04195>`_
 :cite:`mittal2023orbit`. For clarifications on NVIDIA Isaac ecosystem, please check out the
 :doc:`/source/setup/faq` section.

docs/source/deployment/docker.rst

@@ -210,7 +210,7 @@ To view the contents of these volumes, you can use the following command:
 Isaac Lab Image Extensions
 --------------------------
 
-The produced image depends upon the arguments passed to ``container.py start`` and ``container.py stop``. These
+The produced image depends on the arguments passed to ``container.py start`` and ``container.py stop``. These
 commands accept an image extension parameter as an additional argument. If no argument is passed, then this
 parameter defaults to ``base``. Currently, the only valid values are (``base``, ``ros2``).
 Only one image extension can be passed at a time. The produced container will be named ``isaac-lab-${profile}``,

docs/source/deployment/run_docker_example.rst

@@ -22,7 +22,7 @@ To build the Isaac Lab container from the root of the Isaac Lab repository, we w
 
 
 The terminal will first pull the base IsaacSim image, build the Isaac Lab image's additional layers on top of it, and run the Isaac Lab container.
-This should take several minutes upon the first build but will be shorter in subsequent runs as Docker's caching prevents repeated work.
+This should take several minutes for the first build but will be shorter in subsequent runs as Docker's caching prevents repeated work.
 If we run the command ``docker container ls`` on the terminal, the output will list the containers that are running on the system. If
 everything has been set up correctly, a container with the ``NAME`` **isaac-lab-base** should appear, similar to below:
 

docs/source/overview/core-concepts/task_workflows.rst

@@ -6,23 +6,15 @@ Task Design Workflows
 
 .. currentmodule:: isaaclab
 
-Environments define the interface between the agent and the simulation. In the simplest case, the environment provides
-the agent with the current observations and executes the actions provided by the agent. In a Markov Decision Process
-(MDP) formulation, the environment can also provide additional information such as the current reward, done flag, and
-information about the current episode.
+A **Task** is defined by an environment with specific interfaces for observations to and actions from a specific agent (robot). The environment is what provides an agent with the current observations and executes that agent's actions by updating the simulation forward in time. There are many common components of simulating a robot in an environment, regardless of what you might want that robot to do or how it might be trained to do it.
 
-While the environment interface is simple to understand, its implementation can vary significantly depending on the
-complexity of the task. In the context of reinforcement learning (RL), the environment implementation can be broken down
-into several components, such as the reward function, observation function, termination function, and reset function.
-Each of these components can be implemented in different ways depending on the complexity of the task and the desired
-level of modularity.
-
-We provide two different workflows for designing environments with the framework:
+This is especially true of Reinforcement Learning (RL), where managing the actions, observations, rewards, etc... across a vectorized GPU simulation can be daunting to even think about! To meet this need, Isaac Lab provides the ability to build your RL environments within our **Manager-based** system, allowing you to trust various minutia of the appropriate manager classes. However, we also recognize the need to exert granular control over an environment, especially during development. For this need, we also provide a **Direct** interface into the simulation, giving you full control!
 
 * **Manager-based**: The environment is decomposed into individual components (or managers) that handle different
   aspects of the environment (such as computing observations, applying actions, and applying randomization). The
   user defines configuration classes for each component and the environment is responsible for coordinating the
   managers and calling their functions.
+
 * **Direct**: The user defines a single class that implements the entire environment directly without the need for
   separate managers. This class is responsible for computing observations, applying actions, and computing rewards.
 
@@ -36,13 +28,6 @@ or when implementing complex logic that is difficult to decompose into separate
 Manager-Based Environments
 --------------------------
 
-A majority of environment implementations follow a similar structure. The environment processes the input actions,
-steps through the simulation, computes observations and reward signals, applies randomization, and resets the terminated
-environments. Motivated by this, the environment can be decomposed into individual components that handle each of these tasks.
-For example, the observation manager is responsible for computing the observations, the reward manager is responsible for
-computing the rewards, and the termination manager is responsible for computing the termination signal. This approach
-is known as the manager-based environment design in the framework.
-
 .. image:: ../../_static/task-workflows/manager-based-light.svg
     :class: only-light
     :align: center
@@ -53,22 +38,12 @@ is known as the manager-based environment design in the framework.
     :align: center
     :alt: Manager-based Task Workflow
 
-Manager-based environments promote modular implementations of tasks by decomposing the task into individual
-components that are managed by separate classes. Each component of the task, such as rewards, observations,
-termination can all be specified as individual configuration classes that are then passed to the corresponding
-manager classes. The manager is then responsible for parsing the configurations and processing the contents specified
-in its configuration.
+Manager-based environments promote modular implementations of tasks by decomposing it into individually managed components. Each component of the task, such as calculating rewards, observations, etc... can be specified as configurations for a corresponding manager. These managers define configurable functions that are responsible for executing the specific computations as needed. Coordinating a collection of different managers is handled by an Environment class that inherits from :class:`envs.ManagerBasedEnv`. Configurations likewise must all inherit from :class:`envs.ManagerBasedEnvCfg`.
 
-The coordination between the different managers is orchestrated by the class :class:`envs.ManagerBasedRLEnv`.
-It takes in a task configuration class instance (:class:`envs.ManagerBasedRLEnvCfg`) that contains the configurations
-for each of the components of the task. Based on the configurations, the scene is set up and the task is initialized.
-Afterwards, while stepping through the environment, all the managers are called sequentially to perform the necessary
-operations.
+When developing new training environments, it is often beneficial to break the environment into independent components.  This can be highly effective for collaboration, as it lets individual developers focus on different aspects of the environment, while allowing those disparate efforts to be joined back together into a single runnable task. For example, you may have multiple robots with differing sensoriums, requiring different observation managers to process those sensory data into a form that's useful for downstream components.  You might have multiple members on the team with different ideas about what the reward should be to achieve your goals, and by having each one develop their own reward manager, you can swap and test as you see fit. The modular nature of the manager workflow is essential for more complex projects!
 
-For their own tasks, we expect the user to mainly define the task configuration class and use the existing
-:class:`envs.ManagerBasedRLEnv` class for the task implementation. The task configuration class should inherit from
-the base class :class:`envs.ManagerBasedRLEnvCfg` and contain variables assigned to various configuration classes
-for each component (such as the ``ObservationCfg`` and ``RewardCfg``).
+For reinforcement learning, much of this has been done for you already! In most cases, it will be enough to write your environment to inherit from
+:class:`envs.ManagerBasedRLEnv` and and your configuration from :class:`envs.ManagerBasedRLEnvCfg`.
 
 .. dropdown:: Example for defining the reward function for the Cartpole task using the manager-style
     :icon: plus
@@ -82,13 +57,6 @@ for each component (such as the ``ObservationCfg`` and ``RewardCfg``).
         :language: python
         :pyobject: RewardsCfg
 
-
-Through this approach, it is possible to easily vary the implementations of the task by switching some components
-while leaving the remaining of the code intact. This flexibility is desirable when prototyping the environment and
-experimenting with different configurations. It also allows for easy collaborating with others on implementing an
-environment, since contributors may choose to use different combinations of configurations for their own task
-specifications.
-
 .. seealso::
 
     We provide a more detailed tutorial for setting up an environment using the manager-based workflow at
@@ -98,12 +66,6 @@ specifications.
 Direct Environments
 -------------------
 
-The direct-style environment aligns more closely with traditional implementations of environments,
-where a single script directly implements the reward function, observation function, resets, and all the other components
-of the environment. This approach does not require the manager classes. Instead, users are provided the complete freedom
-to implement their task through the APIs from the base classes :class:`envs.DirectRLEnv` or :class:`envs.DirectMARLEnv`.
-For users migrating from the `IsaacGymEnvs`_ and `OmniIsaacGymEnvs`_ framework, this workflow may be more familiar.
-
 .. image:: ../../_static/task-workflows/direct-based-light.svg
     :class: only-light
     :align: center
@@ -114,11 +76,12 @@ For users migrating from the `IsaacGymEnvs`_ and `OmniIsaacGymEnvs`_ framework,
     :align: center
     :alt: Direct-based Task Workflow
 
-When defining an environment with the direct-style implementation, we expect the user define a single class that
-implements the entire environment. The task class should inherit from the base classes :class:`envs.DirectRLEnv` or
-:class:`envs.DirectMARLEnv` and should have its corresponding configuration class that inherits from
-:class:`envs.DirectRLEnvCfg` or :class:`envs.DirectMARLEnvCfg` respectively. The task class is responsible
-for setting up the scene, processing the actions, computing the rewards, observations, resets, and termination signals.
+The direct-style environment aligns more closely with traditional implementations of environments from other libraries.
+A single class implements the reward function, observation function, resets, and all the other components
+of the environment. This approach does not require the manager classes. Instead, users are provided the complete freedom
+to implement their task through the APIs of either :class:`envs.DirectRLEnv` or :class:`envs.DirectMARLEnv`. All direct task environments must inherit from one of these two classes.
+Direct environments still require configurations to be defined, specifically by inheriting from either :class:`envs.DirectRLEnvCfg` or :class:`envs.DirectMARLEnvCfg`.
+This workflow may be the most familiar for users migrating from the `IsaacGymEnvs`_ and `OmniIsaacGymEnvs`_ frameworks.
 
 .. dropdown:: Example for defining the reward function for the Cartpole task using the direct-style
     :icon: plus

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

-Application Development
+Extension Development
 =======================
 
-Extensions
-~~~~~~~~~~
-
-Extensions are the recommended way to develop applications in Isaac Sim. They are
-modularized packages that formulate the Omniverse ecosystem. Each extension
+Everything in Omniverse is either an extension, or a collection of extensions (an application). They are
+modularized packages that form the atoms of the Omniverse ecosystem. Each extension
 provides a set of functionalities that can be used by other extensions or
 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
@@ -30,7 +27,7 @@ Each extension in Isaac Lab is written as a python package and follows the follo
 
 The ``config/extension.toml`` file contains the metadata of the extension. This
 includes the name, version, description, dependencies, etc. This information is used
-by Omniverse to load the extension. The ``docs`` directory contains the documentation
+by the Omniverse API to load the extension. The ``docs`` directory contains the documentation
 for the extension with more detailed information about the extension and a CHANGELOG
 file that contains the changes made to the extension in each version.
 
@@ -83,11 +80,11 @@ standalone applications.
 Custom Extension Dependency Management
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Certain extensions may have dependencies which require installation of additional packages before the extension
+Certain extensions may have dependencies which require the installation of additional packages before the extension
 can be used. While Python dependencies are handled by the `setuptools <https://setuptools.readthedocs.io/en/latest/>`__
 package and specified in the ``setup.py`` file, non-Python dependencies such as `ROS <https://www.ros.org/>`__
 packages or `apt <https://en.wikipedia.org/wiki/APT_(software)>`__ packages are not handled by setuptools.
-To handle these dependencies, we have created an additional setup procedure described in the next section.
+Handling these kinds of dependencies requires an additional procedure.
 
 There are two types of dependencies that can be specified in the ``extension.toml`` file
 under the ``isaac_lab_settings`` section:
@@ -128,15 +125,14 @@ To install all dependencies for all extensions, run the following command:
 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.
+In a typical Omniverse workflow, the simulator is launched first and then the extensions are
+enabled. The loading of python modules and other python applications happens automagically, under the hood, and while this is the recommended
+workflow, it is not always possible.
 
-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:`~isaaclab.app.AppLauncher` and allows complete control over the simulation through
-the :class:`~isaaclab.sim.SimulationContext` class.
+For example, consider robot reinforcement learning. It is essential to have complete control over the simulation step
+and when things update instead of asynchronously waiting for the result. In
+such cases, we require direct control of the simulation, and so it is necessary to write a standalone application. These applications are functionally similar in that they launch the simulator using the :class:`~omni.isaac.lab.app.AppLauncher` and
+then control the simulation directly through the :class:`~omni.isaac.lab.sim.SimulationContext`. In these cases, python modules from extensions **must** be imported after the app is launched.  Doing so before the app is launched will cause missing module errors.
 
 The following snippet shows how to write a standalone application:
 
@@ -171,6 +167,4 @@ The following snippet shows how to write a standalone application:
 
 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:~isaaclab.app.AppLauncher class to start the simulator. After that,
-the :class:~isaaclab.sim.SimulationContext class can be used to control the simulation. For further
-details, we recommend exploring the Isaac Lab tutorials.
+For further details, we recommend exploring the Isaac Lab :ref:`tutorials`.

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

@@ -10,7 +10,7 @@ using VSCode.
 .. toctree::
   :maxdepth: 1
 
-  vs_code
+  VS Code <vs_code>
   repo_structure
   development
   template

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

 Repository organization
 -----------------------
 
-The Isaac Lab repository is structured as follows:
-
 .. code-block:: bash
 
    IsaacLab
@@ -34,19 +32,12 @@ The Isaac Lab repository is structured as follows:
    ├── tools
    └── VERSION
 
-The ``source`` directory contains the source code for all Isaac Lab *extensions*
-and the ``scripts`` directory contains the source code for all *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>`__.
-
+Isaac Lab is built on the same back end as Isaac Sim.  As such, it exists as a collection of **extensions** that can be assembled into **applications**. The ``source`` directory contains the majority of the code in the repository and the specific extensions that compose Isaac lab, while ``scripts`` containing python scripts for launching customized standalone apps (Like our workflows). These are the two primary ways of interacting with the simulation and Isaac lab supports both! Checkout this `Isaac Sim introduction to workflows <https://docs.omniverse.nvidia.com/isaacsim/latest/introductory_tutorials/tutorial_intro_workflows.html>`__ for more details.
 
 Extensions
 ~~~~~~~~~~
 
-Extensions are modularized packages that formulate the Omniverse ecosystem. In Isaac Lab, these are written
-into the ``source`` 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 that compose Isaac Lab are kept in the ``source`` directory. To simplify the build process, Isaac Lab directly use `setuptools <https://setuptools.readthedocs.io/en/latest/>`__. It is strongly recommend that you adhere to this process if you create your own extensions using Isaac Lab.
 
 The extensions are organized as follows:
 

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

 Setting up Visual Studio Code
 -----------------------------
 
-The following is only applicable for Isaac Sim installed from binary.
-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:
+**This is optional.  You do not need to use VScode to use Isaac Lab**
+
+`Visual Studio Code <https://code.visualstudio.com/>`_ has proven an invaluable tool for the development of Isaac Lab. The Isaac Lab repository includes the VSCode files for setting up your development environment. These are included in the ``.vscode`` directory and include the following files:
 
 .. code-block:: bash
 
@@ -31,6 +30,11 @@ To setup the IDE, please follow these instructions:
       :align: center
       :alt: VSCode Tasks
 
+
+.. note::
+   If this is your first time running tasks in VS Code, you may be prompted to select how to handle warnings. Simply follow
+   the prompts until the task window closes.
+
 If everything executes correctly, it should create the following files:
 
 * ``.vscode/launch.json``: Contains the launch configurations for debugging python code.

docs/source/setup/installation/binaries_installation.rst

@@ -289,10 +289,8 @@ behaves like a python executable, and can be used to run any python script or
 module with the simulator. For more information, please refer to the
 `documentation <https://docs.omniverse.nvidia.com/isaacsim/latest/manual_standalone_python.html#isaac-sim-python-environment>`__.
 
-Although using a virtual environment is optional, we recommend using ``conda``. To install
-``conda``, please follow the instructions `here <https://docs.conda.io/projects/conda/en/latest/user-guide/install/index.html>`__.
-In case you want to use ``conda`` to create a virtual environment, you can
-use the following command:
+To install ``conda``, please follow the instructions `here <https://docs.conda.io/projects/conda/en/latest/user-guide/install/index.html>`__.
+You can create the Isaac Lab environment using the following commands.
 
 .. tab-set::
    :sync-group: os
@@ -318,8 +316,7 @@ use the following command:
          isaaclab.bat --conda my_env  :: or "isaaclab.bat -c my_env"
 
 
-If you are using ``conda`` to create a virtual environment, make sure to
-activate the environment before running any scripts. For example:
+Once created, be sure to activate the environment before proceeding!
 
 .. code:: bash
 
@@ -432,3 +429,51 @@ On Windows machines, please terminate the process from Command Prompt using
 
 
 If you see this, then the installation was successful! |:tada:|
+
+Train a robot!
+~~~~~~~~~~~~~~~
+
+You can now use Isaac Lab to train a robot through Reinforcement Learning! The quickest way to use Isaac Lab is through the predefined workflows using one of our **Batteries-included** robot tasks. Execute the following command to quickly train an ant to walk!
+
+.. tab-set::
+   :sync-group: os
+
+   .. tab-item:: :icon:`fa-brands fa-linux` Linux
+      :sync: linux
+
+      .. code:: bash
+
+         ./isaaclab.sh -p source/standalone/workflows/rsl_rl/train.py --task=Isaac-Ant-v0
+
+   .. tab-item:: :icon:`fa-brands fa-windows` Windows
+      :sync: windows
+
+      .. code:: batch
+
+         isaaclab.bat -p source/standalone/workflows/rsl_rl/train.py --task=Isaac-Ant-v0
+
+... Or a robot dog!
+
+.. tab-set::
+   :sync-group: os
+
+   .. tab-item:: :icon:`fa-brands fa-linux` Linux
+      :sync: linux
+
+      .. code:: bash
+
+         ./isaaclab.sh -p source/standalone/workflows/rsl_rl/train.py --task=Isaac-Velocity-Rough-Anymal-C-v0
+
+   .. tab-item:: :icon:`fa-brands fa-windows` Windows
+      :sync: windows
+
+      .. code:: batch
+
+         isaaclab.bat -p source/standalone/workflows/rsl_rl/train.py --task=Isaac-Velocity-Rough-Anymal-C-v0
+
+Isaac Lab provides the tools you'll need to create your own **Tasks** and **Workflows** for whatever your project needs may be. Take a look at our :ref:`how-to` guides like `Adding your own learning Library <source/how-to/add_own_library>`_ or `Wrapping Environments <source/how-to/wrap_rl_env>`_ for details.
+
+.. figure:: ../../_static/setup/shadow_hands_example.jpg
+    :align: center
+    :figwidth: 100%
+    :alt: Idle hands...

docs/source/setup/installation/pip_installation.rst

@@ -340,3 +340,51 @@ On Windows machines, please terminate the process from Command Prompt using
 
 
 If you see this, then the installation was successful! |:tada:|
+
+Train a robot!
+~~~~~~~~~~~~~~~
+
+You can now use Isaac Lab to train a robot through Reinforcement Learning! The quickest way to use Isaac Lab is through the predefined workflows using one of our **Batteries-included** robot tasks. Execute the following command to quickly train an ant to walk!
+
+.. tab-set::
+   :sync-group: os
+
+   .. tab-item:: :icon:`fa-brands fa-linux` Linux
+      :sync: linux
+
+      .. code:: bash
+
+         ./isaaclab.sh -p source/standalone/workflows/rsl_rl/train.py --task=Isaac-Repose-Cube-Shadow-Vision-Direct-v0 --enable_cameras
+
+   .. tab-item:: :icon:`fa-brands fa-windows` Windows
+      :sync: windows
+
+      .. code:: batch
+
+         isaaclab.bat -p source/standalone/workflows/rsl_rl/train.py --task=Isaac-Repose-Cube-Shadow-Vision-Direct-v0 --enable_cameras
+
+... Or a robot dog!
+
+.. tab-set::
+   :sync-group: os
+
+   .. tab-item:: :icon:`fa-brands fa-linux` Linux
+      :sync: linux
+
+      .. code:: bash
+
+         ./isaaclab.sh -p source/standalone/workflows/rsl_rl/train.py --task=Isaac-Velocity-Rough-Anymal-C-v0
+
+   .. tab-item:: :icon:`fa-brands fa-windows` Windows
+      :sync: windows
+
+      .. code:: batch
+
+         isaaclab.bat -p source/standalone/workflows/rsl_rl/train.py --task=Isaac-Velocity-Rough-Anymal-C-v0
+
+Isaac Lab provides the tools you'll need to create your own **Tasks** and **Workflows** for whatever your project needs may be. Take a look at our :ref:`how-to` guides like `Adding your own learning Library <source/how-to/add_own_library>`_ or `Wrapping Environments <source/how-to/wrap_rl_env>`_ for details.
+
+.. figure:: ../../_static/setup/shadow_hands_example.jpg
+    :align: center
+    :figwidth: 100%
+    :alt: Idle hands...

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

@@ -7,7 +7,7 @@ Spawning prims into the scene
 .. currentmodule:: isaaclab
 
 This tutorial explores how to spawn various objects (or prims) into the scene in Isaac Lab from Python.
-It builds upon the previous tutorial on running the simulator from a standalone script and
+It builds on the previous tutorial on running the simulator from a standalone script and
 demonstrates how to spawn a ground plane, lights, primitive shapes, and meshes from USD files.
 
 

docs/source/tutorials/index.rst

+.. _tutorials:
+
 Tutorials
 =========