-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide lifecycle servicing #27
Comments
The system modes's extended lifecycle model could be node specific. |
Actually, the 2nd case is the only one currently intended by the ROS 2 Managed Nodes design document. I.e., reconfiguration, which is what we do when switching mode, is only allowed in the Currently we ignore this constraint (for now) and re-configure (switching modes) while staying in the |
I think MROS test cases could help analyse whether this (going through |
The mode manager usually knows the target state/mode and the current state/mode (via mode_inference) of a system or node. Currently we assume, that there is a trivial transition to the target state, e.g, activate to go to active, deactivate to go to inactive.
However, this is not always true, e.g., if actual state is already the target state, or if target state can only be reached with >1 transitions. In order to allow that, mode manager needs to implement some kind of lifecycle service that knows how to get a node from any state to any other.
The text was updated successfully, but these errors were encountered: