3.1.1. Checking If *"Not Visited Hexagon List"* Is Empty

This is the stopping criterion of the exploring algorithm. Each uncovered discovered hexagon is inserted into the "not visited hexagon list". When a UAV receives a id to explore, it remains in the "not visited hexagon list" to the end of the exploration, but the UAVs that it exploits are registered. This ensures that no UAV stops the exploration process without actually having any new spaces to explore. For example, at one point in the exploration, one UAV may have finished its exploration, while another is working. If no unvisited hexagons are currently available, the first UAV waits for possible discoveries of the second UAV, which is still in exploration activity. If no new hexagon is discovered, then exploration is finished, or new explorations process are done again.

### 3.1.2. Getting Id/Hexagon to Explore

When a UAV is free (no hexagons in the exploration process), it seeks a new place to explore, which is done in the "not visited hexagon list". To define which is assigned to the UAV, two metrics were defined for different simulations: First-In–First-Out (FIFO) and Euclidean distance. The FIFO metric assigns to the UAV that unvisited hexagon than has been awaiting exploration for the longest, so the first discoveries are the first to be explored. The second metric defines that the hexagon to be explored by the UAV is the one with the smallest Euclidean distance from the initial hexagon (id 1).

#### 3.1.3. Go to Hexagon

Once the UAV gets a hexagon to explore, it must travel there. The UAV only transitions through familiar and accessible spaces. Thus, given the hexagon where the UAV is located and the target, one path is defined to go. This path is built from Dijkstra's algorithm [21], with an adapted version from [22]. With this path, the UAV travels the map until it reaches its target.

#### 3.1.4. Add Hexagon Id into "Visited Hexagon List"

When the UAV finishes moving along the path defined by Dijkstra's algorithm, it is in the hexagon to explore. At the beginning of the exploration activity, hexagon id is inserted into the "visited hexagon list" . This ensures that a UAV identifies a hexagon already found and identified by another UAV, not creating a new id for the same space.

### 3.1.5. Rotate to Angle and Check If Angle Has Adjacent Hexagon

For each six sides of the hexagon (six angles), the UAV should rotate and check for adjacency: a sensor checks if it is possible for the UAV to access the center of the neighboring hexagon; in other words, if there are no obstacles between the two hexagons. If so, adjacency is added to an adjacency matrix. Each angle of the explored hexagon is identified in the honeycomb map with dashed lines if there is adjacency at that angle, or with continuous lines if there is none, as shown in Figure 6.

**Figure 6.** Honeycomb map.

#### 3.1.6. Add Adjacent Hexagon Id into "Not Visited Hexagon List"

When the sensor reading discovers an adjacent hexagon for each of the six angles, and it is not in the "visited hexagon list", it sends it to the "not visited hexagon list", if it is not already there (this is a newly discovered hexagon).

#### 3.1.7. Perform RFB-D and Temperature Reads

Map information is available for both UAVs to control their movements in the environment, and for rescue teams to know the space that can be navigated. In addition to obstacle sensors, RGB-D and temperature sensors are used. RGB-D sensors read the 3D angle of the UAV, and a cube view is then built to aid rescue teams in space recognition. At the same time, a thermal sensor reads the temperature from the same angle. If a temperature higher than a reference value is found, it is identified and a photo of the location is taken. In honeycomb map, this scenario is represented with red lines, as shown in Figure 6.

The RGB-D reading returns a matrix structure. The matrix size (*nxm*) and the range of RGB-D sensor are set in a V-REP simulator in the sensor settings. Matrix values are between 0 and 1, where 0 is very close to and 1 very far from the sensor. When the UAV reads RGB-D, the 3D data, and the angle and position of the UAV during the reading are recorded. These data are transformed from a perspective to a global point. For instance, let *R* be the cube size, *amplitudeRGBD* the extent of the RGB-D sensor, *bu f f er* the RGB-D matrix read, *xn* and *yn* the *bu f f er* dimension, *angUAV* the UAV Euler angle, and *posUAV* the *xyz* UAV position. Algorithm 1 brings the data transformation.

**Algorithm 1** RGB-D transformation algorithm.

```
1 function [ xc , yc , zc ] = TransformRGBD (R , amplitudeRGBD ,
2 buffer , xn , yn , angUAV, posUAV)
3 xc = 0 ;
4 yc = 0 ;
5 zc = 0 ;
6 deltaAngleRGBD = double ( amplitudeRGBD ) /double ( xn ) ;
7 for i =1: yn
8 for j =1: xn
9 i f ( double ( b u f f e r ( i , j ) ) <0.99)
10 angUAVz=rad2deg (angUAV( 3 ) ) ;
11 −−−nz i s the d i s t a n c e in meter .
12 −−−RGB−D i s s e t to 2m
13 nz=double ( b u f f e r ( i , j ) ) *
                                 2 ;
14 i f ( j ==1)
15 dtAng =0;
16 e l s e i f ( j ==xn )
17 dtAng=amplitudeRGBD ;
18 e ls e
19 dtAng=deltaAngleRGBD* double ( j ) ;
20 end
21 i f ( dtAng < amplitudeRGBD/2)
22 a l f a =double (angUAVz) + ( ( amplitudeRGBD/2)−dtAng ) ;
23 e ls e
24 a l f a =double (angUAVz) −(dtAng −(amplitudeRGBD/2) ) ;
25 end
26 a l f a r a d =deg2rad ( a l f a ) ;
27 −−−Sine ' s Law
28 dy = double ( nz *
                          sin ( double ( a l f a r a d ) ) /sin ( deg2rad ( 9 0 ) ) ) ;
29 dx = nz *
                    sin ( double ( deg2rad (180 −90 − a l f a ) ) ) /sin ( deg2rad ( 9 0 ) ) ;
30 −−− c a l c u l a t e dz
31 angUAVx = rad2deg (angUAV( 1 ) ) ;
32 i f ( i ==1)
33 dtAngz =0;
34 e l s e i f ( i ==xn )
35 dtAngz=amplitudeRGBD ;
36 e ls e
37 dtAngz = deltaAngleRGBD* double ( i ) ;
38 end
39 i f ( dtAngz < amplitudeRGBD/2)
40 a l f a z =double (angUAVx) + ( ( amplitudeRGBD/2)−dtAngz ) ;
41 e ls e
42 a l f a z =double (angUAVx) −(dtAngz −(amplitudeRGBD/2) ) ;
43 end
44 dz = nz *
                    sin ( double ( deg2rad ( a l f a z ) ) ) /sin ( deg2rad ( 9 0 ) ) ;
45 xp = posUAV( 1 ) + dx ;
46 yp = posUAV( 2 ) + dy ;
47 zp = posUAV( 3 ) + dz ;
48 −−− D i s c r e t i z i n g values .
49 xc = round ( xp/R) *R ;
50 yc = round ( yp/R) *R ;
51 zc = round ( zp/R) *R ;
52 end
53 end
54 end
55 end
```
#### 3.1.8. Remove Id from "Not Visited Hexagon List"

At the end of the reading of the six sides of the hexagon, id is removed from the "not visited hexagon list". Then, the UAV can begin the search for a hexagon to explore again if the "not visited hexagon list" is not empty; otherwise, the UAV's exploration activity is finished.

#### *3.2. Lock Path Resolution*

Throughout the exploration process, the various UAVs will be moving towards their targets, and consequently, their paths may cross. Avoiding collisions is a critical point for an environment with multiple robots. Several approaches have been presented, where means of prevention are proposed by optimized programming [23–25], potential fields [26], sampling-based methods [27], and others. In general, two concepts are applied [28]: one where robots are free and can change their paths, and another where robots have a fixed path with no possibility of changes. Thus, in the first concept, the focus is on changing paths, while in the second, the focus is on controlling movement and time. In [28] a method for treating deadlock for multiple robots where the path is fixed is discussed. To improve performance, some stopping policies are proposed. With these policies, each robot makes the decision to change or wait for another one. A correct-by-construction synthesis approach to multi-robot mission planning that guarantees collision avoidance with respect to moving obstacles are approach in [29], where has done an integration of a high-level mission planner with a local planner that guarantees collision-free motion in three-dimensional workspaces, when faced with both static and dynamic obstacles.

