# Future of BehaviorTree.CPP

**URL:** <https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927>\
**Category:** ROS General\
**Created:** [October 22, 2020, 12:09pm UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927 "2020-10-22T12:09:55Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![facontidavide](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/facontidavide/32/1674_2.png) [@facontidavide](https://discourse.openrobotics.org/u/facontidavide)\
**Post date:** [October 22, 2020, 12:09pm UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927/1 "2020-10-22T12:09:55Z")

</div>

Hi,

to all the users out there of [BehaviorTree.CPP](https://github.com/BehaviorTree/BehaviorTree.CPP/)

I have some ideas about a potential way to simplify debuggability in the next version of BT.CPP.

Since I think there are multiple users in this forum, I wonder if you want to join me as peer reviewers or if you already have your own ideas about it.

in the latter case, I even wanted if a small online workshop makes sense to give the opportunity to multiple people to influence the future of the library with new ideas.

Davide

---

<div class="post-metadata">

**Author:** ![peterpolidoro](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/peterpolidoro/32/2897_2.png) [@peterpolidoro](https://discourse.openrobotics.org/u/peterpolidoro)\
**Post date:** [October 22, 2020, 2:10pm UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927/2 "2020-10-22T14:10:41Z")

</div>

Have you had any more thoughts about somehow making behavior trees event-based rather than polling?

> [@Introducing the SMACC State Machine Library](https://discourse.openrobotics.org/t/introducing-the-smacc-state-machine-library/14963/9):
>
> ## Poor scalability, no real-time, many threads etc.
> 
> Again, **mostly false** or implementation dependent. **BT.CPP** discourage those Actions that spawns their own thread, even if that is possible.
> 
> On the other hand, I admit that the event-based approach is better than the “polling” (AKA “check conditions in a loop”) approach.  
> But there is no reason why that can’t be implemented in BT too (who knows, maybe in the future).

---

<div class="post-metadata">

**Author:** ![francisc0garcia](https://avatars.discourse-cdn.com/v4/letter/f/ac8455/32.png) [@francisc0garcia](https://discourse.openrobotics.org/u/francisc0garcia)\
**Post date:** [October 22, 2020, 2:39pm UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927/3 "2020-10-22T14:39:34Z")

</div>

Thanks @facontidavide,  
A small online workshop would be great! …we have been working with the BT.CPP library for some time and have developed also some tools for it. But still debugging can be improved : )

---

<div class="post-metadata">

**Author:** ![facontidavide](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/facontidavide/32/1674_2.png) [@facontidavide](https://discourse.openrobotics.org/u/facontidavide)\
**Post date:** [October 23, 2020, 6:43am UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927/4 "2020-10-23T06:43:17Z")

</div>

@peterpolidoro yes, I have been thinking about this and in the context of BT there is a clear design pattern that solve this problem.

What I need to decide is if this event driven approach should just be a reference design (to be integrated by the developer, with clear guidelines) or if it can be implemented generally enough to have it in the library itself.

If anyone has experience with that or requirements for low latency BT, please get in contact with me.

---

<div class="post-metadata">

**Author:** ![facontidavide](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/facontidavide/32/1674_2.png) [@facontidavide](https://discourse.openrobotics.org/u/facontidavide)\
**Post date:** [October 23, 2020, 6:44am UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927/5 "2020-10-23T06:44:19Z")

</div>

@francisc0garcia I would love to integrate tools developed by other people, in particular when they are based on real problems that they have.

We should discuss that!

---

<div class="post-metadata">

**Author:** ![flo](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/flo/32/6087_2.png) [@flo](https://discourse.openrobotics.org/u/flo)\
**Post date:** [October 23, 2020, 9:53am UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927/6 "2020-10-23T09:53:05Z")

</div>

I‘d love to participate in this conversation as well.  
Groot in Nav2 already helps with higher level „debugging“, but not actually debugging errors in the BT itself.

Also improving the performance and mechanics behind the BT is a really interesting topic!

---

<div class="post-metadata">

**Author:** ![mirkoferrati](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/mirkoferrati/32/8866_2.png) [@mirkoferrati](https://discourse.openrobotics.org/u/mirkoferrati)\
**Post date:** [October 23, 2020, 12:52pm UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927/7 "2020-10-23T12:52:08Z")

</div>

Workshop sounds great! We are using a custom version of a BT from years ago when this library was not available, but we are planning to switch so I would like to be there and see future ideas of BT.cpp!

---

<div class="post-metadata">

**Author:** ![peterpolidoro](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/peterpolidoro/32/2897_2.png) [@peterpolidoro](https://discourse.openrobotics.org/u/peterpolidoro)\
**Post date:** [October 23, 2020, 1:13pm UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927/8 "2020-10-23T13:13:27Z")

</div>

> [@facontidavide](#):
>
> If anyone has experience with that or requirements for low latency BT, please get in contact with me.

I sent an email to [Petter Ögren](https://petter@kth.se) and [Michele Colledancise](https://michele.colledanchise@gmail.com), the authors of [Behavior Trees in Robotics and AI: An Introduction](https://arxiv.org/abs/1709.00084), to see if they would be interested in sharing their thoughts with us about event-based and low-latency behavior trees.

---

<div class="post-metadata">

**Author:** ![miccol](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/miccol/32/10853_2.png) [@miccol](https://discourse.openrobotics.org/u/miccol)\
**Post date:** [October 23, 2020, 1:19pm UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927/9 "2020-10-23T13:19:17Z")

</div>

I would also be happy to join a workshop. Thanks @facontidavide for bringing this up and thanks @peterpolidoro for contacting me.

My 2 cents regarding the event-based vs polling of BTs, I never had a requirement of low latency BT but, in the case of an event-based BT, which I guess the event is the change of status of a node, we would need to make sure that we can discriminate when a node does not change its status and when the node is stuck. With polling, when debugging, I can realize if e.g. a condition node gets stuck.  
Since sometimes the actual execution of a leaf node can be delegated to another executable (via middleware) there is a chance that a node may get stuck (e.g. the external executable crashes).

---

<div class="post-metadata">

**Author:** ![peterpolidoro](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/peterpolidoro/32/2897_2.png) [@peterpolidoro](https://discourse.openrobotics.org/u/peterpolidoro)\
**Post date:** [October 23, 2020, 1:44pm UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927/10 "2020-10-23T13:44:57Z")

</div>

Thank you @miccol! I have also enjoyed reading your thoughts on behavior trees versus state machines and when it is most appropriate to use one or the other. Has anyone ever used behavior trees in embedded software, with real-time, non-blocking, or constrained resource requirements? Is that also a possible direction for BehaviorTree.CPP?

---

<div class="post-metadata">

**Author:** ![facontidavide](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/facontidavide/32/1674_2.png) [@facontidavide](https://discourse.openrobotics.org/u/facontidavide)\
**Post date:** [October 23, 2020, 2:10pm UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927/11 "2020-10-23T14:10:17Z")

</div>

I don’t see any reason why BT.CPP can’t be used on platforms with constrained resources.

Memory is allocated only at startup and not at run-time and the overhead introduced by the library itself is negligible, compared with the code of the user.

From the point of view of real-time (that is what I refer to as low-latency) it is not a problem of BT itself.  
If your tick() function blocks, I can not do anything about it ☹

There is no magic that prevent user-code from taking a nap and eat my time budget …

What I can guaranty is that BT.CPP itself does its stuff deterministically, that it is the case, as far as i know.

---

<div class="post-metadata">

**Author:** ![miccol](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/miccol/32/10853_2.png) [@miccol](https://discourse.openrobotics.org/u/miccol)\
**Post date:** [October 23, 2020, 2:15pm UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927/12 "2020-10-23T14:15:22Z")

</div>

> [@facontidavide](#):
>
> What I can guaranty is that BT.CPP itself does its stuff deterministically, that it is the case, as far as i know.

+1. I am working on a project where we basically verify (using Formal Methods) that the library follows a specific semantic deterministically.

---

<div class="post-metadata">

**Author:** ![facontidavide](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/facontidavide/32/1674_2.png) [@facontidavide](https://discourse.openrobotics.org/u/facontidavide)\
**Post date:** [October 23, 2020, 2:26pm UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927/13 "2020-10-23T14:26:27Z")

</div>

Ok, It is great to see this interest in the community. I will figure out a good time at the end of November to allow people to join. Everybody is welcome but (there is always a “but”):

- This is specifically about **BehaviorTree.CPP** not behavior tree in general.
- I will create some document that summarize the motivation and philosophy that BT.CPP follows. You may challenge these assumptions (and you are **welcome** to do it), but you need to understand that first.
- Proposal for changes need to be supported by **real** use-cases, not **hypothetical** ones. I have seen, in my career, too much time wasted trying to address problems that do not exist 😛
- People joining with a proposal, should come a little prepared. A couple of slides and some source code will do, nothing fancy.
- No talking about Groot… yet 🙂

Thanks everybody!

Davide

---

<div class="post-metadata">

**Author:** ![Michael\_Jeronimo](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/michael_jeronimo/32/8028_2.png) [@Michael\_Jeronimo](https://discourse.openrobotics.org/u/Michael_Jeronimo)\
**Post date:** [October 23, 2020, 3:23pm UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927/14 "2020-10-23T15:23:45Z")

</div>

@facontidavide I am interested to participate as well. I previously integrated BT.CPP into the ROS2 Navigation stack and have some experience debugging BTs in that context. Looking forward to hearing your ideas.

---

<div class="post-metadata">

**Author:** ![peterpolidoro](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/peterpolidoro/32/2897_2.png) [@peterpolidoro](https://discourse.openrobotics.org/u/peterpolidoro)\
**Post date:** [November 2, 2020, 3:19am UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927/15 "2020-11-02T03:19:36Z")

</div>

> [@miccol](#):
>
> I never had a requirement of low latency BT

So for systems that require low latency responses to events, do you think it is better to use an event-based state machine rather than, or in addition to, a behavior tree?

Or could state machines potentially be totally replaced by behavior trees if they had similar low latency performance?

Could behavior trees, and BehaviorTree.CPP specifically, somehow use a combination of event-based and polling to get the best of both? It would great if behaviors could change as quickly as events occur, but then some polling is ticking along behind checking for failures or events that take too long. Or would that just create a potential source of problems and confusion?

---

<div class="post-metadata">

**Author:** ![facontidavide](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/facontidavide/32/1674_2.png) [@facontidavide](https://discourse.openrobotics.org/u/facontidavide)\
**Post date:** [November 2, 2020, 11:20am UTC](https://discourse.openrobotics.org/t/future-of-behaviortree-cpp/16927/16 "2020-11-02T11:20:16Z")

</div>

> Could behavior trees, and BehaviorTree.CPP specifically, somehow use a combination of event-based and polling to get the best of both?

I do think so. I have some practical ideas to implement that, that I want to discuss further in a short whitepaper.

But the idea is simple: the number of times the tick is done is usually limited by a sleep to avoid collapsing the CPU (a 1 Khz polling should be fine in most cases!)

If we just change the **sleep** function for a `std::condition_variable`, we may send signals that “wake up” the loop and send immediately the tick.