Now that we know how to create an RDF model of the robot and how to visualize it in RVs.
And we have also learned how to launch and configure different nodes using launch files and parameters.
Let's see how to leverage these skills to simulate our robot inside a physics engine.
For the simulation.
In this course, we are going to use a physics engine called Gazebo.
A physics simulator is a software capable of simulating certain physical phenomena such as gravity,
friction, acceleration, and so on.
By implementing these physical laws, the software simulates the behavior of objects that are subjected
to the forces of the world.
There are several physics engines available, and many of them are also often used for creating video
games.
In the field of robotics, Gazebo is certainly one of the most widely used and perhaps one of the easiest
to integrate with Ros two.
It offers various functionalities that are very useful for simulating and debugging robotics application.
In fact, within this physics engine not only is possible to simulate the behavior and the movements
of our robot, but also to simulate the sensors that the robot is equipped with.
And it's even possible to recreate virtual environments such as houses, offices and schools in which
we can move our robot.
But how does all of this works and how does it integrate with Ros2 and with the Ros2 tools that we have
studied so far?
Let's assume that we have a real robot with real hardware.
So the robot's motors, or more precisely the encoders, will publish messages, for example, within
a specific ros2 topic.
These messages can contain their current state, such as their position and the angle by which they
are rotated.
They will continuously publishing messages on this topic even during their movement in order to inform
any other ros2 node about the state of the motors.
Furthermore, assuming that our robot also has a real sensor, for example, it is equipped with a camera
that provides a video stream of the robot's surroundings.
This sensor can also publish the data and thus each frame of the camera within our ros2 topic from which
other nodes that are interested in this information can read it.
The same applies also for the actuators of the robot.
This will be subscribed to a topic in order to read the comments and move accordingly.
For example, one of the two nodes that might be interested in reading this information and subscribing
to all these topics is arviz itself.
In order to display the content of these topics within its graphical interface.
But what happen when we don't have a real robot?
So when we don't have real sensors and real hardware publishing these messages.
This is where Gatsibo comes into play.
The task of Gazebo is a simulator is to replace the same messages and provide the same data and interface
that a real robot with real sensors would provide.
In this way.
All the other Ros, two nodes that are subscribed to these messages and perform central functionalities
with them will be unaware of whether this information is being published by a real robot.
So by a real hardware or just by simulated one, they will function the same independently of who is
publishing this message.
For example, Arvest will display the sensor messages in the same way, whether they come from real
sensors or also from simulated ones in Gazebo.
Furthermore, this allows us to easily test a newly developed node in the simulated robot as we won't
need any hardware component.
Then when we have built the real robot, we can also use the same code that we have already tested in
the simulated environment in the real robot as well, without the need of any modification to the code.
Since the interface will be the same.
Enough talking.
Let's simulate our robot in Gazebo.