Fleets Need a Context Plane: Rethinking Cooperative Perception for Autonomous Drones

Fleets Need a Context Plane: Rethinking Cooperative Perception for Autonomous Drones Liangkai Liu and Xiaoxiao Wu

arXiv:2609.00659v1 [cs.RO] 1 Sep 2026

Department of Computer Science, Texas Tech University, Lubbock, USA

have three observations. First, full sharing is roughly an order of magnitude too rich for the mission being flown: missionrelevant accuracy matches it at 5–10% of the bytes. Second, no fixed scheme is safe, because the best sharing policy flips as the byte budget moves, and holding the wrong one costs up to 7.7 AP within a single sortie. Third, the context signals have to be taken together: at starved budgets, the budget axis alone cannot choose between two policies that mission context separates by about 6 AP. Existing methods, including the most recent runtime adaptive one [9], take at most one of these signals and embed the response in model weights, where it cannot be reconfigured. Considering these issues, we pose a critical question: Can a drone fleet expose its operating context through a common interface, so that sharing becomes a runtime decision rather than a design-time static configuration? We propose the context plane, a second and inexpensive plane alongside the fleet’s data plane of feature and detection traffic. Each drone publishes its mission, scene, platform, and geometry context in a single descriptor of at most 1 KB at 10 Hz (Fig. 1). Small and replaceable policies read the whole fleet’s context and schedule everything the data plane does: which drone computes, which transmits, to which peers, and at what fidelity, rate, and region. Policies never touch data-plane payloads, which keeps every decision cheap to compute and easy to audit. This work is timely for three reasons. First, aerial benchmarks (UAV3D [3], CoPeD [4]) have just appeared and port the V2X protocol without modification. Second, Orin-class onboard compute makes feature-level sharing feasible, so the bandwidth and energy costs are immediate. Third, the transport already exists: DDS QoS and ROS 2 topics can carry a context plane [10], and only the interface is missing. This paper makes four main contributions: • A context-plane abstraction for drone fleets. The design defines a context descriptor, a plane contract, and a policy contract that enable context-aware adaptation of data sharing at runtime. • An empirical study of context-blind sharing. We quantify the benefits of using context to control data sharing. Adapting the sharing policy to context improves accuracy by up to 2.0 AP on held-out contexts compared with the best fixed policy. Jointly considering multiple context axes provides a further ∼6 AP improvement, without retraining the perception model. • A ROS 2 prototype. The context plane uses only ≈0.01% of the data-plane bandwidth it controls, and each

Abstract—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 peerselection 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. I NTRODUCTION Cooperative perception lets a drone fleet share sensor data so that each drone sees around occlusions and from complementary viewpoints [1], [2]. It is effective: on UAV3D, fusing features across five drones doubles detection accuracy over a single drone. Recent methods and benchmarks now bring this capability from ground vehicles to aerial fleets [3], [4], and they carry the sharing defaults of ground V2X with them. SOTA systems decide what to share, with whom, and at what fidelity and rate at design time, and transmit to every peer, every frame, at uniform fidelity [5], [6], [7]. Some methods adapt at runtime, but each responds to a single signal: Where2comm sparsifies features by spatial confidence [8], while HydraCollab adjusts fidelity to the available bandwidth [9]. However, a drone fleet changes along several axes at once within a single sortie: the mission switches phase and each phase values different regions of the scene, the energy budget is the flight time itself, the formation geometry changes in six degrees of freedom, and the scene coverage of each drone overlaps and separates. A policy that reads one of these signals, or none of them, is left with the wrong sharing decision for most of the mission. On UAV3D, using the released DiscoNet [6] checkpoint with no retraining and varying only the sharing schedule, we

1

•

policy evaluation takes 0.10,ms on a Jetson AGX Orin. A general evaluation methodology. By adding evaluation-time context controls to released model checkpoints, our method can enable context-aware sharing policies for existing cooperative-perception models without retraining.

context plane: descriptors ≤1 KB @ 10 Hz fleet ctx ego drone i drone j

drone k

cameras perception (BEV feat.)

II. BACKGROUND AND M OTIVATION

fusion + detector

A. Cooperative Perception

policy πi directives gate data plane: features / detections (MB/s, gated)

Cooperative-perception systems can share information at three levels. Early fusion shares raw sensor data, preserving the most information but requiring the most bandwidth [1]. Late fusion shares only detection results, reducing bandwidth at the cost of discarding useful information. Intermediate fusion shares latent feature maps and balances these two extremes [2]. Most recent systems use intermediate fusion and focus on improving how features are selected and combined. Examples include graph- and attention-based fusion [5], [6], [11], confidence-guided sparsification [8], and camera-only collaboration that outperforms a single-agent LiDAR baseline [12]. Other work improves robustness to pose errors [13] and heterogeneous fleets [14]. However, intermediate features remain large. On UAV3D, full sharing transmits 13.1,MB per fleet-frame (Section V), far exceeding the capacity of a drone’s wireless link. A practical system must therefore decide what to share, with whom, at what fidelity, and at what rate.

middleware: DDS / ROS 2 QoS

Fig. 1. Context-plane design. Every drone publishes a ≤1 KB descriptor at 10 Hz onto a fleet-wide context bus (dashed). Each drone’s policy reads fleet context and emits directives; a gate enforces them on the heavy data plane (gray pipes): which peers, what representation, what ROI, what rate. Policies never touch data-plane payloads. TABLE I T HE CONTEXT DESCRIPTOR AS IMPLEMENTED (C O N T E X T D E S C R I P T O R . M S G ); 180 B SERIALIZED AT N =5. Group

Field

Type

Bytes

— Geometry

stamp, agent id position, orientation, velocity footprint radius battery, cpu, gpu headroom peer goodput[N −1] coverage grid (16×16×2 b) novelty flags task phase region of responsibility priority target ids

Time, u8 f32[3,4,3] f32 f32×3 f32[] u8[64] u8 u8 f32[4] u16[]

9 40 4 12 16 64 1 1 16 2k

Platform Scene Mission

B. Motivation Sharing Decisions Are Fixed at Design Time. Most state-ofthe-art systems set their sharing decisions before deployment and keep them fixed throughout the mission. These choices are largely inherited from ground-based V2X settings, where they are often reasonable. Vehicles in common benchmarks [15], [16], [17] follow fixed routes, draw power from an engine or the grid, maintain near-planar viewpoints, and rely on roadside infrastructure and HD maps. A few systems adapt their sharing decisions at runtime, but they typically respond to only one context signal [8], [9].

the whole fleet and emits directives. A gate then enforces those directives on the drone’s data-plane traffic. A. Context descriptor Each agent publishes one compact descriptor at low rate (∼10 Hz, ≤1 KB), with four field groups; Table I gives the concrete schema our prototype ships (180 B serialized for a four-peer fleet). Two design choices matter. First, the scene summary is a coverage statement, not content: a 16×16 BEV grid at two bits per cell (seen well / seen poorly / unseen / novel) is enough for peers to reason about which drone can contribute what nobody else sees, without shipping features. Second, link quality is reported per peer, as measured by the sender, so every policy sees the same (eventually consistent) link picture without a separate monitoring service.

Context Changes Rapidly in the Air. These assumptions do not hold for drone fleets. During a single flight, the mission phase changes, batteries drain, formation geometry shifts, and each drone observes different parts of the scene. Aerial deployments may also lack supporting infrastructure. Therefore, a sharing policy selected before takeoff is unlikely to remain effective throughout the mission.

B. The plane contract

III. S YSTEM D ESIGN

The plane contract follows six rules. First, each descriptor has a bounded size and publication rate. Second, descriptors use best-effort delivery and handle stale information conservatively. As a descriptor ages, the policy may only reduce sharing fidelity or rate. In our prototype, a descriptor older than three periods marks the link as degraded, while one older than ten periods marks the peer as detached. Third, the context plane carries only context descriptors, never perception payloads. Fourth, policies read only these descriptors, which keeps their decisions fast and auditable. Fifth, the system waits before

Fleets already have a data plane that carries the heavy perception payloads of cooperative perception, including feature maps, detections, and tracks. However, they have no defined place for the information that should govern this exchange. We propose an explicit context plane, a low-rate and structured fleet-wide exchange of operating context that small policies read to schedule the data plane. Figure 1 shows the design. Every drone publishes a compact context descriptor onto a fleet-wide bus. A policy on each drone reads the context of

2

changing a policy, so small or temporary changes do not cause rapid switching. Sending the same command again has no effect. This prevents repeated commands which restarted the data timers and accidentally stop data transmission. Finally, descriptors are authenticated because they directly influence fleet-wide sharing decisions.

TABLE II P RIOR METHODS AS FIXED POINTS IN THE CONTEXT- PLANE POLICY SPACE . • = CONTEXT READ ; DECISION COLUMNS LIST WHAT THE METHOD FIXES AT DESIGN TIME VS . LEAVES UNADDRESSED . Context read

C. The policy contract A policy is a small, swappable function πi : C N → DN −1 from the fleet’s context (the N latest descriptors, however stale) to one directive per outgoing link. A directive includes six decisions: (1) whether to run expensive perception at all (duty cycle); (2) which peers to send to (topology); (3) the representation on the fidelity ladder, whose rungs span four orders of magnitude per link in UAV3D configuration: raw imagery 5.4 MB/frame, full BEV features 655 KB, budgeted features 164 KB at ρ=0.25 and 13 KB at ρ=0.02, detections ∼1 KB, tracks 0.24 KB; (4) the spatial subset (ROI); (5) rate and deadline; and (6) receiver-side fusion weights (trust, staleness). Policies may be engineered rules or learned functions; the contract is agnostic. Because πi reads only local copies of fleet context, no negotiation protocol is required. Policies at different drones may transiently disagree, and the damping clause plus age-monotonicity bound the cost of disagreement, which disappears once the views converge.

Method

Mis. Scene Plat. Geom. Decides

Where2comm [8] When2com [18] Who2com [19] V2VNet [5] DiscoNet [6] SyncNet [20] HydraCollab [9] Fixed compression

– – – – – – – –

• • • – – – • –

– – – – – • – –

– – – – – – – –

ROI topology topology fusion wts fusion wts fusion wts fidelity+ROI fidelity

Ignores

Context plane

•

•

•

•

all six, swappable at runtime

topology, fidelity, rate ROI, fidelity, rate ROI, fidelity, rate all scheduling all scheduling topology, ROI, fidelity topology, rate everything else

TABLE III T HE PROTOTYPE POLICY AS A DECISION TABLE ( THRESHOLDS ARE MODULE CONSTANTS ; EACH RULE READS ONLY DESCRIPTOR FIELDS ). Context condition

Decision

Fields read

battery ≥ 60% 30% ≤ battery < 60% battery < 30% peer goodput < 5 Mbps phase = track always

feature @ 10 Hz feature @ 5 Hz detections @ 2 Hz ↓ detections, rate ≤ 2 ROI = 32 m disc top-2 peers by overlap

platform platform platform platform mission, geometry geometry

the 60% and 30% thresholds. When drone 2’s link quality drops at t=60,s, its outgoing links switch to detection-level sharing within one descriptor period. None of these changes modifies or retrains the perception model.

D. Unifying Existing Sharing Methods The context plane can represent the sharing mechanisms used by existing cooperative-perception systems. Each method corresponds to a particular policy in our design. Where2comm [8] uses a scene confidence map to select the ROI of shared features. When2com and Who2com [18], [19] use visual features as implicit scene context to select communication peers. V2VNet [5] and DiscoNet [6] use a fixed all-toall topology and learn the fusion weights. SyncNet [20] uses network delay to compensate for stale features at the receiver. Fixed-rate compression always uses the same fidelity level. Concurrent work, HydraCollab [9], uses scene confidence to switch between intermediate and late fusion. Table II highlights two remaining gaps. First, existing adaptive methods use at most one context axis and therefore cannot jointly consider mission, scene, platform, and geometry. Second, adaptation is often tied to a specific model architecture or its weights, making it difficult to replace, audit, or verify. The context plane does not replace these existing mechanisms. Instead, it places them behind a common interface so that they can be selected and combined according to runtime context.

F. Middleware mapping and placement The context plane sits between the perception stack and the middleware. A descriptor publisher summarizes each drone’s local state, the policy node converts fleet context into directives, and the gate applies those directives to data-plane publishers. These components use standard DDS/ROS 2 QoS mechanisms [10] and require no new transport. Each drone publishes its descriptor on a best-effort, keeplast-1 topic at 10,Hz. Message loss is handled by the staleness rules in the plane contract. Directives use a reliable, keep-last1 topic, and repeating the same directive has no additional effect. Data-plane topics use QoS profiles suited to their payloads: high-rate features use best-effort delivery, while compact detections and tracks use reliable delivery. The gate is the only component that reads both a directive and a dataplane payload. Thus, the main contribution is not a new transport protocol, but a standard interface for context-aware data sharing.

E. A worked policy

G. Why not model-internal adaptation?

