Simulators
Invariant runs the simulators you already use. It starts them, varies their parameters, collects results and scores them. It does not build simulated worlds.
What “supported” means
"Works with any simulator" is only useful if it's precise. Invariant uses four levels, and every simulator in the compatibility matrix lists the highest level it reaches.
| Level | What you get |
|---|---|
| 1 · Execute | Invariant can start the simulator in a container, run your stack against it, enforce time limits and collect MCAP output. Any simulator you can containerize reaches this level. |
| 2 · Integrate | Invariant can load worlds, spawn entities, set poses, reset and step through a standard control interface, so parameter variation and seeds work without custom scripts. |
| 3 · Evaluate | Ground truth (poses, contacts, collisions, object states) is extracted automatically, so the built-in metric packs work. |
| 4 · Validate | Invariant has measured run-to-run variation for this simulator on the supported hardware, so default run counts and tolerances are calibrated. |
The standard interface
Level 2 uses ROS 2 simulation_interfaces, a vendor-neutral set of services and actions for controlling simulators: load worlds, spawn and remove entities, get and set state, reset, step (ROS docs). It is implemented by Gazebo (Gazebo docs), Isaac Sim and O3DE (Robotec.ai). Where a simulator has no implementation, a thin Invariant adapter provides the same operations.
Compatibility matrix
Target levels for the first releases. The live matrix is tested nightly against current simulator and ROS 2 releases and published with each Invariant release.
| Simulator | Target level | Hardware | Notes | Status |
|---|---|---|---|---|
| Gazebo | 3 · Evaluate | CPU, GPU optional for sensors | Current releases. Gazebo Classic reached end of life in January 2025 (gazebosim.org) and runs at level 1 only. | Next |
| Isaac Sim | 3 · Evaluate | NVIDIA RTX GPU (e.g. L4, L40S) | Requires RTX cores; A100 and H100 are not supported (Isaac Sim requirements). Results are reproducible only on matching hardware and versions. | Next |
| MuJoCo | 3 · Evaluate | CPU | Through the Python adapter. Well suited to large manipulation trial counts. | Next |
| O3DE | 2 · Integrate | GPU | Through its ROS 2 integration and simulation_interfaces. | Later |
| Unreal Engine-based (e.g. CARLA), custom | 1 · Execute | Depends | Bring your own container. Implement simulation_interfaces or a small adapter to reach level 2. | Next |
Scenario variation Next
You provide worlds. Invariant multiplies them into many test cases by varying what the simulator already exposes:
- Seeds for physics, sensor noise and agent behavior
- Poses: robot start pose, object placement, goal positions
- Conditions: lighting, weather where supported, friction, mass
- Sensor faults: dropout, latency, noise level, miscalibration
Ranges are sampled per run and stored in the run record, so every case can be reconstructed and paired across versions (within each simulator's own reproducibility limits). A coverage report shows which parts of each range were tested and where failures cluster.
Out of scope: authoring photoreal worlds, assets or digital twins. Bring your own, or use a dedicated world-building tool or service and point Invariant at the output.
Determinism, honestly
Invariant assumes simulation is not perfectly deterministic. It pins simulator version, GPU type and driver per scenario, records them in the run record, and relies on paired runs and intervals instead of exact repeatability. If a simulator is deterministic in your setup, you simply need fewer runs.