“Configuration/Movement/Safety-critical" interfaces definition

[destogl]

resolves #50

Please add your comments as review.

[gavanderhoorn]

I suggest to be careful labelling something as safety-critical or suitable for safety critical situations.

It implies quite a few things, and I don't believe ros2_control is currently really suitable for such use-cases.

[christophfroehlich]

A little off-topic but relevant here: Is there any documentation about the lifecycle implementation within ros2_control which I couldn't find? Up to now it was not clear to me that read/write methods of the hardware components are called in inactive state, too.

I understand now the motivation here, but I'm not sure if this really solves the problem for every hardware architecture (but honestly, I do not have a lot of experience with industrial robots with ROS):

• if the resource manager deactivates the handles only, no one guarantees that there isn't still "energy flow" from the last command sent, without explicitly deactivating power electronics etc.
• to only deactivate new commands being sent to the hardware, one could do this already by implementing this into the read/write methods of the hardware components, depending on its lifecycle status?
• if some global enable flag (power electronics..) is necessary, one would have to implement this in the hardware component's methods anyways. Or should we extend this proposal with default values for the commands, depending on the components lifecycle?