Our prototype implements the policy in Python. As summarized in Table III, the battery level selects the initial representation and rate, while link quality may reduce both. The mission phase determines the ROI, and overlap in scene coverage selects the two most useful peers. We replayed our 120,s evaluation traces through this policy. As the battery level decreases, the 1→0 link changes its representation and rate at

One alternative is to place all adaptation inside a single fusion model conditioned on battery level, mission phase, and formation geometry. We instead place the adaptation logic behind a typed interface for four reasons. First, drones from different vendors may use different perception models, but they can still exchange the same context descriptors and

3

directives. Second, the logged context and policy decisions clearly show why a drone changed or stopped sharing, while model weights and attention scores are difficult to interpret. Third, operators can change policies for different missions without retraining the perception model. Fourth, a policy with bounded, typed inputs and outputs is easier to check against mission-level safety requirements. The interface does not exclude learned policies; a learned policy can still implement the same contract.

The harness records per-frame predictions, ground truth, and per-agent communication costs. A separate evaluator computes rotated BEV IoU and AP at an IoU threshold of 0.5. All accuracy results in this paper use this evaluator and the same evaluation protocol, ensuring consistent comparisons. The third-party DiscoNet model is used only for inference; the sharing policies, byte accounting, and evaluation are implemented and tested in our code. Applying the context controls at evaluation time also provides a general measurement method. A released cooperativeperception checkpoint can serve as a probe of the policy space without retraining, while the harness records the exact communication cost of each policy. Figure 2 shows one mini-validation frame passing through the harness. It includes the five camera views, the fused BEV detections and ground truth, and the exact feature cells transmitted by each peer under two budgets. At ρ=0.25, the retained cells follow the object structure of the scene. At the more limited ρ=0.02 budget, sharing concentrates on the strongest object evidence.

IV. I MPLEMENTATION We implement and release two artifacts: a ROS 2 prototype of the context plane and a measurement harness for evaluating context-aware sharing on a public multi-UAV benchmark. A. Context-plane prototype The prototype consists of two ROS 2 Humble packages. context_plane_msgs defines two message types. ContextDescriptor contains the four context groups described in Section III and requires 180,B after serialization. DataPlaneDirective specifies the source, destination, representation, ROI, transmission rate, and deadline. The context_plane package provides four types of nodes. A context publisher runs on each drone at 10,Hz and publishes either recorded or live platform state. A policy node stores the latest descriptor from every drone and maps the fleet context to directives on each tick. Our battery-, link-, and phase-aware policy is a 42-line Python function with no ROS dependencies, allowing it to be unit-tested separately. A gate on each drone applies the directives by publishing synthetic, feature-sized payloads with the specified representation, ROI fraction, and rate. Finally, a benchmark node counts the serialized bytes on every topic and measures the CPU time used by the policy. The policy reads only context descriptors. The gate is the only component that reads both directives and data-plane payloads, preserving the separation required by the contracts in Section III.

V. E VALUATION Our evaluation covers two aspects. First, how much accuracy is lost when a fixed sharing policy ignores runtime context? Second, the computation and communication costs of the context plane. We evaluate context-blindness on the 80-frame UAV3D mini-validation split, which contains one frame from each scene. All policies are compared under the same byte budgets and evaluation protocol. Full sharing transmits 13.1 MB per fleet-frame. Because we use the mini-validation split, the absolute AP values should not be compared with results on the full test split. We measure system overhead on a Jetson AGX Orin. Unless stated otherwise, brackets report 95% pairedbootstrap confidence intervals over the 80 frames. Because each frame comes from a different scene, we treat the frames as independent samples. “n.s.” indicates that the confidence interval contains zero. Our evaluation uses one benchmark, UAV3D, and one released model, DiscoNet. These experiments establish that context-blind sharing has a measurable cost and that using context can recover accuracy. We do not claim that the exact values will remain unchanged across other datasets, fusion models, or wireless networks. Our broader claim is that the best sharing policy depends on runtime context and that no single fixed policy performs best across the full operating range. Evaluation across additional models, datasets, and real wireless conditions remains future work.

B. Measurement harness The measurement harness evaluates cooperative-detection accuracy under different context-driven sharing decisions. We use UAV3D [3], a camera-only collaborative 3D-detection benchmark with five UAVs, and the released DiscoNet [6] checkpoint without retraining. All sharing decisions are applied at the feature-exchange point during evaluation. Each peer produces an 80-channel FP16 BEV feature map. A budget ρ limits the total number of cells shared with each ego drone to a fraction ρ of full sharing. A peer-selection policy chooses which drones contribute features, and an allocation rule divides the budget among them. The allocation can be uniform or proportional to footprint overlap computed from the drone poses. We calculate the transmitted bytes exactly as retained cells × 80 channels × 2 B.

A. Cooperative gain and the byte-accuracy frontier Without fusion, a single drone achieves 0.185 AP@0.5. Full cooperative sharing increases accuracy to 0.371, a gain of 18.5 AP [+16.9, +20.3]. Cooperation is therefore clearly beneficial. However, the byte–accuracy curve in Fig. 3a quickly saturates. Reducing the shared bytes by 10×, to ρ=0.1, costs

(1)

4

drone 1

drone 2

drone 3

(b) cells shared to ego, ρ = 0.25

(a) BEV: ground truth (gray) vs detections (blue); drones 100

▲ 100 (1024 of 4096 per peer)

50 0

−100 −100

0

100

(c) cells shared to ego, ρ = 0.02 (82 of 4096 per peer) 50

0

0

−50

−50

−100 −100

0

100

4

100

50 2 4 0 1 3

−50

drone 4

−100 −100

2

0

0

100

Fig. 2. One UAV3D mini-validation frame processed by the measurement harness. Top: the five drones’ nadir camera views. (a) BEV ground truth (gray) and DiscoNet detections (blue); ▲ marks the cross-shaped drone formation. (b,c) The feature cells shared by the four peers with the ego drone at ρ=0.25 and ρ=0.02. Shading indicates how many peers share each cell, and gray boxes show the ground truth. At the lower budget, the selected cells concentrate around the strongest object evidence.

only 2.0 AP [+0.8, +3.4] relative to full sharing. At ρ=0.05, the system retains 58% of the cooperative gain while using only 5% of the bytes. In contrast, reducing the budget to ρ=0.01 lowers accuracy by 24 AP. Thus, the last order of magnitude in bandwidth provides only about two additional points of AP.

reliably predict peer value. Effective peer selection therefore requires the coverage context carried by the context descriptor, rather than a fixed geometric rule. D. Budget sensitivity We repeat the matched-byte comparison across four budgets (Fig. 3b). At the smallest budget, ρ=0.02, concentrating the available bytes on two peers outperforms spreading them across all four peers by +7.7 AP [+6.6, +8.9]. Concentration still leads by +1.4 AP [+0.2, +2.7] at ρ=0.05. The result reverses as the budget increases. At ρ=0.1, spreading across all four peers outperforms the best two-peer policy by +4.0 AP [+2.8, +5.3]. At ρ=0.25, the advantage increases to +4.8 AP [+3.8, +5.8]. The crossover occurs between 5% and 10% of full-sharing bandwidth, a range that a real wireless link can easily cross during operation. No fixed policy performs well across the entire range. The policy that wins with a large budget loses 7.7 AP when the link is starved, while the policy that wins with a small budget loses 4.8 AP when bandwidth is plentiful. To measure the value of context-dependent selection, we construct an oracle that selects the best evaluated fixed policy for each budget. Across the four budgets, the oracle achieves 0.320 mean AP, compared with 0.299 for the best single fixed policy, an improvement of +2.1 AP. We also select the winning policy using half of the frames and evaluate it on the remaining half. The held-out improvement remains +2.0 AP, showing that the gain is not caused by selection bias. This oracle is a measurement tool, not an online policy. It only switches among the fixed policies already evaluated and does not explore the larger directive space supported by

B. Mission context We next evaluate accuracy only within a 32 m mission region, representing a track-a-target task. Mission-specific AP reaches 0.773–0.784 for ρ ∈ [0.05, 0.1], which is statistically indistinguishable from the 0.763 AP achieved with full sharing. The largest difference is +2.2 AP [−0.5, +5.1] (n.s.; Fig. 3a). Therefore, a mission-aware policy can reduce communication by 10× without a measurable loss in task-relevant accuracy. Context-blind full sharing instead spends bandwidth and energy on regions that the current mission does not prioritize. C. Peer selection We compare peer-selection policies at a fixed budget of ρ=0.25. Every configuration transmits the same total number of bytes. Among the two-peer policies, selecting the two most-overlapping peers (best-2), the two least-overlapping peers (worst-2), or two random peers produces no significant difference: [ worst-2 - best-2 = +0.8 AP;[-0.8,+2.3], ] and [ worst-2 - random-2 = +0.1 AP;[-1.1,+1.3]. ] Neither difference is significant. The important factor at this budget is spreading the bytes across more peers. Sharing through all four peers outperforms every two-peer policy by +4.8 AP [+3.8, +5.8]. In this dense aerial formation, pairwise overlap does not

