Skip to content

Isaac Lab Tasks

Isaac Lab is NVIDIA's unified robot learning framework built on top of Isaac Sim. In this repository, it is the main GPU-accelerated RL backend for manager-based task definitions.

Isaac Lab is not installed as part of LAV2's default Python dependencies, so Isaac Lab must be installed and prepared separately before lav2.tasks.isaaclab can be imported or LAV2 tasks can run inside Isaac Sim.

How LAV2 Connects To Isaac Lab

LAV2 exposes Isaac Lab tasks through lav2.tasks.isaaclab. The typical integration step is to ensure that the target training or play script imports that package in addition to the standard Isaac Lab task registry.

In practice:

  1. Move to the Isaac Lab reinforcement learning scripts directory, such as scripts/reinforcement_learning/.
  2. Ensure the script imports lav2.tasks.isaaclab in addition to isaaclab_tasks.
  3. Run the script with a LAV2 task name such as --task Isaac-LAV2-Base-Direct-v0.

On Linux or macOS, add the import below every import isaaclab_tasks line:

sed -i '/import isaaclab_tasks/a\
import lav2.tasks.isaaclab' $(find scripts/reinforcement_learning/ -name '*.py')

On Windows, use PowerShell:

Get-ChildItem -Path scripts/reinforcement_learning/ -Filter *.py -Recurse | ForEach-Object {
    (Get-Content $_.FullName) -replace 'import isaaclab_tasks', "import isaaclab_tasks`nimport lav2.tasks.isaaclab" | Set-Content $_.FullName
}

If direct script patching is undesirable, create a symlink into the Isaac Lab task package tree so Isaac Lab can see the LAV2 task package.

On Linux or macOS:

ln -s /path/to/lav2/tasks/isaaclab source/isaaclab_tasks/isaaclab_tasks/lav2_tasks

On Windows:

New-Item -ItemType SymbolicLink -Path source\isaaclab_tasks\isaaclab_tasks\lav2_tasks -Target C:\path\to\lav2\tasks\isaaclab

Notes

  • Use the import-based method when the change should stay explicit in the script.
  • Use the symlink-based method when multiple RL entrypoint files should remain untouched.

LAV2 Base Task

The primary entrypoint to understand is lav2.tasks.isaaclab.LAV2_base.LAV2_env_cfg (the LAV2EnvCfg class defined in LAV2_env_cfg.py). This is the repository's manager-based RL environment configuration for the base LAV2 task.

Like Isaac Lab's own manager-based environments, this task is assembled from separate config blocks for scene, actions, observations, events, commands, rewards, and terminations. Once the base manager-based environment layout is understood, the rest of the task package follows the same design language.

Training Workflows

There are two primary ways to train LAV2 Isaac Lab tasks.

This is the standard path for workflows that stay close to Isaac Lab's native RL entrypoints and CLI interface.

Example with skrl:

./isaaclab.sh -p scripts/reinforcement_learning/skrl/train.py --task Isaac-LAV2-Base-v0 --num_envs 4096 --max_iterations 500 --headless

To inspect the available CLI arguments and their meaning:

./isaaclab.sh -p scripts/reinforcement_learning/skrl/train.py --help

This path is specific to LAV2 and targets skrl only. Use it when the repository's custom network architecture and training wiring under lav2.runner.skrl.cfg are required.

Example entrypoint:

uv run python -m lav2.runner.skrl.cfg.LAV2_base

The concrete module behind that example is lav2.runner.skrl.cfg.LAV2_base.

Use the built-in Isaac Lab scripts for compatibility with Isaac Lab's standard workflows. Use the LAV2 skrl entrypoints when the custom network and config organization provided by this repository are specifically required.

Recommended Editing Order

Start from the environment config when changing task semantics. Move to the agent or runner config when changing optimizer behavior, network structure, or experiment wiring. Use CLI overrides for short-lived experiments.

Modifying Training Parameters

For meaningful task tuning, the primary method is to edit the configuration files directly instead of relying only on command-line overrides.

In LAV2's Isaac Lab tasks, the main entrypoint is the environment config file, represented here by:

This follows Isaac Lab's manager-based environment pattern, where the task is assembled from config blocks such as scene, actions, observations, events, commands, rewards, and terminations.

What To Modify In The Env Config

Task-behavior changes should usually start from the environment cfg rather than the training script.

Common places to edit:

  • scene: number of environments, terrain or asset layout, spacing, and scene composition
  • actions: action scaling, action type, command mapping, and clipping
  • observations: which signals are exposed to the policy, grouping, noise, and concatenation behavior
  • commands: command ranges, resampling periods, and target generation logic
  • events: reset randomization, perturbations, startup randomization, and domain randomization hooks
  • rewards: reward terms, weights, thresholds, and shaping structure
  • terminations: timeout, crash, drift, or invalid-state termination logic

This is the same structure Isaac Lab uses in its manager-based RL environment tutorial, where each part of the task is broken into dedicated config classes and then assembled into a single environment config.

Common Examples

Typical edits in practice include:

  • Increasing or decreasing the number of parallel environments
  • Changing reward weights to emphasize tracking, smoothness, or energy use
  • Expanding or narrowing command ranges
  • Adjusting reset randomization and perturbation strength
  • Changing observation composition before changing the network architecture

If a parameter affects task semantics, place it in the environment config. If it affects optimizer or policy training behavior, place it in the agent config.

Modifying Agent And Runner Config

Training-specific parameters usually belong in the agent config rather than the environment config.

For Isaac Lab built-in workflows, these values usually live in the corresponding agent config files under the task package, such as the YAML or Python files in lav2.tasks.isaaclab.LAV2_base.agents and related agent subpackages.

For LAV2's custom skrl path, the main entrypoints live under lav2.runner.skrl.cfg. Those modules should be edited when the following items need modification:

  • policy or value network architecture
  • hidden dimensions and activation choices
  • PPO or other learner hyperparameters
  • experiment naming and logging defaults
  • checkpoint or resume behavior wired by the custom runner

A Practical Editing Strategy

Use this order when tuning:

  1. Confirm the task definition and env config are the ones actually being used.
  2. Change task-level parameters in the environment config first.
  3. Change optimizer or policy parameters in the agent or runner config second.
  4. Only then use command-line overrides for quick experiments.

This keeps the repository's source of truth readable and avoids hiding important task behavior inside one-off shell commands.

Hydra CLI Overrides

Hydra CLI overrides are still useful for temporary experiments, but they should be treated as a fast iteration tool, not the main place to maintain a task.

Example:

./isaaclab.sh -p scripts/reinforcement_learning/skrl/train.py --task Isaac-LAV2-Base-v0 --headless env.scene.num_envs=4096 agent.seed=2024

Isaac Lab also keeps convenience CLI flags such as --num_envs, --seed, and --max_iterations. These explicit flags take precedence over Hydra overrides.

Practical Advice

  • num_envs is one of the highest-impact knobs for throughput and memory use.
  • Always use --headless for larger runs to reduce rendering overhead.
  • If out-of-memory errors occur, reduce parallel environments first.
  • If training becomes unstable or produces NaNs, inspect reward scale, action scale, reset randomization, controller gains, and solver-related settings.

References

API Cross-References