A behavior tree example for the patrol application 

Contexts in source publication

Context 1

... way we can relate each agent behavior to its context. For a mobile robot to complete a task successfully it must analyze its state, the environment and its context to choose the best possible actions. Our framework is based on three main steps to accomplish this: context gathering, semantic trajectory building and decision making. The first step is context gathering. To understand the environment and the state of the agent, we gather context information available on the application. Each scenario or application will have its own context. Context information can come of four sources: agent, environment, user and previously known information. The agent context, or inner context, describes internal values and states like speed, acceleration, energy level, etc. These information are obtain through sensors of the robot. The environment context, or outer context, is important to understand the state of the scenario. The user can also input its own context via console like, for example, an user preference, a command, etc. And finally, the context can be previously known information like, for example, a map, a task, or any other information stored on a database. An agent has two trajectories: a planned trajectory and an executed trajectory. The planned trajectory is the trajectory generated by a path planning algorithm and describes the path the agent should follow. The executed trajectory is the trajectory that the agent execute, that could be di ↵ erent from the planned trajectory by unpredictable factors on the map or error in following the path. The planned trajectory is enriched with previous knowledge or by predict the context values. The executed semantic trajectory is enriched with the context captured by the previous step. As the robot moves, each timestamped location is captured and transform into a semantic point. To associate the context value to a trajectory point we use the timestamp of the elements. A context of timestamp t i will be associated to a semantic point of timestamp t i . The task information is decided by the decision making algorithm, and it is associated to the semantic subtrajectory, where a set of points are related to the same task. At the end of a task, we will have a semantic subtrajectory, where the set of semantic points will represent the evolution of all the context associated through the time. At the same time as the trajectory building, the framework uses the context information for the decision making. The decision making process uses a behavior tree to choose the most appropri- ated behavior. The set of possible behaviors are application dependent. For example, in a patrol application where the agent must patrol the areas A and B; the main behavior should have two actions: goToA and goToB. As the agent must execute all the actions in this order, they are con- nected together by a sequence node named patrol . Besides patrol the area, the agent must not run out of energy. So we must have a behavior to keep the agent alive. For this behavior, first we need to verify the state of charge (SoC) of the battery. This step is solved by a condition node that will check if the agent need to recharge. If the agent need to recharge, the next step is to move to an energy source. This is a move action. The last action of the behavior tree is to recharge the battery when the agent get to the energy source. The keep alive behavior is a sequence node connecting the condition and both actions nodes. With the patrol and keep alive behavior tree we have the two behaviors to this application. Now we must connect them. As the agent can not patrol without energy, the keep alive behavior must have the highest priority. The figure 3 illustrates the complete behavior tree. First, the root node will try to execute the keep alive behavior. If the condition (energy level) returns success, it will keep running the keep alive behavior. If the condition fails, the behavior tree will execute the patrol behavior. With more context information we can define more complex behavior of the agent to adapt the navigation to the current state of the application. The semantic trajectory can be used to analyze the context changing and choose the proper behavior. To test our framework, we implemented a patrol application for a mobile robot on the Gazebo 2 simulator. The code was implemented on ROS framework in C++ with the behavior tree library by Marzinotto et al. (2014). Our simulation uses a x80sv driver implementation by Saxion Lifescience Engineering and Design 3 . We implemented a sim- ple experiment to easily demonstrate the application of the proposal, but the framework can be used on much more complex scenarios. Our patrol application follows the same example presented on section 3.2. The robot must contin- uous patrol two areas on the map (A and B). The robot should also check the SoC of the battery and, if is low, go to the energy source to recharge at an energy source. The behavior tree is the same as figure 3. For this application, we implemented an ignore-failure sequence node. The sequence node, as presented on section 2.4, executes each child node as they return success and stop the execution if some return failure. But in a patrol application, the robot should continue to patrol the next point even if it fails to patrol the previous. For example, if the access door for point A is closed, the robot will failure to patrol this area. With a sequence node, it will not try to patrol the next area, as the patrol A action will return failure and the whole patrol behavior returns failure. So in the patrol behavior, each patrol action will not return failure, but the patrol behavior can (more on that later). A problem with this behavior tree is the energy level. The keep alive behavior is responsible to check the SoC and recharge the battery. But as the robot is patrolling the area, the energy can reach the critical SoC. As the patrol behavior is a sequence node, it will try to execute all children nodes before resetting the behavior tree, executing the keep alive behavior. To avoid this situation, as the robot moves, the patrol behavior keeps check- ing the SoC. If the SoC get to the critical level, the patrol action is aborted and the patrol behavior returns failure. So in the next tick, the keep alive behavior will be activated, as the battery is on critical SoC. We simulate the battery of the robot as an ideal battery (never gets addicted, the state of health is always 100% and get full charge at recharges). A full battery has 100 power units. The simulation took sixty minutes in an empty world and the critical SoC was set to 20%. The robot patrol go from region A to region B and recharge the battery at an energy source. At the end, of 120 tasks, the robot failed 12 (10% of the tasks) and completed 108 tasks. To understand the failures, we must analyze the semantic trajectory of the agent. The semantic trajectory showed that the robot start a task without know- ing if it would have enough power to finish it. For example, at a certain time, the robot was almost finishing a goToB task but reach the critical SoC, aborting the task and triggering the keep alive behavior. The robot then changes the behavior to keep alive, going to an energy source to recharge the battery. To try decreasing the number of failed tasks we must change the behavior tree. The semantic trajectory of the robot provide information about the execution and allows us to create a new proper behavior tree. The semantic points stores the energy value of each time instant of the trajectory and the sub-trajectory has the total cost of current task. The average cost of each task (go to region A and go to region B) was calculated around 10 power units. In the previous example, when leav- ing region A, the SoC was 28 power units. As the task cost 10 power units, the robot reached the critical level before finish the task. So we update the data to store that the average cost of each tasks is 10 power units, creating a new context information on the application. Now we have to change our behavior tree to incorporate this new context. The figure 4 illustrates the new behavior tree, now with more context information. The patrol behavior now has two sequence nodes: PatrolA and PatrolB. Each of these nodes has two children nodes: a selector node and the goTo action. We will describe the execution of PatrolA behavior tree. The selector node CheckTaskAEnergy first check if the current SoC is bigger than the critical SoC plus the estimate cost of the task. If this condition returns true, the selector node returns true and the PatrolA node executes the goToA action. But if the EnergyAOk condition returns false, the robot SoC is not su cient to execute the goToA action, so the selector node executes the next child node: RechargeA. The RechargeA node is a sequence node that has two actions: moveToEner- gySource and rechargeBattery. So, the execution of RechargeA will recharge the robot battery and returns true. The selector node will then return true and the robot will execute the goToA action. This same process is executed on PatrolB. This ensures that a patrol task will only be executed if the robot has enough SoC. But, if for some reason, the cost of the task is increased (a new obstacle in the way, for example) and reaches the critical SoC, the robot will abort it and execute the keep alive behavior as before. We made a new simulation with the new behavior tree. The table 1 summarizes the results. This new behavior tree proved to be more e cient than before, without any failure and costing less energy. As more context information are added on the system, more intelligent the navigation be- comes. New context information can be added to prepare the robot to new situations. The behavior tree must be revised to incorporate this new context, resulting in new behaviors. A human navigates by knowledge of the map and absorbing context information of the ...

Context 2

... time parameter keep each context information related to the corresponded semantic point. This way we can relate each agent behavior to its context. For a mobile robot to complete a task successfully it must analyze its state, the environment and its context to choose the best possible actions. Our framework is based on three main steps to accomplish this: context gathering, semantic trajectory building and decision making. The first step is context gathering. To understand the environment and the state of the agent, we gather context information available on the application. Each scenario or application will have its own context. Context information can come of four sources: agent, environment, user and previously known information. The agent context, or inner context, describes internal values and states like speed, acceleration, energy level, etc. These information are obtain through sensors of the robot. The environment context, or outer context, is important to understand the state of the scenario. The user can also input its own context via console like, for example, an user preference, a command, etc. And finally, the context can be previously known information like, for example, a map, a task, or any other information stored on a database. An agent has two trajectories: a planned trajectory and an executed trajectory. The planned trajectory is the trajectory generated by a path planning algorithm and describes the path the agent should follow. The executed trajectory is the trajectory that the agent execute, that could be di ↵ erent from the planned trajectory by unpredictable factors on the map or error in following the path. The planned trajectory is enriched with previous knowledge or by predict the context values. The executed semantic trajectory is enriched with the context captured by the previous step. As the robot moves, each timestamped location is captured and transform into a semantic point. To associate the context value to a trajectory point we use the timestamp of the elements. A context of timestamp t i will be associated to a semantic point of timestamp t i . The task information is decided by the decision making algorithm, and it is associated to the semantic subtrajectory, where a set of points are related to the same task. At the end of a task, we will have a semantic subtrajectory, where the set of semantic points will represent the evolution of all the context associated through the time. At the same time as the trajectory building, the framework uses the context information for the decision making. The decision making process uses a behavior tree to choose the most appropri- ated behavior. The set of possible behaviors are application dependent. For example, in a patrol application where the agent must patrol the areas A and B; the main behavior should have two actions: goToA and goToB. As the agent must execute all the actions in this order, they are con- nected together by a sequence node named patrol . Besides patrol the area, the agent must not run out of energy. So we must have a behavior to keep the agent alive. For this behavior, first we need to verify the state of charge (SoC) of the battery. This step is solved by a condition node that will check if the agent need to recharge. If the agent need to recharge, the next step is to move to an energy source. This is a move action. The last action of the behavior tree is to recharge the battery when the agent get to the energy source. The keep alive behavior is a sequence node connecting the condition and both actions nodes. With the patrol and keep alive behavior tree we have the two behaviors to this application. Now we must connect them. As the agent can not patrol without energy, the keep alive behavior must have the highest priority. The figure 3 illustrates the complete behavior tree. First, the root node will try to execute the keep alive behavior. If the condition (energy level) returns success, it will keep running the keep alive behavior. If the condition fails, the behavior tree will execute the patrol behavior. With more context information we can define more complex behavior of the agent to adapt the navigation to the current state of the application. The semantic trajectory can be used to analyze the context changing and choose the proper behavior. To test our framework, we implemented a patrol application for a mobile robot on the Gazebo 2 simulator. The code was implemented on ROS framework in C++ with the behavior tree library by Marzinotto et al. (2014). Our simulation uses a x80sv driver implementation by Saxion Lifescience Engineering and Design 3 . We implemented a sim- ple experiment to easily demonstrate the application of the proposal, but the framework can be used on much more complex scenarios. Our patrol application follows the same example presented on section 3.2. The robot must contin- uous patrol two areas on the map (A and B). The robot should also check the SoC of the battery and, if is low, go to the energy source to recharge at an energy source. The behavior tree is the same as figure 3. For this application, we implemented an ignore-failure sequence node. The sequence node, as presented on section 2.4, executes each child node as they return success and stop the execution if some return failure. But in a patrol application, the robot should continue to patrol the next point even if it fails to patrol the previous. For example, if the access door for point A is closed, the robot will failure to patrol this area. With a sequence node, it will not try to patrol the next area, as the patrol A action will return failure and the whole patrol behavior returns failure. So in the patrol behavior, each patrol action will not return failure, but the patrol behavior can (more on that later). A problem with this behavior tree is the energy level. The keep alive behavior is responsible to check the SoC and recharge the battery. But as the robot is patrolling the area, the energy can reach the critical SoC. As the patrol behavior is a sequence node, it will try to execute all children nodes before resetting the behavior tree, executing the keep alive behavior. To avoid this situation, as the robot moves, the patrol behavior keeps check- ing the SoC. If the SoC get to the critical level, the patrol action is aborted and the patrol behavior returns failure. So in the next tick, the keep alive behavior will be activated, as the battery is on critical SoC. We simulate the battery of the robot as an ideal battery (never gets addicted, the state of health is always 100% and get full charge at recharges). A full battery has 100 power units. The simulation took sixty minutes in an empty world and the critical SoC was set to 20%. The robot patrol go from region A to region B and recharge the battery at an energy source. At the end, of 120 tasks, the robot failed 12 (10% of the tasks) and completed 108 tasks. To understand the failures, we must analyze the semantic trajectory of the agent. The semantic trajectory showed that the robot start a task without know- ing if it would have enough power to finish it. For example, at a certain time, the robot was almost finishing a goToB task but reach the critical SoC, aborting the task and triggering the keep alive behavior. The robot then changes the behavior to keep alive, going to an energy source to recharge the battery. To try decreasing the number of failed tasks we must change the behavior tree. The semantic trajectory of the robot provide information about the execution and allows us to create a new proper behavior tree. The semantic points stores the energy value of each time instant of the trajectory and the sub-trajectory has the total cost of current task. The average cost of each task (go to region A and go to region B) was calculated around 10 power units. In the previous example, when leav- ing region A, the SoC was 28 power units. As the task cost 10 power units, the robot reached the critical level before finish the task. So we update the data to store that the average cost of each tasks is 10 power units, creating a new context information on the application. Now we have to change our behavior tree to incorporate this new context. The figure 4 illustrates the new behavior tree, now with more context information. The patrol behavior now has two sequence nodes: PatrolA and PatrolB. Each of these nodes has two children nodes: a selector node and the goTo action. We will describe the execution of PatrolA behavior tree. The selector node CheckTaskAEnergy first check if the current SoC is bigger than the critical SoC plus the estimate cost of the task. If this condition returns true, the selector node returns true and the PatrolA node executes the goToA action. But if the ...