You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently tasks can be composed as fixed sequences of robot activities. The next major leap forward would be to define tasks as arbitrary behavior diagrams. This would allow far more complex tasks to be defined, tasks which can include conditional branches and loops.
This would also lend itself to a graphical front-end that lets users define tasks by dragging, dropping, and connecting building blocks.
The text was updated successfully, but these errors were encountered:
Would it be possible for you to provide me with more detailed explanations and examples regarding your concept of defining a task in a behavior diagram? I'm interested in this ticket and would like to use this opportunity to expand my thesis.
From my understanding, your concept could be applied to a multi-robot task allocation problem that aims to optimize efficiency in the face of an uncertain set of tasks.
I did a more comprehensive write up on the idea in this discussion: open-rmf/rmf#169
I fully agree with using behavior diagrams for defining mutli-robot tasks, and also generating models from the behavior diagrams so that optimal task allocation can be performed.
But there are some significant challenges for achieving optimal allocation. For example, if there are multiple active complex behavior diagrams, how do you balance resources between them? In RMF currently we make many assumptions to simplify this problem, like each task is assigned to exactly one robot and each robot only does one task at a time. Balancing the allocation of resources between multiple complex multi-agent tasks will be an interesting but also very challenging problem.
Currently tasks can be composed as fixed sequences of robot activities. The next major leap forward would be to define tasks as arbitrary behavior diagrams. This would allow far more complex tasks to be defined, tasks which can include conditional branches and loops.
This would also lend itself to a graphical front-end that lets users define tasks by dragging, dropping, and connecting building blocks.
The text was updated successfully, but these errors were encountered: