This chapter discusses the strategies used to address the way of UAVs can effectively collect data from CHs. Figure 6 illustrates a possible arrangement of CHs that would need to be visited by UAVs to obtain CH’s data during a period T.
As only shortrange communication is assumed to be available, all CHs must be visited by at least one UAV during the collection period T. The set of CHs can be interpreted as points of interest, and a path must be set for each UAV. We call the ordered path that a UAV navigates to visit a set of CHs a "tour". Thus, from the perspective of the CHs, this can be treated as a coverage problem and reduced straight to problems as the TSP and the VRP (vehicular routing problem). As any UAV can move from one CH to another in any order, it is a complete graph.
The edges of Fig. 6 are discretized as a complete graph, which illustrates a possible arrangement of CHs during a period T. CH A represents the GS. The cost of moving from one CH to another can be interpreted as distance or as more complex cost (e.g. composite costs combining more than one value, such as distance and barriers) as presented in Fig. 6.
The following subsections describe the most recent and advanced approaches that use UAVs to collect data from WSNs, in addition to our approach to a fully distributed UAV application. For all of the following strategies, the time to compute the tours is not discussed until Section 6.
4.1 Optimization approachs (TSPbased)
Similar to the strategy presented by Burman et al. [64] and Ho et al. [65], this strategy includes visits to all CHs by way of the best possible tour. This strategy directly maps to the TSP problem. Accordingly, the best tour is the result of a minimization function. For future reference, we named this approach the TSPbased strategy.
This TSPbased strategy represents several uptodate optimization approaches for collecting data with UAVs [18, 22, 32, 38, 53][9093]. On the complete graph G(V,E), the vertices V are CHs, and the edges E represent the cost of a UAV flight between two vertices V. Obstacles and prohibited flight zones are represented in the costs attached to the edges.
In the studies discussed in the related works section, it is typical to use a single UAV. However, as previously mentioned, this method introduces a single point of failure. Moreover, this approach requires relevant computational effort to compute the best tour in a centralized manner. In our scenario, we implement this strategy by using several UAVs on the same tour. In most works, on the best tour computed, all UAVs fly keeping an equal distance from each other and perform their data collection following a Hamiltonian Cycle, as shown in Fig. 7. When each UAV passes near the GS, it delivers its collected data. As the collection takes into consideration a complete graph, it is obviously difficult to compute the best tour with a large number of CHs, because TSP is an NPhard problem.
Although this approach is not a distributed strategy but a centralized one with UAVs, we present this strategy as a benchmark to be used as a comparative baseline.
4.2 FPPWR algorithm
Fast Path Planning with Rules (FPPWR) is a solution proposed by Wang et al. [26] to address the computational effort necessary to solve the optimization problems in a TSPbased strategy when collecting WSN data with UAVs. This strategy relies on the FPPWR routine to compute the tour, which we explain in next paragraphs. Once the FPPWR tour is computed by the GS, all UAVs are sent to collect the data. We apply this strategy by programming all the UAVs to fly at an equal distance from each other and perform their data collection following a Hamiltonian Cycle, as in the TSPbased strategy described above. Then, as shown, each UAV delivers its data when it passes near the GS.
In the FPPWR strategy, tours are calculated by splitting the area into smaller geometric clusters, as illustrated by the dotted lines in Fig. 8. These clusters are calculated using the radio range of UAV and CHs. FPPWR then performs a sortbased computation on the CH positions. This sortbased tour computation runs on each cluster, taking into consideration the most recent cluster processed. All clusters are analyzed in the order indicated by the arrows in Fig. 8. Figure 9 illustrates a possible tour generated by FPPWR.
The algorithm complexity is \(\mathcal {O}(p\log {}p)\) [26] (as p denoting the number of CHs). However, the fixed time to split the clusters cannot be neglected. This issue is discussed in the evaluation section. As in the previous strategy, this is not originally a distributed strategy but a centralized one, using several UAVs in a straightforward manner. To the best of our knowledge, this is the only other approach that proposes an alternative to optimization strategies, besides our own.
4.3 DADCA
The Distributed Algorithm for Aerial Data Collection (DADCA) is an algorithm [10] that maintains the sensor data collection by UAVs during a period of time T (measured in hours). This strategy is our approach to enable a distributed data collection with several UAVs. We do not claim to get better results than optimization approaches, but we propose DADCA as a viable alternative to centralized approaches. An early version of this method and some essential details were introduced in [9], with improvements and further details presented in [10].
In order to present DADCA in details, we divide its presentation into two phases as follows. In Fig. 10 DADCA’s main architecture is presented: (1) Figure 10a indicates the computation responsible for planning the tour that the UAVs will follow and (2) Figure 10b is the strategy for using the computed tour in Fig. 10a.
From this point on, the tour computed in Fig. 10a will be called the Original Tour. Each UAV plan its Original Tour and, as all UAVs start working near from GS, all Original Tours are the same. The Original Tour is not computed again during the period of time T and all UAVs will have the same Original Tour. The Original Tour is a simple path that passes by each CH only once and does not return to GS. Instead of doing the Hamiltonian Cycle the UAVs will use the Original Tour moving forward and backward meeting each other on the same tour.
We begin with DADCA tour computation explanations and then all DADCA variations share the same UAV behavior that will be explained on Section 4.3.1. The main characteristics of the tours used in the first phase of the DADCA method, as illustrated in Fig. 10a, are the following:

1.
UAVs do not compute a Hamiltonian Cycle. The tours used by DADCA are defined by a single path leaving the GS and passing close to each CH exactly once without returning to the GS. Therefore, there is no roundtrip using DADCA, as opposed to the TSPbased and FPPWR methods;

2.
The DADCA tours are computed without any optimization techniques. DADCA enables processing time to be predictable based on the size of the CH set, enabling the processing unit present in UAV to execute the processing. Furthermore, DADCA is suitable for use distinct tour planning tecniques with its individual advantages and its restrictions of each tour planning characteristics.
From Sections 4.3.6 to 4.3.9, we present four distinct tour computation methods that generate nonoptimized tours used in Fig. 10a. In Section 4.3.1, we explore the approach used in Fig. 10b.
4.3.1 DADCA  tour coverage
In short, all UAVs have the same behavior: They go from one extreme to the other extreme of a tour and return, such tour passes only once through all CHs; UAVs collect data from CHs and deliver to GS based on UAVs passages over that. When there is more than one UAV in operation, the UAVs try to divide the workload by the number of UAVs in operation. This division of the workload only occurs with the meeting of UAVs in pairs.
4.3.2 DADCA  initialization
Once any of the DADCA algorithms from Sections 4.3.6 to 4.3.9 creates a tour, the next phase begins (as indicated in Fig. 10b). This second phase extends and adapts the algorithm originally proposed by Kingston et al. [66]. Their algorithm controls a set of UAVs surveilling a linear path in \(\mathbb {R}^{2}\) that represents a boundary, such as a frontier or a pipeline. The path in [66] cannot cross itself.
The first step of DADCA is the initialization of GSand UAVs, as presented in Algorithm 1. The GS begins informing each UAV of the CHs’ geographic locations and flagging the UAV flag free as false. The flag free is used by each UAV to control their (re)entrance in a data collection activity that has already begun.
At the initialization of each UAV in Algorithm 1, its variables are initialized. Function RunStrategy() is responsible for calling one of the planned tour from the algorithms presented in Sections 4.3.6 to 4.3.9. What we call Original Tour is the first tour computed by a UAV from a setOfCH. Once the DADCA tours form a single line that pass through all CHs, we call the first limit of the Original Tour our left limit and the end the right limit.
Furthermore, the variables rightNeighbors, leftNeighbors, and totalNeighbors begin at zero. We use these variables to control the number of other UAVs that each UAV knows are working at the moment t of T. The variable leftNeighbors of a UAV _{A} denotes the number of UAVs working properly between UAV _{A} and the left limit, while rightNeighbors denotes the number of UAVs working properly between UAV _{A} and the right limit. These variables are updated when a rendezvous occurs between two UAVs or when a UAV reaches one of the tour limits.
4.3.3 DADCA  behaviour
When a UAV is launched, it acts as it would working in isolation, no matter how many UAVs the GS is launching. This UAV acting in isolation will use its Original Tour to collect data from all CHs. Figure 11 illustrates the UAV _{A} traveling from the left limit (A) to the right limit (E) and collecting data. When UAV _{A} reaches any limit, it returns from the opposite direction.
Every time a UAV passes over the GS, it delivers the collected data. Adding the GS to the tour in all four planning algorithm allows for this passage over the GS. In the example of Fig. 11, GS could be illustrated by A to E varying of the tour planning being in use. The UAV _{A} remain in that situation until T ends or a rendezvous occurs with another UAV. Each UAV is controlled by Algorithm 2 and Algorithm 3, which we describe in the following paragraphs.
Eventually, other UAVs perform their collection, as illustrated in Fig. 12. Two UAVs may also fly close enough to be within radio range of each other, and at this point both perform a rendezvous.
DADCA only performs rendezvous in pairs, which means that if three or more UAVs are close enough to perform a rendezvous, each UAV will ignore any UAV after the first UAV it discovers from a logical point of view. For instance, UAV _{A}, UAV _{B} and UAV _{C} may all be close enough to each other to perform a rendezvous. There are six possible scenarios of mutual discovery among the three UAVs, but these scenarios can illustrated in just two cases:

