Pseudo code of Sequence / Sequence With Memory

[facontidavide]

Hi,

first thanks a lot for taking the initiative and time to write REP 2018. It is a great start!

The pseudocode in the SequenceWithMemory and FallbackWithMemory are not a correct representation of the BehaviorTree.CPP .

I will refer only to Sequence next, for brevity.

• There is no mention of toTick being reset to 1 when the Sequence ends successfully
• In BT.CPP, Sequence and SequenceWithMemory differ in the fact that when a child returns Failure, the former will reset the toTick index, whilst the latter won't.

The problem with the SequenceWithMemory described by Colledanchise is that it doesn't correctly describe what happens when a node return Running.

[facontidavide]

I would like to insist on the reason why a Sequence must not reset the index, when a node returns Running.

Even if we are all grateful to the work that Michele Colledanchise did, can we agree that this pseudo code is WRONG and we should not use this as reference any more?

Let's suppose that 2 nodes (child 2 and child 3, for instance) are asynchronous.

• Child-1 is executed any single time.
• Child-2 takes 2 seconds to execute.
• Child-3 takes 1 second to execute.

What would happen is that:

1. First 2 seconds are spent to do Child-2
2. We tick once Child-3, that return Running.
3. We spend AGAIN 2 seconds repeating Child-2

In the motivating example this is avoided thanks to stateful conditions in each child:

But this is a workaround to Sequence (as described in the book), being intrinsically broken, in my opinion.

[miccol]

Hi Davide,

Unfortunately, I haven't been able to dedicate as much time as I would have liked to this working group. It seems there may be some confusion stemming from a naming mismatch. The 'Sequence' and 'Fallback' nodes in the book are reactive nodes, and the book distinguishes those with memory using a '*' symbol next to their graphical representation.

Regarding the naming in BT.CPP, the 'Sequence' and 'Fallback' nodes have instead memory; and the modification was implemented a while ago (see BehaviorTree/BehaviorTree.CPP#75)

About the use of Condition nodes in reactive compositions: I commonly pair a condition with an action (or a subtree) as a design pattern.
I find this approach more intuitive and extremely effective for designing reactive behaviors (and it also provides some nice convergence properties https://www.diva-portal.org/smash/get/diva2:1456873/FULLTEXT02) but of course, without the condition, the parent node would tick the first action every time.

[ct2034]

@facontidavide Could you please explain why the pseudocode is wrong. Sorry, I think I don't get your point.

If I am not missing something, this is also how the literature defines Sequence nodes. As I read them, they are stateless, in that they will have to tick all preceding children again, every time. Which is part of the reason why BTs are considered so reactive.

I am not quite sure what you mean with asynchronous nodes. Yes, when you assume each child takes time to execute in the order of seconds, this will not work.

This would be a proposal for an addition to the REP: We could also add some guidelines in the form that the ticking of each control node should take less than a given percentage of the intended tick frequency of the whole tree:
$$t_{node} << t_{tree}$$

This is even something that could be implemented as a watchdog into the runtime, so that people know if their conditions and actions take to long to be ticked.

[ct2034]

@miccol Thanks Michele for taking the time. It is very much appreciated.
Yes, the naming is definitely one issue. But therefore, we are trying to choose less ambiguous names in the rep. And don't use the names Sequence and Fallback without additional differentiations. Instead, we use names like Sequence with Memory and Reactive Sequence. Do these names make sense for you? And do you think this would solve the misunderstanding?

[miccol]

@ct2034 yes! it totally makes sense to me to not use the generic names Sequence and Fallback.
I think some misunderstanding might remain as we may not have a common agreement on some details (e.g. when nodes with memory reset their memory)
Thanks!

[ct2034]

Thanks for sharing this, Davide. I have addressed the first bullet point here: https://github.com/ros-wg-delib/toTickFromLastIterationrep/pull/3 Could you please let me know what you think.