WEBVTT 00:00.590 --> 00:07.180 Now that we know how to create an RDF model of the robot and how to visualize it in RVs. 00:07.190 --> 00:14.630 And we have also learned how to launch and configure different nodes using launch files and parameters. 00:14.900 --> 00:20.960 Let's see how to leverage these skills to simulate our robot inside a physics engine. 00:22.430 --> 00:23.420 For the simulation. 00:23.420 --> 00:27.800 In this course, we are going to use a physics engine called Gazebo. 00:28.550 --> 00:35.540 A physics simulator is a software capable of simulating certain physical phenomena such as gravity, 00:35.570 --> 00:38.030 friction, acceleration, and so on. 00:38.670 --> 00:45.240 By implementing these physical laws, the software simulates the behavior of objects that are subjected 00:45.240 --> 00:46.950 to the forces of the world. 00:47.610 --> 00:53.430 There are several physics engines available, and many of them are also often used for creating video 00:53.430 --> 00:54.060 games. 00:54.510 --> 01:02.130 In the field of robotics, Gazebo is certainly one of the most widely used and perhaps one of the easiest 01:02.130 --> 01:03.600 to integrate with Ros two. 01:04.590 --> 01:11.310 It offers various functionalities that are very useful for simulating and debugging robotics application. 01:11.940 --> 01:18.240 In fact, within this physics engine not only is possible to simulate the behavior and the movements 01:18.240 --> 01:23.460 of our robot, but also to simulate the sensors that the robot is equipped with. 01:23.490 --> 01:31.170 And it's even possible to recreate virtual environments such as houses, offices and schools in which 01:31.170 --> 01:32.490 we can move our robot. 01:33.410 --> 01:40.160 But how does all of this works and how does it integrate with Ros2 and with the Ros2 tools that we have 01:40.160 --> 01:41.240 studied so far? 01:42.100 --> 01:45.760 Let's assume that we have a real robot with real hardware. 01:45.760 --> 01:52.810 So the robot's motors, or more precisely the encoders, will publish messages, for example, within 01:52.810 --> 01:54.580 a specific ros2 topic. 01:54.880 --> 02:01.870 These messages can contain their current state, such as their position and the angle by which they 02:01.870 --> 02:02.770 are rotated. 02:02.800 --> 02:09.310 They will continuously publishing messages on this topic even during their movement in order to inform 02:09.310 --> 02:12.850 any other ros2 node about the state of the motors. 02:13.390 --> 02:20.320 Furthermore, assuming that our robot also has a real sensor, for example, it is equipped with a camera 02:20.320 --> 02:23.740 that provides a video stream of the robot's surroundings. 02:23.950 --> 02:31.360 This sensor can also publish the data and thus each frame of the camera within our ros2 topic from which 02:31.390 --> 02:34.930 other nodes that are interested in this information can read it. 02:35.820 --> 02:39.480 The same applies also for the actuators of the robot. 02:39.570 --> 02:45.570 This will be subscribed to a topic in order to read the comments and move accordingly. 02:46.740 --> 02:53.820 For example, one of the two nodes that might be interested in reading this information and subscribing 02:53.850 --> 02:56.890 to all these topics is arviz itself. 02:56.910 --> 03:02.250 In order to display the content of these topics within its graphical interface. 03:03.030 --> 03:06.090 But what happen when we don't have a real robot? 03:06.090 --> 03:11.460 So when we don't have real sensors and real hardware publishing these messages. 03:12.180 --> 03:14.730 This is where Gatsibo comes into play. 03:15.310 --> 03:23.110 The task of Gazebo is a simulator is to replace the same messages and provide the same data and interface 03:23.110 --> 03:27.070 that a real robot with real sensors would provide. 03:27.710 --> 03:28.640 In this way. 03:28.640 --> 03:34.550 All the other Ros, two nodes that are subscribed to these messages and perform central functionalities 03:34.550 --> 03:40.460 with them will be unaware of whether this information is being published by a real robot. 03:40.460 --> 03:47.600 So by a real hardware or just by simulated one, they will function the same independently of who is 03:47.600 --> 03:49.070 publishing this message. 03:49.690 --> 03:55.960 For example, Arvest will display the sensor messages in the same way, whether they come from real 03:55.960 --> 03:58.990 sensors or also from simulated ones in Gazebo. 03:59.730 --> 04:07.170 Furthermore, this allows us to easily test a newly developed node in the simulated robot as we won't 04:07.200 --> 04:08.940 need any hardware component. 04:09.360 --> 04:15.420 Then when we have built the real robot, we can also use the same code that we have already tested in 04:15.420 --> 04:21.370 the simulated environment in the real robot as well, without the need of any modification to the code. 04:21.390 --> 04:23.670 Since the interface will be the same. 04:24.350 --> 04:25.280 Enough talking. 04:25.280 --> 04:27.470 Let's simulate our robot in Gazebo.