-
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
Should get_available_modes be influenced by inference #43
Comments
Proposal after discussion with MROS team:
|
When/how can we consider modes to be not reachable by nodes? |
* Introduces additional field reachable_modes to GetAvailableModes service #43 Signed-off-by: Arne Nordmann <arne.nordmann@de.bosch.com>
Maybe we could associate the ErrorProcessing transition to the node MODE at that moment, so that only that MODE is considered not reachable. |
The Mode Manager has to keep track of reachable modes, yes. |
No, not all modes. |
Okay, so the mode manager would then keep track of the modes that "made" the nodes transition into error processing and exclude them from the list of reachable modes. Maybe until the node gets reset? |
Sounds reasonable to me. |
If we know through mode inference, that a certain state or mode of a (sub-)system can't be transitioned to, should
get_available_states
andget_available_modes
of (sub-)systems report accordingly?Example:
error_processing
, certain states and modes for subsystem A are not available until errors in node B are fixedget_available_states
andget_available_modes
of subsystem A only report states and modes that allow node B to be in error_processing, e.g., degraded modesThe text was updated successfully, but these errors were encountered: