isaaclab.app#
Sub-package containing app-specific functionalities.
These include:
Ability to launch the simulation app with different configurations
Run tests with the simulation app
Classes
Start Isaac Sim / Kit for scripts that have not moved to |
|
Staged progress display that owns the console while a run starts up. |
|
Starts the process runtime a resolved simulation config requires, and stops it. |
Functions
|
Add simulation-launcher CLI arguments ( |
|
Context manager that launches the appropriate simulation runtime for cfg. |
|
Prepare configured consumers and reject incompatible runtimes without starting them. |
|
Report what the startup path is doing right now. |
Simulation Launcher#
- isaaclab.app.launch_simulation(cfg, launcher_args: Namespace | dict | None = None) Generator[PhysicsCfg | None, None, None][source]#
Context manager that launches the appropriate simulation runtime for cfg.
Resolves configured consumers before starting their required runtimes. Each runtime starts once and closes on exit. Cameras are auto-enabled for Kit-renderer sensors.
Resolve viewer and physics choices on the same config used to construct the simulation:
sim_cfg = SimulationCfg() with launch_simulation(sim_cfg, args_cli): sim = SimulationContext(sim_cfg)
Yields the resolved physics config when a caller needs to adjust solver settings before construction.
- Parameters:
cfg¶ – Concrete config tree declaring backend, renderer, and sensor requirements.
launcher_args¶ –
Parsed launcher arguments, typically the script’s
args_cli. Besides the arguments added byadd_launcher_args(), the following keys are read when a script contributes them:physics: Backend selector applied to every physics config in cfg.require_kit: Whether the caller needs Kit for a reason cfg cannot express, e.g. a tool that reaches a Kit-only extension API. This is additive – it can only turn a kitless launch into a Kit one, never the reverse, so a config that already needs Kit still launches it when the key is absent orFalse.
- isaaclab.app.validate_launch(cfg, launcher_args: Namespace | dict | None = None) tuple[tuple[Any, ...], tuple[str, ...]][source]#
Prepare configured consumers and reject incompatible runtimes without starting them.
Applies launcher selections and resolves automatic physics/renderer configurations in place. Task-run enumeration and
launch_simulation()use this same preparation step.- Parameters:
- Returns:
Resolved runtime configurations and the components requiring Isaac Sim / Kit.
- Raises:
ValueError – If selections are invalid or configured runtimes cannot share one process.
- isaaclab.app.add_launcher_args(parser: ArgumentParser) None[source]#
Add simulation-launcher CLI arguments (
--device,--viz, etc.) to parser.The arguments are defined by the Kit launcher, which consumes most of them.
- class isaaclab.app.SimulationLauncher[source]#
Starts the process runtime a resolved simulation config requires, and stops it.
A backend package subclasses this and names the subclass in its config’s
launcher_type.launch_simulation()constructs it, which starts the runtime, and callsclose()when the simulation ends.Attributes:
Simulation device chosen by the runtime, or None to keep the config's device.
Methods:
- device: str | None = None#
Simulation device chosen by the runtime, or None to keep the config’s device.
- class isaaclab.app.AppLauncher[source]#
Start Isaac Sim / Kit for scripts that have not moved to
launch_simulation().Deprecated since version Use:
add_launcher_args()andwith launch_simulation(cfg, args_cli):, which start only the runtime the config needs.Methods:
__init__([launcher_args])add_app_launcher_args(parser)Add the launcher arguments, see
add_launcher_args().- static add_app_launcher_args(parser: ArgumentParser) None[source]#
Add the launcher arguments, see
add_launcher_args().
Additional Public Classes#
The following classes are part of the public isaaclab.app API.
Staged progress display that owns the console while a run starts up. |
|
A settings manager that provides a carb.settings-like interface without requiring Omniverse. |
- class isaaclab.app.LoadingScreen[source]#
Bases:
objectStaged progress display that owns the console while a run starts up.
While the screen is open, the startup path writes to standard output and error are spooled to a temporary file instead of the console, so they cannot break the progress bar. POSIX also captures native writes to the underlying file descriptors; Windows and macOS preserve their console descriptors and capture Python-level output. Alongside the bar the screen shows the step currently running, as reported by
report_activity(), and a clock that keeps ticking through long silent steps. The spool is replayed when startup fails and dropped when it succeeds. Closing the screen hands the console back, so whatever runs next (typically an RL library’s training log) prints undisturbed.While active, the context replaces
builtins.input()process-wide. An interactive prompt restores normal output and replays captured context before waiting for input. Later stages and summaries use plain console output.The screen degrades to plain stage lines, with no redirection, when it is disabled – for a non-interactive console or a verbose run – so nothing is hidden from a captured log.
Example:
with LoadingScreen(2) as screen: screen.summary("Isaac Lab", {"Task": task}) screen.stage("Launching simulation") ... screen.stage("Creating environment") ... screen.close()
Methods:
- __init__(num_stages: int, *, enabled: bool | None = None, logo: bool = True) None[source]#
Initialize the screen.
- Parameters:
num_stages¶ – Number of stages the progress bar counts up to.
enabled¶ – Whether to draw a live progress bar and spool startup output. Defaults to None, which enables both when standard output is a terminal.
logo¶ – Whether
summary()shows a responsive greeting beside the run summary. Defaults to True.
- classmethod __new__(*args, **kwargs)#
- class isaaclab.app.SettingsManager[source]#
Bases:
objectA settings manager that provides a carb.settings-like interface without requiring Omniverse.
This class can work in two modes: - Standalone mode: Uses a Python dictionary to store settings - Backed mode: Delegates to the backend given to
set_backend()The interface is designed to be compatible with the carb.settings API.
This is implemented as a singleton to ensure only one instance exists across the application, even when used in different execution contexts (e.g., Hydra). The singleton is stored in sys.modules to survive module reloads.
Methods:
__new__(cls)Singleton pattern - always return the same instance, stored in sys.modules to survive reloads.
__init__()Initialize the settings manager (only runs once due to singleton pattern).