Provides an example of on_error implementation for hardware interfaces

[yguel]

Is your feature request related to a problem? Please describe.
We are trying to follow closely the hardware interface lifecycle and we stumble upon a strange situation we are unable to solve:
when returning rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn::ERROR during the on_activate transition we expect the on_error function to be called that will set the system to the UNCONFIGURED state.
We expect to be exactly in the same state if we manually require the resource_manager to pass the hardware in the INACTIVE state then follow an on_cleanup transition because we require the resource_manager to get the hardware back to the UNCONFIGURED state.
However looking at the state of the interfaces: in the first case, interfaces are «available» but in the second case interfaces are «unavailable».
Our on_cleanup method was called in our on_error method. But it seems that in addition the resource_manager calls the method:
remove_all_hardware_interfaces_from_available_list
This last case looks to be what is to be expected. However:

1. is our understanding correct ?
2. if yes, why is an equivalent method remove_all_hardware_interfaces_from_available_list not called from the error manager ?
3. if we have to manually set all interfaces unavailable, is-it possible to have a example of how we are expected to do it from an hardware_interface::SystemInterface derived class ?

Describe the solution you'd like
The best solution, would be that the error manager handle the removal of the hardware interfaces from the available list.
A less good solution, but interesting from a developer perspective would be that a a method set_all_hardware_interfaces_unavailable be implemented in the base class that can be called by the derived class,
Or a meta on_error function on the base class that call the derived function and call the set_all_hardware_interfaces_unavailable for the user

Describe alternatives you've considered
We are not yet there, since we try to understand the situation.

Additional context
We are the maintainers of the ethercat_driver_ros2 and we try to closely follow the ros2 hardware_interface lifecycle to allow users reproducible behaviour in case of errors.

[bmagyar]

Thank you for raising this. We had a chat about this issue at the Working Group meeting today.

Let me start with some references:

Our docs:
https://control.ros.org/rolling/doc/ros2_control/hardware_interface/doc/hardware_components_userdoc.html

Lifecycle node chart:
https://design.ros2.org/articles/node_lifecycle.html

Relevant point in code: https://github.com/ros-controls/ros2_control/blob/master/hardware_interface%2Fsrc%2Fsystem.cpp#L177-L179

[yguel]

Thanks for your input.
I am sorry, I was unable to attend the Working Group meeting (is there some track or minutiae of what was said about the issue 1907 that I could read or listen to ?)

I reviewed the documents you attached. From my understanding of the lifecycle node chart, I expect the interface not to be available like it is in the unconfigured state at the start of a process.

Do you agree about the interfaces unavailability after an error on_error ?

I am willing to contribute a PR for that issue, if you confirm it.

If the state of the interfaces availability should be undetermined after an error, I am also willing to contribute to code a mechanism to allow user to setup availability and to correct the documentation for the lifecycle.