39  CoRAD Drone Data Collection

emerging-paradigms
corad
drone
flight

39.1 Start Simple

Start with a mission that moves, loses energy, and changes its radio path while it works. In CoRAD Drone Data Collection, the practical question is what the aircraft must sense, relay, decide, and prove before the flight or network role is safe enough to trust.

Phoebe the physics guide

Phoebe’s Why

This chapter’s feasibility check compares flight time plus hover time against a flat 1800-second battery budget, as if every second of flight cost the pack the same milliamp-hours. A real multirotor does not fly that way: forward cruise gets a well-known efficiency assist from translational lift, while hover has to support the whole vehicle weight continuously with no such help, so hover current is normally higher than cruise current for the same airframe. A “1800 second battery” is really “1800 seconds at whatever current the pack was rated at” – mixing cruise seconds and hover seconds into one time budget quietly assumes they cost the same milliamp-hours each, which is the assumption most likely to break first as a mission adds more stops.

The Derivation

Energy from charge and pack voltage, and terminal voltage under load:

\[E=\frac{Q_0}{1000}\times V\qquad V_{term}=V_{oc}-I\,R_{int}\]

Charge remaining after a self-discharge storage gap:

\[Q(t)=Q_0(1-r)^{t}\]

Converting this chapter’s time-additive budget into an energy-additive one, with hover current \(I_{hover}\) and cruise current \(I_{cruise}\):

\[\%\text{used}=\frac{I_{cruise}\,t_{flight}+I_{hover}\,t_{hover}}{I_{ref}\,T_{battery}}\times100\]

which reduces to this chapter’s own \((t_{flight}+t_{hover})/T_{battery}\) only when \(I_{cruise}=I_{hover}=I_{ref}\).

Worked Numbers: This Chapter’s Own 5-Node Mission

  • This chapter’s own worked example: \(t_{flight}=37.0\) s, \(t_{hover}=50.0\) s, \(T_{battery}=1800\) s \(\to (37.0+50.0)/1800=4.83\%\) – reproduces this chapter’s own stated 4.8% exactly, confirming the naive time-additive model is what the worked example actually uses.
  • Energy-weighted correction (catalog-typical multirotor hover current \(\approx1.3\times\) cruise current, since hover carries the full weight with no forward-flight efficiency assist): equivalent seconds \(=37.0\times1.0+50.0\times1.3=102\) s, giving \(102/1800=5.67\%\) – about 17% higher than the naive 4.83% figure, from the same 87.0 seconds of flight.
  • Why this matters more as node count grows: this chapter’s own scaling note names 500 s of hover alone at 50 nodes (\(50\times10\) s); since hover is the more current-expensive phase per second under this model, a hover-heavy mission’s real energy draw grows faster than its raw-seconds total suggests – a physical reason behind this chapter’s own instruction to re-check feasibility, not just re-run the same TSP-and-divide arithmetic, as node count scales up.
  • Self-discharge across a storage gap (catalog-typical LiPo \(r\approx2\%\)/month; a 30-day gap between charging and a remote recovery flight): \((0.98)^{30/30.4}=98.0\%\) remains, a 2.0% loss – small next to the flight budget, but a second, physically real reason this chapter’s 20% reserve should not be spent down to zero by routing efficiency alone.
  • Voltage sag, a distinct catalog-typical pack from this module’s mapping-drone sibling chapter (4S LiPo, \(V=14.8\) V, \(R_{int,pack}\approx30\,\text{m}\Omega\), hover current \(\approx30\) A): sag \(=30\times0.030=0.900\) V, about 6.08% of nominal – modest for a fresh pack, and the term that grows fastest as the pack ages.
In 60 Seconds

CoRAD (Connectivity Re-establishment with Aerial Drones) uses drones to fly within short-range radio reach of isolated sensor nodes, collecting buffered data via store-carry-forward. TSP nearest-neighbor heuristics plan efficient flight paths, and battery feasibility requires a measured reserve such as 20%. A drone recovery mission is production-ready only when the node list, route, transfer time, weather, airspace limits, return-to-home reserve, and buffer overwrite deadline are checked before launch.

Chapter Roadmap

Read this chapter as a mission-release path:

  1. First identify why normal sensor links fail and why the drone is a mobile data collector, not a permanent network repair.
  2. Then follow the TSP route and battery calculations until distance, hover time, and reserve become one feasibility check.
  3. Next test the plan against weather, node discovery, data transfer, and multi-flight constraints.
  4. Finally turn the route into an auditable release record before the aircraft launches and after recovered data uploads.

Checkpoint callouts summarize what you should be able to prove; collapsed sections and quizzes provide extra practice when you need it.

39.2 Learning Objectives

By the end of this chapter, you will be able to:

  • Explain CoRAD Architecture: Describe how drones restore connectivity to isolated sensor nodes
  • Apply TSP algorithms: Use Traveling Salesman Problem solutions for efficient flight path planning
  • Calculate flight budgets: Estimate drone battery requirements including flight time, hover time, and safety margins
  • Plan recovery missions: Design complete drone data collection missions with multiple disconnected nodes
  • Handle constraints: Account for battery limits, weather conditions, and real-time route adaptation
Quick Check: CoRAD Mission Boundaries
MVU: Minimum Viable Understanding

Core concept: When sensors can sense but cannot communicate (due to interference or failures), drones fly overhead to collect buffered data via short-range radio. Why it matters: A feasible drone mission can recover buffered data from isolated sensors before local storage overwrites it, preserving continuity during adverse conditions. Key takeaway: Use TSP heuristics (nearest neighbor) for quick route planning; verify battery feasibility including 20% safety margin before deploying.

39.3 Prerequisites

Before diving into this chapter, you should be familiar with:

  • CoRAD (Connectivity Re-establishment with Aerial Drones): Drone-assisted recovery scheme for collecting data from isolated but still-functioning sensor nodes
  • Coverage Path Planning: Algorithm determining the path a drone follows to cover a target area; lawnmower, spiral, or adaptive patterns
  • Relay Positioning: Placing UAV relay nodes at optimal locations to bridge communication gaps between ground stations and distant drones
  • Flight Plan: Pre-computed sequence of waypoints, altitudes, and speeds defining a drone’s mission trajectory
  • Geofencing: Defining allowed flight boundaries; drones automatically turn back or land when approaching exclusion zones
  • Path Optimization: Minimizing mission time, energy consumption, or total distance while satisfying coverage and connectivity constraints
  • Obstacle Avoidance: Real-time or pre-planned path modification to avoid static (buildings) and dynamic (birds, other UAVs) obstacles
  • Mission Replanning: Dynamic flight plan modification in response to changing conditions (weather, detected failures, new priorities)

39.4 For Beginners: What is CoRAD?

Problem scenario: Agricultural network with 500 sensors. Heavy rain causes “dumb nodes”—sensors that work but can’t transmit (radio range drops from 100m to 5m due to water interference). How do you collect data from isolated nodes?

CoRAD solution: Send a drone to fly overhead, get within 5m of each isolated sensor, download buffered data via short-range radio, return to base. Drone acts as mobile data collector when normal multi-hop routing fails.

Key terms:

  • CoRAD: Connectivity Re-establishment with Aerial Drones – using drones to collect data from unreachable sensors.
  • Dumb Node: Sensor that can sense and buffer data but cannot communicate because its radio link is impaired.
  • TSP: Traveling Salesman Problem – finding a short path that visits all required locations.
  • Hover Time: Time the drone spends stationary above each sensor downloading data.

Why drones? They can bypass damaged multi-hop paths and terrain obstacles when each target can be reached safely. One 30-minute drone flight may visit 20+ isolated sensors in a compact, calm scenario, but the mission size must be recomputed from route distance, hover time, wind, and reserve.

39.4.1 When Sensors Cannot Phone Home

Oh no! It was raining SO hard at Farmer Chen’s sunflower field that something strange happened. All the little sensor friends could still FEEL the rain and measure how wet the soil was, but they couldn’t TALK to the base station anymore!

Sammy the Soil Sensor was worried: “I’ve been saving important data for THREE WHOLE DAYS, but I can’t send it anywhere! The rain made my radio whisper instead of shout!”

Lila the Light Sensor nodded: “Me too! I can only talk to things really, REALLY close—like 5 steps away instead of 100!”

That’s when Danny the Drone flew in to save the day!

“Don’t worry, friends!” Danny buzzed. “I’ll fly right over each of you, hover close enough to hear your whispers, download all your saved data, and carry it back to the base station!”

39.4.2 Danny’s Smart Route

Danny had to be clever about where to fly—drones can’t fly forever! Their batteries run out, just like when your tablet runs out of charge.

Danny’s Plan:

  1. Start at the charging station (home base)
  2. Visit the CLOSEST sensor first
  3. Then fly to the next closest one that hasn’t been visited
  4. Keep going until all sensors are visited
  5. Fly back home before the battery runs out!

Simple route map showing a drone starting at base, visiting four isolated sensors, downloading buffered data, and returning home safely

Danny the Drone’s rescue route visiting all sensor friends

The Magic Formula: Danny had to make sure: Flying Time + Hovering Time < Battery Time

If Danny’s battery lasted 30 minutes, and flying took 10 minutes and hovering over 4 sensors took 8 minutes (2 minutes each), Danny had: 30 - 10 - 8 = 12 minutes to spare! Plenty of time to get home safely!

39.4.3 Fun Challenge

Imagine YOU are Danny the Drone! You have 20 minutes of battery. You need to visit 3 sensors that are each 2 minutes of flying apart, and you hover for 3 minutes at each sensor. Can you complete the mission?

  • Flying: 2 + 2 + 2 + 2 = 8 minutes (to visit all 3 and return)
  • Hovering: 3 + 3 + 3 = 9 minutes
  • Total: 8 + 9 = 17 minutes

Yes! You have 3 minutes left to spare!

39.5 The Challenge: Disconnected Sensor Nodes

Time: about 12 min | Level: Advanced | Unit: P05.C02.U02

CoRAD (Connectivity Re-establishment with Aerial Drones) addresses the problem of collecting data from isolated sensor nodes (“dumb nodes”) that can sense but cannot communicate due to interference or topology fragmentation.

39.5.1 Why Sensors Become Disconnected

In real-world deployments, sensors may become temporarily unreachable:

  • Environmental interference: Rain/fog reduces radio range (100m -> 5m)
  • Node failures: Battery depletion or hardware failures create coverage gaps
  • Terrain obstacles: Buildings, hills, or vegetation block line-of-sight
  • Mobile scenarios: Nodes move out of communication range

Solution: Deploy a drone as a mobile data collector to visit disconnected nodes and download buffered sensor data.

Flowchart diagram showing the CoRAD connectivity problem in three stages: Stage 1 shows normal network operation with sensors communicating to gateway, Stage 2 shows interference causing disconnection creating dumb nodes that can sense but not communicate, Stage 3 shows drone deployment visiting isolated nodes to collect buffered data and restore connectivity

CoRAD Connectivity Problem and Solution
Figure 39.1: CoRAD connectivity problem and solution flowchart showing three stages: normal operation, disconnection due to interference, and drone-based data recovery

39.6 TSP Flight Path Optimization

Objective: Find the shortest flight path visiting all disconnected nodes and returning to base.

This is the classic Traveling Salesman Problem (TSP):

  • Input: Coordinates of \(N\) disconnected nodes + base station
  • Goal: Minimize total flight distance/time
  • Constraint: Drone battery capacity limits flight duration

Graph diagram showing the CoRAD flight planning workflow where TSP (Traveling Salesman Problem) solver receives node coordinates as input along with flight constraints including battery capacity, cruise speed, hover time per node, and safety margin percentage, then outputs an optimized flight route with estimated distance, time, and battery usage

CoRAD Flight Planning Workflow
Figure 39.2: CoRAD flight planning workflow: TSP solver takes node coordinates and flight constraints (battery capacity, speed, hover time, safety margin) to generate optimized route

39.6.1 TSP Algorithm Options

Choose the solver based on node count and planning urgency:

  • Brute force: O(n!) and optimal, but only practical for about 10 nodes or fewer.
  • Branch and bound: exponential worst case; useful for about 20 nodes or fewer when pruning is effective.
  • Nearest neighbor: O(n^2), fast enough for real-time planning, often 10-25% longer than the best route.
  • 2-opt improvement: O(n^2) local improvement pass; often trims nearest-neighbor routes for moderate node counts.
  • Genetic algorithms: generation count times population size; useful for larger networks when a near-optimal route is enough.

For CoRAD applications, nearest neighbor heuristic provides a good balance of speed and solution quality for real-time drone deployment.

Decision tree for CoRAD TSP algorithm selection based on real-time need, node count, and battery sensitivity

TSP Algorithm Selection Decision Tree for CoRAD Applications

39.7 Agricultural Field Mission

Example Calculation:

Agricultural field with 5 disconnected nodes:

  • Nodes: (0,0), (50,30), (80,60), (120,50), (40,90) meters
  • Base: (0,0)
  • Drone specs: 10 m/s cruise speed, 10s hover per node, 1800s battery (30 min)

Using nearest neighbor heuristic:

  1. Start at base (0,0)
  2. Visit nearest unvisited node
  3. Repeat until all nodes visited
  4. Return to base

Path found: Base -> Node1(50,30) -> Node2(80,60) -> Node4(40,90) -> Node3(120,50) -> Base

Flight time calculation:

  • Distance: 58.3m + 42.4m + 50.0m + 89.4m + 130.0m = 370.1 meters
  • Flight time: 370.1m / 10m/s = 37.0 seconds
  • Hover time: 5 nodes x 10s = 50 seconds
  • Total mission time: 87.0 seconds
  • Battery usage: 87.0s / 1800s = 4.8%
  • Feasible: Yes, with 1713.0s (95.2%) battery remaining

Output:

Planned flight path: [(0, 0), (50, 30), (80, 60), (40, 90), (120, 50), (0, 0)]
Estimated flight distance: 370.1 meters
Estimated flight time: 87.0 seconds (flight: 37.0s, hover: 50.0s)
Battery capacity: 1800 seconds
Battery usage: 4.8%
Feasibility: Feasible with 1713.0s (95.2%) margin
Safety margin (20% reserve): 1440s required, 1713.0s available -- OK

Blueprint BinaCheckpoint: Route Feasibility

You now know:

  • CoRAD planning starts with disconnected nodes that still sense and buffer data but cannot communicate through the normal network.
  • The agricultural route ties coordinates to proof: 370.1 meters, 87.0 seconds, 4.8% battery usage, and a 20% reserve check.
  • Scaling from 5 disconnected nodes to 40 nodes or more is a battery question first, because hover time and return reserve can dominate the route.

39.8 Battery Feasibility Analysis

Critical constraint: Drone must return to base before battery depletes.

Battery Budget Formula:

T_total = T_flight + T_hover + T_safety

Where:

  • T_flight = D_total / v_cruise (distance / speed)
  • T_hover = N_nodes x t_download (nodes x time per node)
  • T_safety = 0.2 x T_battery (20% reserve)

Feasibility check:

T_total <= 0.8 x T_battery

You can estimate how many nodes a mission can service from the available time budget.

N_max = (0.8 x T_battery - T_flight) / t_download

Worked example: Suppose a drone has \(T_{battery}=1800\) s, planned flight time \(T_{flight}=420\) s, and per-node data download hover time \(t_{download}=25\) s:

N_max = (0.8 x 1800 - 420) / 25 = (1440 - 420) / 25 = 40.8

You can safely plan for 40 nodes per sortie (round down). Any larger mission should be split into multiple flights to preserve reserve margin.

39.8.1 Multi-Flight Planning

When a single drone flight cannot cover all disconnected nodes:

  1. Cluster nodes by geographic proximity
  2. Plan separate missions for each cluster
  3. Prioritize by data urgency or buffer fullness
  4. Schedule sequential flights with battery swap/recharge

Example: 50 disconnected nodes over a 2 km^2 area

  • Drone range: 15 minutes effective (with 20% safety)
  • Nodes per flight: ~12-15 (depending on spacing)
  • Required flights: 4 sequential missions
  • Total recovery time: ~2 hours (including recharge)

39.9 Trade-offs in CoRAD Planning

Planning trade-offs:

  • Optimal TSP gives the shortest path but becomes computationally expensive as node count grows.
  • Heuristics produce fast approximate routes, often close enough for field deployment.
  • Battery constraints may force large networks into multiple flights even when the route is efficient.
  • Real-time adaptation improves resilience, but every mid-flight change must be rechecked against return-to-home reserve.

This variant shows a complete CoRAD mission lifecycle from detection to data recovery, illustrating the operational workflow.

Timeline diagram showing CoRAD mission phases: detect disconnected nodes, plan route and battery budget, collect buffered data by drone, upload recovered data, and update normal operations

CoRAD Mission Timeline

Operational Metrics: A small CoRAD mission for 8 disconnected nodes can take about 40 minutes end-to-end when weather and airspace are clear. Rain, high wind, or poor visibility can delay launch and extend detection-to-recovery by several hours.

39.10 Implementation Considerations

39.10.1 Node Discovery Protocol

Before drone deployment, the gateway must identify which nodes are disconnected:

  1. Heartbeat monitoring: Nodes send periodic “I’m alive” messages
  2. Timeout detection: Missing heartbeats trigger “disconnected” status
  3. Location lookup: Gateway retrieves last known coordinates from database
  4. Route planning: TSP solver receives disconnected node list

39.10.2 Data Download Protocol

When drone arrives at each node:

  1. Proximity trigger: Node detects drone within 5m range
  2. Wake-up: Node exits low-power mode
  3. Authentication: Drone sends credentials, node verifies
  4. Bulk transfer: Node transmits buffered data (BLE or short-range 802.15.4)
  5. Acknowledgment: Drone confirms receipt, node clears buffer
  6. Power down: Node returns to sleep mode

39.10.3 Weather Constraints

Weather planning rules:

  • Light rain: radio range may shrink; increase hover time and lower the number of nodes per sortie.
  • Heavy rain: flight may be unsafe; delay CoRAD and consider a ground robot if data is urgent.
  • Wind above 15 m/s: stability and energy margins degrade; reduce route size or postpone.
  • Fog: navigation and line-of-sight monitoring become harder; require conservative geofencing and launch approval.

Blueprint BinaCheckpoint: Field Constraints

You now know:

  • The launch list must include heartbeat status, last known coordinates, route planning, and short-range transfer steps.
  • Weather changes the mission: light rain can shrink radio range, wind above 15 m/s reduces margin, and fog makes conservative geofencing more important.
  • Multi-flight recovery is normal for large fields; the ice-storm scenario uses 9 sequential flights to recover 244,800 readings from 340 disconnected nodes.

39.11 Knowledge Check

Quiz: CoRAD Flight Planning

39.12 Ice Storm Drone Data Recovery

Scenario: Post-Storm Sensor Recovery

This planning scenario shows how CoRAD would be used after an ice storm damages gateway connectivity across a large agricultural deployment. The exact numbers are illustrative, but the workflow is the same one used in field planning: identify isolated sensors, partition them into feasible clusters, run TSP inside each cluster, and verify battery reserve before launch.

Problem Scale:

  • 340 disconnected nodes across 4,000 acres (16.2 km^2)
  • Average node spacing: 110 m
  • Each node had 5 days of buffered data (720 readings)
  • Data urgency: high – the operator needs freeze-depth documentation before buffers overwrite
  • Ground access: delayed by ice-covered roads and snow

Drone Recovery Plan:

  • Drone platform: industrial quadcopter with about 55 minutes nominal flight time.
  • Effective mission time: 44 minutes after a 20% reserve is held back.
  • Cruise speed: 12 m/s for planning calculations.
  • Hover/download time: 25 seconds per node using short-range bulk transfer.
  • Nodes per mission: about 38-42 in calm conditions, reduced when wind increases.
  • Required missions: 9 sequential flights after clustering.

TSP Optimization Results:

The farm used k-means clustering to partition 340 nodes into 9 geographic clusters, then ran 2-opt TSP optimization within each cluster.

  • Mission 1: 42 nodes, 4.8 km, 41 min, 30,240 readings.
  • Mission 2: 40 nodes, 4.3 km, 39 min, 28,800 readings.
  • Mission 3: 38 nodes, 4.1 km, 37 min, 27,360 readings.
  • Mission 4: 41 nodes, 4.6 km, 40 min, 29,520 readings.
  • Missions 5-9: reduced to 32-39 nodes each as wind increased.
  • Total: 340 nodes, 36.5 km planned flight distance, about 332 minutes of flight time, and 244,800 readings recovered.

Total recovery time: 2 days (9 flights across 2 days with battery recharging between flights). In this scenario, all planned buffered readings are recovered before local buffers overwrite older samples.

Recovery options:

  • Wait for thaw and ground access: lowest direct cost, but highest risk of missing the data deadline or overwriting buffers.
  • Helicopter visit: faster access, but expensive and poorly matched to precise short-range sensor downloads.
  • Drone recovery: slower than helicopter access but precise enough to hover over each node and collect all buffered readings.

Key Takeaway: The 20% battery safety margin is a planning reserve, not spare capacity to spend. If unexpected wind increases power consumption, later missions should be re-planned with smaller clusters so the drone still returns with a safe reserve.

Common Pitfalls

A drone may complete its survey mission but be too far from ground stations to transmit collected data. Flight planning must jointly optimize coverage and connectivity – either by bringing a relay drone or ensuring the survey path stays within communication range.

Wind significantly affects drone speed, battery consumption, and flight time. Headwind halves forward speed while doubling energy consumption. Flight plans calculated in zero-wind conditions may exhaust batteries before mission completion in real conditions. Always include wind forecasts in energy and time planning.

Drones must initiate return-to-home (RTH) with enough battery remaining to complete the return flight. RTH must be triggered at a battery level calculated from current distance to home – not at a fixed percentage. A drone 1 km away needs more battery for RTH than one 100 m away.

GPS accuracy varies with satellite geometry, atmospheric conditions, and multipath from nearby structures. In urban canyons or under dense foliage, GPS error can reach 5-10 meters instead of the typical 1-2 meters. Flight plans with tight obstacle clearances must account for position uncertainty in GPS accuracy.

Label the Diagram

Code Challenge

39.13 CoRAD as Recovery Claim

A CoRAD route is useful only when it proves a recovery claim: these isolated nodes still hold valuable data, a drone can reach them safely, the transfer can finish in range, and the aircraft can return with reserve. The TSP route is one piece of that claim, not the whole production decision.

The chapter examples show how route distance, hover time, node count, and safety margin interact. A production planner adds the evidence that makes the sortie launchable: weather, airspace, geofence, data deadline, transfer authentication, backup landing path, and a stop rule when any assumption changes.

CoRAD system architecture showing gateway heartbeat monitoring, route planning, drone data collection from isolated sensors, and gateway upload after recovery.
CoRAD is release-ready only when monitoring, route planning, drone collection, isolated-node transfer, gateway upload, and status refresh are checked as one recovery chain.
Mobile summary: Treat CoRAD as a recovery chain: detect isolated nodes, plan a feasible route, collect buffered data by drone, upload recovered readings, and refresh node status before buffers overwrite.

Recoverable Data

The mission starts with a node list, last-heard timestamps, buffer age, and overwrite deadline. No data deadline means no urgency claim.

Reachable Targets

Coordinates, GPS error, geofence, link range, and hover clearance prove that the drone can reach each node and complete the transfer.

Return Reserve

The route is accepted only while current distance home, wind, payload, and battery health leave enough energy to return safely.

Treat the 20% reserve as a release rule, not a spare budget. If wind, no-fly boundaries, download time, or node count changes, the mission is no longer the same mission and must be recalculated.

Read the CoRAD plan as a chain of falsifiable claims. The gateway heartbeat proves which nodes are isolated, the buffer estimate proves which readings are still worth recovering, the TSP or 2-opt route candidate proves a short visit order, the hover budget proves each download can finish, and the return reserve proves the aircraft can stop collecting data and come home. If any link in that chain is missing, the output is only a route sketch. It is not yet a mission release.

This matters because CoRAD sits between networking and flight safety. A networking-only plan may optimize packet recovery while ignoring battery aging, wind, geofence limits, or a degraded landing path. A flight-only plan may keep the aircraft safe while visiting nodes whose buffers have already overwritten the needed readings. The production version joins both views into one go/no-go decision.

39.14 CoRAD Mission Release Record

A launchable recovery mission needs one record that connects the routing calculation to field evidence. The record should let an operator say why the sortie was allowed, what would stop it, and how recovered data will be reconciled after upload.

Build that record before the operator arms the aircraft. Start with the isolated-node report, then freeze a route candidate, a usable battery budget, the per-node hover timeout, the communications authentication method, and the recovery priority order. Keep the raw assumptions beside the route: airspeed, wind forecast, no-fly boundaries, altitude constraints, payload mass, expected link range, and the battery reserve rule. A route that only says "visit these coordinates" cannot answer whether the sortie should launch; a release record can.

