Pergunta

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

  1. Iterate all children
  2. Stop if child fails or is running
  3. Return failure or running if depending on child
  4. Return success if all children succeeded

Selector

  1. Iterate all children
  2. Stop if child succeeds or is running
  3. Return success or running depending on child
  4. 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?

Foi útil?

Solução

Here is an example tree:

Selector
    Sequence
         Roll Forward 1 foot
         Beep
    Panic

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:

Selector [RUNNING]
    Sequence [RUNNING]
         Roll Forward 1 foot [RUNNING]
         Beep
    Panic

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:

Selector [SUCCESS]
    Sequence [SUCCESS]
         Roll Forward 1 foot [SUCCESS]
         Beep [SUCCESS]
    Panic

But this is bad, because it isn't supposed to beep until after rolling forward.

Perhaps we should have used FAILURE?

Selector [SUCCESS]
    Sequence [FAILURE]
         Roll Forward 1 foot [FAILURE]
         Beep
    Panic [SUCCESS]

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.

Licenciado em: CC-BY-SA com atribuição
scroll top