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:
ChangeState
Example Usage
ChangeStateHandler
is similar to aGoalHandle
Expand 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
ChangeState
handler that:This is very similar to a
GoalHandler
within 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
ChangeStateHandler
allows 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_ERROR
is 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:
ChangeStateHandler
is "marked" as cancelled and waits until the user marks the cancel as completedCallbackReturn::Failure
path. This is desired tostate_machine
validity/backward compatibilitychange_state
Control flow of an async transition
The example flow of a cancelled transition. Note this is all possible even on a
SingleThreadedExecutor
as 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>