WEBVTT 00:00.050 --> 00:03.920 What is a ros2 service as we did for Ros topics. 00:03.920 --> 00:06.710 Let's start with a real life analogy. 00:06.740 --> 00:10.640 I will make an analogy with an online weather service here. 00:10.640 --> 00:12.650 Again, this is just an analogy. 00:12.650 --> 00:18.470 So the point is to make things simple enough and to focus on understanding ros2 services. 00:18.470 --> 00:25.580 Let's say we have a weather service online which can give us the local weather after we send our location. 00:25.580 --> 00:31.310 Now imagine that you are behind your computer and you want to get the weather from this service. 00:31.310 --> 00:38.060 You on your site are considered as the client and the weather service online is the server. 00:38.090 --> 00:43.940 You will be able to access the server through an HTTP request with a URL. 00:43.970 --> 00:48.890 You can think of the http url as a ros2 service name. 00:48.890 --> 00:53.330 So first of all, your computer will send a request to the server. 00:53.360 --> 00:55.580 The request will contain a message. 00:55.580 --> 01:02.810 Here we send our location and the server will then process the request and send back a response. 01:02.810 --> 01:06.160 The response will also contain a message here. 01:06.160 --> 01:08.020 The requested weather. 01:08.050 --> 01:14.890 Note that in order to communicate, the request sent by the client must be a location, or else the 01:14.890 --> 01:20.740 server will not be able to process the data and the server must send back a weather data. 01:20.770 --> 01:25.180 Otherwise the client will not understand what the response is. 01:25.210 --> 01:30.550 Okay, we have now one client and one server communicating through a service. 01:30.550 --> 01:33.070 But what if we have multiple clients? 01:33.070 --> 01:34.930 Well, that's not a problem. 01:34.930 --> 01:42.580 All the clients will send a request containing a location to the server through the same http url. 01:42.610 --> 01:49.000 The server will then process the requests and send back a response to each client, so you can have 01:49.000 --> 01:50.020 several clients. 01:50.020 --> 01:55.840 However, note that you should not have more than one server for the same service here. 01:55.840 --> 02:01.270 With this example, if we come back to the Ros2 terminology, we have three different computer nodes 02:01.270 --> 02:03.790 and one node for the weather service. 02:03.790 --> 02:08.050 The http url can be seen as a ros2 service name. 02:08.050 --> 02:11.650 The computer nodes each contain a service client. 02:11.680 --> 02:18.700 This service client will call the Ros two service and send a request with a location on the other side. 02:18.700 --> 02:25.570 The weather service contains a Ros to service server, which will process all the requests and send 02:25.570 --> 02:29.410 back a response through the Ros two service. 02:29.410 --> 02:37.120 And again, all clients and the server inside nodes are not aware of each other, they only see up to 02:37.150 --> 02:38.830 the service interface. 02:38.860 --> 02:43.120 Now let's see another example, this time dealing directly with robotics. 02:43.120 --> 02:47.260 This example can be a part of a real Ros two application. 02:47.260 --> 02:53.290 So let's say that you have one node in your application which is controlling an LED panel. 02:53.320 --> 02:58.210 The node is dealing with the hardware to power on and power off the LEDs. 02:58.240 --> 03:02.080 Of course you want this node to be able to communicate with the outside. 03:02.080 --> 03:08.410 For example, other nodes could ask this node to power on or off a specific LED. 03:08.680 --> 03:12.070 In this case, you create a Ros to service that you name. 03:12.070 --> 03:14.210 For example set LED. 03:14.570 --> 03:16.550 Inside the LED panel node. 03:16.550 --> 03:21.350 You will have a service server for this set LED service. 03:21.380 --> 03:26.960 Now you have another node in your application dealing with the battery of a robot. 03:26.990 --> 03:32.360 One of the functionalities is to check if the battery is low and to notify the user. 03:32.360 --> 03:35.300 Let's say that we want to turn on one LED. 03:35.330 --> 03:41.360 To do that, the battery node will contain a service client for the set led service. 03:41.390 --> 03:44.060 Imagine now that the battery is going low. 03:44.090 --> 03:49.460 When it is detected, the battery node will send a request to the Ros2 service. 03:49.460 --> 03:52.520 It will send an LED number and a state. 03:52.520 --> 03:57.830 The server, which is the LED panel node, will expect to receive that information. 03:57.830 --> 04:04.220 If the data structure is the same as expected, the node can process the information and as requested 04:04.220 --> 04:06.530 here, power on the third LED. 04:06.650 --> 04:10.310 Once this is done, the server will send back a response. 04:10.340 --> 04:16.760 The response here will contain a success flag, and during this process, the battery node is waiting 04:16.790 --> 04:23.070 synchronously or asynchronously with a callback upon reception of that success flag. 04:23.100 --> 04:28.710 The battery node knows that the requested action was successfully done or not. 04:28.710 --> 04:29.700 And that's it. 04:29.700 --> 04:31.860 The communication is finished. 04:31.860 --> 04:35.430 The server is still up and waiting for new requests. 04:35.460 --> 04:41.640 Later on, after charging the battery, the battery node detects that the battery is now full again. 04:41.670 --> 04:47.760 It will then decide to send a new request to the set led service to power off the third LED. 04:48.270 --> 04:55.020 The server receives this request, performs the operation, and sends back a success flag. 04:55.020 --> 04:57.180 The communication is done. 04:57.210 --> 04:58.080 All right, that's it. 04:58.080 --> 05:04.260 For this example, you should now have a better idea of what Ros2 services are and when you should use 05:04.260 --> 05:04.680 them. 05:04.710 --> 05:09.540 To recap here, a Ros2 service is a client server system. 05:09.540 --> 05:12.690 It can be either synchronous or asynchronous. 05:12.690 --> 05:18.840 When synchronous, the client will send a request and then block until it receives a response. 05:18.840 --> 05:26.030 When asynchronous, the client will send a request and then register a callback function for the response 05:26.030 --> 05:28.280 and continue its execution. 05:28.280 --> 05:33.890 When the server replies, the callback will be triggered and as you will see later, that's the method 05:33.890 --> 05:35.030 that we will choose. 05:35.060 --> 05:40.610 Also, a service is defined by a name and a pair of messages. 05:40.610 --> 05:42.890 So two messages here. 05:42.890 --> 05:47.510 One message is the request, the other one is the response. 05:47.540 --> 05:54.440 As for nodes and topics, you can directly create service clients and servers inside ros2 nodes using, 05:54.440 --> 06:00.530 for example, the RCL cpp library for Cplusplus and the CLP library for Python. 06:00.620 --> 06:08.360 Finally, and this is an important point, a service server can only exist once, but can have many 06:08.360 --> 06:14.240 clients and basically the service will start to exist when you create the server. 06:14.270 --> 06:19.520 To conclude, you can see that services offer a nice complementarity with topics. 06:19.550 --> 06:25.730 Topics will be used for unidirectional data streams and services will be used when you need a client 06:25.730 --> 06:26.270 server. 06:26.270 --> 06:27.470 Communication.