# Framework for Fast Experimental Testing of Autonomous Navigation Algorithms
## 3 Framework Design  
Our research group is currently working on developing localization algorithms for mobile robots. More specifically we are interested in the integration of GNSS information in graph SLAM algorithms. On the other hand, we would like to test these algorithms in the context of a complete autonomous application to study how the localization influences the system performance and to be able of conducting such experiments in the widest possible variety of environments. With this purpose, we first tried to implement an autonomous navigation system using the well-known ROS navigation stack. Nevertheless, we found that the tools provided by this stack were too much geared towards the use of two-dimensional grid maps, which makes difficult the integration of alternative localization algorithms as can be seen in [36]. For this reason, we designed an alternative framework that--among other interesting features--provides enough flexibility to integrate localization algorithms of different nature in an easy and convenient way. In advance of what will be discussed in this section, we summarize here the main advantages that our final framework design brings with respect to navigation stack:Our planning is independent of the environment representation. In the navigation stack, global planning depends on a grid map, making it difficult to use alternative representations of the environment. On the contrary, following our approach any planning module must be independent of the environment representation, as can be seen in Figure 1. This favors modularity and eliminates conversions and other undesired extra processes required to integrate alternative environment representations with the navigation stack. An example of this can be found in [36], where the authors explain the integration of a graph-based visual SLAM system with the navigation stack planning and control modules. The authors report that they had to create a grid map from their native graph representation and that this extra process introduced additional problems that even forced to discard two of the three scenarios for the path-planning experiments carried out for the paper. 2. Every ROS node belongs to a single module. The navigation stack does not follow this rule, which makes difficult the substitution of certain components. For example, the move_base node fuses planning and control, which makes it rigid in its operation [26]. In contrast, replacing modules in our framework is as easy as changing a single line in the ROS launch file. This makes the produced systems flexible and easy to adapt to different specifications (e.g., different robot kinematics, highlighted as a ROS navigation stack limitation in [24; 35]) because only the related nodes need to be modified or substituted. 3. Our framework follows a clear conceptual structure. In [37] we see an example of how developing a complex system using the navigation stack can lead to an intricate architecture. On the contrary, we follow a conceptual structure based on abstraction levels to make the applications clear, organized and scalable. Moreover, a neat division in conceptually different sub-problems makes easier to keep the research focus on the topics of interest without giving up the advantages that a complete system in real-world operation provides for experimental testing, as happens when using datasets or simulators. Figure 1: Proposed framework design. Each node represents a software module, and each solid line represents a communication channel between modules. The dashed lines represent optional channels that might connect the localization module with a map of the environment and the planning module with a map of trajectories. The existence of these optional channels depends on the concrete localization and planning algorithms used. The different modules are organized in abstraction layers (sensors, preprocessed...) as well as in conceptual blocks denoted by colours: perception (blue nodes), motion (green nodes) and high-level (white nodes).