Behavior Trees that avoid checking All conditions All the time (BT intro part 5A)

In this video we suggest a solution to the problem of BTs that execute slowly due to their constant checking of many conditions. The key trick is to store the beliefs regarding the conditions in a bit vector, and then update this vector in separate processes. The BT will execute smoothly, as checking a bit vector is super fast, and the values of the bit vector (the beliefs) can be updated at whatever time intervals that is deemed reasonable.
We also see how doing this enables so-called event based ticking, as well as active sensing, where data is collected to update beliefs when needed to make important decisions.

[@FlipYourLearning]

It's funny I arrived at this series while searching about FSMs, trying to use them in my game, but the quality of video 4 was so good I went to the beginning and I am now one hour into the playlist and taking notes about BTs which I hadn't considered for my project yet. They are cool.

[@petterogren7535]

Thanks a lot! I am glad you find it useful!

[@spairus4492]

Exact same way I came here as well

[@RoeJogan]

This playlist is like hearing birds singing in nature

[@Haapavuo]

An architectural question (might be a preference): Would you store these beliefs A) inside each Condition class instance (or as a static variable for all agents to check easily)? B) inside a centralized "ForkliftBeliefs" class? Forklift specific or global? Perhaps depends on the use case? C) Somewhere else, where?

[@petterogren7535]

Good question. I'm afraid I do not have a good answer. Both options make sense to me.

[@player-eric]

@@petterogren7535 How about using Blackboard to implement beliefs?

[@petterogren7535]

Sounds like a very reasonable idea. @@player-eric

[@Killofamas]

Could we implement some kind of parallel container that would act as a « memory » that would record each time we check for a condition both its result and it’s time of verification ?
We could then use this memory when a simple belief is needed and actually check it when this is really important to have fresh data.
Moreover, when only the belief is needed, we could have a subtree checking quickly how recently has this checked occurred and, if « good enough », trust it as such, if not, check it
For the example you used about the closed door before going to bed, if I remember closing the door 15 minutes ago, even though it’s very important, I’m still confident enough that the door is indeed closed, if I haven’t checked the door for the whole day, I might want to check it

[@petterogren7535]

Good point, I think your suggestion makes sense. Best, Petter

[@thaos5499]

hi, i'm little late to the series, I'm just wondering what happens if the time taken to compute the success, failure or running status in a leaf is more, what will happen if it can't able to maintain the frequency of the ticks?

[@petterogren7535]

In these cases it is definitely a good idea to run the update of the conditions in a separate process, running in parallel to the BT execution. The the BT would react to the best available information so far (perhaps computed a few ticks ago), but once new information arrives, the BT will react to it in the next tick.

[@thaos5499]

@@petterogren7535 I understand, that makes sense. I'm trying to design the Behaviour Tree for a robot and I couldn't find proper tutorials on Behaviour Trees, ur tutorials are really good and very helpful, thank you very much for making this series. :)

[@petterogren7535]

@@thaos5499 I'm glad you like them!

[@matthewmorgan6814]

I don't understand how the bit vector gets updated if you stop ticking the BT, how else do the conditions get updated?

[@petterogren7535]

The "standard" way is to do the computations needed to evaluate conditions when the conditions are ticked. However, this will be slow if you have many conditions, and they require extensive computations. And it if it is slow, the whole BT execution will be slow.
The solution is to create the bit vector (or some other representation) and separate checking what your beliefs are from updating those beliefs. Then you can quickly check if you believe the car is in the driveway, but it might take longer time to update that belief (doing object recognition on a video feed of the driveway). In order to do this separation, the BT execution must run in a separate thread from the belief update. And, if they run in separate threads, you can actually delay ticking the BT if you know that no conditions or other return status have changed.