WEBVTT 00:00.200 --> 00:06.140 When developing a driver or an interface for a certain hardware component to communicate with. 00:06.140 --> 00:06.380 Ros. 00:06.380 --> 00:10.710 Two traditional Ros two nodes have some limitations. 00:10.760 --> 00:14.870 For this reason, Ros two introduced lifecycle nodes. 00:15.670 --> 00:19.200 To understand the importance of this new type of nodes. 00:19.210 --> 00:24.970 Let's start with an example of a true application that uses traditional nodes. 00:25.630 --> 00:32.050 Let's assume that we have a classic cross two node that acts as a driver and allows us to control a 00:32.050 --> 00:39.610 servo motor through Ros2 and also reads its data such as its current position, and make those information 00:39.610 --> 00:40.660 available in Ros to. 00:41.600 --> 00:48.950 This node acts as the servo motor driver for us two and is specific for the particular hardware that 00:48.950 --> 00:49.910 is being used. 00:50.000 --> 00:51.110 In practice. 00:51.140 --> 00:56.600 If we change the hardware so if we change the servo motor, we also need to change these drivers or 00:56.600 --> 01:00.260 these software components to be compatible with the new motor. 01:00.260 --> 01:05.600 And so with the different set of communication protocol that probably the new motor is using. 01:06.380 --> 01:08.600 All of this is invisible from the outside. 01:08.600 --> 01:14.240 So from the other nodes and application that only use the Ros two tools, for example, for the nodes 01:14.240 --> 01:20.690 that use topics, services and actions to send comments to the motors and receive the data. 01:20.690 --> 01:25.640 So they are not concerned about how this low level communication takes place. 01:26.150 --> 01:30.620 This is amazing and allows the separation of each node's purpose. 01:30.800 --> 01:37.190 For example, the application that makes the robot pick up an object so the pick pen node will work 01:37.190 --> 01:40.910 independently of the motor and the driver being used. 01:41.090 --> 01:47.600 It only needs each driver so for each motor to offer the same Ros two topics or services. 01:48.260 --> 01:55.070 The pick the pen node for example, can request the driver to move the robot to a specific position 01:55.070 --> 01:58.100 and wait until the action is completed. 01:58.310 --> 02:04.640 Despite this being very transparent to the user of the hardware internally, the driver typically needs 02:04.640 --> 02:06.360 to perform various operations. 02:06.480 --> 02:12.420 For example, it needs to configure the communication with the hardware, and this might take some time 02:12.420 --> 02:17.250 depending on the communication protocol that is being used and the hardware initialization. 02:17.730 --> 02:24.870 Meanwhile, the pick the pen node is still waiting for the driver to perform the desired movement and 02:24.870 --> 02:28.950 also has no idea what the driver is doing in the meantime. 02:29.860 --> 02:36.280 After the configuration phase, the driver can finally move on to the startup phase and so initiate 02:36.280 --> 02:40.060 the communication with the hardware and enable its operation. 02:40.570 --> 02:43.660 This phase may also take some time to complete. 02:43.690 --> 02:50.290 For example, the driver might be wanting for a response from the hardware, confirming its correct 02:50.290 --> 02:51.910 start up and operation. 02:52.240 --> 02:59.830 Again, the peak depend node is still waiting for the driver and has no idea about what the driver is 02:59.830 --> 03:05.980 doing and its current state or how much time is left for the requested command to complete. 03:06.460 --> 03:13.390 Sometimes for certain applications it might be useful to have a greater control over the nodes and their 03:13.390 --> 03:14.140 states. 03:14.260 --> 03:21.070 For example, to give a feedback to a user and provide an estimate of the time required to complete 03:21.070 --> 03:24.700 the command or simply to visualize the current state of the system. 03:25.300 --> 03:30.470 To overcome these limitations in Ros2, there are the life cycle nodes. 03:31.070 --> 03:37.730 If you are already familiar with our state machine works, then the operation of a life cycle node will 03:37.730 --> 03:38.900 be familiar to you. 03:39.490 --> 03:48.520 A lifecycle node as four states and configured inactive, active and finalized, and several transitions 03:48.520 --> 03:51.010 that allow the node to change its state. 03:52.020 --> 03:53.790 Just like with state machines. 03:53.820 --> 03:58.330 Lifecycle nodes can only be in one state at a specific moment. 03:58.350 --> 04:04.860 For example, if the node is in the Unconfigured state, it cannot also be in the active state at the 04:04.860 --> 04:06.540 same time and so on. 04:07.680 --> 04:15.270 To change states various events or transitions, namely function that changes the state of the state 04:15.270 --> 04:18.810 machine are available in each of these states. 04:18.810 --> 04:21.180 The node performs different operations. 04:21.360 --> 04:27.360 When a state is activated, the node performs the functionalities associated with the state. 04:28.370 --> 04:29.600 Upon the note creation. 04:29.600 --> 04:33.230 For example, it is in the Unconfigured state. 04:33.260 --> 04:37.610 Here the node has no information, no instantiated data. 04:38.340 --> 04:43.140 In this state, there are only two transitions, only two functions available. 04:43.560 --> 04:50.850 The node can be shut down so terminated with the shutdown function and end up in the finalized state 04:50.850 --> 04:54.360 which comes before the destruction of the node itself. 04:54.930 --> 05:02.120 Alternatively, the node can enter the inactive state with the configured transition in this state, 05:02.130 --> 05:05.610 the node does not yet perform any action or logic. 05:05.790 --> 05:13.080 The purpose of this state is to allow the node to be configured or reconfigured during its execution. 05:13.080 --> 05:19.890 For example, in this state it is possible to change the node parameters or add new publisher subscriber 05:19.890 --> 05:22.200 without changing the nodes behavior. 05:23.530 --> 05:30.220 During this stage, the node will not receive any callbacks such as subscription to topics or processing 05:30.220 --> 05:32.110 of services and so on. 05:32.110 --> 05:39.430 Any request the node receives while in this state will not be handled and will be directly rejected. 05:40.270 --> 05:44.470 In the inactive state, there are three active transitions. 05:44.500 --> 05:51.040 The node can be shut down and enter the finalized state with the shut down transition, or the node 05:51.040 --> 05:55.960 can return to the Unconfigured state with the clean up transition. 05:56.640 --> 05:59.640 This transition allows resetting the node. 05:59.640 --> 06:04.860 So to remove the configuration parameters that were set in the inactive state. 06:05.160 --> 06:12.690 Finally, from the inactive state, we can move to the active state with the activate function. 06:13.590 --> 06:20.760 This is the main state of the node where the nodes logic is executed, where any service requests are 06:20.760 --> 06:26.100 received, where any Ros message from Ros, two topics are received and so on. 06:26.980 --> 06:27.970 In this state. 06:28.000 --> 06:30.100 Two transitions are available. 06:30.130 --> 06:33.670 Still, the shut down and then the deactivate. 06:34.010 --> 06:41.410 With the deactivate transition, the node returns to the inactive state and the execution of subscribers 06:41.410 --> 06:48.070 and services is terminated, allowing the node to be reconfigured and its parameter to be changed for 06:48.070 --> 06:49.330 the next execution. 06:49.960 --> 06:57.450 Otherwise the node can be shut down with the shutdown function and it will end up in the finalized state 06:57.460 --> 07:00.730 that is the one that precedes the destruction of the node. 07:01.700 --> 07:02.930 In this state. 07:03.050 --> 07:09.860 Once the life cycle node is in the finalized state, there is only one transition that leads to the 07:09.860 --> 07:11.150 node being destroyed. 07:11.480 --> 07:15.470 This state exists uniquely to support node debugging. 07:15.500 --> 07:22.250 For example, if its execution fails, the node will remain visible in the finalized state before being 07:22.250 --> 07:26.870 destroyed, so that the reason for the node failures can be investigated. 07:26.870 --> 07:30.500 And so some debug tool can be used to resolve the issue. 07:31.270 --> 07:37.690 In the next laboratory lesson, we will first create a simple example of a life cycle node, and then 07:37.690 --> 07:45.190 we will use it to create the driver, the interface with Arduino and the Servomotors for the communication 07:45.190 --> 07:47.170 with the control library.