Deferrable + Cancelable lifecycle change_state transition function implementation
#2214
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses: #2213
Depends on: ros2/rcl_interfaces#157
Demo Code
Lifecycle re-architecture dependency: #2212 / #2211
This is a proposed first-stage solution:
ChangeStateExample Usage
ChangeStateHandleris similar to aGoalHandleExpand example 1 code
Expand example 2 code
Expand example 3 code
Expand example 4 code
Expand
ChangeStateHandler
An async transition follows the same flow as before but now passes a
ChangeStatehandler that:This is very similar to a
GoalHandlerwithin a ROS 2 Action. However, we want to maintain backward compatibility.Async transition
Control flow of an async transition
The above image outlines the process. Only 1 request can be processed at a given time, all other requests are rejected. The
ChangeStateHandlerallows for the user to send a response whenever they are done with the transition (accomplished by passing a newly createdshared_ptr<ChangeStateHandler>to the user).Cancelling a transition
Reference for `Callback::FAILURE` paths of lifecycle nodes
(Note
RAISE_ERRORis not currently merged having an open set of issues described here: ros2/design#283 (comment))Given that the transition is async, it would be ideal if it could also have the potential to be cancelled. The goal would to attempt to recover the node into a valid primary state. With this:
ChangeStateHandleris "marked" as cancelled and waits until the user marks the cancel as completedCallbackReturn::Failurepath. This is desired tostate_machinevalidity/backward compatibilitychange_stateControl flow of an async transition
The example flow of a cancelled transition. Note this is all possible even on a
SingleThreadedExecutoras the timer acts as a monitor for the transition. Note the rejection and failure criteria / reasons are passed back to the client within theCancelTransition.srv.<\details>