Simulation — build robots for free

What a simulator gives you

A robot simulator like Gazebo (or Isaac Sim, Webots) is a virtual world with a physics engine. You give it a model of your robot — its shape, mass, joints, and where its sensors sit — and a model of the environment, and it computes how the robot moves under gravity, friction and motor forces, and what its virtual sensors would see. This buys you enormous freedom: no hardware to damage, no batteries to charge, the ability to pause and inspect, to teleport the robot to a tricky spot, to run faster than real time, and to test dangerous scenarios safely. For anyone learning without a robot in hand, a simulator is the single most valuable tool — you can complete this whole track's practicals virtually.

The same code, virtual or real

The reason simulation is so powerful in the ROS world is that your control code does not know or care whether it is driving a real robot or a simulated one. Recall from the ROS lesson that nodes talk over topics: your navigation node publishes velocity commands to a topic and subscribes to sensor topics. A simulator publishes the same sensor topics and subscribes to the same command topics a real robot would. So you can develop your entire stack against Gazebo, and when the hardware is ready, you swap the simulator for real drivers publishing those same topics — and your code runs unchanged. This clean separation between 'the robot's software' and 'where the robot's body comes from' is one of the best reasons to build on ROS 2.

# Same navigation node, two different 'bodies' underneath.

# In simulation: Gazebo provides /scan, /odom and consumes /cmd_vel
ros2 launch my_robot sim.launch.py
ros2 run my_nav navigator            # publishes /cmd_vel, reads /scan

# On hardware: real drivers provide /scan, /odom and consume /cmd_vel
ros2 launch my_robot hardware.launch.py
ros2 run my_nav navigator            # the SAME node, unchanged

The reality gap

Simulation is never a perfect copy of reality, and the difference is called the reality gap. A simulator approximates friction, its virtual sensors are cleaner than real ones, motor behaviour is idealised, and countless small effects (wheel slip, sensor noise, flex, timing jitter) are simplified or absent. So code that works flawlessly in simulation can misbehave on the real robot. This does not make simulation useless — it makes it a powerful first stage that you must validate on hardware. Two habits narrow the gap. Add realism: turn on sensor noise, model friction better, randomise parameters so your code cannot depend on a perfect world. Domain randomization — deliberately varying masses, frictions, and sensor noise across many simulated runs — forces a controller to be robust, so it survives the messiness of reality. The mindset to carry: trust simulation to develop and shake out logic, but never declare victory until it runs on the physical robot.

Using simulation well

Simulation earns its keep at specific moments. Use it to develop and debug logic where iterating on hardware would be slow — navigation, planning, behaviour trees, perception pipelines. Use it to test the dangerous and the rare — a fall, a collision, an edge case you would never risk on a real arm. Use it to train where real trials are impractical, as reinforcement-learning controllers do, running millions of episodes overnight. And use it as a regression test — a scene your robot must still handle after a code change. When do you move to hardware? Once the logic is solid in sim and you need to confront the real sensor noise, timing, and physics — the things simulation smooths over. The professional flow is a loop: prototype in sim, validate on hardware, feed what you learned back into a more realistic sim.

• Develop and debug logic fast, without hardware wear.
• Test dangerous or rare scenarios safely.
• Train learning-based controllers over many episodes.
• Use scenes as regression tests after code changes.
• Move to hardware to confront real noise, timing and physics.