# Autonomous 3D Exploration of Large Structures Using an UAV Equipped with a 2D LIDAR
## 4 System Architecture  
The system architecture detailed in Figure 4 is divided into two large areas: Vehicle and Exploration Architecture. As shown, these areas are abstractions that can be easily interchanged for different types of systems as long as the sub-components, which will be detailed throughout this section, follow the same architecture.  
The software architecture is based upon the Robot Operating System (ROS) software framework by [PERSON] et al. [46], which allows a hardware-agnostic design through the use of its interprocess communication interfaces. The different components are described in the following:  
* **Sensor**: The sensor is a Hokuyo 30 LX 2D laser sensor with a range of 30 m;
* **Software for basic commands execution**:
* _UAL (UAAV Abstraction Layer)_: A software-interface for hardware abstraction [47] which handles the standard commands to control the vehicle such as velocity control, taking-off, and landing;
* _Path Follower_: Software to follow a waypoint sequence [48], while also adjusting vehicle yaw, so that in every segment the Hokuyo sensor is aligned with the movement.
* **Octomap**: Occupancy octree for world representation using the octomap framework [42], as previously detailed in Section 3.1. The world representation is shared among all the components;
* **Flyby manoeuvre**: The manoeuvre executed to collect data around the target to gather 3D information with the 2D laser, as described in Section 3.2;
* **Path Planning**: The Lazy Theta* any-angle deterministic planner proposed by [43] and adapted in previous work of the authors [44] due to the advantages mentioned in Section 3.3;
* **Exploration Strategy**:  
Figure 4: System architecture showing the correspondence between the generic elements and the chosen components and algorithms.  
* _Frontier Algorithm_: The classical and widely-used frontier exploration algorithm presented in [28]; The implementation used is an extension of [49], that generates neighbours taking the sensor range into account as presented in Section 3.4;
* _Frontier Management_: Combines and orders the operational requirements, such as safety distance, observation manoeuvre visibility, or obstacle detection, with exploration optimisation. The characteristics presented in Section 3.5 are incorporated in this component.
* **Exploration Manager**: Orchestrates all other components to achieve the high-level mission goal of the whole-scenario exploration.  
To select a suitable unknown point to sample, the frontiers algorithm searches inside a boundary and identifies several candidate frontiers, listing their unknown neighbours by order of proximity. Afterwards, the Frontier Management component searches for a safe flyby manoeuvre around each unknown point with only the caveat that manoeuvre selected: (1) If there is visibility between the flyby and the unknown point; (2) if the flight corridor of the flyby is within free space; and (3) if the start of the flyby is reachable by the path planner. Furthermore, this component first searches locally, around the current position of the UAV when no frontiers are found and then escalates to the operator-defined region (global search). At a global level, the iterator of the tree is circular and the search within the octree continues after the last successful search to avoid analysing the same voxels repeatedly. Once a flyby is selected, the path planner generates a sequence of waypoints to reach the start of the next flyby. After the UAV reaches the endpoint of the flyby, the search for frontiers starts again. Finally, when no more frontiers are found, the Exploration Manager component declares the mission as finished.