Writing software for a robot is different from writing a website or a phone app. A robot’s software moves real motors in the real world, so a mistake can break something. Robot simulation solves this: the robot is built as a model inside the computer, put into a pretend world with pretend physics and pretend sensors, and tested there first. This page explains the idea step by step. Every step has a simulator to play with: a program that lies in its log, a race between a real robot and a simulation, a robot model builder, a 3D viewer, a physics sandbox and a sensor simulator. No real robot is needed.
Software for a website or a phone app can be written and tested on one computer. Nothing physical is involved. Robot software is different: it controls real hardware, so it must be tested on a real robot, and the way the robot moves in its surroundings has to be watched. The usual way to debug is to read log messages, but those are often not enough. A program can print “goal reached” while the robot is actually stuck against a wall. Pick a bug below and see how far the log alone can go.
Testing on a real robot is harder than testing software alone. Every test needs time, because the robot must be set up, charged and put in the right place. It needs money, for the robot, the sensors and the motors, and for repairs when something breaks. It needs hardware, and it needs safety, because a robot with a bug can hit things and people. Here the same program with the same hidden bugs is tested on a real robot and in a simulator. Both do exactly the same tests in the same order.
To simulate a robot, the computer first needs to know what the robot is. ROS 2 can describe a robot with three kinds of information. The structure is the shape of each part. The components are the parts that do jobs: wheels, sensors and so on. The connections say how the parts are joined, for example that a wheel is attached to the body and spins. Together this is the robot model. The model can then be shown on a screen (visualization) and placed in a pretend world (simulation). Build a robot below by adding and removing parts.
A robot model can be shown on the computer. This is called visualization, and a tool named RViz does it for ROS 2. It lets people inspect the structure of the robot, its components and its sensors, and look at it from any side, without the real robot being in front of them. Turn the robot around below. The robot is the same one that was built in the last section.
The robot model can also be placed inside a physics simulator, a program that copies the rules of the real world. A tool named Gazebo does this for ROS 2. The simulator can reproduce movement, gravity, friction and collisions, and also how the robot interacts with its surroundings. Try it below: drive a robot up a ramp toward a wall, or drop it from a height. Change gravity, friction and bounciness and watch what changes.
Many robot sensors can be simulated too, so the robot software can receive simulated sensor information without any real sensor. The PDF names three: the laser scanner, the sonar and the camera. A robot plus an environment plus physics plus sensors makes a simulated robot system. Drag the robot around the room below and watch what each sensor reports.
The reason is simple: test and debug the robot’s behaviour before using real hardware. Simulation reduces hardware damage, testing cost, development time and risk. It helps students, who can learn and try ideas without buying a robot, and it helps professionals, who can find errors and unsafe behaviour before the real robot is switched on. Simulation is not the real world, though, and some problems only appear on the real robot. Slide the numbers below to see the trade.