Create lifecycle for components/hardware

[destogl]

The hardware in the robotic system can have different states, e.g. the communication to the robot is initialized, but the breaks are still on, or emergency halt happened and the robot needs to be recovered, etc.

A proposal for list of this state:

using component_state_type = uint;
static constexpr component_state_type ROS2C_COMPONENT_STATE_LOADED = 1;
static constexpr component_state_type ROS2C_COMPONENT_STATE_CONFIGURED = 2;
static constexpr component_state_type ROS2C_COMPONENT_STATE_INITIALIZED = 3;
static constexpr component_state_type ROS2C_COMPONENT_STATE_STARTED = 4;
static constexpr component_state_type ROS2C_COMPONENT_STATE_STOPPED = 5;
static constexpr component_state_type ROS2C_COMPONENT_STATE_HALTED = 6;

[destogl]

started in #121 and during ros-controls/ros2_control_demos#5 has to be investigated in detail.

[bmagyar]

We need a design doc to progress with this

[destogl]

I am currently working on this and planning to do it in multiple phases.

The main goal is to use lifecycle_msgs::msg::State type internally to define states as for controllers and implement the same lifecycle defined by the ROS2 design doc. Why? To keep things simple and unified.

1. Phase - Change hardware_interface::status names and values to correspond to those in lifecycle_msgs/State (keeping the old names with new values still there) - no need for user-code changes, only recompile

2. Phase - Extend hardware_interface/base_interface.hpp to have lifecycle management as in controller_interface - no need for user-code changes, only recompile.

3. Phase - Extend Sensor, Actuator and System definitions to support all methods for the lifecycle. And implement "automatic" lifecycling as done in the ControllerInterface.

4. Phase Replace hardware_interface::status with lifecycle_msgs/State in the whole framework - users need to adjust their code (mostly removing "status_ = ..." expressions.

[destogl]

Some more thoughts about Lifecycle of the HW. The state and transition reference, see here.

Meaning of states:

• Unconfigured: memory and storage are allocated; parameters are read from the HardwareInfo structure.
• Inactive: Communication to hardware is established; everything is prepared for “immediate” start of power-circuits of HW. Hardware can be read-out but writing commands is disabled.
• Active: Power circuits are turned on, hardware can execute its function corresponding to the commands in write method.

Meaning of transitions (real-time and non-real-time):

• Configuring (non-real-time): initialize and start communication with the HW; The hardware values are readable after this transition is executed.
• Activating (real-time): enabling power for the hardware; Reading states and writing commands are possible after this.
• Deactivating (real-time): disabling power for the hardware. Reading states is possible after this.
• CleaningUp (non-real-time): stopping/disabling communication with the hardware. Memory stays allocated (at least for non-communication related objects).

About HW configuration and blocking during communication is initialized

There are two cases to distinguish:

1. Configuring transition will be triggered manually using service call. This call is executed in a separate (non-real-time) thread then update loop. Therefore, blocking there for longer time should not be a problem. Still, using timeout makes sense, but then HW stays in "Unconfigured" state. Then you should try to do this again until HW is configured.

2. Configuring a HW with "autostart" option in ControllerManager: In this case "Configuring" will be called in the main loop of CM and will block its initialization. This keeps current functionality and shouldn't be a problem, except spawners' timeouts happening from time to time (see spawner.py in controller_manager is a bit unstable #475). Therefore, only scenario-critical hardware should be used in "autostart".
   Currently, let's keep it as it is. In the long term, we could do hardware initialization asynchronously leading to a bit more complex management and synchronization between Controller Manager and Resource Manager opening a gate for new issues that have to be mitigated (for example see this comment).

[destogl]

Update...

After implementing starting and stopping functionality, there are some issues to implement configure and cleanup methods:

1. Current configure is expecting to get HardwareInfo with parsed URDF. Form the previous comment this should be part of the initialization. --> This will result in API change
2. We need an extension of API for cleanup method.

I would "jump" immediately to "Phase 3" from this comment, otherwise, we will need to do changes multiple times user level if now try to simply extend API.

Do you agree with "1.".