Gazebo vs Isaac Sim: Which Should a New Team Pick?

A new team should pick Gazebo, and reach for Isaac Sim only when what the robot's cameras see is what decides how the robot behaves. Gazebo assumes the shape most robots already have, runs on computers a small team already owns, and matches the material your people will actually find when they search. The verdict flips when the product is a vision model needing images nobody can photograph, or when the real fault is timing between your own programs, which is a ROS 2 or HORUS question rather than a simulator one. The rest of this post is for a team of two to ten choosing one simulator this month and living with that choice for a year.

Somebody on the team watched a video of a warehouse rendered so convincingly you would swear it was filmed, with an arm lifting parcels out of a bin, and that video is now in the group chat with the word "this" underneath it. Somebody else installed a simulator on a Tuesday and by Thursday had a robot that sank slowly through the floor, a wheel that spun while the base sat still, and a depth camera returning a flat grey nothing.

Those two people are now arguing, and neither argument is really about physics. One of them is worried that starting on the plainer tool makes the demo look amateur beside a competitor's video. The other is worried about a download the size of an operating system, a graphics card nobody has bought, and a month spent authoring a virtual warehouse instead of writing the software that picks the parcel.

Underneath both worries sits a question nobody has said out loud, which is whether this choice is reversible. If it is not, and the team gets it wrong, the robot is late by a quarter and the reason will be a tool chosen from a video rather than from the work.

Should a new team pick Gazebo or Isaac Sim?

Pick Gazebo, unless the robot's behaviour is produced by a camera and the team already owns capable NVIDIA hardware, in which case pick Isaac Sim. That is the whole decision, and it is decided by what you are trying to find out, not by which tool is more advanced.

Most new teams are trying to find out whether their programs work together. Does the driver come up, does the planner get a map, does the arm stop before it hits the table, does the whole thing survive being left running over lunch. Gazebo is built around exactly that shape, and the connection between Gazebo and the software a robot actually runs is the well-trodden path rather than a thing you configure.

A minority of teams are trying to find out whether a network reading pictures will behave when the pictures come from a real lens. That is a different question, it needs images that resemble photographs, and it needs many more of them than a human can capture. Isaac Sim exists for that question and is good at it.

The mistake is picking the tool for the question you expect to have in a year instead of the one blocking you this month.

What does a robot simulator actually give a team?

A simulator gives three separate things, and a new team usually needs only two of them. The first is physics: where everything ends up a moment from now, given weights, joints, friction and whatever is pushing on what. The second is pictures: what a camera bolted to the robot would have seen. The third, and the one teams undervalue, is impersonation, where the simulator presents itself to your software as motors, encoders, a laser scanner and a clock so that your code cannot easily tell the machine is missing.

That third job is what pays for itself in the first month. It is where you find the flipped sign, the frame named after the wrong link, the node that dies quietly at startup, the message that everyone assumed somebody else was publishing. Those are boring bugs, they are most of the bugs, and finding them costs nothing in a simulator and costs a broken gearbox on a bench.

Physics fidelity matters far less than a new team expects, right up until the robot has to touch something on purpose. Picture quality matters not at all until a neural network is the thing looking.

What are the real options beyond Gazebo and Isaac Sim?

There are about seven, and a lot of teams end up running two of them for different jobs. Gazebo is the default for whole-robot testing with sensors. Isaac Sim is NVIDIA's photoreal simulator, with Isaac Lab layered on top for training locomotion and manipulation policies at volume. MuJoCo, open source under Apache-2.0, is where contact-heavy control research lives. Webots installs in an afternoon and is the kindest to a team with nobody experienced yet. PyBullet remains the fastest way to get a Python experiment moving. And if you bought a platform, the maker probably shipped a model for one of the above, which is worth more than any argument about fidelity.

One distinction saves teams a quarter: the simulator is not the layer your programs talk through. That layer is ROS 2, or a vendor stack, or a middleware such as HORUS, an open-source real-time robotics middleware for Rust, Python and C++ where the three languages share the same shared-memory ring buffers, so messages between programs on one machine are not serialised. That project is Apache-2.0 and validated in simulation, and it is not a simulator, renders nothing and replaces neither of the tools in this comparison. Confusing the two layers is why some teams buy fidelity to fix a problem fidelity cannot touch.

How do the simulator options compare side by side?

Read the last column first, because most teams are eliminated into a simulator rather than argued into one. The graphics card already in the building, the language your team writes, and the week you can genuinely spare will cross out most of this table before anybody's preference gets a vote.

No column in that table ranks physical accuracy, because for a new team accuracy is almost never the deciding constraint.

Which simulator fits the kind of team you actually are?