Claim
Evidence
Acceptance Rule
Retest Trigger
Node list is current
Gateway heartbeat report, last-known coordinates, buffer age, and overwrite deadline.
Each target has a reason to visit and a latest safe recovery time.
New heartbeat, changed priority, or updated buffer estimate.
Route fits the sortie
TSP route distance, hover/download time, geofence check, obstacle clearance, and weather forecast.
Total mission time stays inside the usable battery budget with reserve held back.
Wind shift, no-fly update, added node, or route deviation.
Transfer will finish
Short-range link test, authentication method, expected payload size, and per-node timeout.
Download time per node stays within the hover budget and failed transfers have a skip rule.
Firmware change, credential change, larger payload, or repeated transfer timeout.
Recovery is auditable
Flight log, transfer receipt, node acknowledgement, gateway upload, and missing-node exception log.
Recovered readings can be traced back to node, time window, route, and operator decision.
Unmatched receipt, missing upload, incident report, or disputed sensor data.
Before Launch Freeze the node set, route, weather window, reserve rule, transfer timeout, and abort criteria.
During Flight Track distance home, battery state, wind, missed transfers, and route deviation against the release rule.
After Upload Reconcile recovered readings, failed nodes, timestamps, and operator exceptions before declaring recovery complete.

During execution, treat changes as release-record updates rather than informal operator judgment. If a node takes longer than its hover timeout, log the failed transfer and recompute the remaining route with that battery already spent. If a new heartbeat arrives from a target node, remove it from the recovery set unless the data deadline still justifies a visit. If wind or airspace changes, recalculate the return-to-home threshold from current distance home instead of relying on a fixed battery percentage. The record is what makes those decisions auditable after the data is uploaded.

39.15 Reserve as Return Constraint

The route calculation is usually done before launch, but the safety constraint changes during flight. The drone spends energy moving away from home, hovering, fighting wind, handling retries, and sometimes detouring around airspace or obstacles. A fixed route that was feasible at takeoff can become infeasible after the first few transfers.

Under the hood, the reserve check is not one subtraction from nominal battery life. The planner is maintaining a state estimate: current battery, distance home, expected return energy, remaining target value, transfer-time distribution, and the cost of missed nodes. A nearest-neighbor route can look efficient at launch and still be the wrong route after a high-priority node fails to transfer, because the remaining tour, return leg, and data value have changed. A production planner therefore recomputes the suffix of the route, not just the whole original loop, each time mission assumptions drift.

The energy model should separate flight, hover, communications, reserve, and contingency. Flight time depends on distance, airspeed, wind, climb/descent, and detours. Hover time depends on payload size, radio link quality, authentication handshake time, and retry policy. Reserve depends on current distance home and landing options, not a comforting fixed percentage. Contingency covers practical field effects such as a blocked landing area, a rejected geofence crossing, a second transfer attempt, or a forced skip around a low-value node. Keeping those terms separate helps the operator know which constraint actually failed.

Static Budget Failure

A route can pass the 80% planning check and still become unsafe if the return leg is longer than expected or headwind raises power draw.

Transfer-Time Drift

Weak short-range links increase hover time. Every extra retry spends battery and may force lower-priority nodes out of the sortie.

Safe Degradation

A production mission includes skip rules, cluster splitting, return-to-home thresholds, and a plan for recovering missed nodes later.

The right question is not "Did the TSP route fit?" It is "Does the current mission state still preserve return reserve, data value, and safe recovery if the next transfer fails?"

This is also why reconciliation belongs in the mission model. The aircraft may return safely while the data mission is incomplete: one node may be skipped, one transfer receipt may fail to match a gateway upload, or one reading batch may arrive with an ambiguous time window. The under-the-hood success condition is therefore two-part: the aircraft preserves safe recovery, and the data ledger preserves traceability. If either part fails, the system should produce an exception record and a follow-up route, not silently mark the recovery complete.

Blueprint BinaCheckpoint: Release Record

You now know:

  • A launchable CoRAD route is a recovery claim: node list, data deadline, route, transfer timeout, weather, airspace, and reserve must agree.
  • Return-to-home reserve is dynamic; a drone 1 km away needs a different threshold than one 100 m away.
  • Audit proof continues after landing because flight logs, transfer receipts, gateway uploads, missing-node exceptions, and follow-up routes decide whether recovery is complete.

39.16 Summary

This chapter covered CoRAD (Connectivity Re-establishment with Aerial Drones) for collecting data from isolated sensor nodes:

  • Disconnection causes: Environmental interference, node failures, terrain obstacles, and mobile scenarios
  • TSP optimization: Using algorithms like nearest neighbor to find efficient flight paths
  • Battery budgeting: Calculating flight time, hover time, transfer retries, and return reserve before launch and during flight
  • Multi-flight planning: Splitting large networks into sequential drone missions
  • Operational workflow: From detection through release evidence, planning, deployment, collection, reconciliation, and data recovery

39.17 What’s Next