DeepDyve requires Javascript to function. Please enable Javascript on your browser to continue.
Behavior Trees for Smart Robots Practical Guidelines for Robot Software Development Behavior Trees for Smart Robots Practical Guidelines for Robot Software Development
Dortmans, Eric;Punter, Teade
2022-09-07 00:00:00
Hindawi Journal of Robotics Volume 2022, Article ID 3314084, 9 pages https://doi.org/10.1155/2022/3314084 Review Article Behavior Trees for Smart Robots Practical Guidelines for Robot Software Development Eric Dortmans and Teade Punter Fontys University of Applied Sciences, Research Group High Tech Embedded Software, Eindhoven, Netherlands Correspondence should be addressed to Teade Punter; teade.punter@fontys.nl Received 20 May 2022; Revised 1 July 2022; Accepted 23 July 2022; Published 7 September 2022 Academic Editor: Ramadoni Syahputra Copyright © 2022 Eric Dortmans and Teade Punter. �is is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. Behavior Trees are a promising approach to model the autonomous behaviour of robots in dynamic environments. Behavior Trees represent action selection decisions as a tree of decision nodes. �e hierarchy of these decision nodes provides the planning of actions of the robot including its reactions on exceptions. Behavior Trees enable „exible planning and replanning of robot behavior while supporting better maintainable decision-making than traditional Finite State Machines. �is paper presents an overview of lessons, which we have learned when applying Behavior Trees to various autonomous robots. We present these lessons as a sequence of steps that is meant to support robot software practitioners to develop their systems. robot needs to be encoded as a sequence of actions but also 1. Introduction: Need for all possible real-world states must also be taken into account. Embodied Intelligence In general, a policy will comprise a combination of a de- liberative plan of actions and a set of actions that are Robots are designed to get a particular task done in the real triggered only when the state of the world requires it. world such as manoeuvre along shop „oors in warehouses, As the real world is too complex to deal with in full detail, it or to support caring staŠ in hospitals. �ey are made to is common practice for roboticists to make abstractions of it. perceive the world using speci‹c sensors, such as camera’s, Every detail that is not relevant for the task at hand is abstracted laser scanners, pressure sensors, and to act in this world away. In this paper, we will use the following abstractions: using speci‹c actuators like grippers, arms, and wheels [1]. In general, an autonomous robot has a control unit that (i) We represent the state space of the world using a takes sensor data as input, builds a model of the world, and collection of boolean conditions. Each condition is a selects appropriate actions for the situation it thinks it is in. predicate that the robot can check for its truth value. To act in its world the robot has a set of built-in skills [2], In this way, we basically divide the complex and such as the ability to move around and to pick and place analogue state-space of the world into a limited objects. (see Figures1 and 2) amount of discrete states. �e decision-making intelligence of an autonomous (ii) Complex actuation algorithms (“skills”) of the robot robot is in its action selection mechanism that determines are abstracted as a collection of actions A that can which skill to activate for which state of the world. �e action bring the world (with high probability) from a selection mechanism can be seen as the centre of the robot precondition to a postcondition. brains. It determines its behavior and with that its (iii) We assume that the conditions can be checked usefulness. instantaneously while actions may take some (un- Designing a robust and maintainable action selection known) time to complete. policy is not an easy task. Not only the primary task of the 2 Journal of Robotics (iv) �e mapping of states S to actions A is represented Action selection (‘robot brain’) as a so-called action selection policy π: S ⟶ A. Action selection policies can be implemented in diŠerent ways. A traditional way to implement such a policy is by using Perception Actions imperative programming language constructs, such as World model Skills statement sequences, if-then-else, and while constructs. �e example in Figure 3 shows a procedural policy, speci‹ed using pseudocode, for an industrial robot that has to move objects. �e example robot has four actions that can be selected: Sensors Actuators “move_to_object,” “grab_object,” “move_to_goal,” and “relea- Figure 1: Robot software architecture embodying intelligence: se_object.” Something might go wrong, and the robot should perception, action, and world model. “stop.” �is results in a fairly simple „ow depicted in the left part of the ‹gure. However, things get complicated when sensor inputs are taking into account as well, see right part of Figure 3. In general, action selection policies are strongly in„u- enced by the environment in which the robots have to work. STATE (S) ACTION (A) Modern, autonomous robots usually have to operate in Object_Detected Pick unstructured environments and have lots of sensors to deal Holds_Object Place Is_At Move_To with. Coding an action selection policy in the traditional, ... POLICY: S → A ... procedural way leads to complex code that is hard to de- Figure 2: Action selection. velop, maintain, and improve. �erefore, we prefer to model robot behavior explicitly instead of implicitly coding it in some programming lan- control nodes, that represent the decisions in the tree, and guage. Our preferred way of modelling is using Behavior leaf nodes that are the actions to be executed and the Trees (BTs) [3, 4]. BTs generalize Sequential Behavior conditions under which those actions are executed. Compositions, the Subsumption Architecture, and Decision Four diŠerent „ow control types are distinguished: Trees [5]. BTs are an e£cient as well as „exible way of (i) Sequence (⟶ )—Execute child nodes one by one creating complex systems that are both modular and re- active. �ese properties are crucial in many applications, until one fails. Execute the ‹rst child, and then the next one until all children have succeeded. which have led to the spread of BTs from computer game programming to many branches of AI and Robotics [6]. (ii) Fallback or Selector (?)—Execute child nodes one by Several authors have already shown that Behavior Trees are a one until one succeeds.Try the ‹rst child, and if it promising approach to model autonomous behaviour in does not succeed then try the next one until one of dynamic environments [6–11], [25, 27]. the children succeeds. A growing amount of literature discusses fundamental (iii) Parallel (||)—Execute all child nodes in parallel until aspects and applications of behavior trees for robotics [3, 6, 7]. a speci‹ed number (e.g., all) of them succeed. Several authors provide formal de‹nitions of Behavior Trees (iv) Decorator (◊)—Modify the execution (result) of its [3, 4] or propose extensions [12]. Others provide algorithms (only) child node. For example: invert, time-out, to implement goal-directed task plans using behavior trees and repeat-until-success. and provide convergence proofs [13–17]. �e goal of this paper is to bridge the gap between Leaf nodes represent the world conditions that are to be fundamental research and practical application of Behavior checked and the actions that can be selected: Trees for action selection in autonomous robots. We provide (i) Condition– Check the state of the world (model). guidelines how to construct BTs to implement reactive, robust, and maintainable robot behavior. We also provide (ii) Action– Act upon the world using a particular skill. advice how to build a „exible BT execution infrastructure. In practice, most BT libraries have all kinds of variations Section 2 introduces the BT formalism and its main of the above introduced „ow control nodes and also allow to syntax. Section 3 provides an overview of advantages and extend the basic node set with domain-speci‹c nodes [7]. disadvantages of using BTs. �e remaining sections provide Action and condition nodes are mostly domain and ap- lessons we learned during BTapplication (Section 4) and are plication speci‹c. aimed to help robot software engineers in building a „exible Figure 4 shows an example of a simple, intuitive BT of a execution architecture for BTs (Section 5). robot that has to pick an object, move it to a destination, and place the object at that location. �e action selection policy of the robot is fully de‹ned by 2. BT Syntax and Semantics the structure and semantics of the „ow control and leaf A Behavior Tree [3] describes the decision-making policy of nodes of the BT. �e hierarchy of decision nodes concisely a robot (or software agent or non-player game character) as a speci‹es all possible sequences of actions of the robot, and rooted, directed tree of nodes. �e tree consists of „ow how these sequences are in„uenced by conditions. Journal of Robotics 3 Figure 3: Example of a procedural policy: basic code (left), extended with sensor input (right). transaction. It can be used to run a sequence of actions as a BehaviorTree transaction, or to always check a precondition before starting an action. Sequence 3. BT Trade-Offs Behavior Trees provide an alternative to Hierarchical State MoveToObject PickObject MoveToGoal PlaceObject Machines (HSMs). Both are equally expressive. We per- ceived the following advantages when applying BTs [3]: Figure 4: Na¨ıve BT with four action nodes and a “sequence” (i) Modularity, Reusability—BTs are modular on all control „ow node. scales. Any subtree from a BT or even any complete BT can be reused as a subtree in another BT. To be able to execute a BT, each node supports a “tick” (ii) Readability—�eir tree structure and modularity method. When this method is called (by its parent node), the makes BTs well readable and therefore better ana- node is activated. If a node needs more time than one tick to lysable and understandable by humans. execute, the tick method returns status “RUNNING” to its (iii) Maintainability—�e tree structure of BTs is better parent. When the node completed its task, its tick method maintainable than the transitions in HSMs. Deci- returns “SUCCESS” if its outcome was positive or “FAIL- sions in BTs are represented explicitly as nodes, and URE” otherwise. are not hidden in state transition conditions. A BT is executed by calling the tick method of the root (iv) Learnability—BTs can be learned by (machine) node at a certain frequency. Ticking the BTneeds to continue learning programs [3] or generated from a for- while its root node returns “RUNNING” and stop when the malized plan [15]. root node returns SUCCESS or FAILURE. Each „ow control node passes the tick on to its child On the negative side, we should mention: nodes, one by one, or in case of a parallel node all at the same (i) Veri‹ability- BTs are not yet supported by formal time. Eventually the tick reaches a leaf node. �e tick allows veri‹cation tools, contrary to HSMs. �is short- this leaf node to execute itself, i.e., to check a condition, or to coming can, however, be addressed by translating the apply a skill. A „ow control node that receives a status BTinto an HSM and then conducting the veri‹cation, “RUNNING” from a child will return “RUNNING” to its see, e.g., the Carve project (https://carve-robmosys. parent. How it reacts to receiving “SUCCESS” or “FAIL- github.io/results/). URE” status from a child depends on its type. It is important to note that Sequence and Fallback nodes 4. A Practical Approach to Define BTs tick their children one by one. �is automatically implies a priority: the ‹rst child (from the left) is run before the second �is section aims at providing a structured approach for child and so on. �is can be used to give certain actions robot practitioners for constructing robust and reactive BTs. higher priority than others. We will describe four steps. �ese steps result from our A Fallback node works like a logical “OR” function, but lessons learned when applying BTs in robot research projects instead of checking the status of its children all at once, it at Fontys University of Applied Sciences. �e steps we will ticks its children one by one, starting with the ‹rst, left-most elaborate on are: child. Fallback is often used for trying prioritized alternatives that, when executed, have the same eŠect, i.e., would result in (1) Describe context and purpose of the robot. the same postcondition. (2) Basic plan—describe a “good weather” BT. A Sequence node works like a logical “AND” function, (3) Create a robust plan. but again checking its children one by one instead of all at the same time. A Sequence enforces an all or nothing (4) Add reactivity to the plan. 4 Journal of Robotics “PickObject,” “MoveToGoal,” and “PlaceObject.” (is is the Specific idioms, needed to go from step 2 to 3, are in- troduced as an intermezzo. We illustrate the steps by means same sequence that we would write down as a programmer. Nothing gained yet by using a BT. However, the “good of a running example. (e example that we have chosen is a mobile robot that picks up objects and places them at some weather” scenario is only valid under the following goal location. assumptions: (1) (e state of the world at the start is as required by the 4.1. Step 1: Describe Context and Purpose of the Robot. scenario. Before even starting to create a BT, a context description of (2) All actions do eventually complete successfully. the robot application helps to identify the relevant aspects to (3) No external agent does interfere by changing the be covered by your BT. (inking about the system context world state, while the scenario is running. first is a general good design principle, which is, e.g., ad- vocated by the C4-model (https://c4model.com/). (e fol- In practice, it is unlikely that all these assumptions hold lowing aspects are helpful when defining the context for a true; in our example: robot application: system goal, actions, scenarios, and states; (1) (ere might not be an object at the pickup location. inspired by Winikoff and Padgham [18]. (2) Grabbing the object might fail. (e system goal describes what the robot should do. (e goal for our robot is moving objects to a goal location. (is (3) (e robot might lose the object it has picked. should start the thinking process. What actions does the (4) (e robot might run out of (battery) power. robot need to perform? Which world and robot states should (5) An external agent, such as a human or another robot, we be able to check? What action to execute in which state? might take the object away and puts it at the goal (e actions describe which action skills are needed by the location. robot to achieve its system goal? In case of our example robot, obvious actions will be “move to object,” “pick ob- (is implies that many more possible scenarios should ject,” “move to the goal,” and “place object.” In reality, there be incorporated in our BT. In general, a good BT should be a are usually many more actions to consider. concise model that describes all the possible scenarios, i.e., A scenario describes the dynamics of the robot, by all possible sequences of actions. In order to select between linking the actions into a sequence, like first moving to an various scenarios, we need to add conditions to the BT, i.e., object object, then picking it up, then moving to the goal we need to check the actual state of the world (including the location, and finally placing it there. Although writing down robot itself) to decide which action is eligible for execution. a scenario might look straightforward, in practice often problems pop up when you think about all situations that 4.3. Intermezzo: Adding Checks (Idioms) for Robustness. can interrupt the normal sequence of actions, e.g., when our (e BT that was derived in step 2 encodes a “good weather” robot finds itself at a closed door or when its battery is scenario and assumes that all actions go well. It does not empty. Do always take non-functional requirements, like react on any disturbances and just gives up if one of the power or safety, into account when thinking about scenarios. actions fails. In the previous step, the robot is modelled by Being aware of contingencies, and thinking in terms of “bad ordering the actions as then . . . else, but not taking the if, the weather” behavior for the robot, does in general help to condition, really into account. (ese ifs, the conditions or define a robust BT (see step 3). In general the “good weather” guards, are added to ensure the appropriate context to scenario is just one of the scenarios to consider. execute the action. We can do better than that by adding States are related to the scenarios because they define checks to enrich the BT with other possible ways to execute when actions are eligible for execution. In our example, the to make the BT more robust. most important state of the robot is its position in the world. Several checks can be added. A precondition check can Dependent on its position (at origin, at goal), appropriate be added to the action (or subtree) using a Sequence node, as actions can be conducted, like: picking at origin, placing at depicted in Figure 5 (left). A postcondition check can be goal. In general, there are many more states to consider than added using a Fallback node as depicted in Figure 5 (right). just the robot position, such as the location of the objects, the A specific pattern that is constructed from these idioms state of the robot gripper, or the state of the robot battery. is the postcondition precondition action (PPA) pattern [3]. Being aware of which states are relevant helps to refining the Several actions can have the same postcondition but with BT (see step 2). different preconditions. By combining these alternatives using a Fallback node, we can improve the robustness of the 4.2. Step 2: Basic Plan, Define a “Good Weather” BT. BT. (e PPA pattern is a subtree which combines fallback to When the context and purpose of the robot are defined, it is alternative actions with precondition and postcondition time to draw a first BT to describe the task that the robot has checks. (see Figure 6) to do as a sequence of actions. (is procedure should result in a first, intuitive version of the BT which should work when there are no disturbances, a so-called “good weather” BT. 4.4. Step 3: Create a Robust Plan. Now, the idioms—to In our running example, our BT is identical to the BT of achieve robustness—have been introduced, we can apply Figure 4, a simple sequence of actions: “MoveToGoal,” them. Step 3 is about the creation of a robust BT, to execute a Journal of Robotics 5 → ? post action pre action Precondition–specifies what must be true to Post condition–specifies what will be true when a execute a skill. It is the condition that applies to a skill is executed. It applies to a fallback of skills: sequence of skills. In pseudocode: if pre do if the condition is not fulfilled another action action. should be done. In pseudocode: if not post do action. Figure 5: Pre- and post-condition de‹ned. Note that in this case a so-called “ReactiveFallback” node is used. �is node always ticks all its children (from left to right), even those that have already returned “SUCCESS” during earlier ticks. post →→ An alternative approach to create a deliberative plan is expanding the BT by using “backward chaining” [13, 14, 16]. �e method here is to iteratively expand preX actionX preY actionY preconditions. We start by taking the last, most down- stream action, and work our way backwards. �e pre- Figure 6: Postcondition-precondition-action (PPA) pattern subtree. condition of this action is replaced with the PPA subtree which postcondition is the same as this precondition and so on. (see Figure 9) When applying backward chaining to our running ex- ample, the result will be the following robust BT Figure 10. Mart´ın et al. [15] describe yet another approach to generate a deliberate BT. �ey start by generating a plan → → → using a PDDL-based planner [19] and then automatically convert this plan into a robust BT for execution. ... preN actN pre2 act2 pre2 act1 Figure 7: Representation of a robust logical-dynamical chain 4.5. Step 4: Add Reactivity to the Plan. �e deliberative plan (RLDC). for the robot ensures that the robot will do its primary task. However, there might be contingencies to deal with. A robot can only ful‹ll its task when it remains safe and in good deliberate, goal-oriented plan in an eŠective and e£cient working condition. While it is executing its deliberate plan, way. �e way to generate such a plan in the form of a BTcan problems may occur, like an empty battery. We do not know be done manually as well as automatically by a deliberative if and when these problems will occur, but we should take planner. care of them as soon as possible. Handling contingencies is A straight forward way to de‹ne a robust BT is by using of higher priority than executing a deliberate plan. �e the “Robust Logical-Dynamical Chain” pattern [17] Figure 7, Fallback node already handles this priority. Its leftmost child which is also described as “Implicit Sequence” in [3]: is ticked ‹rst and thus has the highest priority. From left to (1) Reverse the order of the actions, de‹ning most right, priority goes down. Contingencies therefore have to be downstream action ‹rst (reading from the left of the added to the left of the existing deliberative subtree as tree). depicted in Figure 11. In our running example, we introduce reactivity to the (2) Replace the Sequence node by a Fallback node in order to change from an explicit to an implicit deliberative plan by adding a check on battery power level of the robot. If the power level will drop below a minimum level, sequence. the robot is triggered to move to its charging station and starts (3) Add a precondition check to each action. charging itself. �is functionality is added as rows 3 and 4 in When we apply this pattern on our running example, we Figure 12, which is a supplement on the left compared to the reverse the order of the actions, compared to how they were deliberate BT that was earlier created in Figure 10. �e de‹ned in the na¨ıve BTor basic plan BT, Figure 4. �e result resulting Figure 12 presents a robust and reactive BT. is shown in Figure 8. If the precondition of an action fails, we fall back to the 5. BT Execution Architecture next (more upstream) action, and so on. �e order of the actions is reversed because we are primarily interested in Now, the basic steps for creating a robust BTs have been running the last, most downstream action, because running introduced and the BT-models have to be executed by real that action will give us the outcome we want. code. �is section deals with the construction of a BT 6 Journal of Robotics BehaviorTree ReactiveFallback Sequence Sequence Sequence Sequence AtGoal PlaceObject HoldsObject MoveToGoal AtObject PickObject DetectedObject MoveToObject Figure 8: Result of step 3—robust logical-dynamical chain. postN →→ postN actN deliberate contX reactX contY reactY subtree postN-1 → preN actN Figure 11: Handling contingencies by adding reactivity to the plan. preN-1 actN-1 (sequencer) tier, and a controller (skills) tier. �e deliberator Figure 9: Expanding the BT using backward chaining. produces high-level task plans. �e executor is responsible for the execution of those plans, by sequencing primitive skills. In a reactive robot architecture [8, 21, 22], the executor BehaviorTree is in charge of driving the overall system by requesting new plans from the deliberator and dispatching subtasks to speci‹c robotic controller (skill) modules. In this case, the Sequence executor considers the deliberator as one of the available skills. �e three-tier architecture can be applied at multiple Fallback PlaceObject abstraction levels. Some skills might be quite complex and will require a three-tier structure themselves. For instance, a “NavigateTo” skill needs a motion planner to calculate a path AtGoal Sequence in the map and a controller to follow that path while avoiding collisions and a recovery skill that gets the robot out of navigation problems. A BT-based executor could be used Fallback MoveToGoal to coordinate these subskills [8]. A deliberator is essential in applications where plans need to be constructed at run time. Runtime planning takes HoldsObject Sequence time but does also provide optimized and e£cient behavior. For a lot of applications, a good enough plan can be con- structed at design time, either manually or using an auto- Fallback PickObject matic planner. �is holds in particular for reactive, behavior- based robotic applications [23]. Design time generated plans have the advantage that they can be validated or veri‹ed AtObject Sequence before deployment. Flexibility can be added to such a plan by runtime switching between prede‹ned subplans. Skills [2, 12, 24] are basic building blocks of task plans. A DetectedObject MoveToObject robotic manipulator arm typically has skills like “Pick” and “Place” to be able to pick-up an object and place it somewhere. Figure 10: Another result for step 3—by backward chaining. A mobile robot typically has skills like “NavigateTo” to plan a path and follow that path while avoiding objects. Basic skills execution architecture for the successful application of BTs related to object detection, navigation, and arm motion are in robots. common to a lot of robots. Added to those common skills, Robot software is typically divided into three tiers [20], speci‹c application domains like manufacturing [24] or robot comprising a deliberator (planner) tier, a task executor soccer [25] require domain speci‹c skills. Journal of Robotics 7 Production quality, opensource Behavior Tree libraries, and BehaviorTree editors for robotic applications are available [7]. A good ex- ample is BehaviorTree.CPP (https://github.com/BehaviorTree). ReactiveFallback �is open source library is currently being used in essential ROS2 packages, such as the Nav2 (https://navigation.ros.org) navigation stack [8]. It is a C++ based library that reads and Sequence Sequence runs behavior trees speci‹ed in XML. �ese XML ‹les can be created using any text editor but also a nice graphical editor is provided, called Groot (https://github.com/BehaviorTree/ ChargeBattery PlaceObject BatteryLow Fallback Groot). �is editor will not only be applicable to edit a Be- havior Tree but does also monitor a BT-execution in real-time AtGoal or enables replay of a trace of its execution. Sequence When applying the BehaviorTree.CPP for your BT- implementation, all of the required BT control-, decorator-, Fallback MoveToGoal condition- and action nodes need to be implemented in C++. A couple of frequently used BT nodes are provided. When other application or domain speci‹c nodes are HoldsObject Sequence needed, they must be implemented as C++ plugins. Various base-classes are provided to make it easier to construct such new behavior tree plugins. A good practice is to make these Fallback PickObject plugins as thin as possible and make them delegate the work to specialized servers. AtObject Sequence BTengines do usually support some kind of a blackboard. �is way parameters can be set by one node and read by another. BehaviorTree.CPP action and condition nodes can DetectedObject MoveToObject exchange data via named and typed ports on a blackboard. All input and output ports, including their name and type, must Figure 12: �e reactive deliberative plan by adding a contingency be declared in the source code (header ‹le) of a node. on battery level. In ROS, an application is a computation graph of interacting ROS nodes. ROS nodes interact by using any of �e purpose of a skill is changing the state of the world the following interface concepts: topics, services, and actions. what the robot lives in. By using its sensors, the robot can Topics are meant to be used for publish/subscribe commu- discover which objects are present in its world and where nication of continuous data streams (e.g., sensor data, robot state). Services are meant for remote procedure calls that these objects are probably located and what their status is. Using sensor fusion and prediction, the robot can derive a terminate quickly, e.g., for querying or setting the state of a node or for calling a quick calculation. Actions should be used WorldModel out of these observations, containing all beliefs that the robot has about its world. Skills can be implemented for activating long running activities such as making a plan or moving a robot to goal pose. An action can be preempted, i.e., in a reusable manner by parameterization. Objects and locations can for instance be passed to skills as names of cancelled before completion (see Figure 13). objects or locations that are attached to physical objects and A BT sequencer that is implemented in ROS should be a locations by a lookup in the WorldModel. node that runs the BT engine. It enables the BT engine to For task planning and execution, it is important to note read the BT structure from an XML ‹le and instantiates the that a skill has a precondition to be successful and an eŠect, nodes and it makes it possible to tick the root node of the BT i.e., a prediction of the postcondition after its execution. For with a ‹xed frequency, which will be somewhere between 10 and 1000 Hz. the use of automatic planners, skills with their precondition and eŠect are usually formally de‹ned using, e.g., PDDL [19]. �e BT action and condition plugins would act as action clients of ROS Action Servers or service clients of ROS �e executor (sequencer) is the software module that coordinates the execution of a task plan by sequencing skills. Service Servers. Action and Service Servers would be implemented in other nodes that could have been written in In our case, the executor (sequencer) is a BT engine, i.e., a software module that instantiates a BT in memory and ticks C++ but could be implemented in Python as well. �is is it. �e structure of the BT may be hardcoded in the source exactly how the ROS2 Nav2 navigation stack works [8]. code but may also be derived dynamically from a speci‹- cation ‹le (in XML or JSON format). We prefer the latter. 6. Summary A common platform for robot software development is the Robot Operation System (ROS (https://www.ros.org/)) Behavior Trees (BTs) are very well suited to model and [26]. ROS is a set of software libraries and tools for building implement the robot behavior. �eir modularity is a big robot applications. ROS2 [27], the next generation of ROS, is advantage because it enables robot engineers to quickly well suited for industrial applications. A successful BT exe- develop, adapt, and extend the behavior of a robot. Fur- cution architecture should be able to ‹t in this infrastructure. thermore, the visual representation of the BTs makes them 8 Journal of Robotics bt file bt engine blackboard condition condition action plugin action plugin action plugin plugin plugin Service Server Service Server Service Server Action Server Action Server WorldModel Skill_x Skill_y Figure 13: Behavior tree execution architecture. [2] S. Bøgh, O. Nielsen, M. Pedersen, V. Krueger, and O. Madsen, easier to read and to be modi‹ed compared to (larger) “Does your robot have skills?” in Proceedings of the 43rd hierarchical state machines (HSM); in particular, when International Symposium on Robotics, Taipei, China, 2012. supported by a graphical editor. [3] M. Colledanchise and P. Ogren, Behavior Trees in Robotics �is paper provides a hands-on approach for robot and AI—an Introduction, Chapman & Hall, London, UK, software developers to apply BTs in their robot designs by: (1) a way of working for the stepwise construction of robust [4] A. Marzinotto, M. Colledanchise, C. Smith, and P. Ogren, and reactive BTs and (2) the de‹nition of a „exible archi- “Towards a uni‹ed behavior trees framework for robot tecture to execute BTs for ROS(2) based robots. control,” in Proceedings of the IEEE International Conference on Robotics and Automation (ICRA), Philadelphia, PA, USA, Data Availability 2014. [5] M. Colledanchise and P. Ogren, “How behavior trees mod- �e data used to support the ‹ndings of the study can be ularize hybrid control systems and generalize sequential be- obtained from the corresponding author upon request. havior compositions, the subsumption architecture, and decision trees,” IEEE Transactions on Robotics, vol. 33, no. 2, pp. 372–389, 2017. Conflicts of Interest [6] M. Iovino, E. Scukins, J. Styrud, P. Ogren, and C. Smith, “A survey of Behavior Trees in robotics and AI,” Robotics and �e authors declare that they have no con„icts of interest. Autonomous Systems, vol. 154, Article ID 104096, 2022. [7] R. Ghzouli, T. Berger, E. Johnsen, S. Dragule, and A. Wasowski, “Behavior trees in action: a study of robotics Acknowledgments applications,” in Proceedings of the 13th ACM SIGPLAN In- �is work was supported by programming autonomous ternational Conference on Software Language, Chicago, IL, USA, 2020. robots in the applied research projects Raak MKB Close [8] S. Macenski, F. Mart´ın, R. White, and J. Clavero, “�e Encounters and Raak Pro DurableCase. �e authors thank marathon 2: a navigation system,” IEEE/RSJ International Simon Jansen and Heico Sandee of Smart Robotics for Conference on Intelligent Robots and Systems (IROS), enabling the use of the example in Section 1. Daejeon, Republic of Korea, 2020. [9] C. Paxton, A. Hundt, F. Jonathan, K. Guerin, and G. Hager, References “CoSTAR: instructing collaborative robots with behavior trees and vision,” in Proceedings of the Robotics and Automation [1] R. Siegwart, I. Nourbakhsh, and D. Scaramuzza, Introduction (ICRA) IEEE International Conference, Philadelphia, PA, to Autonomous Mobile Robots, MIT press, Cambridge MA, USA, 2011. USA, 2017. Journal of Robotics 9 [10] M. Colledanchise and P. Ogren, “How behavior trees gen- 2017: Robot World Cup XXI, H. Akiyama H., Ed., Springer, eralize the teleo-reactive paradigm and and-or-trees,” in Berlin, Germany, 2018. [26] M. Quigley, B. Gerkey, K. Conley et al., “ROS: an open-source Proceedings of the IEEE/RSJ International Conference on In- robot operating system,” in Proceedings of the ICRA Workshop telligent Robots and Systems (IROS), Las Vegas, NV, USA, Open Source Software, Philadelphia, PA, USA, 2009. ¨ [27] S. Macenski, T. Foote, B. Gerkey, C. Lalancette, and [11] P. Ogren, “Increasing modularity of UAV control systems W. Woodall, “Robot operating system 2: design, architecture, using computer game behavior trees,” in Proceedings of the and uses in the wild,” Science Robotics, vol. 7, 2022. AIAA Guidance, Navigation and Control Conference, Min- neapolis, MN, USA, 2012. [12] F. Rovida, M. Crosby, D. Holz et al., “SkiROS—a skill-based robot control platform on top of ROS,” in Robot Operating System (ROS), A. Koubaa, Ed., Springer, Berlin, China, 2017. [13] Z. Cai, M. Li, W. Huang, and W. Yang, “BT expansion: a sound and complete algorithm for behavior planning of in- telligent robots with behavior trees,” in Proceedings of the AAAI Conference on Artificial Intelligence, vol. 35, no. 7, pp. 6058–6065, Washington, DC, USA, 2021. [14] M. Colledanchise, D. Almeida, and P. Ogren, “Towards blended reactive planning and acting using behavior trees,” in Proceedings of the International Conference on Robotics and Automation (ICRA), Philadelphia, PA, USA, 2019. [15] F. Mart´ın, M. Morelli, H. Espinoza, F. Lera, and V. Matellan, ´ “Optimized execution of PDDL plans using behavior trees,” in Proceedings of the 20th International Conference on Auton- omous Agents and MultiAgent Systems (AAMAS ’21), Rich- land, SC, USA, 2021. [16] P. Ogren, “Convergence analysis of hybrid control systems in the form of backward chained behavior trees,” IEEE Robotics and Automation Letters, vol. 5, no. 4, pp. 6073–6080, 2020. [17] C. Paxton, N. Ratliff, C. Eppner, and D. Fox, “Representing robot task plans as robust logical-dynamical systems,” in Proceedings of the IEEE/RSJ International Conference on In- telligent Robots and Systems, Macau, China, 2019. [18] M. Winikoff and L. Padgham, “(e Prometheus methodol- ogy,” in Developing Intelligent Agent Systems: A Practical Guide to Design, L. Padgham and M. Winikoff, Eds., John Wiley & Sons, Hoboken, NJ, USA, 2004. [19] M. Ghallab, A. Howe, C. Knoblock et al., “PDDL—the planning domain definition language,” in Proceedings of the AIPS-98 Planning Competition Committee, Pittsburgh, PA, USA, 1998. [20] E. Gat, “On three-layer architectures,” in Artificial Intelligence and Mobile Robots, D. Kortenkamp, R. Bonnasso, and R. Murphy, Eds., MIT/AAAI Press, London, UK, 1998. [21] R. Bonasso, D. Kortenkamp, D. Miller, and M. Slack, “Ex- periences with an architecture for intelligent, reactive agents,” Journal of Experimental and Beoretical Artificial Intelligence, vol. 9, no. 2-3, pp. 237–256, 1995. [22] Y. Jiang, N. Walker, M. Kim et al., “LAAIR: a layered ar- chitecture for autonomous interactive robots,” in Proceedings of the AAAI Fall Symposium on Reasoning and Learning in Real-World Systems for Long-Term Autonomy, Arlington, VA, USA, 2018. [23] R. Brooks, “A robust layered control system for a mobile robot,” IEEE Journal on Robotics and Automation, vol. 2, no. 1, pp. 14–23, 1986. [24] M. R. Pedersen, L. Nalpantidis, R. S. Andersen et al., “Robot skills for manufacturing: from concept to industrial deploy- ment,” Robotics and Computer-Integrated Manufacturing, vol. 37, pp. 282–291, 2016. [25] L. de Koning, J. Mendoza, M. Veloso, and R. van de Molengraft, “Skills, tactics and plays for distributed multi-robot control in adversarial environments,” in RoboCup
http://www.deepdyve.com/assets/images/DeepDyve-Logo-lg.png
Journal of Robotics
Hindawi Publishing Corporation
http://www.deepdyve.com/lp/hindawi-publishing-corporation/behavior-trees-for-smart-robots-practical-guidelines-for-robot-JEj8A09V0n