Match the simulator to who is going to maintain it on a bad week, not to who is excited about it today. A two-person team where one person also does the electronics cannot carry a scene-authoring workload, and Gazebo asks for much less of that person than Isaac Sim does.

A research group with a graphics budget and a student whose whole project is the vision model is the natural home for Isaac Sim, because that student's time is the thing being spent and the images are the deliverable. A startup with six engineers building a product usually wants Gazebo for daily testing, plus Isaac Lab later and only if a learned controller becomes the plan.

A hardware-first team, where most of the work is a machine on a bench, is often better served by simulating less than they were told to. If the robot exists, the simulator is for the checks that are dangerous or slow to run on it, not for a virtual copy of a machine sitting two metres away.

The pattern that goes wrong is a team choosing the tool that suits the engineer who argued hardest, then discovering that engineer is the only person who can open it.

What hardware does each simulator demand?

Gazebo runs on an ordinary developer laptop and Isaac Sim does not. That single sentence resolves the argument for a large share of new teams, and resolves it before anybody debates realism.

Isaac Sim wants a current NVIDIA graphics card with generous video memory, current drivers, a lot of disk, and a machine that will not thermally throttle itself into uselessness in the second hour. On integrated graphics, Isaac Sim is not a slower option, Isaac Sim is simply not an option. If the team is on laptops from mixed vendors, or if half the team is on a Mac, adopting Isaac Sim means buying and administering a machine, and probably a shared one that people have to book.

Gazebo is happier, though not free. Sensor-heavy worlds with several cameras will still make a laptop's fan audible, and a full stack running against a busy world in a container is not a light thing.

The wider point is that a shared simulation machine changes how a team works. When only one person can run the simulator at a time, testing stops being something everyone does before pushing and becomes an event that gets skipped, which is why a robot that works in simulation still fails in a real room.

How long before each simulator pays for itself?

Gazebo usually pays back within a few weeks and Isaac Sim within a few months, and that difference matters more than any capability gap when the runway is short. The clock is not install time. The clock runs until the simulator answers a question that changes what somebody does next.

For Gazebo, that moment arrives when the whole stack comes up against a simulated robot and somebody finds a bug they would otherwise have found on hardware. Getting there means a description of the robot, plugins for the sensors, and a world with enough furniture to be interesting.

For Isaac Sim, payback arrives when a model trained or tested on generated images behaves on real ones. Everything before that is scene authoring, lighting, materials, domain randomisation and a lot of driver troubleshooting, and none of it is wasted but none of it is payback either.

So the honest question for a team with a demo in eight weeks is not which tool is better. It is which tool returns something before the demo. A team that starts in Gazebo can add Isaac Sim in the second quarter. A team that starts in Isaac Sim frequently has nothing to show at week six except a very handsome empty warehouse.

What does each simulator assume your team already knows?

Gazebo assumes ROS 2 habits and Linux comfort, while Isaac Sim assumes those plus graphics and scene-authoring skills your team may not have. Neither assumption is stated on the download page, and both are the actual cost.

Working in Gazebo means writing a robot description in a format with quirks, attaching sensor plugins, and understanding how coordinate frames relate to each other. When something is wrong the symptom is physical and readable: the robot sinks, the arm folds through itself, the laser sees through walls. A person who has debugged one of those can debug the next.

Isaac Sim adds a stage-based scene model, materials, lighting, physics settings with their own vocabulary, and a bridge to configure before your existing software sees anything. When something is wrong there, the symptom can be a black image or a scene that will not open, and the debugging is closer to graphics work than robotics work.

If nobody on the team has done either, start on the smaller vocabulary. There is a reasonable case for spending a week in a simulator built for people starting out purely to learn what a simulator is for, then moving.

What does a bad simulator choice look like a year later?

It looks like a robot model that only one person can change, and a simulator nobody opens any more. That is the shape the failure takes, and it takes it slowly enough that nobody calls it a failure.

The sequence is consistent. The team picks the heavier tool because the demo has to look good. One engineer builds the world and becomes the only person fluent in it. That engineer gets pulled onto hardware for a deadline. The scene falls behind the real robot, so results from it stop being trusted, so people stop running it, so it falls further behind. Six months later somebody proposes deleting it and nobody argues.

The other failure is quieter and more expensive: the simulation stays healthy and stays wrong. Everything passes, hardware keeps failing, and the team responds by improving the physics, because that is the visible knob. Meanwhile the actual difference is drivers, startup order and timing, and no amount of fidelity will surface it. Telling those apart early is most of the value in knowing when to stop simulating and build the real thing.

What do you give up by choosing Gazebo?

You give up photorealism, generated training images at volume, and the ability to train a policy across many worlds at once. Those are real losses and they are worth naming plainly rather than pretending the plainer tool wins on every axis.

