I'm following the paper: Towards a Unified Behavior Trees Framework for Robot Control and attempting to implement my own behavior tree. I believe that I have the correct logic working for the main nodes: Sequence, Selector, Condition, and Action, but I'm only allowing nodes to return Success or Failure for now. Additionally, I'm not sure I understand why you need a Running state.
My distillation of the two main branch nodes, Selector and Sequence, is as such:
Sequence
- Iterate all children
- Stop if child fails or is running
- Return failure or running if depending on child
- Return success if all children succeeded
Selector
- Iterate all children
- Stop if child succeeds or is running
- Return success or running depending on child
- Return false if no children were successful or running
To me, Running is just synonymous to Success or Failure depending on if it is used in a Selector or Sequence respectively. When does Running actually matter?
Best Answer
Here is an example tree:
The idea here is that the robot should roll forward and then beep. If something goes wrong, it should panic.
While the robot is rolling forward, what does the roll forward node return?
The correct way is to have it return RUNNING, because its still rolling forward. Then three looks like:
In this state, everything is running, and the Beep and Panic don't happen.
Alternatively, could we use SUCCESS instead of RUNNING? In that case, the tree would be:
But this is bad, because it isn't supposed to beep until after rolling forward.
Perhaps we should have used FAILURE?
But this is bad again, because we panicked, when we should have waited to see if rolling forward worked.
Thus, we need RUNNING in order to indicate when a task is not yet finished.