BehaviorTree.CPP
BehaviorTree.CPP copied to clipboard
BehaviorTree
Renaming of Sequence and Fallback node in version 3
I think users will have a hard time with the renaming of Sequence to Reactive Sequence (see e.g. #74) shall we name the two nodes as Static Sequence and Reactive Sequence (or Persistent Sequence) to make the difference super clear? Unfortunately, in the BT literature, there is a bit of confusion of what a Sequence node is (if reactive or static)
I try to apply the "principle of least surprise" in the API and the "static Sequence" is the one that is less surprising, therefore it should be the default one in my opinion.
Note that if you want to create an alias name, you can just add these two lines in your source code
BT::BehaviorTreeFactory factory;
factory.registerNodeType<FallbackNode>("StaticFallback");
factory.registerNodeType<SequenceNode>("StaticSequence");
I totally agree with you about the "principle of least surprise". I think having only Static Sequence and Reactive Sequence in the palette (i.e. not just "Sequence") will give less surprise to the users.
Now that people rely on this APi, no bug changes in naming should be done.
Actually, during the workshop, many people were surprised by the unconventional naming of nodes in this library.
@fnivek @frovida @cpaxton @doroK @DJuego
I agree with Michele, with "Sequence" I would expect the "ReactiveSequence" rather than the sequence with memory (or static). The majority of papers agree that reactive is the default. Having Static Sequence and Reactive Sequence in the palette seems like the safest choice.
Personally, I prefer the default to be the "ReactiveSequence." Behavior trees are meant to be highly reactive and the "StaticSequence" removes some of that reactivity. I want both in a library, because "StaticSequence" has important use cases. I worry that newcomers to BTs won't get the full potential of BTs because they'll just default to the static sequence. Also I suppose that "Principal of least surprise" is a relative term. I'd guess individuals from the robotics community might be more surprised by static sequence being the default than reactive sequence.
I think explicitly naming each one is the safest way to go. For people who aren't versed in behavior trees, a static sequence might seem much more... sequential.
Can we just add, for the time being, a warning message in the constructor of the "Sequence" that explains what the node does and suggests using "ReactiveSequence" or "StaticSequence/MemorySequence/SequenceStar" for clarity? So we don't introduce a breaking but we still make clearer what is the expected behavior of the "Sequence". We can think of deprecating the node "Sequence" in favor of "ReactiveSequence" and "StaticSequence/MemorySequence/SequenceStar" later.
What do you think?
Over the last couple of years, I've gone from completely unaware of behavior tree's existence to regularly reading research papers and using them in my daily work. I believe I have a unique perspective to share because of this, so apologies for digging up an old thread. I think my arc can be summarized as learning about Control Nodes or: How I Learned to Stop Worrying and Love Reactivity.
Starting out quite familiar with finite state machines, I found the semantics of memory sequence to be intuitive, as I read that BTs were somehow superior to FSMs but a memory sequence felt comfortable because it naturally modeled a sequence of states in an FSM with few branches. I also perceived a performance cost around ticking condition nodes frequently during a long-running action, so I shied away from non-memory control nodes like ReactiveSequence and ReactiveFallback except in very specific situations. As I learned more about behavior trees, the benefits of reactive design*, and how to write efficient conditions, my intuition flipped. If you came from an academic background, had extensive experience in designing robotic behavior systems, or learned under the wings of people who did, perhaps this difference was natural to you, but it wasn't to me for a while.
Part of the reason this wasn't natural to me as a BT newbie was because my learning sources (code libraries and their docs, blogs/articles, research papers, etc.) would refer to and use the canonical "sequence" and "fallback/selector" control nodes without always pointing out the nuance between the memory and non-memory versions of these control nodes. I naturally tended towards the memory control nodes in BT.CPP because they were the default implementation, they were intuitively simpler for me to reason about from an FSM background than non-memory control nodes, and they shared a name verbatim with what I read from outside sources. Perhaps my experience of memory vs. non-memory is my naivety showing from jumping into BTs without much background on the subject of robotic behavior systems, but perhaps others share a similar experience to me (I can attest that some of my coworkers have).
In my opinion, the difference between memory and non-memory as the default begs the question: who is the BT.CPP library written and maintained for? If it's for experts who already understand the nuances of control nodes, throw my [minute to zero] vote behind non-memory being the default. If it's also for everyone else, still throw my vote behind non-memory, but perhaps there should be additional effort put into educating users about the differences between them, plus the how, when, and why to use the right one. If it's also for everyone else, what's the role of a library to educate its users on the "proper" (somewhat subjective) way to utilize its patterns in its target domains?
*Petter Ögren's videos on Behavior Trees were what really hit the idea of reactivity home for me
