ESCAPE: an efficient and safe distributed UAV swarm exploration framework with collision avoidance perception

After an earthquake, the structure of a damaged building is often too unstable for rescuers to enter. The floors above could give way. The walls could shift. The entire structure could collapse in on itself at any moment. But somewhere inside there may still be survivors, and the time you have to find them is ticking away. What do you do? Sending in a drone can help (a lot), but a single drone can only cover so much ground at a time. There might be dozens of floors to cover: hundreds of rooms and offices, basements, elevator shafts, subterranean parking spaces, closets and hallways. Innumerable places that a human being might have taken cover when the shaking started. So what you really need is a swarm: dozens of drones all entering the building, and fanning out. Mapping the interior, identifying hazards, and finding people fast. The problem is that the more drones you put into a confined space, the more likely they are to crash into each other. And most existing swarm frameworks just aren't built to handle these kinds of scenarios.

If you look at the light-displays that drones perform at sporting events and on special occasions, you might think that swarm optimization is a solved problem. And for some use-cases it is. Like when dozens (or hundreds) of drones launch from a flat field, follow scripted trajectories, and trace patterns against a wide-open sky. But those performances have huge margins for error. If one unit drifts a few centimeters off course, no one notices. If communication hiccups, the show still goes on. The environment is controlled, it's obstacle-free, and the stakes are mostly aesthetic.

But in disaster-recovery and search-and-rescue, we're still at the starting line. The existing frameworks aren't worthless in that situation. But they do face a ton of issues that just aren't present when you're putting on a 4th of July display, or writing someone's name in the sky. Inside a collapsed structure, communication bandwidth is limited and unreliable. The environment is unknown and cluttered with debris. And the drones themselves are forced into tight corridors, blind corners, and vertical shafts. In that context even small delays in coordination can translate directly into collisions: against the surroundings and against each other.

So what can we do? How can we get better at distributed exploration? How can we get a swarm of drones to map complex interiors and cover large volumes quickly without crashing into each other or stalling out? That's where today's paper comes in.

In it, the authors propose a framework called ESCAPE: an Efficient and Safe distributed swarm exPloration framework with collision Avoidance pErception. Yes the acronym is contrived and hackey, but the engineering isn't. It's solid. ESCAPE integrates five key features together:

1. Grid-based distributed task allocation.
2. TSP-based global coverage planning.
3. Frontier-driven local viewpoint generation.
4. Predictive collision risk modeling.
5. Priority-based stop-and-replan trajectory optimization.

And on today's episode we'll find out how all of it works. But first, we need to wrap our heads around the kind of solutions that have come before it.

Most UAV exploration strategies fall into one of two camps.

• The first is "frontier-based" exploration. As a drone flies around and maps its environment, the frontier is the boundary between the parts of the map that are already known and the parts that are still unexplored. The drone continuously identifies these frontiers and moves toward them, pushing the exploration forward. It's intuitive and works reasonably well in open environments, but in obstacle-dense spaces it tends to produce a lot of backtracking and redundant movement.
• The second camp is sampling-based exploration. This is closely related to something called Next Best Viewpoint (NBV) planning. Rather than chasing frontiers, the drone randomly generates possible next positions, evaluates how much new information each one would reveal, and then picks the best. This works well in complex spaces but it gets computationally expensive as the environment grows.

And those strategies are just how a single drone operates. When you try to apply either of them to a whole swarm, a new set of problems appear. How do you ensure two drones aren't headed to the same area? How do you divide the work fairly? Etc. To solve this, many existing systems rely on centralized coordination: one drone (or a ground station) manages everything, and gives orders. That works...until communication degrades. That's a corner case when you're flying above a football field. But when you're flying indoors with rooms and obstacles, that can happen constantly. Other systems use distributed approaches instead. These are often either auction mechanisms where drones bid on tasks, or pairwise interactions where drones negotiate assignments directly with each other. The Racer framework is one of these: it divides the workspace into a grid, uses pairwise task allocation to assign cells to individual UAVs, and has each drone plan coverage paths through its assigned cells. ESCAPE (the authors' contribution) builds directly on top of Racer.

But why do they need to modify Racer at all? Because, like most of its peers, Racer still treats collision avoidance as a secondary objective that is layered into the trajectory optimization problem. The system tries to avoid collisions, sure. But other goals like path smoothness, travel time, and efficiency compete for weight in the same optimization. And when they conflict, safety doesn't always win. On top of that, much of the collision avoidance logic relies on drones continuously sharing their planned trajectories with each other. So the communication delays I talked about a moment ago can have cascading effects. When you drop a packet, the recipient ends up making avoidance decisions on stale data. Not ideal.

ESCAPE fills these gaps by adding two modules that run in parallel. The first is a cooperative exploration module and the other is a collision-handling module. Lets walk through them.

The cooperative exploration module tightens the coupling between global allocation and local feasibility. The environment is discretized into grid cells, and task allocation is framed as a capacitated vehicle routing problem. Each UAV participates in pairwise interactions to determine which subset of grid cells it is responsible for. The idea being to minimize overall travel cost while balancing workload. The pairwise costs are computed from feasible paths between the drone positions and the grid centroids, as well as between grid centroids themselves. This is then reduced to a TSP: a Traveling Salesman Problem, and solved using an LKH-style heuristic. What you end up with is like a set of driving directions: a visiting order for each vehicle. Then, each UAV begins executing its assigned tour. It performs frontier extraction within each grid, identifying the boundary between known and unknown space and generating viewpoints that guarantee volumetric coverage. A local planner then sequences these viewpoints into a smooth, dynamically feasible trajectory. The authors also introduce a continuity term here in the cost function that penalizes grid centers embedded within obstacles, to reduce backtracking when large structures span multiple cells. The result is a layered pipeline: distributed grid assignment at the macro level, frontier-driven coverage at the micro level, and cost shaping to prevent inefficiencies.

Then running alongside that stack is the collision-handling module. It actually operates independently of the main objective. Instead of embedding "separation" (ie buffer zones) as a penalty in the optimizer, the system computes an explicit collision risk score in real time. For every neighboring UAV within a detection radius, the system evaluates a weighted combination of relative distance, relative bearing, and relative velocity.

• Distance risk increases as separation falls below a safety threshold.
• Orientation risk reflects whether the vehicles are converging or diverging.
• Velocity risk scales with the magnitude of their relative speed.

These components are fused into a scalar risk metric. And when it crosses a threshold, the system transitions into an emergency state. At that point, avoidance is no longer negotiable, it's mandated. A priority rule dictates which UAV must yield immediately. The lower-priority agents execute a hover, freezing their state in space, while higher-priority agents trigger a local trajectory re-optimization planner that incorporates the frozen peers as hard spatial constraints. Emergency-mode is effectively a traffic cop. It decides who stops, who goes, and which routes they both take.

To find out how well this system works, the authors put it through a series of tests: first in simulation, then in real-world deployments. In simulation, they compared it against two established frameworks, Role and Racer, across three increasingly complex maps. They varied the swarm size from 2 to 6 drones, and measured exploration time, total path length, and variability across repeated runs. For most configurations, ESCAPE reduced both completion time and travel distance, particularly in the more obstacle-dense layouts. It mitigated detours around large obstacles and maintained a more balanced workload. Then, they validated the framework in real environments (both indoors and outdoors) using real quadrotor drones equipped with LiDAR-modules and onboard compute. And again, the swarm successfully navigated the terrain, constructed maps, and maintained safe separation, without issue. The authors' conclusion is straightforward: this system improves efficiency and materially increases safety under realistic constraints.

If you want to go deeper on the authors' trajectory optimization strategy, the safety margin calibration, or the experimental results, I'd highly recommend that you download the paper. There's also a supplementary video linked in the PDF of the flights they took indoors and out.