[Possible Bug] [Question] BehaviorTree.CPP v3.8: StdCoutLogger issue, Conceptual (AlwaysRunning Nodes?)

[varungiridhar]

Hi,

I have the following tree:

The idea is to increment "num" until it is greater than 20, and then fallback to the subtree "ExecuteOnlyIfGreaterThan20."

"add" is a sync action node.

Since I am using all reactive nodes, I expect "add" to be repeatedly called - which it is when I verified with ROS_INFO statements. However, when I used BT.cpp's StdCoutLogger, the following was the output:

StdCoutLogger seems to skip logging the "add" node. Is there any explanation why?

Also, I added the following to emulate a "RUNNING" node:

<KeepRunningUntilFaliure>
    <AlwaysSuccess>
</KeepRunningUntilFaliure>"

This leads me to my conceptual question. PPA design tells us to wait till until post condition succeeds before "falling back" on a tree. So, how can we have an action that returns success then? The instant an action returns success, maybe "add" in the above example, the subtree "ExecuteOnlyIfGreaterThan20" will be ticked even though it's not supposed to be tick.

Or is the idea to have an action of PPA return success when the post condition would return success?

Please let me know - I've been wondering about this edge case for a while now but it's catching up to me...

Thanks,
Varun

[facontidavide]

Please note that:

• I do not support 3.8 anymore
• This would be MUCH simpler in 4.x

Said that, it looks probably as an error in ReactiveSequence and ReactiveFallback not setting the children to IDLE.
I think this is fixed in 4.3.x

By the way, I am not sure what this logic implies, since the counter is based on the number of ticks, and I don't think that you should make any assumption about the speed at which these ticks are executed.

Also, in version 3.8, the KeepRunningUntilFailure will cause an infinite loop that the ReactiveSequence can not interrupt. This is solved in 4.x.

The only solution that I can suggest is, instead of this complex logic made of reactive nodes, to implement all of it in a single custom node.

I pushed a change in branch v3.8 that should fix the issue with logging, at least

[varungiridhar]

Thanks for the fixes .

What if the "complex logic" is too complex to boil down to one node. Maybe something like:

<ReactiveSequence>
    <ReactiveFallback>
        <AtDestination>
        <ReactiveSequence>
              <CheckBattery/>
              <NavigateToDestination/>
        </ReactiveSequence>
    </ReactiveFallback>
    <SubtreeX> <! -- only execute once AtDesination returns success -->
</ReactiveSequence>

My concern is that the moment "NavigateToDesignation" returns Success, it will run SubtreeX, which is not my intended behavior. I would like to run SubtreeX iff AtDestination returns SUCCESS. It's a small subtlety, but does it mean NavigateToDestination should only return "RUNNING"?

Thanks.