To avoid collisions, the proposed architecture defines that only one UAV can occupy one hexagon (honeycomb) at a time. Thus, it is necessary to have a record of the hexagon that the UAV currently occupies. To do this, each time a UAV moves from one hexagon to another, it records both which one it is in and what is the next move. Collision is avoided in this way; however, deadlock states can happen.

In the proposed approach, it is assumed that a UAV can be found in three possible states: "in exploration", "in displacement" or "stopped". The state "in exploration" means that the UAV is reading the six angles of the hexagon (honeycomb), and generating the mapping data. "In displacement" means that the UAV is moving to a hexagon and make their exploitation. The "stopped" state means that the UAV has no allocated exploration, and is not moving to any honeycomb.

A key element for resolving path blocks in this approach is the Adjacent Degree (AD), which is the number of adjacent hexagons, directly or indirectly, to which the UAV can travel, in order to free the paths. To obtain the AD, each UAV checks how many hexagons are directly adjacent to it, excluding those in which they are occupied by other UAVs. If the AD value is greater than 1, it means that there is space to perform a maneuver to release the passage. If the AD value is 1, the AD value for this adjacent single is searched. The AD value found for the adjacent one will be its value as well.

A comparison between the AD values of each UAV is made, and if there is a conflict between UAVs, the one with the highest AD must give way to the one with the smallest, moving to one of its adjacent hexagons to resolve the deadlock . When he finishes moving, he retraces his trajectory for his hexagon to explore and returns to his tasks. The Figure 7 presents a scenario with two UAVs, where the UAV in the blue hexagon has three adjacent hexagons directly and its AD value is 3, while the one in yellow has a single adjacent one; however, this, in turn, it has two adjacent hexagons, making the UAV AD in the yellow hexagon to be 2.

**Figure 7.** Adjacent Degree: blue hexagon has AD = 3, while yellow hexagon AD = 2.

Considering the existence of several UAVs in the environment, each one identified as *A*, *B*, *C*, ..., *Z*, and *A* → *B* representing the UAV who wants to move to the hexagon which is the UAV B. Some cases of path blocking can happen:

• **Case 1—***A* → *B* **and** *B* → *A***:**

In this scenario, UAV A wants to move to the hexagon of UAV B, and at the same time, UAV B wants to move to the hexagon where UAV A. Here, each UAV calculates its adjacent degree (AD). The UAV that has the largest AD will open the way to the other UAV.

$$\bullet \quad \mathsf{Case 2} \\ \neg A \to B \\ \bullet \quad \bullet$$

In this scenario, only UAV A shows that it wants to move to the hexagon of UAV B; however, B will not go to the hexagon of A is. In this case, UAV B may be in an "in exploration" or "stopped" state. If it is in an "in exploration" state, UAV A will recalculate a new path trying to deflect the hexagon occupied by B. If there is only one path, UAV A waits for UAV B to complete its exploration. On the other hand, if UAV B is in a "stopped" state, UAV B itself will identify that UAV A wants to go to the hexagon it occupies. That way, it will calculate your AD and compare it with the UAV A. If your AD is greater, it will move to a free adjacent hexagon, and otherwise, it will try to move to a hexagon adjacent to the UAV A, which causes them to find themselves in Case 1.

$$\begin{array}{ccc} \bullet & \mathsf{Case 3} \longrightarrow A \to B \,\, B \to \mathbb{C} \text{ and } \mathbb{C} \to A \colon \end{array}$$

In this case, two UAVs are unable to mutually identify a deadlock. So, it is necessary to check if there is a cyclically blocking. Thus, from the hexagon to which you want to move, UAV A checks if there are any others that want to move to where it is. If this block is detected, the UAV calculates its AD, and if it is greater than 0, it will give space for the resolution of the deadlock. After that, the path to the defined hexagon will be recalculated, and then continue your task.
