Skip to content
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

Define proper objective status logic (state machine?) #128

Open
chcorbato opened this issue Apr 26, 2022 · 1 comment
Open

Define proper objective status logic (state machine?) #128

chcorbato opened this issue Apr 26, 2022 · 1 comment
Assignees

Comments

@chcorbato
Copy link
Contributor

chcorbato commented Apr 26, 2022

if obj_in_error.o_status in ["UPDATABLE"]:

This needs to be fixed simultaneously with logic in the Wrapper (monitors objectives) and in the MROS Observer (which apparently in ROS2 monitors components/nodes)

@estherag
Copy link
Collaborator

estherag commented May 20, 2022

@chcorbato I've been thinking how to solve this but it is not that easy. The problem is that the Observer only handles components and the Wrapper only handles objectives. When a component is RECOVERED we have two options:

  • Extend the observer to also handle objectives:

    • Send a objective UPDATABLE status and handle it as if the Objective were in INTERNAL ERROR -> need to select the best, available and realizable FD to ground
  • Keep the structure as it is:

    • The observer sends a component RECOVERED status to the ontology
    • We apply a rule to set the objective to UPDATABLE status
    • For the next loop, the component shall be in NONE status (not updatable, not in error) so in Python we remove the status of the component

In both cases, once a FD is grounded, the objective status is reset to NONE in the ontology

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants