Skip to content
MK

Can a Drone Team Keep Working When Communications Fail?

A multi-drone mission needs more than parallel flight. Task ownership, stale shared state, collision risk and recovery determine which work can continue when links degrade.

Three survey drones occupy separate parts of a mountain river valley, with a distant ridge interrupting sightlines
M.K. / FIELD NOTESPhysical AI / 2026

Three drones surveying a valley appear to offer three times the coverage. Then one passes behind a ridge and loses its link. Do the others still know what it has completed? May another drone take over its sector? What keeps two aircraft from moving toward the same place on incompatible plans?

The hard part of a multi-drone mission is knowing when the team's shared picture has become untrustworthy. A link interruption may leave room for narrow, pre-authorized work that does not depend on the other vehicles. It cannot preserve the same assurance for a task that needs fresh positions, synchronized movement or a confirmed reassignment. This is a way to examine a system, not a safety claim for a particular fleet or flight instructions.

A team makes promises that one drone does not

The earlier article on a single drone's inspection mission asks whether one aircraft brought back usable evidence and handed off incomplete work. With multiple vehicles, another question appears: who owns each sector, who knows a task is complete, and who has authority to change the assignment? Every aircraft may be flying correctly while the overall mission still has gaps, duplicated work or conflicting decisions.

NASA's CADRE project studies a group of lunar exploration robots that exchange information and can combine observations through a base station. Its potential value is simultaneous measurements from separate positions, not simply multiplying one robot's speed. CADRE is a technology demonstration; it does not establish that a civilian drone team can autonomously survey any terrain.

A task assignment has an information lifetime

Allocating separate sectors before a mission is different from reassigning them when conditions change. Reassignment depends on knowing which vehicles remain available, what each has done, what it can still do and whether a route remains usable. Under weak communications, those facts become snapshots taken at different times.

A NASA technical report on divergent robot worldviews identifies missed and duplicated tasks as possible results when weak links leave robots with inconsistent internal views. It describes a failure mode, not the inevitable outcome of every fleet. My design argument is that ownership of a task should have an explicit validity boundary. A disconnected vehicle might continue a clearly scoped, authorized sector; another vehicle should not silently assume that sector is vacant. This is my proposed framework, not a feature NASA says CADRE has implemented.

JPL's description of NeBula offers a useful comparison: multi-robot roles and mesh communication are used to support exploration with intermittent links. A mesh can provide more routes for messages. It cannot make terrain obstruction, latency or a complete partition disappear. A late message and no trustworthy message are different conditions for task reassignment.

Collision avoidance cannot depend only on reported intentions

Coordinated routes often use another vehicle's reported position and intended path. Once those reports age, the separation assumed by the shared plan may no longer be valid. An IEEE study of selective communication for multi-robot collision avoidance asks when a robot should request another's trajectory information according to prospective collision risk. Its comparison used four quadrotors in simulation; it does not prove collision prevention for a fielded fleet.

I would distinguish two layers. Shared planning can improve efficiency. Each vehicle's own sensing, confidence in its position and tested failure response govern whether it can continue within an authorized boundary. Separating work areas in advance can reduce dependence on live messaging, but it cannot remove unknown obstacles, position error or other airspace users. These are engineering questions for a particular site and aircraft, not universal settings.

PX4's failsafe documentation describes configurable delays and actions after loss of a ground-station data link, alongside separate geofence and position-loss responses. Losing the ground-station link is not the same event as losing an inter-drone link. Nor should a PX4 configuration be taken as the behaviour of every flight controller. A multi-drone design has to evaluate how its own mechanisms interact.

A complete partition has a hard coordination limit

In a JPL paper on planning and execution for CADRE, the authors explicitly assume that a bidirectional channel between each robot and the leader remains available, although it may be slow and low bandwidth. If all packets can be lost, coordination generally cannot be guaranteed. They also acknowledge that delayed abort messages can leave robots acting inconsistently for a time. That is a more useful boundary than a promise of seamless cooperation through any blackout.

After a partition, the question is not merely whether an aircraft can still fly. It is whether the remaining job still needs a shared commitment. Collecting data inside distinct, pre-assigned areas may be eligible for limited continuation. Passing through a shared bottleneck, jointly carrying an object or synchronizing a new assignment depends on confirmation that may no longer exist. Whether the appropriate response is to pause, return or change tasks belongs to the specific system, site and operating permissions; an article cannot make that decision for an operator.

Reconnection does not automatically mean “resume.” A team must reconcile what each vehicle actually did, which task version it followed, where work remains and why any task stopped before an authorized controller resolves conflicts. Otherwise the restored network merely combines contradictory records faster. Reconcile first, then reassign is my systems argument. The research supports the risk of stale state; it does not certify one reconciliation method across every environment.

Measure coordinated work, not vehicle count

To evaluate a multi-drone system, I would ask for separate results under normal and degraded links: usable coverage, duplicated and missed sectors, rejection of stale commands, close-proximity conflicts, human intervention and reconciliation after reconnection. Distance flown and the number of simultaneous aircraft cannot show whether the team coordinated reliably.

DARPA's SubT Challenge treated autonomy, perception, networking and mobility as distinct technical problems; underground obstructions made the networking problem especially visible. Ground and aerial conditions differ, so this is a useful classification of problems rather than an acceptance result for a drone product. The question I would put to any fleet provider is: when the link disappears, which task commitments still hold, and how can you prove it?

Frequently asked questions

Are several drones automatically a swarm?

No. Vehicles flying separate pre-planned sectors are a multi-drone deployment. Coordination becomes more demanding when one vehicle's assignment, route or observation changes another's work. The label alone says little about that dependence.

Can the team keep working without communications?

Some bounded, independent tasks may continue under conditions established and tested for the system. Work requiring live confirmation between vehicles cannot be assumed safe on stale information. The deployment must define its own degraded mode.

No. It may increase available message paths, but terrain, failed nodes and delay can still partition the team. The mission also needs a rule for stale data and complete disconnection.

Vehicles may have different versions of the plan and different records of progress. Reconcile completed, duplicated and missing work first, then make a new assignment without importing the old conflict.

Sources and further reading