When developing a driver or an interface for a certain hardware component to communicate with.
Ros.
Two traditional Ros two nodes have some limitations.
For this reason, Ros two introduced lifecycle nodes.
To understand the importance of this new type of nodes.
Let's start with an example of a true application that uses traditional nodes.
Let's assume that we have a classic cross two node that acts as a driver and allows us to control a
servo motor through Ros2 and also reads its data such as its current position, and make those information
available in Ros to.
This node acts as the servo motor driver for us two and is specific for the particular hardware that
is being used.
In practice.
If we change the hardware so if we change the servo motor, we also need to change these drivers or
these software components to be compatible with the new motor.
And so with the different set of communication protocol that probably the new motor is using.
All of this is invisible from the outside.
So from the other nodes and application that only use the Ros two tools, for example, for the nodes
that use topics, services and actions to send comments to the motors and receive the data.
So they are not concerned about how this low level communication takes place.
This is amazing and allows the separation of each node's purpose.
For example, the application that makes the robot pick up an object so the pick pen node will work
independently of the motor and the driver being used.
It only needs each driver so for each motor to offer the same Ros two topics or services.
The pick the pen node for example, can request the driver to move the robot to a specific position
and wait until the action is completed.
Despite this being very transparent to the user of the hardware internally, the driver typically needs
to perform various operations.
For example, it needs to configure the communication with the hardware, and this might take some time
depending on the communication protocol that is being used and the hardware initialization.
Meanwhile, the pick the pen node is still waiting for the driver to perform the desired movement and
also has no idea what the driver is doing in the meantime.
After the configuration phase, the driver can finally move on to the startup phase and so initiate
the communication with the hardware and enable its operation.
This phase may also take some time to complete.
For example, the driver might be wanting for a response from the hardware, confirming its correct
start up and operation.
Again, the peak depend node is still waiting for the driver and has no idea about what the driver is
doing and its current state or how much time is left for the requested command to complete.
Sometimes for certain applications it might be useful to have a greater control over the nodes and their
states.
For example, to give a feedback to a user and provide an estimate of the time required to complete
the command or simply to visualize the current state of the system.
To overcome these limitations in Ros2, there are the life cycle nodes.
If you are already familiar with our state machine works, then the operation of a life cycle node will
be familiar to you.
A lifecycle node as four states and configured inactive, active and finalized, and several transitions
that allow the node to change its state.
Just like with state machines.
Lifecycle nodes can only be in one state at a specific moment.
For example, if the node is in the Unconfigured state, it cannot also be in the active state at the
same time and so on.
To change states various events or transitions, namely function that changes the state of the state
machine are available in each of these states.
The node performs different operations.
When a state is activated, the node performs the functionalities associated with the state.
Upon the note creation.
For example, it is in the Unconfigured state.
Here the node has no information, no instantiated data.
In this state, there are only two transitions, only two functions available.
The node can be shut down so terminated with the shutdown function and end up in the finalized state
which comes before the destruction of the node itself.
Alternatively, the node can enter the inactive state with the configured transition in this state,
the node does not yet perform any action or logic.
The purpose of this state is to allow the node to be configured or reconfigured during its execution.
For example, in this state it is possible to change the node parameters or add new publisher subscriber
without changing the nodes behavior.
During this stage, the node will not receive any callbacks such as subscription to topics or processing
of services and so on.
Any request the node receives while in this state will not be handled and will be directly rejected.
In the inactive state, there are three active transitions.
The node can be shut down and enter the finalized state with the shut down transition, or the node
can return to the Unconfigured state with the clean up transition.
This transition allows resetting the node.
So to remove the configuration parameters that were set in the inactive state.
Finally, from the inactive state, we can move to the active state with the activate function.
This is the main state of the node where the nodes logic is executed, where any service requests are
received, where any Ros message from Ros, two topics are received and so on.
In this state.
Two transitions are available.
Still, the shut down and then the deactivate.
With the deactivate transition, the node returns to the inactive state and the execution of subscribers
and services is terminated, allowing the node to be reconfigured and its parameter to be changed for
the next execution.
Otherwise the node can be shut down with the shutdown function and it will end up in the finalized state
that is the one that precedes the destruction of the node.
In this state.
Once the life cycle node is in the finalized state, there is only one transition that leads to the
node being destroyed.
This state exists uniquely to support node debugging.
For example, if its execution fails, the node will remain visible in the finalized state before being
destroyed, so that the reason for the node failures can be investigated.
And so some debug tool can be used to resolve the issue.
In the next laboratory lesson, we will first create a simple example of a life cycle node, and then
we will use it to create the driver, the interface with Arduino and the Servomotors for the communication
with the control library.