First-Class support for safe stop/fault states

[T045T]

Is your feature request related to a problem? Please describe.
The LifeCycleNode inspired state machine for HardwareComponents does not capture the states of industrial robots fully. In particular, many of them have a "faulted" and/or "safe stop" state.

This state usually doesn't allow motion, and the robot can only leave it with explicit manual acknowledgement from the user.

As an example, the UR driver handles this with a dedicated service.

This pattern seems common enough across industrial robots that it could be worth representing it at the lifecycle level. With a dedicated "faulted" lifecycle state, it would be easy to see when a robot is in this state, rather than having to "overload" the unconfigured or inactive state.

Describe the solution you'd like

• A new Faulted lifecycle state
• Change things so that ErrorProcessing transitions to Faulted instead of Unconfigured
• A new on_faulted() function that is called when entering Faulted
  • Backwards compatibility: The default implementation of on_faulted() immediately triggers a transition to Unconfigured

i.e.

stateDiagram-v2
    ErrorProcessing-->Faulted : onError: [SUCCESS]
    Faulted-->Unconfigured : onFaulted: [SUCCESS]

Loading

Describe alternatives you've considered

• Stay with the current approach: Each HardwareComponent handles faults and fault recovery in its own way.

  This isn't too bad, but it makes it harder for users to use different HardwareComponents

• A standardized topic/service interface (e.g. an std_msgs/Bool topic /is_faulted and an std_srvs/Trigger service /clear_fault)

  Also nice, but doing that would mean the faulted state is "overlaid" over the existing lifecycle.

Additional context
Add any other context or screenshots about the feature request here.