Robot simulation software

Why there is no single answer

Simulators differ along axes that do not trade off against each other cleanly: how the physics solver handles contact, how good the rendering is, how many instances you can run in parallel, how well it connects to the rest of a robot stack, and what the licence permits. A tool that is excellent for training a contact-rich manipulation policy is often poor for testing a navigation stack against a warehouse layout, and the reverse.

So the question is never which simulator is best. It is which of several jobs you are doing: developing and regression-testing a robot stack, generating training data at scale, or studying a control problem precisely.

The landscape

Gazebo. The default simulator of the ROS world, and the one most teams meet first. It is the right tool for testing a whole robot stack — sensors, drivers, navigation, behaviour — against realistic environments, because its integration with ROS is deep and the sensor models are serviceable. Note the naming: the original Gazebo, retroactively called Gazebo Classic, has reached end of life, and the current project is a rewritten codebase that spent some years called Ignition. Releases run on a named cycle with long-term-support versions; as this was written, Jetty was the newest LTS with support to 2031, Harmonic the previous one to 2029, and Ionic a non-LTS release ending in December 2026. Check which your ROS distribution pairs with before you pick.

Isaac Sim and Isaac Lab. NVIDIA's offering, built on their Omniverse platform. Strong rendering, strong synthetic data generation, and GPU-accelerated physics that lets you run very large numbers of environments in parallel — which is what reinforcement learning at scale requires. Isaac Lab is the learning framework that sits on top and supersedes the earlier Isaac Gym and Orbit efforts. The cost is gravitational pull: it works best when you are on NVIDIA hardware and inside NVIDIA's tooling, and it is heavyweight to stand up.

MuJoCo. Originally commercial, acquired by DeepMind and released open source. It is fast and its contact model is well regarded, which made it the default for research in continuous control and manipulation. MJX runs it on accelerators for massively parallel rollouts. It is a physics engine with a viewer rather than a robot development environment — excellent for studying a control problem, not what you reach for to test a full stack.

Drake. From Toyota Research Institute. The choice when you care about the mathematics: rigorous multibody dynamics, optimisation-based control, and a design that treats systems and their interconnections seriously. Steeper to learn, and it rewards people doing control theory rather than people wiring up a demo.

PyBullet. Old, free, trivially easy to start, runs anywhere. Less accurate and less pretty than the others, and still the fastest way to get a rough idea in front of you. A large amount of published research used it, which makes reproduction easier.

Webots. Open source, batteries included, a long history in education and in mobile robotics. Good when you want something that works out of the box without assembling a stack first.

There are more — SAPIEN for articulated-object manipulation, Genesis among the recent arrivals — and the list turns over faster than it used to. The axes below outlast the names.

What actually differentiates them

• Contact. The hardest thing to simulate and the thing manipulation depends on most. Engines differ in how they resolve simultaneous contacts, whether they allow penetration, and how friction is approximated. This is where a plausible-looking simulation diverges from reality fastest.
• Parallelism. Reinforcement learning needs thousands of environment steps per wall-clock second. Simulators designed to run thousands of instances on a GPU are in a different category from those designed to run one instance faithfully.
• Rendering. If you are training a vision policy, image realism is part of the physics. If you are testing a planner, it is decoration that costs frame rate.
• Sensor models. Whether lidar returns behave like lidar returns, whether depth fails where real depth fails, whether the camera has rolling shutter and exposure behaviour. Usually the weakest part of any simulator.
• Stack integration. Whether your actual robot software can run against it unmodified. This decides whether the simulator can serve as a regression test, which is its highest-value use.
• Licence and lock-in. What you may do with it commercially, and how much of your tooling becomes specific to it.

Choosing, in practice

Testing a robot stack and catching regressions before they reach hardware: Gazebo, because the integration is what you are buying. Training vision-based policies at scale: Isaac Sim with Isaac Lab, accepting the ecosystem commitment. Studying a manipulation or locomotion control problem: MuJoCo. Control design where correctness matters more than throughput: Drake. Trying an idea this afternoon: PyBullet.

Most serious groups end up with two: one for scaled training, one for stack-level testing. That is not indecision, it is the correct answer to two different questions.

The cost nobody budgets

The simulator is free. The simulation is not.

What costs real engineering time is everything around it: building and maintaining accurate models of your robot, its sensors and its environment; keeping those models in step with hardware as the hardware changes; building scenario generation so that coverage is systematic rather than anecdotal; and running the whole thing in continuous integration so a regression is caught by a machine rather than by a person on the floor. Teams routinely underestimate this by an order of magnitude, discover that their simulation has quietly drifted away from their robot, and stop trusting it — at which point the investment is written off.

A simulation nobody trusts is worse than no simulation, because it still consumes maintenance while producing results people have learned to discount.

What none of them solve

Every simulator above is wrong about contact, deformable objects, cable behaviour, actuator non-idealities and the long tail of real environments. That is not a defect to be fixed in the next release; it is the nature of the thing. The gap between a policy that works in simulation and one that works on hardware is a subject in its own right, and the guide on sim-to-real transfer covers the techniques used to cross it.

Simulation is how you avoid wasting hardware time on the obviously broken. It is not how you find out whether something works.

Simulation as a test harness

The highest-value use of a simulator in a working team is not training policies. It is catching regressions.

A stack that can run headless against a fixed set of scenarios, on every commit, turns an entire category of defect into something a machine finds in minutes rather than something a person finds on the floor in a fortnight. The scenarios that pay for themselves are the ones nobody wants to reproduce physically: the aisle with a person standing in it, the pallet half a metre out of position, the sensor that drops out mid-manoeuvre, the battery at fifteen per cent.

Three things make this work. Scenarios must be defined as data rather than code, so that adding one is cheap and a non-programmer can do it. Results must be a pass or a fail against a stated criterion, not a video somebody watches. And a failure has to block the merge, because a test suite that reports without blocking becomes a wall of amber that everyone learns to ignore.

Knowing when your simulation has drifted

The quiet failure is a simulation that was accurate at commissioning and is not any more, because the robot was modified and the model was not. It is quiet precisely because everything still runs.

The defence is a small set of calibration behaviours executed on both the real robot and the simulated one, on a schedule, with the results compared automatically. Move to a pose and compare the joint trajectory. Drive a fixed path and compare the odometry. Lift a known mass and compare the current draw. None of this is sophisticated, and the point is not precision — it is to produce a number that moves when something changes, so drift becomes visible before it becomes expensive.

Teams that do this tend to keep trusting their simulation. Teams that do not tend to stop trusting it, and eventually rebuild. How long that takes depends on how fast the hardware and the environment change, and this guide has no measured figure for it — the earlier version of this sentence gave one, and it had no source behind it.