5

# peers sharing cell

drone 0 (ego)

(a) the byte-accuracy frontier is mission-dependent

the context plane. Designing practical online policies over that space, using either rules or learning, remains future work. In the evaluated cross formation, drones are separated by approximately 20 m and have 42 m footprints. Because their overlaps are similar, overlap-proportional allocation performs about the same as uniform allocation. This result does not imply that allocation is unimportant; its effect should become stronger as the formation spreads and overlap becomes less uniform.

AP@0.5

0.8

full-scene AP mission-task AP (r=32 m)

task saturates at ~5-10% of bytes

0.6 0.4 0.2 0.0

100

E. Composition of context axes

shared bytes / frame (MB, log)

The context plane is designed to combine multiple context axes, and the results show why this is necessary. At ρ=0.02, the two concentration policies, best-2 and worst-2, both achieve 0.257 AP on the full scene. The budget alone therefore cannot determine which two peers should be selected. Adding mission context breaks this tie. For the track-a-target task, best2 achieves 0.787 AP, compared with 0.728 AP for worst-2, a difference of +5.9 AP [+2.5, +9.4]. The mission and budget axes also interact at ρ=0.05. A concentration policy performs best on the full scene, while spreading performs better within the mission region by +3.1 AP [−0.6, +7.0]. This second result is directionally consistent but not statistically significant at the current sample size. Overall, a policy that reads only the budget leaves approximately 6 AP unclaimed compared with one that jointly reads budget and mission context. Both signals fit within the same 1 KB descriptor.

101

(b) best peer policy flips with budget (▼ per-regime best)

AP@0.5

0.4

all

best2

worst2

best1

0.3 0.2 0.1 0.0

0.02

0.05

0.1

0.25

Fig. 3. The context-blindness tax on UAV3D (DiscoNet, released checkpoint, eval-time knobs, matched bytes within every comparison). (a) Full-scene AP saturates while mission-task AP peaks at 5–10% of full-sharing bytes. (b) At matched bytes, the best peer-selection policy flips between budget regimes (▼ marks each regime’s best; whiskers are 95% bootstrap CIs); a contextswitched oracle beats the best fixed policy by 2.1 mean-AP (2.0 held-out), and the wrong fixed choice pays up to 7.7 AP in-regime.

F. Overhead of the context plane Four simulated agents replay 120 s context traces containing a mission phase change, battery decay, and a link-quality drop. We run the prototype natively on a Jetson AGX Orin with 64 GB of memory, a companion-computer platform suitable for capable drones. Four 180 B descriptors published at 10 Hz, together with 80 directives per second, use 10.1 KB/s. The data plane controlled by these messages transmits 105 MB/s. The context plane therefore adds approximately 0.01% of the dataplane bandwidth. Policy evaluation takes 0.10 ms at the median and 0.13 ms at the 99th percentile. This is approximately three orders of magnitude below the 100 ms deadline imposed by the 10 Hz update rate. The full ROS 2 prototype uses 9% of one CPU core. An x86 container produces similar results, with a 62 MB/s data-plane rate and a median policy latency of 0.03 ms. The replayed traces exercise the complete fidelity ladder. At t=45 s, a mission-phase change reduces feature payloads by 10× through an ROI directive. Battery decay moves agent 1 down the rate ladder, and a link drop at t=60 s switches agent 2 to detection-level sharing. Each transition is triggered by context, and none modifies the perception model.

properties (“never drop detection sharing while a human is in the region of responsibility”) may be checkable mechanically. (2) Context-plane security. A drone that lies about its coverage can stop its peers from looking at a region, so trust calibration for small and cheaply cross-validated descriptors deserves study before the interface is standardized. (3) Active cooperation. We scoped this paper to passive sharing, but drones also choose their viewpoints. Mission and coverage context together form a natural basis for deciding which drone repositions to see what, which is the extension with the largest payoff and the largest safety obligations. (4) Contextconditioned benchmarks. Aerial datasets [3], [4] ship frames but no battery, link, or mission traces, so policies cannot be evaluated where they matter. We release our traces and harness as a start. (5) Minimal sufficient context. The smallest descriptor that preserves policy quality is a rate-distortion question, and its answer sets how cheap the plane can ultimately be. VII. R ELATED W ORK

