WEBVTT 00:00.510 --> 00:01.580 Robotic enthusiast. 00:02.000 --> 00:09.920 Finally, we have a model of the robot that you can use to visualize interviews or to simulate in Gazebo. 00:10.640 --> 00:14.030 We can use this model to develop now new functionalities. 00:14.750 --> 00:21.770 However, so far our robot is static and so we are not yet able to move the robot in the simulated environment 00:21.770 --> 00:22.700 of gazebo. 00:22.970 --> 00:26.150 For the moment, our robot is just a nice decoration. 00:26.860 --> 00:33.520 In this section, we will talk about the first and perhaps the most elementary functionality that a 00:33.520 --> 00:40.180 robot must implement, which is to actuate the joint motors in response to a received command. 00:40.570 --> 00:47.290 This functionality, although the most basic, it is also fundamental as it will be used by all the 00:47.290 --> 00:54.370 other modules that perform advanced operation with the robot to move it accordingly to the own logic. 00:55.330 --> 01:02.170 The operation of sending a command to a robot following its movement and ensuring that it matches the 01:02.170 --> 01:09.520 desired movement is called control, and it is an entire field of study that deals with the development 01:09.520 --> 01:14.200 of the mathematics for creating a component called controller. 01:14.980 --> 01:18.790 The goal of this discipline is very simple and practical. 01:18.960 --> 01:26.110 It's to implement a logic that activates a certain system, in this case, a motor as required by the 01:26.110 --> 01:27.250 input variable. 01:27.610 --> 01:34.480 For example, a goal, an input variable that we can send to the control system is to rotate the motor 01:34.480 --> 01:39.700 to reach a certain angle, let's say a position of 90 degrees. 01:39.910 --> 01:46.480 So this goal, this input variable that we pass to the control system contains the desired value of 01:46.480 --> 01:47.740 the system movements. 01:48.490 --> 01:52.510 This input is compared with the current state of the system. 01:52.510 --> 01:58.750 So with the current state of the motor, because it can also happen that the motor, for example, is 01:58.750 --> 02:04.510 already at the desired position and therefore it doesn't need to move to reach it. 02:04.780 --> 02:11.320 So the difference between the current state of the motor that is called output and the goal that we 02:11.320 --> 02:17.350 assigned to the motor that is called input produces a new variable called error. 02:18.220 --> 02:21.970 This variable indicates how far the current state of the motor. 02:21.970 --> 02:25.660 So the output variable is from the desired state. 02:25.660 --> 02:27.800 So the input variable. 02:27.820 --> 02:33.190 For example, let's assume that the motor is currently in the zero degree position. 02:33.190 --> 02:36.130 So in this case the output variable is zero. 02:36.130 --> 02:42.640 And let's also say that we instruct the motor to move in the 90 degrees position, which means that 02:42.640 --> 02:45.040 we are setting the input variable to 90. 02:45.550 --> 02:51.910 Now the error variable will be the difference between the input variable, which is 90 degrees and the 02:51.910 --> 02:56.710 output variable which is zero because the motor is indeed zero degree position. 02:56.710 --> 03:00.250 So the error variable will be 90 degrees. 03:01.300 --> 03:07.900 The purpose of developing a control system is to create a block called controller that receives the 03:07.900 --> 03:13.090 error variable as input and converts it into a command to send to the motor. 03:13.690 --> 03:20.320 This calculation is done with the aim of minimizing the error variable so that its value gets closer 03:20.320 --> 03:23.530 and closer to zero and also as quickly as possible. 03:24.130 --> 03:30.490 This calculation is done with the aim of minimizing the error variable so that its value gets closer 03:30.490 --> 03:33.580 and closer to zero as quickly as possible. 03:34.590 --> 03:40.350 Upon receiving the comment, the motor starts to rotate and gradually change its angle. 03:40.350 --> 03:44.460 So it's position and then the control loop is executed again. 03:44.850 --> 03:50.460 As the motor moves to reach the desired position, the error variable will no longer be equal to 90 03:50.460 --> 03:56.640 degrees because the motor is getting closer to it and the closer it gets, the smaller the error variable 03:56.670 --> 04:03.750 becomes and consequently the comments sent by the motor and consequently also the command that is sent 04:03.750 --> 04:05.550 by the control system to the motor. 04:06.300 --> 04:12.570 When the motor finally reaches the desired position that is 90 degree, then the output variable finally 04:12.570 --> 04:14.400 matches the input variable. 04:14.400 --> 04:15.750 And so the difference. 04:15.750 --> 04:18.630 So the error variable is finally zero. 04:19.700 --> 04:22.900 The control problem is common to all robots. 04:22.910 --> 04:27.830 Whether you want to develop a manipulator or a mobile base or even a drone. 04:27.980 --> 04:33.650 Sooner or later in the development of your robots, you will have to deal with the control problem, 04:33.650 --> 04:40.820 which means sending commands to actuators and receiving feedback from the sensors on how the actuators 04:40.820 --> 04:42.950 we commanded have actually moved. 04:44.650 --> 04:50.740 For this reason, since this is a common problem for all robots, there is a fantastic framework in 04:50.740 --> 04:53.710 Ros two called Ros to control. 04:54.760 --> 04:59.470 At the core of this framework, there are components called hardware resources. 04:59.620 --> 05:06.580 This can be composed of actuators to which we can send commands or sensors from which we can retrieve 05:06.580 --> 05:12.010 information about the state of an actuator, such as its velocity or position. 05:12.900 --> 05:19.890 Additionally, an hardware resource can also represent an entire complex system composed of several 05:19.890 --> 05:21.450 actuators and sensors. 05:21.930 --> 05:29.280 All these components can be both real or also simulated within the physical engines, including Gazebo. 05:30.250 --> 05:32.590 To interface with the hardware resources. 05:32.620 --> 05:36.820 The Ros2 Control Library provides two interfaces. 05:36.940 --> 05:40.630 The command interface and the state interface. 05:42.090 --> 05:46.860 With the command interface, we can send commands to the robot's hardware. 05:46.890 --> 05:52.080 We can basically write commands with the state interface instead. 05:52.110 --> 05:57.450 We can only receive information, so we can only read the current state of the hardware. 05:57.750 --> 06:03.840 In short, with the command interface, we write commands to the hardware and with the state interface 06:03.840 --> 06:05.640 we read from the hardware. 06:06.570 --> 06:12.510 Managing this interface with the hardware resource is a component called resource manager, which is 06:12.510 --> 06:17.650 an abstraction of the actual hardware components of the robot and its drivers. 06:17.670 --> 06:24.630 It allows the reuse of already implemented hardware components without the need to implement new ones. 06:25.490 --> 06:33.050 The resource manager can load one or more hardware components and make them available and thus interactable 06:33.050 --> 06:40.160 with the other components of the control library and so with the controller manager. 06:41.140 --> 06:47.810 At this component provides an additional level of abstraction and acts as a middleware, a connection 06:47.810 --> 06:54.500 point between the resource manager and the actual controllers that implement the control logic of the 06:54.500 --> 06:56.600 specific system or actuator. 06:57.500 --> 07:04.130 In fact, the controller manager can load multiple controllers simultaneously that implement different 07:04.130 --> 07:11.240 control logics and connect them to the hardware or more precisely, connect them to the resource manager 07:11.240 --> 07:14.540 that manage the robot's hardware components. 07:15.580 --> 07:22.000 The controllers loaded by the controller manager are the components where the control logic is implemented. 07:22.030 --> 07:27.940 The one that ensures that the system output equals the desired input. 07:28.300 --> 07:34.840 In addition to developing new controllers, it is also possible to use many controllers that are already 07:34.840 --> 07:38.170 available in the Ros two Controllers library. 07:39.030 --> 07:42.480 Beware of being misled by the names of these two libraries. 07:42.990 --> 07:50.490 The Ros2 Control Library contains the definition of the controller manager and the resource manager 07:50.490 --> 07:51.420 instead. 07:51.450 --> 07:58.320 The Ros two Controllers library contains the definition of some controllers which already implement 07:58.320 --> 08:03.600 some specific control logic, for example, to move differential drive, robot and so on. 08:04.440 --> 08:10.530 In addition to connecting the controllers which implement the control logic and the hardware components 08:10.530 --> 08:17.430 which must execute the logic, the controller manager also provides an interface to others to application 08:17.430 --> 08:23.760 and even to the user who can use the command line interface, for example, to obtain the list of all 08:23.760 --> 08:29.430 the controllers or the list of all the hardware components, and then can also load the new controllers 08:29.430 --> 08:33.930 and can in general interact with the control library. 08:34.630 --> 08:42.070 Likewise other ros2 nodes and application that want to use that want to activate the hardware or obtain 08:42.070 --> 08:48.730 information about its state can do so directly through the services and the topics that are provided 08:48.730 --> 08:50.380 by the controller manager.