1.
Not feasible: UAV _{A} discovers UAV _{B} before discovering any other UAV, UAV _{B} discovers UAV _{C} before discovering any other UAV, and UAV _{C} discovers UAV _{A} before discovering any other UAV. In these scenarios, no pair is available to perform a valid rendezvous. In this case, all three UAVs will ignore each other.

2.
Feasible: UAV _{A} discovers UAV _{B} before discovering any other UAV, UAV _{B} discovers UAV _{A} before discovering any other UAV, and UAV _{C} discovers either UAV before discovering the other UAV. In this case, UAV _{A} and UAV _{B} will perform a DADCA rendezvous.
Apart from the requisite logical pairing described above, we introduce another restriction to enable a valid rendezvous: two UAVs can only perform a rendezvous if and only if UAV _{A}’s origin CH is UAV _{B}’s destination CH and vice versa. This requirement extends the original idea presented in [66] of a linear noncrossing path in \(\mathbb {R}^{2}\) enabling tours in \(\mathbb {R}^{3}\). When UAVs follow the logical meeting order, it is possible that tours will cross themselves.
4.3.4 DADCA  rendezvous
If more than one UAV is active and two UAVs are moving in opposite directions on the Original Tour, they will eventually be within radio range, as shown in Fig. 13. This meeting is what we call a rendezvous—at this moment, the UAVs exchange current information about other known UAVs, the data they’ve collected, and then adjust their subtours accordingly. These rendezvous runs are presented in Algorithm 2 and in Algorithm 3.
To explain this rendezvous, let UAV _{A} be the first UAV sent and let UAV _{B} be the second. When UAV _{A} begins collecting data, its tour is from A to E; when it reaches E, it begins its return. At some point, UAV _{B} begins the same Original Tour, as shown in Fig. 12.
Figure 14 presents two UAV performing a rendezvous. They exchange their metadata, and are capable of understanding which UAV originates from the nearest side of the GS. This UAV is called the left UAV and the other is the right UAV. Both UAVs update each other on the number of working UAVs that they’re aware of by using the other UAV to update their information in the opposite direction. This protocol means that rightNeighbors and leftNeighbors are updated based on the information relayed during the rendezvous. Thus, the left UAV (UAV _{B}) receives the other UAV’s data to deliver to the GS because it is closer, and the right UAV (UAV _{A}) changes its direction.
Both UAVs compute new subtours to take into account the ideal division of the Original Tour with known available UAVs working at that moment. Therefore, both UAVs compute the same SharedBorder, which refers to the theoretical point where both subtours meet regarding the number of CHs. As a result, both UAVs navigate to the SharedBorder and turn in opposite directions, as presented in Fig. 15. At this point, both UAVs update their metadata and one UAV transfers its collected data.
The UAVs remain in such a pattern until they reach a tour limit, rendezvous with other UAVs, encounter a malfunction, or the period T ends. As discussed above, it is important to note that whenever a UAV passes within range of the GS, it delivers all the data in its possession.
4.3.5 DADCA  algorithm
In order to better describe DADCA in Algorithm 2, we present four possible rendezvous cases from the perspective of the left UAV which is presented as v_{left}. Each UAV have some internal control variables:

free: stands for the UAV in (re)entrance;

next: stands for the ID of next CH to visit;

last: stands for the ID of last CH visited;

leftNeighbors: known number of UAVs from left;

rightNeighbors: known number of UAVs from right;

tour: actual tour;

setOfCHs: whole set of CHs;

originalTour: first tour computed.
Line 2 to line 6 filters cases in which two UAVs have already begun their data collection, otherwise the scenarios start from line 7 which at least one of the UAVs are (re)entering.
Line 3 shows cases in which both UAVs are effectively coming from opposite directions. If both UAVs are close enough to perform a balance but are not on consecutive subtours, then the rendezvous is ignored, as in the case of line 6. It is necessary to ignore this rendezvous for crossing tours—an option that was not possible in Kingston’s original proposal [66].
In Algorithm 2 line 7, the cases is presented where at least one UAV is (re)entering activity. If two (re)entering UAVs attempt to perform a rendezvous, then the shared information becomes ignored. A (re)entering UAV therefore acts in isolation until it finds an older UAV collecting data.
A UAV (re)entering a data collection that has already begun must meet another UAV in activity. Line 8 indicates cases when only one UAV is (re)entering activity and both UAVs perform the rendezvous. The free UAV will use the metadata from the older one in order to function as a working UAV. Therefore, both UAVs perform a regular rendezvous. Lines 18 and 21 represent cases when the UAVs are updated as they reach the first or last CH from the original tour. Line 25 refers to a case in which a UAV reinforces data collection, which can occur when a new UAV is sent to collect data or a temporarily disabled UAV returns to work at any point of the Original Tour.
The algorithm 3 in its routine Rendezvous is responsible for rebalancing and recalculating a UAV subtour. During the period T, all UAVs perform their balancing function to (re)establish the whole system balance. Each UAV reuses the Original Tour length and divides it by the updated number of known working UAVs upon a rendezvous. Subsequently, each UAV generates its segments S_{left} and S_{right} and its theoretical intersection b (S_{left}∩S_{right}). In this work, the RecalculateBalancedSegments() is the rounded median of the number of CHs in the tour.
Given the research of Kingston et al., this visitation model has been adapted from their research. However, the UAVs did not know their tour before commencing their flight. In consequence, the model does not use a linear path, but instead creates a path by visiting CHs. In DADCA each UAV receives an unordered list of CHs from the GS and creates their tours without any GS processing. Our extension is capable of (re)calculating their tours in \(\mathbb {R}^{3}\) with tour intersections.
Finally, in terms of resilience and malfunctions, we can receive new UAVs at any point in the tour, rather than only the beginning and end of the tour, as in [66]. It is remarkable that is not necessary that UAVs have the same processing capabilities. Each UAV can compute the result of the Original Tour at distinct moments, and all Original Tour will be the same. Furthermore, each UAV can begin its data collection at distinct moments, and the entire system will adjust its behavior.
4.3.6 DADCAgreedy
In this DADCA variation, we generate the Original Tour with a greedy algorithm, which is polynomial and deterministic and runs at θ(p^{2}) (as p denoting the number of CHs) and searches for the nearest CH not included in the tour and addes it to the tour. Algorithm 4 demonstrates the DADCAgreedy first phase, with line 1 presenting the function NaviteTour(), which is the tour planning of DADCAgreedy. From the GS to the final CH in the setOfCH, the nearest CH is obtained through the GetNearestNotTaggedCH() function in line 6.
DADCAgreedy does not necessarily create the best tour. Instead, it creates the tour in a straightforward manner. DADCAgreedy can provide a shorter tour than the best tour, which contains a Hamiltonian cycle, due to the reduced number of edges. Function GreedyTour() creates a tour with one edge less than the TSP solution. Nevertheless, as the Function GreedyTour() checks the nearest CH from the CH added last, it can also provide a much larger tour than a TSP tour optimization. This is the original DADCA approach presented in [9].
4.3.7 DADCAparted
In this DADCA variation, we create the Original Tour in two steps, as presented in Algorithm 5, which is polynomial and deterministic. First, the coverage area is split into two geographic parts, as we illustrate in Fig. 16. Lines 6 to 10 in Algorithm 5 represent the creation of two sets of CHs based on their coordinates. (Fig. 17)
After the two geographic sets of CHs are created, we perform the DADCAgreedy method in both sets. Thus, we merge both sets in the following lines (11 to 16) and create the Original Tour of DADCAparted, as illustrated in Fig. 16. The main idea of this variation of DADCA is to roughly place the GS in the center of the tour without any tour analysis. The role computation remains at a complexity of θ(p^{2}).
4.3.8 DADCALKH
DADCALKH is another variation to DADCA tour planning. For the best of our knowledge, the best method of computing solutions for the TSP problem in polynomial time is the LinKernighanHelsgaun (LKH) algorithm. The LKH algorithm is approximate and nondeterministic, but optimal solutions for TSP are produced with high frequency, and it currently holds the record for all instances with unknown optima^{Footnote 1}. Its complexity is \(\mathcal {O}(p^{2.2})\) [26, 67].
In DADCALKH, LKH is used to compute the best tour that closes a Hamiltonian Cycle in polynomial time, as presented in Algorithm 6, but the tour obtained may not be necessarily the best tour that a TSP heuristic can find. Once this tour is found, DADCALKH removes the last edge before the GS to create a tour as exemplified in Fig. 18.
It is reasonable to assume that DADCALKH can produce a smaller tour than a TSPbased strategy, because LKH is likely to find the same tour generated by a TSPbased strategy, and DADCALKH removes one edge, making the final tour smaller. The main goals of this strategy are to maintain low processing complexity for the UAV and to improve the DADCA tour.
4.3.9 DADCALKHcut
Finally, we propose another variation on DADCA named DADCALKHCut, which is described in Algorithm 7. This version computes its tour using the LKH algorithm but does not remove the final tour edge as in DADCALKH. Instead, DADCALKHCut removes the edge roughly in the middle of the Hamiltonian Cycle, as shown in Fig. 19. DADCALKHCut is very similar to DADCALKH, but the data reaches the GS more often, once GS is not in one of the tour’s extremities. This DADCA variation is nondeterministic as its also based on LKH.
A pertinent question regarding this specific strategy would relate to which edge we remove. For example, instead of the middle edge, we could remove the biggest edge, which would increase the chances of the tour be smaller than the one created through the TSP solution for such a set of CHs. However, we do not aim to produce a smaller tour but instead maintain the GS roughly in the middle of the tour. In addition, this algorithm produces more straightforward results regarding message delays.