WEBVTT 00:00.510 --> 00:06.600 Another essential feature implemented by an operating system is the management and the communication 00:06.600 --> 00:13.950 between processes, enabling different processes often executed in parallel to exchange messages and 00:13.950 --> 00:14.910 information. 00:15.540 --> 00:16.280 In Russia. 00:16.680 --> 00:24.480 These processes are called nodes where a node is simply an application that performs a specific functionality. 00:24.510 --> 00:31.020 For example, a node could be a mobile robot application that plans a path to a goal while avoiding 00:31.020 --> 00:31.800 obstacles. 00:32.310 --> 00:38.430 This node may require information processed in other nodes such as obstacle detection. 00:39.100 --> 00:47.140 Communication between two nodes in ros2 can occur in three different ways using three different communication 00:47.140 --> 00:47.950 protocols. 00:48.430 --> 00:54.970 The first mode is through topics using the publisher subscriber communication protocol. 00:55.540 --> 01:03.490 In this communication protocol, a node also known as publisher, publish a message within a topic which 01:03.490 --> 01:06.850 acts as a channel in the same channel. 01:06.880 --> 01:14.770 Another node known as subscriber can listen and so can receive all the messages that are transmitted 01:14.770 --> 01:16.240 within that channel. 01:17.100 --> 01:23.040 Multiple nodes can subscribe to the same channel simultaneously as several applications. 01:23.040 --> 01:27.030 Might be interested in the data transmitted within the channel. 01:27.800 --> 01:33.920 Moreover, within the same channel, multiple applications can also send messages. 01:34.490 --> 01:41.810 There is no limit to the number of channels that can be created as long as each channel is identified 01:41.810 --> 01:43.610 by an unique name. 01:43.850 --> 01:50.720 For instance, a node can publish within two topics or two channels, while another node can listen 01:50.720 --> 01:54.470 and receive messages that are transmitted in both channels. 01:55.180 --> 02:02.500 Furthermore, a node is not limited to being only a publisher or a subscriber, but can fulfil both 02:02.500 --> 02:03.940 roles simultaneously. 02:04.090 --> 02:09.970 A node can be, for example, interested in data transmitted within a channel, then process it and 02:09.970 --> 02:15.010 then republish the processed result in a separate channel in a separate topic. 02:16.480 --> 02:22.960 The second communication protocol that is available in Ros two for Inter-process communication is through 02:22.960 --> 02:23.800 services. 02:24.630 --> 02:26.340 In this communication protocols. 02:26.340 --> 02:29.880 There are two actors involved, a service server. 02:29.880 --> 02:34.710 So that is a node that offers a functionality as a service client. 02:34.710 --> 02:39.840 That is another node that requests the functionalities provided by the server. 02:40.320 --> 02:46.290 For example, a service server node can offer the functionality for the calculation of an integral. 02:46.290 --> 02:53.760 And so any other node that requires to calculate the integral instead of implementing the logic and 02:53.760 --> 02:57.030 the code can instead directly call the server. 02:58.040 --> 03:05.000 The communication begins when the client node sends a request to the server that is offering this functionality 03:05.000 --> 03:07.280 by sending a request message. 03:07.730 --> 03:15.080 The service server upon receiving a request, process it, and performs the necessary calculation to 03:15.080 --> 03:16.700 respond to the request. 03:16.730 --> 03:20.660 For example, in this case calculating the requested integral. 03:21.540 --> 03:27.900 While the server processes the request, the client can continue its execution and, for example, may 03:27.900 --> 03:33.090 perform other operation while he's waiting for the server to complete the request. 03:33.090 --> 03:35.310 And so to return a response. 03:36.170 --> 03:42.740 Once the server completes its processing, it sends back a response message containing the result back 03:42.740 --> 03:47.780 to the client, who can then use this information and continue with its execution. 03:50.060 --> 03:56.750 The third and last communication protocol for Inter-node communication that is available in Ros2 is 03:56.750 --> 03:57.980 through actions. 03:58.770 --> 04:06.840 In this communication protocol, the actors are again two nodes, an action server that offers an action, 04:06.840 --> 04:14.190 and this is typically a long running task and an action client that requests the action execution. 04:14.890 --> 04:21.400 Despite its similarity to the services action communication differs in the type of the functionality 04:21.430 --> 04:23.980 provided by the server to the client. 04:24.570 --> 04:31.230 As we have seen, our service server can offer functionalities like calculating an integral, which 04:31.230 --> 04:34.080 has a relatively quick execution time. 04:34.740 --> 04:42.960 Conversely, an action server may offer a navigation service for a robot from a point A to point B, 04:42.990 --> 04:45.900 which is clearly a more time consuming task. 04:46.580 --> 04:53.450 Thus, it is preferable to use an action server to implement such functionalities rather than a service 04:53.450 --> 04:54.140 server. 04:55.210 --> 05:02.290 Communication through actions begins when the client node requests the execution of the action offered 05:02.290 --> 05:05.110 by the server by sending a goal message. 05:05.590 --> 05:12.340 For example, if in this case the action server is offering a robot navigation functionality, the goal 05:12.340 --> 05:17.470 can be the desired position or the destination that the robot needs to reach. 05:18.250 --> 05:24.520 Upon receiving the goal, the action server initiates its functionalities, performing all the necessary 05:24.520 --> 05:31.510 calculations and movements to guide the robot to the desired position, and it remains in the execution 05:31.510 --> 05:33.310 until the goal is achieved. 05:34.070 --> 05:37.630 Since to complete this action might take some time. 05:37.640 --> 05:43.910 The client node can continue executing other operations while waiting for the server to complete its 05:43.910 --> 05:44.840 execution. 05:45.500 --> 05:53.000 In this case, unlike services, the action server periodically sends feedback messages to the client, 05:53.000 --> 05:58.250 informing it about the progress of the action while it's being executed. 05:59.060 --> 06:05.720 Finally, once the goal is achieved, the action server notifies the client of the completion of its 06:05.720 --> 06:08.600 execution by sending a result message. 06:10.080 --> 06:12.090 During the action execution. 06:12.090 --> 06:20.430 So after the client has initiated the server execution with the goal message, upon receiving the initial 06:20.430 --> 06:27.870 feedback messages, the client may decide to cancel the action if it is not satisfied with the partial 06:27.870 --> 06:30.690 feedback or if the goal, for example, has changed. 06:31.750 --> 06:37.690 This is achieved by sending a cancel message from the action client to the action server. 06:38.230 --> 06:46.360 Anyway, upon receiving the cancel message, the action server interrupts its execution and returns 06:46.390 --> 06:52.210 a result message to the client, indicating that the action has been successfully aborted.