# Autonomous Navigation Framework for Intelligent Robots Based on a Semantic Environment Modeling
## 3 TOSM-Based Autonomous Navigation Framework
### Semantic Autonomous Navigation
#### 3.3.1 Task Planner  
After receiving a mission, such as _robotAt place1_ (navigation) and _inspected place2_ (inspection), the SMF creates the robot's on-demand database based on the mission and its capabilities. For example, different robots have different capabilities: some can go up and downstairs, while others can operate an elevator autonomously, as shown in Figure 6. Considering a robot that can operate the elevator, the on-demand database does not need to contain the staircases' information.  
The task (i.e., mission) planner access only to the on-demand database speeding up the queries during the plan execution. The environmental implicit information, namely _isConnectedTo_ property together with the robot's location, is used to populate the ROSPLAN [11] knowledge base. The robot's implicit information is also used to provide the domain PDDL file. Thereupon, ROSPLAN is used to generate a valid behavior sequence. To generate a behavior sequence, PDDL planners require two files: domain and problem. The domain file describes the environment predicates and robot actions. As different robots can perform a distinct set of actions, a comprehensive set of domain actions, all sharing common predicates between them, is stored into the behavior database. Given the robot's implicit TOSM data, a matching domain file is generated and fed to ROSPLAN by the behavior database; the problem file is generated automatically by ROSPLAN knowledge base. It needs, however, the environment state information to do so. ROSPLAN state update services are  
Figure 5: Human-like memory architecture.  
used to feed the map data into the knowledge base. After that, the behavior sequence is generated through the Partial Order Planning Forwards (POPF) planner [97]. Despite the current state of the behavior database not including temporal-actions, we have plans to also support them in the future. Therefore, we opted to use the POPF planner due to its ability to deal with both simple and durative actions. ROSPLAN also sends the current behavior to the Behavior Planner through the medium of the Plan Dispatcher node.  
In our example, the 02 robot shown in Figure 6b receives the multi-floor navigation mission. The robot then receives the on-demand database generated by the SMF based on the robot's implicit information (i.e., its capabilities). This on-demand database contains the building floors and the elevators, but no stairs, as the robot cannot transverse through them. Moreover, a domain file containing all the possible robot actions is sent to the ROSPLAN knowledge base. An example action, which sends a robot to a waypoint on the same floor, is shown on Listing 1. The predicates are general and shared between all actions stored on the database, thus making possible generating the domain file simply by querying which actions can be performed by the robot. Subsequently, the environment TOSM data is used to populate the ROSPLAN knowledge base environment state, adding connected waypoints, elevator, robot, and goal predicates. After running the POPF planner, the behavior sequence shown on Listing 2 is generated and sent by the dispatcher node to the Behavior Planner module.  
```
(:actiongoto_waypoint :parameters(?v - robot?from?to - waypoint?fl - floor) :precondition (and (outside_elevator?v) (robot_at?v?from) (waypoint_at_floor?from?fl) (waypoint_at_floor?to?fl) (hallway_waypoint?from) (hallway_waypoint?to) (connected_to?from?to) ) :effect (and (robot_at?v?to) (not (robot_at?v?from)) )
```  
Figure 6: The CIR robot is equipped with a continuous track and extension arms, enabling going up and downstairs. The 02 robot is equipped with sensors and manipulators that allow elevator operation.