Robot Software
Gazebo, Isaac Sim, MuJoCo: Robot Simulators Compared
Which robot simulator to use depends on whether you are testing software, training a policy or studying contact dynamics. The three leading options each fail at the others' job.
Pick by purpose. Gazebo for integration testing of a full robot software stack, MuJoCo for fast and accurate contact dynamics in research and policy training, Isaac Sim for photorealistic perception data and massively parallel reinforcement learning on GPUs. Using one for another's job is the most common reason teams conclude that simulation does not work.
Three different jobs
| Job | Best tool | Why |
|---|---|---|
| Testing a full robot software stack | Gazebo | Native middleware integration, sensor plugins, established models |
| Contact-rich manipulation research | MuJoCo | Accurate, stable contact solver, very fast, easy to script |
| Training policies at scale | Isaac Sim or a GPU physics engine | Thousands of parallel environments on one accelerator |
| Generating photorealistic perception data | Isaac Sim | Ray-traced rendering with domain randomisation |
| Verifying a cell layout and reach | Vendor offline programming tool | Uses the real controller kinematics and cycle model |
| Predicting cycle time for a quotation | Vendor offline programming tool | Physics simulators do not model the real motion planner |
The bottom two rows are frequently missed. A physics simulator will happily animate a robot arm, but it does not implement the manufacturer's trajectory generator, blending behaviour or acceleration limits, so its cycle time estimate is fiction. For cycle time, use the vendor tool.
The properties that decide the choice
| Property | Gazebo | MuJoCo | Isaac Sim |
|---|---|---|---|
| Physics step size | 1 to 4 ms | 0.5 to 2 ms | 1 to 16 ms |
| Speed, single simple scene | 1 to 5x real time | 10 to 100x | 1 to 10x |
| Parallel environments | 1 to 8 | 10 to 1,000 on CPU or GPU | 1,000 to 8,000 on one GPU |
| Rendering | Functional | Basic | Ray traced, photorealistic |
| Contact solver quality | Adequate | Strong | Good |
| Middleware integration | Native | Via wrappers | Bridge available |
| Hardware requirement | CPU | CPU, GPU optional | GPU, several GB of memory |
| Model format | SDF and URDF | MJCF and URDF | USD and URDF |
| Learning curve | days | hours | weeks |
| Licence | Open source | Open source | Proprietary, free tiers |
Two rows explain most of the field's behaviour. The parallel environments row is why reinforcement learning moved to GPU simulators: training that needs 100 million environment steps is impractical at 5x real time on one instance and routine across 4,000 parallel ones. The learning curve row is why Gazebo and MuJoCo remain the default for teams whose goal is a working robot rather than a trained policy.
What none of them do well
- Friction. Coulomb friction with a single coefficient is a crude model of a real surface, and grasp stability depends on exactly this. Policies trained on simulated friction routinely fail on real objects.
- Deformable objects. Cloth, cable, foam, food and packaging are either unsupported, slow, or modelled with parameters nobody can measure.
- Sensor noise with the right structure. Adding Gaussian noise to a depth image does not reproduce the specific failure modes of a real depth sensor on dark, shiny or transparent surfaces.
- Actuator dynamics. Backlash, friction in gearboxes, torque ripple and control latency are often modelled as ideal, and the gap shows up as a policy that is too aggressive on hardware.
- Timing. A simulator runs the controller synchronously with physics. A real robot has network delay, jitter and dropped packets.
The strategy that works
- Use simulation for what fails cheaply. Reach, collision, sequence logic, error handling and the first 80 % of a policy.
- Randomise what you cannot measure. Friction, mass, latency, sensor noise and lighting. A policy that survives wide randomisation is likelier to survive reality.
- Keep a hardware loop from week one. Teams that simulate for six months before touching hardware discover a systematic mismatch at the worst moment.
- Measure the gap deliberately. Run the same trajectory in both and record the difference. That number, not a subjective impression, tells you whether the simulator is fit for the task.
- Use the vendor tool for anything commercial. Quoting a cycle time from a physics simulator is a good way to lose money.
Frequently asked questions
Which robot simulator should I use?
Gazebo for testing a full software stack with real middleware, MuJoCo for contact-rich manipulation research, and a GPU-based simulator such as Isaac Sim for large-scale policy training and photorealistic perception data.
Can I estimate cycle time in a physics simulator?
Not reliably. Physics engines do not implement the manufacturer's trajectory generator, blending or acceleration limits. Use the vendor offline programming tool, which runs the real controller motion model.
Why do policies trained in simulation fail on hardware?
Most often friction, actuator dynamics and timing. Simulated friction is a crude single-coefficient model, gearbox friction and backlash are usually idealised, and the simulator runs the controller synchronously without network delay or jitter.
What is domain randomisation?
Deliberately varying simulation parameters that cannot be measured accurately, such as friction, mass, latency, lighting and sensor noise, so that the trained policy has to work across the whole range rather than for one idealised setting.
How early should hardware enter the loop?
From the first weeks. Teams that simulate in isolation for months discover systematic mismatch late, when the cost of changing the approach is highest. A weekly hardware check keeps the gap measurable.
Sources
- Gazebo documentationOpen Robotics, simulator architecture, sensor plugins and middleware integration
- MuJoCo documentationContact solver design and performance characteristics
- arXiv robotics preprints, sim-to-real transferPrimary literature on the reality gap and domain randomisation