Gazebo's images look drawn. A vision model trained on them learns the drawing, and meets a real camera as a stranger. If your product is a network that looks at a bin and decides what to grasp, Gazebo will not get you there, and the workaround people reach for, collecting real images by hand, is slow and often blocked because the real robot does not exist yet.

You also give up scale. Learning a walking gait means running an enormous number of attempts, and Gazebo is not shaped for that, whereas Isaac Lab and MuJoCo are.

What you keep is the ability to run the whole system every day, on hardware you own, maintained by anybody on the team. For most new teams that trade is correct, and it stops being correct exactly when the camera becomes the thing that decides. If your robot has legs and hands, that crossover arrives sooner, which is part of why the software half of a humanoid is the hard half.

When is ROS 2 the better choice?

ROS 2 is the better choice for nearly every new team building a robot with sensors, a map and more than one program, and it is the right default under either simulator. HORUS is not the answer there, and a team that adopts a smaller middleware because a comparison post said the messaging was better will spend its first quarter rebuilding navigation, transforms, visualisation and drivers that ROS 2 already ships.

Choose ROS 2 when you need a mapping stack, a motion planner, a camera driver and a tool for seeing what happened after a run went wrong. Choose ROS 2 when you want to hire people who arrive already knowing the vocabulary, or when a customer expects to receive something their own engineers can maintain. Choose ROS 2 when the robot is mostly standard parts and the interesting work sits at the top.

Gazebo is the simulator that assumes this world, which is another reason the pairing is the low-risk default for a team without strong reasons to deviate.

The case for looking further starts later, when several programs on one computer are getting in each other's way and the robot stutters under load. That is a narrow problem and it is not where a new team begins.

Does choosing Gazebo mean settling for a robot that looks amateur?

No, and here is why: nobody outside your team judges the robot by the simulator, and inside your team the simulator is a test rig rather than a showreel. The video that started the argument was made by a company whose product is rendering, and it was made to sell rendering.

What an investor or a customer wants to see is a machine doing something useful, and that video is filmed with a phone. What a hiring candidate wants to see is that your stack is legible. What your own engineers need is a thing that runs on the laptop in front of them every day without booking a shared machine.

There is a genuine version of this worry, and it is narrow: if you are selling the simulation itself, or delivering synthetic data as the product, appearance is the product and Isaac Sim is correct. Otherwise, the pretty world is an internal luxury paid for in engineer-weeks.

If a stakeholder truly needs a beautiful picture once a quarter, that is a rendering task for one person, not a decision about which simulator the whole team lives in every day.

Will a photoreal simulator close the gap to the real robot?

Partly, but not the way you think: photorealism closes the gap for the camera and leaves every other gap exactly where it was. If a network reading images is the part that breaks on hardware, better pictures genuinely help, and that is the case Isaac Sim was built for.

The gaps it does not touch are the common ones. Friction and contact were guessed rather than measured. The gearbox has play in it that no model included. The real camera hands over pictures later than the simulated one did, and the planner acts on a view of where the world used to be. Programs compete for the same processor and start missing their slot, so the machine hesitates in a way it never did on your desk.

You can tell these apart without buying anything. A physics gap repeats: the robot always understeers on that carpet, always misses that shelf by the same margin. A timing gap does not: the same input gives different behaviour on different days, worse with everything running, better with half the programs switched off. Run the robot with the heavy programs disabled before spending a quarter on fidelity, and consider how the three main simulators actually divide the work.

How should a new team make the call this week?

Write down the one question you need a simulator to answer before your next deadline, then pick whichever tool answers that question with the least modelling work. Not the better simulator. The one that answers your question. Almost every regretted choice comes from picking for a question the project did not have yet.

• If you are testing a whole robot with sensors -> Gazebo, because the path from Gazebo to your robot's software is already worn in.
• If a trained network reading images is the product -> Isaac Sim, because the pictures have to convince a model rather than a person.
• If you are learning a walking or grasping policy -> Isaac Lab or MuJoCo, because volume and contact are the entire job.
• If nobody on the team has simulated anything before -> Webots for one week, then move, because momentum beats correctness at the start.
• If half the team lacks an NVIDIA card -> Gazebo, because a simulator only one person can run is a simulator nobody runs.
• If the simulated robot works and the real one stutters -> stop buying fidelity, because the fault is timing rather than physics.

The HORUS Fit Framework reduces this to five things you can judge without running a benchmark: ecosystem size, setup effort, team size fit, deployment target and licence. For simulators, setup effort and team size fit decide it most often, and licence matters more than people expect on the day a client asks whether the whole setup can be handed over.

The week your simulated robot behaves and the real one hesitates is a bad week to start reading about the layer underneath. Put HORUS on the shelf before then: star it so it is in your list when you start building.