-
Notifications
You must be signed in to change notification settings - Fork 34
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
Add modular task selector interface #297
Conversation
self.tasks = tasks | ||
|
||
@abstractmethod | ||
def next_task(self) -> Task: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you indicate that all tasks are finished? Should it return None or raise an exception? I see that in the state machine we expect a StopIteration exception when there are no more tasks left. This works fine for the IterativeTaskSelector, but should probably be generalized with an exception that is not specific to iterators. Suggest adding some documentation on the expected behavior of the next_task method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A possibility is to add a function that checks if all tasks are finished.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. Will generalize the stopping condition for updating the current task in the state machine.
What is the plan with regards to do the overall planning? I guess in most cases the planning will be done once based on some algorithm and then the tasks are provided in that order based on the first planning. Is this planning going to be done in the initialize function? Should there be an option to replan the remaining tasks? |
The idea is for the planning to be done either once-off, or alternatively based on dynamic criteria in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rename Iterative_select to sequential_select.
Update readme to show how to implement new selector implementation.
4fb1117
to
6e967b5
Compare
Implements a modular interface for task selection per mission. Replaces the iterator in the Mission class responsible for selecting the next task of the current mission. When there are no more tasks to select for the current mission, the TaskSelectorStop exception should be raised in order to comply with the interface.
9c0eb01
to
b3cab11
Compare
b3cab11
to
ef49865
Compare
Closes #261.
This PR implements a modular interface for task selection per mission. It also replaces the iterative task selection from the Mission class.