TL;DR:
A simulator runs your robot software against a computer model of the robot and its world, so mistakes cost nothing.
A physics engine steps the model forward in small time slices, and simulations can often run faster than real time.
The reality gap means a model never matches the real world exactly, so simulation finds bugs but does not replace hardware tests.
You have written code that should drive a wheeled robot to the far side of a room, around a table. The first time you run it on real hardware, a sign error sends the robot straight at the table leg at full speed. A simulator lets that happen on a screen instead.
What a simulator does for a robot
A robot simulator contains a virtual world and a virtual copy of your robot, with simulated sensors and motors. Your software connects to it the way it would connect to the real thing, reading simulated camera or LiDAR data and sending wheel commands. The software often cannot tell the difference.
The big wins are speed and safety. Nothing can break, nobody can be hurt, and you can reset in a second. You can also repeat the exact same test a hundred times, which is hard in a real room where the lighting, floor and battery level keep changing.
How physics engines work
A physics engine advances the world in small steps. At each step of length Δt, it adds up forces and torques on every body, uses F = ma to find accelerations, updates velocities and positions, and checks for collisions. Smaller steps are more accurate but cost more computing.
It needs numbers describing the robot: mass of each part, how that mass is spread out (the inertia), friction between surfaces, and motor limits. These come from the robot's description file. If they are wrong, the simulated robot behaves like a different robot.
Worked example: testing a navigation stack in simulation
A navigation stack takes a goal, plans a path around obstacles and sends velocity commands. Say you want to test it on a 5 m × 4 m room with a table in the way, in a simulator.
Build the world: four walls, one table-sized box, and a start and goal pose on opposite sides.
Load the robot model, with a simulated LiDAR and wheel odometry, and start your navigation software exactly as you would on hardware.
Send the goal. Watch the planned path in a visualizer and check that it bends around the table with some clearance.
Record the result: did it arrive, how long did it take, did it touch anything?
Move the table, repeat, and change one setting at a time, such as the robot's safety margin around obstacles.
Now put numbers on the speed benefit. If the simulator runs at a real-time factor of 4, one simulated minute takes 15 real seconds, since 60 / 4 = 15. A batch of 50 runs at 90 simulated seconds each is 50 × 90 = 4500 simulated seconds, or 4500 / 4 = 1125 real seconds, about 19 minutes. On a real robot the same batch would take 75 minutes of driving, plus resets and battery swaps. These factors depend on your computer and scene, so measure your own.
Say 3 of the 50 runs fail because the robot clips the table corner. That is a finding you can chase: perhaps the robot footprint in the software is smaller than the real body. You fix it in a minute and rerun, with no scraped paint.
The reality gap
A simulation is a model, and models leave things out. The difference between how the model behaves and how the real robot behaves is called the reality gap. It matters most where physics is messy: wheel slip on a dusty floor, gearbox backlash, motor friction, flexing parts, camera blur, and reflections that confuse a LiDAR.
Simulated sensors are also too polite. A simulated LiDAR often returns neat distances with simple noise, while a real one gets confused by glass and sunlight. Code tuned until it is perfect in simulation can still fail on the first real run.
Where it goes wrong
Trusting a run that looks too good. If simulation never fails, make it harder: add noise, change friction, move obstacles.
Wrong model numbers. A mass off by a factor of two changes how hard the robot can stop.
Large time steps. Fast-moving parts can pass through thin walls or jitter.
Hidden differences. Real communication delay, battery sag and startup behaviour are rarely modelled.
Skipping hardware tests. Simulation reduces risk, it does not remove it.
First real run: After simulation, still start slowly on hardware. Put the robot on blocks or use a low speed limit, keep the emergency stop reachable, keep clear of wheels and arms, and treat the first real run as a test of the model too.
How real robots use it
Teams typically test in simulation first, then in a controlled area with a safety operator, then in the target space. Simulation also runs automatically whenever code changes, to catch regressions. If you want to compare tools, see choosing a robot simulator as a beginner.
Try it yourself
Pick any free simulator that comes with a two-wheel robot and a basic room. Make the robot drive a 2 m square using only timed commands, then repeat with the floor friction lowered. The corners will drift. That drift is a small, safe version of the reality gap, and it is why robots use sensors to correct themselves.
Frequently asked questions
Can a simulator replace a real robot?
No. It cuts down the number of hardware tests and finds many software bugs early, but final checks need the real machine.
Why not make the simulation perfectly realistic?
More detail costs more computing time, and you still would not know every real value. A simple model that runs fast is often more useful for finding logic bugs.
Get started
