WEBVTT 00:00.260 --> 00:06.050 In this lesson, we are going to study another very powerful and useful tool available in Ros two, 00:06.440 --> 00:13.430 which will allow us to develop application more easily, start the execution, control their status 00:13.430 --> 00:16.490 and being notified at the end of their execution. 00:17.140 --> 00:23.680 These are the rescue actions which represent an alternative communication protocol between the rescue 00:23.680 --> 00:24.430 nodes. 00:24.610 --> 00:31.270 In addition to the publisher subscriber protocol used by the Ros2 topics, and in addition to the request 00:31.270 --> 00:38.830 response protocol used by the rescue services actions offered a new communication protocol that we can 00:38.830 --> 00:41.710 define as goal feedback result. 00:42.040 --> 00:48.190 Let me give you a practical example to understand how this communication protocol works and when we 00:48.190 --> 00:49.060 can use it. 00:49.990 --> 00:56.020 Let's say that we have equipped our robot with a camera and we have developed our computer vision algorithm 00:56.020 --> 01:03.010 that uses the camera to detect the position of an object, let's say a pen, so that the robot can grasp 01:03.010 --> 01:03.400 it. 01:04.430 --> 01:10.880 As our good robotic software developer, we organize our application into different nodes, each of 01:10.880 --> 01:13.070 which performs a specific task. 01:13.550 --> 01:20.750 One of these nodes is called pen detector, which simply subscribes to the camera messages to detect 01:20.750 --> 01:23.420 the presence and position of a pen. 01:24.140 --> 01:31.880 Then we develop a second node, the grab pen node, which is responsible for moving the robot to a predefined 01:31.910 --> 01:34.130 position and grasping an object. 01:34.640 --> 01:42.500 We can implement this node so the grab pen as an action server, meaning it acts as a node that handles 01:42.500 --> 01:49.520 the robot movement from its current pose to a desired pose and offers this functionality to all the 01:49.520 --> 01:53.180 other nodes that needs to move the robot to a specific position. 01:53.180 --> 01:56.510 And this includes also our pen detector node. 01:57.240 --> 02:04.110 Once the append position is detected, the pen detector node simply needs to send a goal to the action 02:04.110 --> 02:10.590 server containing the position of the pen to the grab pen node, which then takes care of moving the 02:10.590 --> 02:12.570 robot to the desired position. 02:13.720 --> 02:19.840 Upon receiving the gold message containing the desired pose of the robot, the action server starts 02:19.840 --> 02:24.520 planning a trajectory and moves the robot to reach the desired position. 02:25.410 --> 02:31.890 Since this operation may take some time to complete while the action server performs its functionalities 02:31.890 --> 02:38.730 and moves the robot to the desired position, the pen detector node, namely the action client. 02:38.730 --> 02:45.510 So the one who requested the execution of this server continues with its execution independently from 02:45.510 --> 02:52.470 what the action server is doing and is only notified with some feedback messages about the server progresses 02:52.950 --> 02:53.840 and so on. 02:53.850 --> 02:59.670 So while the robot moves, while the robot approaches its goal, the action server that is managing 02:59.670 --> 03:04.680 its execution continuously sends feedback message to the action client. 03:05.070 --> 03:11.940 Finally, when the robot reaches its goal as requested, the action server sends a result message to 03:11.940 --> 03:15.660 the client to inform about the completion of the action. 03:16.380 --> 03:23.340 This message is also sent by the server to the client, even if the action fails to execute, for example, 03:23.340 --> 03:26.400 due to an obstacle along the robot trajectory. 03:27.450 --> 03:35.100 This communication protocol in addition to the goal feedback and result messages also has a cancel message, 03:35.250 --> 03:36.750 as the name suggests. 03:36.780 --> 03:43.560 This message allows the action client to request the cancellation of a goal that was being executed 03:43.560 --> 03:44.880 by the action server. 03:45.650 --> 03:52.850 So let's still assume that our pen detector node has detected the presence and the position of a pen 03:52.850 --> 03:54.730 using the robot's camera. 03:54.740 --> 04:01.610 And it sends a goal message to the action server asking the robot to move to a specific position and 04:01.610 --> 04:02.570 grab the pen. 04:03.440 --> 04:06.170 The action server starts its execution. 04:06.170 --> 04:08.870 And so it starts the robot's movements. 04:09.810 --> 04:16.110 However, during the execution, the pen detector node realizes that the pen has been removed. 04:16.140 --> 04:21.810 It is no longer in the previous position, so the robot doesn't need to reach that position. 04:21.840 --> 04:26.460 The action has no reason to continue since there is nothing to grasp anymore. 04:27.170 --> 04:33.950 For this reason the action client so depend detector node can send a cancel message to the server. 04:34.550 --> 04:41.060 Upon receiving this message, the action server handle the goal cancellation and then safely stops the 04:41.060 --> 04:41.720 robot. 04:42.510 --> 04:49.600 In any case, regardless of whether the action was cancelled at the action, client requests the grab 04:49.600 --> 04:56.730 a pen node so the action server still sends a result message at the end of the action cancellation to 04:56.730 --> 05:00.870 inform the client whether the cancellation was successful or not. 05:01.860 --> 05:09.390 To summarize in this communication protocol, there are two actors an action server that offers an action, 05:09.420 --> 05:16.590 typically a task with a long execution time and an action client that requests the action execution. 05:16.980 --> 05:24.480 Another example of an action server can be a node that offers the robot navigation from a point A to 05:24.570 --> 05:26.250 point B as an action. 05:26.930 --> 05:33.620 Clearly this is a task that takes more time to complete, so it's preferable to use an action server 05:33.620 --> 05:37.700 rather than using a service to provide such functionality. 05:38.370 --> 05:44.640 Communication through actions begins with the client node requesting the execution of the action offered 05:44.640 --> 05:46.820 by the server with a goal message. 05:46.830 --> 05:50.990 For instance, for the action server implementing the robot navigation. 05:51.000 --> 05:55.500 The goal could be the point, the position that the robot needs to reach. 05:56.380 --> 06:02.350 Upon receiving the goal, the action server starts its functionalities and executes the calculation 06:02.350 --> 06:06.300 and movements needed to make the robot reach the desired pose. 06:06.310 --> 06:10.750 And so it also remains in execution until the goal is reached. 06:11.970 --> 06:14.940 Since completing the action could take some time. 06:15.090 --> 06:21.920 While the client waits for the server to finish its execution, it can continue executing other operations, 06:21.940 --> 06:26.610 other functionalities in this case at regular time intervals. 06:26.610 --> 06:32.850 So during the execution of the goal, the action server can send feedback messages that inform the client 06:32.850 --> 06:34.980 about the progress of the action. 06:35.340 --> 06:41.880 Finally, once the goal is achieved, the action server informs the client about the completion of the 06:41.880 --> 06:43.830 action with our result message. 06:44.340 --> 06:51.570 It may also happen that during the execution so after the client has initiated the server execution 06:51.570 --> 06:59.850 with the goal message upon receiving the first feedback messages, the client may decide to cancel the 06:59.850 --> 07:05.610 execution if is not satisfied, for example, of the partial feedback that is getting. 07:06.530 --> 07:13.910 Upon receiving the cancel message, the action server interrupts its execution and in any case, it 07:13.910 --> 07:20.120 sends back a result message to the client to notify that the action has been correctly cancelled.