VI. D ISCUSSION

Collaborative perception. Section III-F shows how existing collaborative-perception methods [1], [2], [8], [18], [19], [5], [6], [20], [9] fit within our policy space. The closest recent method is HydraCollab [9], which switches between fidelity

The reorganization makes five problems addressable. (1) Policy synthesis and verification. Policies are bounded functions of bounded typed inputs, so mission-level safety

6

levels at runtime. However, it responds only to scene confidence and does not combine multiple context axes. Other work improves the fusion model itself, including transformer fusion [11], [7] and camera-only collaboration [12]. These methods determine how received features are combined, while the context plane determines which features should be sent, by which drones, and at what fidelity and rate. The two directions are therefore complementary. The same distinction applies to methods that handle pose errors [13] or heterogeneous agents [14]: they improve the fusion of received data, whereas the context plane controls the data that arrive. Finally, aerial and multi-robot datasets [3], [4] provide perception data but generally lack operational context such as battery, link-quality, and mission traces. We release our traces to help fill this gap.

[2] Q. Chen, X. Ma, S. Tang, J. Guo, Q. Yang, and S. Fu, “F-Cooper: Feature based cooperative perception for autonomous vehicle edge computing system using 3D point clouds,” in ACM/IEEE Symposium on Edge Computing (SEC), 2019. [3] H. Ye, R. Sunderraman, and S. Ji, “UAV3D: A large-scale 3D perception benchmark for unmanned aerial vehicles,” in Advances in Neural Information Processing Systems (NeurIPS) Datasets and Benchmarks Track, 2024. [4] Y. Zhou, L. Quang, C. Nieto-Granda, and G. Loianno, “Coped-advancing multi-robot collaborative perception: A comprehensive dataset in realworld environments,” IEEE Robotics and Automation Letters, vol. 9, no. 7, pp. 6416–6423, 2024. [5] T.-H. Wang, S. Manivasagam, M. Liang, B. Yang, W. Zeng, and R. Urtasun, “V2VNet: Vehicle-to-vehicle communication for joint perception and prediction,” in European Conference on Computer Vision (ECCV), 2020. [6] Y. Li, S. Ren, P. Wu, S. Chen, C. Feng, and W. Zhang, “Learning distilled collaboration graph for multi-agent perception,” in Advances in Neural Information Processing Systems (NeurIPS), 2021. [7] R. Xu, Z. Tu, H. Xiang, W. Shao, B. Zhou, and J. Ma, “CoBEVT: Cooperative bird’s eye view semantic segmentation with sparse transformers,” in Conference on Robot Learning (CoRL), 2022. [8] Y. Hu, S. Fang, Z. Lei, Y. Zhong, and S. Chen, “Where2comm: Communication-efficient collaborative perception via spatial confidence maps,” in Advances in Neural Information Processing Systems (NeurIPS), 2022. [9] L. Chen, C.-J. Wu, D. R. Martin, Q. Ye, P. Khargonekar, and M. A. Al Faruque, “HydraCollab: Adaptive collaborative-perception for distributed autonomous systems,” in IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 2026. [10] S. Macenski, T. Foote, B. Gerkey, C. Lalancette, and W. Woodall, “Robot operating system 2: Design, architecture, and uses in the wild,” Science Robotics, vol. 7, no. 66, 2022. [11] R. Xu, H. Xiang, Z. Tu, X. Xia, M.-H. Yang, and J. Ma, “V2X-ViT: Vehicle-to-everything cooperative perception with vision transformer,” in European Conference on Computer Vision (ECCV), 2022. [12] Y. Hu, Y. Lu, R. Xu, W. Xie, S. Chen, and Y. Wang, “Collaboration helps camera overtake LiDAR in 3D detection,” in IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2023. [13] Y. Lu, Q. Li, B. Liu, M. Dianati, C. Feng, S. Chen, and Y. Wang, “Robust collaborative 3D object detection in presence of pose errors,” in IEEE International Conference on Robotics and Automation (ICRA), 2023. [14] Y. Lu, Y. Hu, Y. Zhong, D. Wang, Y. Wang, and S. Chen, “An extensible framework for open heterogeneous collaborative perception,” in International Conference on Learning Representations (ICLR), 2024. [15] R. Xu, H. Xiang, X. Xia, X. Han, J. Li, and J. Ma, “OPV2V: An open benchmark dataset and fusion pipeline for perception with vehicle-tovehicle communication,” in IEEE International Conference on Robotics and Automation (ICRA), 2022. [16] Y. Li, D. Ma, Z. An, Z. Wang, Y. Zhong, S. Chen, and C. Feng, “V2XSim: Multi-agent collaborative perception dataset and benchmark for autonomous driving,” IEEE Robotics and Automation Letters, vol. 7, no. 4, pp. 10 914–10 921, 2022. [17] H. Yu, Y. Luo, M. Shu, Y. Huo, Z. Yang, Y. Shi, Z. Guo, H. Li, X. Hu, J. Yuan, and Z. Nie, “DAIR-V2X: A large-scale dataset for vehicle-infrastructure cooperative 3D object detection,” in IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2022. [18] Y.-C. Liu, J. Tian, N. Glaser, and Z. Kira, “When2com: Multi-agent perception via communication graph grouping,” in IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), 2020. [19] Y.-C. Liu, J. Tian, C.-Y. Ma, N. Glaser, C.-W. Kuo, and Z. Kira, “Who2com: Collaborative perception via learnable handshake communication,” in IEEE International Conference on Robotics and Automation (ICRA), 2020. [20] Z. Lei, S. Ren, Y. Hu, W. Zhang, and S. Chen, “Latency-aware collaborative perception,” in European Conference on Computer Vision (ECCV), 2022. [21] D. D. Clark, C. Partridge, J. C. Ramming, and J. T. Wroclawski, “A knowledge plane for the internet,” in ACM SIGCOMM, 2003, pp. 3–10. [22] A. K. Dey, “Understanding and using context,” Personal and Ubiquitous Computing, vol. 5, no. 1, pp. 4–7, 2001. [23] D. Gündüz, Z. Qin, I. E. Aguerri, H. S. Dhillon, Z. Yang, A. Yener, K.-K. Wong, and C.-B. Chae, “Beyond transmitting bits: Context, semantics, and task-oriented communications,” IEEE Journal on Selected Areas in Communications, vol. 41, no. 1, pp. 5–41, 2023.

