WEBVTT 00:00.260 --> 00:06.470 In this lesson, we will examine in detail the working principle of another tool available in Ros2, 00:06.710 --> 00:13.160 which provides an alternative communication protocol between nodes different from the publisher subscriber 00:13.160 --> 00:15.110 protocol we have used so far. 00:15.410 --> 00:17.420 These are called services. 00:18.110 --> 00:26.240 A service in Ros2 is a node that offers some functionalities to other nodes and use a request response 00:26.240 --> 00:32.240 communication protocol instead of a publisher subscriber protocol used within topics. 00:32.810 --> 00:38.210 Let me give you an example to help you understand how this protocol and our services works. 00:38.660 --> 00:45.260 Let's say you are implementing a node, an application in order to that detects faces from a camera 00:45.290 --> 00:49.220 image and moves the robot to follow the detected phase. 00:49.820 --> 00:55.220 This node contains various functionalities, one of which is the face recognition. 00:55.250 --> 01:02.510 It basically takes a camera frame as input and provides the position of the face in the image as output. 01:03.130 --> 01:08.950 Once you have implemented this application, you can continue to develop new nodes and add new functionalities 01:08.950 --> 01:09.820 to your robot. 01:10.120 --> 01:16.570 For example, one of these new functionalities is to make the robot speak when a person is detected 01:16.720 --> 01:17.320 nearby. 01:18.400 --> 01:24.220 Among the other functionalities implemented in this node for making the robot speak, you realize that 01:24.220 --> 01:28.990 you need the face recognition function that you have already implemented in the previous node. 01:29.110 --> 01:33.790 So you decide to simply copy paste the code into the new node. 01:34.780 --> 01:38.170 In the software development in general, not just in robotics. 01:38.200 --> 01:44.080 Copy Pasting the code that performs the same operation in different places is always a bad idea. 01:44.230 --> 01:50.290 If you need to change a few lines of code or to use a faster and more efficient algorithm, or even 01:50.290 --> 01:56.710 to switch to a different library for face detection, you will have to apply these changes in two different 01:56.710 --> 02:00.160 places and ensure that they work in both places. 02:00.840 --> 02:04.230 This is why there are the two services. 02:04.380 --> 02:11.100 They allow you to offer the same functionality to different nodes without rewriting the same code in 02:11.100 --> 02:12.270 multiple nodes. 02:12.300 --> 02:19.050 In practice, instead of having a duplicate of the face recognition function in each node, we create 02:19.050 --> 02:26.010 a new node, specifically a service server which contains this functionality and offers it to other 02:26.010 --> 02:26.610 nodes. 02:27.210 --> 02:33.720 This way, the face recognition function is implemented only once, only in one place, and you only 02:33.720 --> 02:37.910 need to maintain, test and optimize it in one place. 02:37.920 --> 02:45.540 Afterward, you can guarantee that it will work the same way in all the nodes that require this functionality. 02:46.640 --> 02:53.300 To use a function provided by a service in routes to a different communication protocol is used compared 02:53.300 --> 02:57.230 to the topics instead of the publisher Subscriber protocol. 02:57.320 --> 03:01.910 A request response protocol is used in this communication protocol. 03:01.940 --> 03:08.660 The node that needs the functionality offered by the server is called client and sends a request message 03:08.660 --> 03:11.570 to the server requesting its functionalities. 03:12.210 --> 03:18.720 This request message can also contain some arguments, some data that the server needs to use to perform 03:18.720 --> 03:19.980 its functionalities. 03:20.190 --> 03:26.340 For example, in a service server that offers a face recognition function, it is useful to provide 03:26.340 --> 03:28.050 to the server with the frame. 03:28.050 --> 03:34.440 So with the camera image on which the server should perform the face recognition and this is done within 03:34.440 --> 03:35.790 the request message. 03:36.440 --> 03:42.320 Once our request message is received, the service server implements its logic and for example, it 03:42.320 --> 03:49.580 performs the face recognition on the image and then generates an output containing the face position 03:49.580 --> 03:50.600 in the image. 03:51.440 --> 03:52.370 This output. 03:52.370 --> 03:58.580 So the information returned from the execution of the service server is sent back to the client in a 03:58.580 --> 04:04.970 response message which can then be used by the client, for example, to move the robot in the direction 04:04.970 --> 04:06.500 of the detected phase. 04:06.860 --> 04:13.310 Similarly, any other note that needs the same functionality can send a request to the service server. 04:13.340 --> 04:19.340 The server process the request and returns an output with a response message. 04:20.140 --> 04:26.590 In this communication protocol, there are two actors, a service server node that offers a service 04:26.590 --> 04:32.290 and a service client node that requests the functionalities offered by the server. 04:32.650 --> 04:38.860 For example, a service server can also be a node that calculates an integral and instead of letting 04:38.860 --> 04:45.040 every node implementing the logic and the code for the calculation of the integral, they can directly 04:45.040 --> 04:48.880 call the service server and request for such calculation. 04:49.930 --> 04:56.830 The communication begins when the client node requests the server functionality with a request message. 04:57.130 --> 05:04.960 The service server that received the requests start processing it and performs the necessary calculation 05:04.960 --> 05:07.150 to answer to the request. 05:07.180 --> 05:10.900 For example, it starts calculating the requested integral. 05:11.540 --> 05:18.890 While the server processes the request, the client can continue executing other functionalities while 05:18.890 --> 05:20.720 waiting for the server response. 05:21.230 --> 05:27.560 When this happens, when the server finishes its calculation, it sends a response message with the 05:27.560 --> 05:33.530 result of the calculation to the client, which is notified about this event, about the completion 05:33.560 --> 05:40.880 of the service execution and can finally use the server processing results to continue its execution.