You are welcome!

I'm happy to hear that!

The virtual environment is the game engine Unity 3d. And the BT package used is Panda BT (the free version).

Sorry for the late reply, only saw this now. No, not the union of different Kbar_j's, only the one for which the stuff to the right of the ":" holds. That is, it is non-empty, it is either j=k, or it is such that the next one is empty.

That is correct. An infinite loop might be part of the desired design. Such as a lawn mower robot that switches back and forth between recharging the battery and mowing the lawn. Assuming the lawn keeps growing, the job will never be "finished", and that is ok. A similar situation is vacuum cleaning, and the patrolling of security robots. But in some instances it is a problem. If you ask a robot go get you a glas of water, you don't want it to be stuck in an infinite loop somewhere along the way.

I appreciate your response.

You need to have reactive versions (without memory) of both the Sequence and Fallback nodes. Unfortunately, some software has memory nodes as default. Sometimes this is a simple option, otherwise you have to use a workaround. In Panda BT you have to "reset" the BT every tick to remove the memory.

@@petterogren7535 Thank you for your reply. I am currently more familiar with Python, and I have hardly used Unity, so I has little knowledge about the usage of Panda BT. I am currently learning py_trees. What I actually wanted to say is that, for a single `tick()` of a BT, I feel that the traversal of the entire tree should be serial, maybe depth-first traversal. If so, then BT has already executed to "Has a key", then even if "a person came by" at this time, I feel that BT will not go back to "confirm that a person nearby was suddenly returned success", but will continue to "Search door mat / garden", unless there is a parallel mechanism that allows another subprocess to constantly detect whether "a person came by".

Yes, a single tick traverses as you describe, but the next tick starts from the root. So the next tick can respond to the presence of a person and act accordingly. @@player-eric

​@@petterogren7535 Thanks sincerely for your guidance.

Or we use random decorator

Or we add new type of decorator

Hi Mohakhachai! Yes, it can depend on a cost estimate, or an urgency estimate. If for example, the children nodes are created using reinforcement learning, they have a value function estimating average future reward, this can be used to pick the best option.

Hi Volkan! Thanks for your question. Yes, I think a was a bit unclear around 18:28. As you note, for the fix to work you need to either disable or remove the "Turn light off", or add "Hide camera" to the left of "Turn light off". Thanks for pointing this out!

Hi Petter. Thank you for making a video series so clear and understandable that even a small mistake can be noticed :).

Hi Siarhei, I'm glad you found the videos useful. Best regards, Petter

Hi Jayvatar. Q1: The execution of a BT always starts from the Root node. Otherwise you would not have any reactivity, such as the possibility to react to a fire alarm while you are eating. There is an old version of BTs used by some, that does not include the "running" and always executes a node until it either succeeds or fails, but as noted above, it has significant drawbacks. Q2: You are right, if it didn't start from the root, interruptions would not work.

@@petterogren7535 Great ok, thanks for clarifying that :)

Hi Kaan. The video describes the general concept of Behavior Trees. There are many implementations: some tailored for Unreal Engine, some for Unity3D, some general implementations for Python, some for C++ and so on. There are some differences between different implementations: Sometimes the Fallback node is called a "Selector", sometimes nodes have memory (I think this is a bad idea as it reduces reactivity, as explained here: kzbin.info/www/bejne/jWjTZGennaeorpo). It seems that the creators of the Unreal BT have described some of the ways their implementation differs from the "standard" under the heading "Differences in Unreal Engine Behavior Trees" found here: docs.unrealengine.com/5.1/en-US/behavior-tree-in-unreal-engine---overview/

Hi Kaan. The video describes the general concept of Behavior Trees. There are many implementations: some tailored for Unreal Engine, some for Unity3D, some general implementations for Python, some for C++ and so on. There are some differences between different implementations: Sometimes the Fallback node is called a "Selector", sometimes nodes have memory (I think this is a bad idea as it reduces reactivity, as explained here: kzbin.info/www/bejne/jWjTZGennaeorpo). It seems that the creators of the Unreal BT have described some of the ways their implementation differs from the "standard" under the heading "Differences in Unreal Engine Behavior Trees" found here: docs.unrealengine.com/5.1/en-US/behavior-tree-in-unreal-engine---overview/

Hi Telokis. Thanks for your questions. If you want to know more about real applications you might want to check out the PlanSys2 video here: kzbin.info/www/bejne/emirnHtsiNukoLs As you might have noticed, there is one "version" of BTs that does not include the "Running", where basically all actions are allowed to terminate (returning Success or Failure) before another action starts. However, as you note, this makes reactivity impossible, so I think this version is crap. In principle, I would say that if there is reason to believe that my life is in danger, I would indeed just drop the banana and start leaving the building. A banana on the floor might look a bit messy, but it is not that bad compared to dying in the fire. Another example where there is a bigger need for "gracefully terminating an action" is if you are driving a car when alarm goes off (imagine someone told you there is a bomb in the car). Just getting out of the car at full speed would probably kill you. Here I would say that the responsibility for stopping the car should be with the "get out of car" action. "get out of car" should have a precondition of "very low speed" and if that is not satisfied it would first slam the brakes, and then get out. (Check the video on Backchaining to see how preconditions and postconditions can be used to build the BT). One drawback of this "goal directed" approach is that you would only execute actions needed to reach your next goals, and not tidy up after you. When you are done eating, you just leave the table, not putting dishes back in the sink. This can be addressed by explicitly adding the goal of "having a tidy home" to the BT (again using backchaining). In some sense it comes down to your implementation. You might have a robot system where an action executes motor commands in a really high frequency control loop in a separate process, and if you stop sending new motor commands, the hardware might just stick to the last given command indefinitely, causing something to brake. In such cases, if you implementation really requires that an action is "stopped" before another one is "started", you might just add a middle layer to your design keeping track of "current" and "next" action. The BT then keeps sending this layer an instruction of what should be done next. In the example the new command is "leave building", then the layer knows that it is currently executing "eat banana" and thus sends a "stop" message to "eat banana", waits for confirmation of a proper stop and then sends a "start" message to "leave building" and updates its notion of "current" to be "leave building" and "next" to be "(empty)". As long as "next" is empty, the current one is allowed to run. With this design, if stopping an action takes a long time, it might be that "next" is replaced by something else by the BT before "current" can confirmed its stop. Such a layer would not be overly complex.

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

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.

@@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. :)

@@thaos5499 I'm glad you like them!

Hi Kimochi, I'm glad you liked it!