Context and control planes in other systems. Our system follows established ideas rather than claiming the general concept of a separate plane. Examples include Clark et al.’s knowledge plane [21], the separation of control and data in software-defined networking, context-aware computing [22], and the fidelity ladder used in adaptive bitrate streaming. Taskoriented communication [23] is especially relevant because it argues that a link should carry information needed by the current task. Our mission-context results apply this principle to cooperative BEV perception. To our knowledge, prior work does not provide a fleetwide bus to which every drone publishes context and from which policies derive perception-specific directives, such as peer selection, representation, ROI, rate, and fusion trust. This interface must also account for flight-time energy constraints and support auditable decisions. VIII. C ONCLUSION Fixed sharing is a poor mechanism for aerial cooperative perception because mission goals, bandwidth, battery level, formation geometry, and scene coverage all change during flight. We introduce the context plane, which separates lightweight operating context from large perception payloads and allows policies to adapt what each drone computes, shares, and fuses. Our UAV3D evaluation shows that mission-aware sharing preserves task-relevant accuracy with only 5–10% of full-sharing bytes, while the best sharing policy changes with the available bandwidth. Pairwise geometry alone cannot reliably identify the most useful peers, and combining multiple context axes provides approximately 6 AP over using a single axis. Our ROS 2 prototype adds only 0.01% communication overhead and takes 0.10 ms per policy decision on a Jetson AGX Orin. Together, these results show that the context plane can adapt sharing decisions to runtime conditions with minimal overhead. R EFERENCES [1] Q. Chen, S. Tang, Q. Yang, and S. Fu, “Cooper: Cooperative perception for connected autonomous vehicles based on 3D point clouds,” in IEEE International Conference on Distributed Computing Systems (ICDCS), 2019.

7

Related documents

• Fleets Need a Context Plane: Rethinking Cooperative Perception for Autonomous Drones#820081
• Evaluating Multimodal LLMs as Generalist Vision-Language-Action Agents for Drone Control: Commanding, Approaching, Tracking and Searching#627735
• Perception-Aware Communication Middleware for Distributed Visual Perception in UAV Swarms#1051358
• G-MAD: A Game-Based Data Generation Framework for Multi-View RGB-T Aerial Object Detection#610000
• G-MAD: A Game-Based Data Generation Framework for Multi-View RGB-T Aerial Object Detection#608938