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.
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!
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?
@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?