## 3 Description of the Selected Proposals
### ROSPlan  
ROSPlan [82] is a framework that, according to their authors, provide a collection of tools for AI planning in a ROS system. Although ROSPlan is designed for any robotics, it was originally developed for the PANDORA [83] project for its use with AUVs, and was validated in the experiments that were carried out in said project [84].  
ROSPlan uses a modular design where a number of ROS nodes provide the functionalities for planning, problem generation and plan execution. Initially presented in [85], in June 2018 a complete new version was presented.  
The components of ROSPlan are defined as ROS nodes, and the general overview of the system is shown in Figure 22. There are five ROS nodes defined [86]:  
* The knowledge base, used to store plan models using PDDL.
* The problem interface, used to generate the description of a problem using PDDL, and publish it on a ROS topic or write it to a file.  
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Feature** & **Category** & **Explanation** \\ \hline Plan & 1 & The proposal does not imply the use of a predefined mission \\ Specification & & plan specification. \\ \hline Adaptation & 5 & Although there is no clear mention to the use of self-adaptation, the TRAC architecture evaluates the current state of the system \\  & & continuously, allowing for the re-planning of the mission plan if \\  & & required, both at the mission control and at the vehicles. \\ \hline
**Virtualization** & 1 & There is no mention to the use of virtualization or abstraction of the vehicles capabilities. \\ \hline Dispatching & 3 & From the ACE description it seems that the dispatching of the actions to the vehicles is performed task by task. \\ \hline \hline \end{tabular}
\end{table}
Table 11: TRAC assessment.  
Figure 21: ACE Action Manager components.  
* The planner interface, used to invoke a planner and either publish the resulting plan to a ROS topic, or write it to a file.
* The parsing interface, used to translate a PDDL plan into ROS messages.
* The plan dispatch, which is responsible for the plan execution.  
In ROSPlan the process starts by the specification of a problem as a PDDL problem instance using the Problem Interface node and the knowledge base. When the problem description is available, it is published to a ROS topic. A planner interface subscribed to that topic will receive the problem description, and using an AI planner will try to find a solution. If the planner is successful, the solution is published to another ROS topic. In this case it will be addressed to a subscribed parsing interface that will process the published solution to genere a plan representation that can be a Petri-net plan, an ESTEREL plan, or a sequential plan. This plan representation is again published to another ROS topic addressed to a subscribed plan dispatch. The plan dispatch receives the plan as a whole, and dispatches each action individually. A diagram for the plan dispatch node is shown in Figure 23.  
Figure 23: ROSPlan Plan Dispatch node.  
Figure 22: ROSPlan framework overview.  
Regarding the assessment of the features considered in this survey, the ROSPlan proposal is quite clear in the use of PDDL for the specification of the mission plans. There have been some efforts on developing additional ROS nodes capable for handling probabilistic plans described with RDDL [87], but they are not still part of the ROSPlan framework. Therefore, we have assigned it with a category 3 for the plan specification feature.  
However, ROSPlan does not describe either an adaptation or a virtualization mechanism. Therefore, we have assigned a category 1 for both the adaptation and the virtualization features.  
Finally, the dispatch of the tasks in the mission plan is done in a sequential way, and subsequently we have assigned a category 3 for the dispatching feature.  
A summary of the categorization for the measured features is included in Table 12.