| ROS Resources: ROS Homepage | Media and Trademarks | Documentation | ROS Index | How to Get Help | Q&A Help Site | Discussion Forum | Service Status |
Hi,
to all the users out there of 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
Have you had any more thoughts about somehow making behavior trees event-based rather than polling?
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 : )
@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.
@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!
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!
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!
I sent an email to Petter Ăgren and Michele Colledancise, the authors of Behavior Trees in Robotics and AI: An Introduction, to see if they would be interested in sharing their thoughts with us about event-based and low-latency behavior trees.
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).
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?
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.
+1. I am working on a project where we basically verify (using Formal Methods) that the library follows a specific semantic deterministically.
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â):
Thanks everybody!
Davide
@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.
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?
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.