Source-linked AI summary
Fleets Need a Context Plane: Rethinking Cooperative Perception for Autonomous Drones
Liangkai Liu, Xiaoxiao Wu
TL;DR
Aerial fleets have changing mission, bandwidth, geometry, and coverage contexts, while existing sharing systems often fix policies or adapt to just one signal. The paper introduces a bounded context plane that lets lightweight policies make runtime sharing decisions using fleet context. On UAV3D, mission-aware sharing matches full-sharing accuracy with 5–10% of the bytes, and results show that the best policy varies with budget and multiple context axes matter.
Problem
Existing systems often fix sharing decisions at design time or adapt to one signal, although drone missions, bandwidth, geometry, and scene coverage change during flight.
Source: B. Motivation · p. 2Method
The context plane provides a bounded fleet-wide context descriptor and a common interface for replaceable policies to schedule data-plane sharing at runtime.
Source: §I · p. 1, D. Unifying Existing Sharing Methods · p. 3Results
Mission-aware sharing matches full-sharing accuracy at 5–10% of the bytes, and choosing the wrong sharing policy costs up to 7.7 AP as the budget changes.
Source: §I · p. 1Takeaways & Limitations
Existing sharing mechanisms can be placed behind a common interface and selected or combined according to runtime context.
Source: D. Unifying Existing Sharing Methods · p. 3Aerial datasets, provide frames but no battery, link, or mission traces, limiting evaluation of policies against those contexts.
Source: §VI · p. 6
Abstract
from arXiv · showhide
Cooperative perception allows a drone fleet to combine observations from multiple viewpoints. However, existing systems typically fix their feature-sharing policies at design time or adapt to only one context signal. This is a poor fit for aerial fleets, whose missions, bandwidth, formation geometry, and scene coverage can change during flight. We quantify the cost of context-blind sharing on UAV3D by controlling feature exchange at evaluation time using a released DiscoNet checkpoint, without retraining. Mission-aware sharing matches full-sharing accuracy while using only 5-10% of the bytes. The best tested peer selection policy changes with the byte budget, and choosing the wrong policy loses up to 7.7 AP. Moreover, under a constrained budget, two policies with the same full-scene accuracy differ by 5.9 AP within the mission region, showing that multiple context axes must be considered jointly. We therefore propose the context plane, a bounded, structured interface for runtime context. Each drone publishes a descriptor of at most 1 KB at 10 Hz, and lightweight, replaceable policies use the fleet context to decide what each drone computes, shares, and fuses. Existing sharing schemes become fixed policies within this interface. In our ROS 2 prototype on a Jetson AGX Orin, the context plane uses approximately 0.01% of the data-plane bandwidth, and each policy decision takes 0.10 ms. These results show that an explicit context interface can support low-overhead runtime adaptation without modifying or retraining the perception model.
I. INTRODUCTION
Aerial fleets face changing mission, bandwidth, geometry, and coverage contexts, while existing sharing policies are often fixed or adapt to only one signal. The paper proposes a runtime context plane and evaluates context-aware sharing without retraining, finding substantial byte savings and gains from jointly considering context.
I. INTRODUCTION
- Existing systems commonly set sharing decisions at design time, while aerial missions can change across several operating axes during a sortie.The paper motivates the interface alongside recent aerial benchmarks, onboard compute, and available ROS 2 transport.Source: §I · p. 1
- Mission-aware sharing matches full-sharing accuracy at 5–10% of the bytes, while the best policy changes with budget and choosing the wrong one costs up to 7.7 AP.Under starved budgets, two policies with the same full-scene accuracy differ by about 6 AP when evaluated within the mission region.Source: §I · p. 1
- The context plane gives drones a shared, bounded context interface that lightweight, replaceable policies use to schedule computation, sharing, and fusion at runtime.Each drone publishes a descriptor of at most 1 KB at 10 Hz; policies do not access data-plane payloads.Source: §I · p. 1
- Jointly considering multiple context axes provides a further ∼6 AP improvement, while adapting to context improves accuracy by up to 2.0 AP over the best fixed policy on held-out contexts.These results use a released DiscoNet checkpoint without retraining.Source: §I · p. 1
- The context plane uses approximately 0.01% of data-plane bandwidth, and policy evaluation takes 0.10 ms on a Jetson AGX Orin.The prototype uses ROS 2.Source: §I · pp. 1–2
II. BACKGROUND AND MOTIVATION
Cooperative perception combines observations across drones, but its feature-sharing demands can exceed wireless-link capacity. Many systems inherit fixed sharing choices from ground-vehicle settings, whereas aerial fleets change mission, battery, geometry, and coverage during flight.
A. Cooperative Perception
- Intermediate fusion shares latent feature maps to balance the information retained and bandwidth required, but full sharing on UAV3D transmits 13.1 MB per fleet-frame.Early fusion shares raw sensor data, while late fusion shares detection results.Source: A. Cooperative Perception · p. 2
B. Motivation
- Most state-of-the-art systems fix sharing decisions before deployment, and runtime-adaptive systems typically respond to only one context signal.These defaults largely derive from ground V2X settings with fixed routes, stable power, near-planar viewpoints, and infrastructure or HD maps.Source: B. Motivation · p. 2
- During a drone flight, mission phase, battery, formation geometry, and scene coverage change, making a preselected sharing policy unlikely to remain effective throughout the mission.Aerial deployments may also lack supporting infrastructure.Source: B. Motivation · p. 2
III. SYSTEM DESIGN
The context plane separates a low-rate exchange of operating context from the data plane carrying perception payloads. Descriptors and plane rules bound how context is published and used, while policies produce directives that gates enforce on data traffic.
III. SYSTEM DESIGN
- The context plane adds a fleet-wide context bus: each drone publishes a descriptor, a policy reads fleet context, and a gate enforces directives on data-plane traffic.Policies do not touch data-plane payloads; directives cover peers, representation, region of interest, and rate.Source: §III · p. 2, Figure 1 · p. 2
A. Context descriptor
- Each agent publishes a descriptor at about 10 Hz, with a maximum size of 1 KB; the prototype serializes its four field groups in 180 B for a four-peer fleet.The scene summary is a 16×16 BEV grid at two bits per cell, and link quality is reported per peer by the sender.Source: A. Context descriptor · p. 2
B. The plane contract
- The plane contract bounds descriptor size and rate, uses best-effort delivery, and permits stale information only to reduce sharing fidelity or rate.In the prototype, descriptors older than three periods mark a link degraded and those older than ten periods mark a peer detached.Source: B. The plane contract · p. 2
- The plane carries context rather than perception payloads, policies read descriptors, and descriptors are authenticated because they influence fleet-wide sharing decisions.The contract also damps policy changes and makes repeating the same command have no effect.Source: B. The plane contract · pp. 2–3
C. The policy contract
The policy contract maps fleet context into directives governing computation, communication, and fusion, without requiring negotiation between drones. It also provides a common interface for existing sharing schemes and illustrates how a prototype policy responds to context changes.
C. The policy contract
- A policy maps the latest fleet descriptors to per-link directives covering duty cycle, peers, representation, spatial region, rate and deadline, and receiver-side fusion weights.Policies may be engineered rules or learned functions; because each reads a local copy of fleet context, no negotiation protocol is required.Source: C. The policy contract · p. 3
D. Unifying Existing Sharing Methods
- Existing methods can be represented as policies in the context plane, but many adaptive methods use at most one context axis and tie adaptation to a model or its weights.The interface allows existing mechanisms to be selected and combined according to runtime context.Source: D. Unifying Existing Sharing Methods · p. 3, Table II · p. 3
E. A worked policy
- The prototype policy uses battery to select initial representation and rate, link quality to reduce them, mission phase to set the region of interest, and coverage overlap to select two peers.The policy was replayed over 120-second evaluation traces.Source: E. A worked policy · p. 3
- When battery falls, the 1→0 link changes representation and rate at 60% and 30% thresholds; a link-quality drop at t=60 s switches drone 2’s outgoing links to detection-level sharing within one descriptor period.These changes do not modify or retrain the perception model.Source: E. A worked policy · p. 3
F. Middleware mapping and placement
The context plane places runtime adaptation between perception and middleware through descriptors, policies, and gates. Its typed interface separates adaptation from perception models so policies can be changed without retraining.
F. Middleware mapping and placement
- The context plane places a descriptor publisher, policy node, and gate between the perception stack and middleware.The publisher summarizes local state, the policy converts fleet context into directives, and the gate applies them to data-plane publishers.Source: F. Middleware mapping and placement · p. 3
- Descriptors use best-effort keep-last-1 delivery, while directives use reliable keep-last-1 delivery and data topics use QoS suited to their payloads.High-rate features use best-effort delivery; compact detections and tracks use reliable delivery.Source: F. Middleware mapping and placement · p. 3
G. Why not model-internal adaptation?
- A typed interface supports different vendors’ perception models, interpretable policy decisions, mission-specific policy changes without retraining, and safety checks.Learned policies can also implement the same contract.Source: G. Why not model-internal adaptation? · pp. 3–4
IV. IMPLEMENTATION
The implementation provides a ROS 2 context-plane prototype and a measurement harness for context-aware sharing on UAV3D. The harness applies sharing controls during evaluation using a released DiscoNet checkpoint without retraining.
IV. IMPLEMENTATION
- The implementation releases a ROS 2 prototype and a measurement harness for evaluating context-aware sharing on a public multi-UAV benchmark.Source: §IV · p. 4
A. Context-plane prototype
- The prototype defines a 180 B ContextDescriptor and a DataPlaneDirective specifying source, destination, representation, ROI, transmission rate, and deadline.Source: A. Context-plane prototype · p. 4
- A policy node maps fleet descriptors to directives each tick, while a gate applies them and a benchmark node measures bytes and policy CPU time.The battery-, link-, and phase-aware policy is a 42-line Python function with no ROS dependencies.Source: A. Context-plane prototype · p. 4
B. Measurement harness
- The measurement harness controls feature exchange during evaluation on five-UAV camera-only UAV3D using the released DiscoNet checkpoint without retraining.The budget limits shared cells per ego drone, and peer-selection and allocation rules determine the contributors and budget split.Source: B. Measurement harness · p. 4
- The evaluator computes rotated BEV IoU and AP at an IoU threshold of 0.5, and the harness records predictions, ground truth, and communication costs.Evaluation-time controls also let a released checkpoint probe the policy space while the harness records exact communication costs.Source: B. Measurement harness · p. 4
- At ρ=0.25, retained feature cells follow scene object structure; at ρ=0.02, sharing concentrates on the strongest object evidence.Source: B. Measurement harness · p. 4
V. EVALUATION
The evaluation measures context-blind sharing on UAV3D’s mini-validation split and measures system overhead on a Jetson AGX Orin. The authors limit their conclusions to one benchmark and one released model.
V. EVALUATION
- The evaluation asks how much accuracy fixed sharing policies lose when they ignore runtime context and measures context-plane computation and communication costs.Source: §V · p. 4
- The study uses 80 UAV3D mini-validation frames, with full sharing transmitting 13.1 MB per fleet-frame, and measures overhead on a Jetson AGX Orin.Absolute AP values from the mini-validation split should not be compared with full-test-split results.Source: §V · p. 4
- The evaluation uses one benchmark, UAV3D, and one released model, DiscoNet, so values are not claimed to hold across other datasets, models, or wireless networks.Evaluation across additional models, datasets, and real wireless conditions remains future work.Source: §V · p. 4
A. Cooperative gain and the byte-accuracy frontier
Cooperative sharing substantially improves detection over a single drone, and the byte–accuracy curve saturates quickly. Mission-region accuracy remains statistically indistinguishable from full sharing at 5–10% of its bytes, while peer-selection outcomes depend on the sharing configuration.
A. Cooperative gain and the byte-accuracy frontier
- Full sharing raises accuracy from 0.185 AP@0.5 for a single drone to 0.371, a gain of 18.5 AP [+16.9, +20.3].Source: A. Cooperative gain and the… · p. 4
- At ρ=0.1, reducing shared bytes by 10× costs only 2.0 AP relative to full sharing; at ρ=0.05, the system retains 58% of the cooperative gain using 5% of the bytes.At ρ=0.01, accuracy falls by 24 AP; the ρ=0.02 visualization shows shared cells concentrating around the strongest object evidence.Source: A. Cooperative gain and the… · pp. 4–5, Figure 2 · p. 5
B. Mission context
- In the 32 m mission region, AP reaches 0.773–0.784 for ρ ∈[0.05, 0.1], statistically indistinguishable from 0.763 AP with full sharing.The largest difference is +2.2 AP [−0.5, +5.1] (n.s.). A mission-aware policy can reduce communication by 10× without a measurable loss in task-relevant accuracy.Source: B. Mission context · p. 5
C. Peer selection
- At ρ=0.25, sharing through all four peers outperforms every two-peer policy by +4.8 AP [+3.8, +5.8].The two-peer best-, worst-, and random-overlap policies do not differ significantly; pairwise overlap does not reliably predict peer value in this dense formation.Source: C. Peer selection · p. 5
D. Budget sensitivity
The best peer-selection policy changes with the byte budget, so no fixed policy performs well across the tested range. A context-switched oracle improves on the best single fixed policy, but remains a measurement tool rather than an online policy.
D. Budget sensitivity
- +7.7 AP at ρ=0.02 and +4.8 AP at ρ=0.25 favor opposite peer-selection strategies, with the crossover between 5% and 10% of full-sharing bandwidth.Concentrating bytes on two peers wins at ρ=0.02 and ρ=0.05; spreading across four peers wins at ρ=0.1 and ρ=0.25.Source: D. Budget sensitivity · p. 5
- The winning large-budget policy loses 7.7 AP when bandwidth is starved, while the small-budget winner loses 4.8 AP when bandwidth is plentiful.The oracle is a measurement tool, not an online policy, and only switches among the fixed policies already evaluated; practical online policies remain future work.Source: D. Budget sensitivity · pp. 5–6
- +2.1 AP separates the budget-switched oracle from the best single fixed policy across four budgets, with a +2.0 AP held-out improvement.The oracle selects among evaluated fixed policies; the held-out result uses half the frames for selection and the remainder for evaluation.Source: D. Budget sensitivity · p. 5
- In the evaluated cross formation, overlap-proportional allocation performs about the same as uniform allocation because peer overlaps are similar.The passage notes that allocation's effect should become stronger as the formation spreads and overlap becomes less uniform.Source: D. Budget sensitivity · p. 6
E. Composition of context axes
At constrained budgets, mission context can distinguish peer choices that have equal full-scene accuracy. The context plane's prototype adds little bandwidth and policy latency, while the discussion identifies policy verification, security, active cooperation, context-conditioned benchmarks, and descriptor size as open problems.
E. Composition of context axes
- +5.9 AP separates best-2 from worst-2 for the track-a-target task at ρ=0.02, although both achieve 0.257 AP on the full scene.At ρ=0.05, spreading performs better than concentration within the mission region by +3.1 AP, a directionally consistent but statistically nonsignificant result.Source: E. Composition of context axes · p. 6
F. Overhead of the context plane
- Approximately 0.01% of data-plane bandwidth is used by the context plane in the four-agent ROS 2 prototype.Four 180 B descriptors at 10 Hz plus 80 directives per second use 10.1 KB/s against a 105 MB/s data plane.Source: F. Overhead of the context plane · p. 6
- 0.10 ms median policy latency is about three orders of magnitude below the 100 ms deadline imposed by the 10 Hz update rate.The prototype uses 9% of one CPU core; replayed context changes trigger ROI, rate-ladder, and detection-level sharing changes without modifying the perception model.Source: F. Overhead of the context plane · p. 6
VI. DISCUSSION
- The discussion identifies policy safety verification, descriptor trust, active viewpoint selection, operational-context benchmarks, and minimal sufficient context as open problems.A drone misreporting coverage could prevent peers from looking at a region; existing aerial datasets lack battery, link, and mission traces, and the smallest quality-preserving descriptor remains a rate-distortion question.Source: §VI · p. 6
VII. RELATED WORK
The related work distinguishes policies governing which features are sent from methods improving how received features are fused. The conclusion reports task-relevant accuracy at 5–10% of full-sharing bytes and approximately 6 AP from combining context axes rather than using one alone.
VII. RELATED WORK
- HydraCollab switches fidelity levels at runtime but responds only to scene confidence, without combining multiple context axes.The related-work discussion identifies it as the closest recent method.Source: §VII · pp. 6–7
- Fusion-model methods improve how received features are combined, whereas the context plane controls which features are sent, by which drones, and at what fidelity and rate.The distinction also applies to work on pose errors and heterogeneous agents; the approaches are described as complementary.Source: §VII · p. 7
- The paper situates its separate context plane alongside established ideas such as control/data separation and task-oriented communication, rather than claiming the general concept of a separate plane.It states that prior work does not provide the specific fleet-wide context bus and perception-directive interface it describes.Source: §VII · p. 7
VIII. CONCLUSION
- Mission-aware sharing preserves task-relevant accuracy with only 5–10% of full-sharing bytes, while combining context axes provides approximately 6 AP over using a single axis.The conclusion also reports 0.01% communication overhead and 0.10 ms per policy decision in the ROS 2 prototype.Source: §VIII · p. 7