## 3 Planning-Based Architecture  
As presented in the previous section, components can contain finite state machines within, allowing a qualitative leap in generating behaviors. FSMs let us overcome the limitation of implementing only reactive behaviors, being able to implement more complex behaviors. FSMs let us organize the mission of a robot into phases, activating different skills in each one. Furthermore, a skill can adapt its performance by dividing it into different states. By having multiple FSMs at different levels, we can easily implement hierarchical finite state machines (HFSMs). This approach is appropriate for a large number of applications. HFSMs have also their limitations. Behavior designers need to know all the steps a robot must take to accomplish its mission. Not only that, designers must also anticipate all the error situations that can occur in each of the states. Separate states handle each contingency, and transitions to these states need to cover all the error conditions. Additionally, there should be a transition to the pre-error state, once managed the contingency. If an error can occur in more than one state, it is possible to duplicate the state that handles the exception, or use a more complex technique, since it is necessary to differentiate which state to return to after the contingency. Due to these limitations, we decided to include symbolic planning abilities in our architecture instead of defining states and transitions, planning specifies actions and under which conditions they can be applied. Given a goal, a planner calculates a plan (a sequence of actions) to obtain it. A planning system checks at run-time whether the conditions of the current action continue to be met. If any condition is not met, the planner generates an alternative plan. If the condition verifies that a problem has not occurred (that the robot has a battery, for example), the alternative plan will include actions to solve it (charge its battery), followed by actions until the objective is met. Planning Domain Definition Language (PDDL) [28] is an attempt to standardize languages for defining actions, conditions, and goals for different planners. It was fundamentally inspired by STRIPS and is the basis for many symbolic planners. Two components are required to generate a plan using PDDL: a domain and a problem. The domain specifies:  
* The types of instances that can exist. * The types of predicates available. These predicates are facts, which can contain several instances to which it refers. * Actions, with their preconditions and their effects, expressed in terms of predicates and logical operators. A problem is a set of instances and predicates. It is the starting point from which we want to create a plan. A plan also contains the goal to be achieved. We could consider a domain as the static part and the problem the active part. A planner is the core of a planning system but also contains other parts, as shown in Figure 4: A planning system also contains a knowledge base where to store the problem and provides all the mechanisms to query/update its content. The planning system reads the plan generated by the planner and executes the actions in the plan. Therefore, it must be a standard interface to activate actions and pass them the arguments that that plan contains. The planning system is also responsible for checking the conditions of the action at run-time, as the knowledge base could be updated with new information beyond the effect of the successfully performed actions. Our architecture grew with the incorporation of a planning system, creating three new layers, as shown in Figure 5.  
Figure 4: The components of a planner system. Figure 5: Layered planning-centered architecture. * The inner level, or tier 1, works at a symbolic level based on the information contained in the planning system knowledge base. This layer controls the robot's mission, establishing the goal to be achieved in each phase. We implemented it with a component that included FSM, which allows us also to use HFSM if necessary.