Simulation
Choose a simulator for the project's hardest requirement, then define the
evidence that would make its results trustworthy.
Pick by bottleneck
- Gazebo: prefer for ROS-centric mobile robots, standard sensor simulation,
and projects without a confirmed compatible NVIDIA GPU.
- Isaac Sim: consider when photorealism, synthetic data at scale, or the
NVIDIA Isaac stack is central. Confirm the current RTX GPU, driver, OS, and
VRAM requirements before committing to it; use
gazebo if that environment
is not real and available.
- MuJoCo: prefer for lightweight, contact-rich manipulation that does not
need ROS integration or photoreal rendering.
- A project may use different simulators for different concerns. Avoid forcing
one tool to own both navigation validation and training-data generation.
After selection, use gazebo, isaac-sim, or mujoco for tool mechanics.
Use isaac-lab for training workflows on top of Isaac Sim.
Define fidelity before building
- Name what must transfer to hardware: interfaces, sensor behavior, dynamics,
contacts, timing, or visual appearance.
- Match real sensor rate, noise, frame names, range, field of view, resolution,
and timestamp source where those affect downstream decisions.
- Record known model gaps instead of treating simulation success as real-world
evidence.
- If the simulator will back regression tests, control time step and randomness
and judge behavior with tolerances rather than pixel-perfect coincidence.
Read sensor fidelity when adding sensors, preparing
sim-to-real work, or turning a scenario into a repeatable test. Use data when
the unresolved question is what training data to generate rather than how to
simulate it.
Done
- The selected tool fits the available hardware and the project's main
fidelity requirement.
- The simulation contract names which interfaces and physical properties must
match reality.
- Every consumer uses a consistent clock and frame convention.
- Repeatability is designed where the simulation will be used as a test.
- Version and hardware requirements were checked in the current upstream
Gazebo,
Isaac Sim, or
MuJoCo documentation.
1---2name: simulation3description: Choose between Gazebo, Isaac Sim, and MuJoCo and define what the simulation must prove.4---56# Simulation78Choose a simulator for the project's hardest requirement, then define the9evidence that would make its results trustworthy.1011## Pick by bottleneck1213- **Gazebo:** prefer for ROS-centric mobile robots, standard sensor simulation,14 and projects without a confirmed compatible NVIDIA GPU.15- **Isaac Sim:** consider when photorealism, synthetic data at scale, or the16 NVIDIA Isaac stack is central. Confirm the current RTX GPU, driver, OS, and17 VRAM requirements before committing to it; use `gazebo` if that environment18 is not real and available.19- **MuJoCo:** prefer for lightweight, contact-rich manipulation that does not20 need ROS integration or photoreal rendering.21- A project may use different simulators for different concerns. Avoid forcing22 one tool to own both navigation validation and training-data generation.2324After selection, use `gazebo`, `isaac-sim`, or `mujoco` for tool mechanics.25Use `isaac-lab` for training workflows on top of Isaac Sim.2627## Define fidelity before building2829- Name what must transfer to hardware: interfaces, sensor behavior, dynamics,30 contacts, timing, or visual appearance.31- Match real sensor rate, noise, frame names, range, field of view, resolution,32 and timestamp source where those affect downstream decisions.33- Record known model gaps instead of treating simulation success as real-world34 evidence.35- If the simulator will back regression tests, control time step and randomness36 and judge behavior with tolerances rather than pixel-perfect coincidence.3738Read [sensor fidelity](SENSOR-FIDELITY.md) when adding sensors, preparing39sim-to-real work, or turning a scenario into a repeatable test. Use `data` when40the unresolved question is what training data to generate rather than how to41simulate it.4243## Done4445- The selected tool fits the available hardware and the project's main46 fidelity requirement.47- The simulation contract names which interfaces and physical properties must48 match reality.49- Every consumer uses a consistent clock and frame convention.50- Repeatability is designed where the simulation will be used as a test.51- Version and hardware requirements were checked in the current upstream52 [Gazebo](https://gazebosim.org/docs/),53 [Isaac Sim](https://docs.isaacsim.omniverse.nvidia.com/), or54 [MuJoCo](https://mujoco.readthedocs.io/) documentation.