Proper usage of FlexBE' s "priority" container

asked 2020-11-17 11:39:50 -0600

joao.aguizo
53 ●3 ●9 ●10

Hello,

I have recently started working with the flexbe ROS package ([http://wiki.ros.org/flexbe]) and have been having some difficulty understanding the purpose of the container of type "priority". Initially, I assumed that it would be a container that one would place at the root of your behavior and whenever a transition to it was requested, it would preempt the currently running state and execute itself (for me this seems logical and practical). However, after trying to induce this through the "/flexbe/command/transition" topic, I have realized that it does not work as expected.

In my use case I would like to have a robot that can be performing multiple complex tasks (one at a time), however I would like to be able to switch at any time to the "user teleoperation" state (my priority container). It is good to mention that I would like to avoid killing one behavior and initializing another one.

Does anyone has any idea of how to implement these types of containers properly? I could not find any documentation on the topic.

answered 2020-11-18 07:02:13 -0600

Philipp Schillinger

321 ●6 ●4 http://flexbe.github.io/

Hi, you are right in that a priority container will prevent other states from executing as soon as it is entered. More precisely, it pauses execution. For an active state, it will be the same as if the user pressed "pause" at the moment when the priority container is entered and "resume" when it is left.

The catch is only that a regular state machine would execute one state after the other, there is no way for a priority container to become active at the same time as another state. To achieve this, place a priority container somewhere within a concurrency container. In a concurrency container, all direct children are active at the same time and if at any time the priority container in one of the sub-statemachines becomes active, it will pause all other states that are otherwise active at the same time.

In your use case, it might also be sufficient to simply pause execution, e.g., via "/flexbe/command/pause", or to adjust the level of autonomy depending on the type of intervention.

edit flag offensive delete link

Comments

Thank you very much for the quick response, it gave me a better understanding of the functionality of priority containers, but it also raised other doubts, specially when you suggest this: "place a priority container somewhere within a concurrency container. (...)[if] at any time the priority container in one of the sub-statemachines becomes active, it will pause all other states that are otherwise active at the same time."; Wouldn't this be the same thing as having a concurrent state listening to a topic and exiting the concurrency if triggered?

joao.aguizo ( 2020-11-18 11:26:21 -0600 )edit

Not quite, but both alternatives have their use cases. Difference is exiting vs. pausing. When using the priority container as described above, you can resume execution of the active states after the priority container did its job. Main purpose for this is the definition of an interruption routine in parallel to other tasks, e.g., go charging as soon as required, but then resume afterwards. In other cases, you are completely right, it could be more suitable to fully exit on the respective event and continue with something different.

Philipp Schillinger ( 2020-11-19 07:35:06 -0600 )edit

Ok, I can see why some would want to use the priority container now. Once more thank you very much for the help.

joao.aguizo ( 2020-11-19 07:37:53 -0600 )edit

add a comment

Proper usage of FlexBE' s "priority" container

1 Answer

Comments

Question Tools

Stats

Related questions

Proper usage of FlexBE' s "priority" container edit

1 Answer

Comments

Question Tools

Stats

Related questions

Proper usage of FlexBE' s "priority" container