Principle:Isaac sim IsaacGymEnvs Task Selection and Configuration
| Sources | Domains | Last Updated |
|---|---|---|
| IsaacGymEnvs, Hydra | Configuration, Training | 2026-02-15 00:00 GMT |
Overview
Mechanism for composing task, environment, and training configurations using hierarchical YAML files and command-line overrides, powered by the Hydra/OmegaConf framework.
Description
IsaacGymEnvs uses Hydra and OmegaConf to compose configuration from multiple YAML sources organized in a hierarchical directory structure:
- config.yaml -- Top-level entry point defining defaults and global parameters (num_envs, seed, headless, sim_device, etc.)
- cfg/task/*.yaml -- Per-task configuration files (e.g., Cartpole.yaml, Ant.yaml, ShadowHand.yaml) defining environment geometry, physics parameters, observation/action spaces, reward functions, and domain randomization settings
- cfg/train/*.yaml -- Per-task training configuration files (e.g., CartpolePPO.yaml, AntPPO.yaml) defining RL algorithm hyperparameters, network architecture, learning rate schedules, and logging settings
The defaults list in config.yaml uses Hydra's composition mechanism: when a user specifies task=Cartpole on the command line, Hydra loads cfg/task/Cartpole.yaml and cfg/train/CartpolePPO.yaml (the training config name is derived from the task name plus the algorithm suffix). All parameters can be overridden from the CLI using dot-notation (e.g., num_envs=512, train.params.config.learning_rate=1e-4).
The preprocess_train_config function merges task-level parameters into the training config dict, ensuring that the RL algorithm receives the correct observation dimensions, action dimensions, and device assignments.
Usage
Use when launching any training or evaluation run. Every invocation of train.py triggers Hydra configuration composition, making this the universal entry point for all task/algorithm combinations in IsaacGymEnvs.
Theoretical Basis
This follows the configuration composition pattern -- a design approach where configuration is assembled from multiple partial sources rather than maintained in a single monolithic file. Key aspects:
- Hierarchical defaults -- Base configurations are layered with task-specific overrides
- Variable interpolation -- OmegaConf supports ${variable} references across config nodes, enabling DRY (Don't Repeat Yourself) configuration
- CLI overrides -- Hydra allows any config value to be overridden from the command line without modifying YAML files, enabling rapid experimentation
- Config groups -- The task and train directories act as Hydra config groups, where the group name selects which YAML file to load
This approach separates concerns: physics simulation parameters live in task configs, RL algorithm parameters live in train configs, and global orchestration parameters live in the top-level config. Researchers can modify one layer without affecting others.