A single relay is the right tool for a coastline, a harbour, a river mouth — anywhere one patrol route fits. It is the wrong tool for a whole island, a maritime EEZ, or a border zone that runs tens of kilometres in either direction. Fleet patrol mode now splits any operator-drawn AOI into 2, 4, 8, or 16 sectors, each with its own sub-fleet and its own relay, running in parallel under one FleetCommander. The operator doesn’t pick the sector count — Overwatch reads the drawn AOI, the fleet size, and the battery endurance, and chooses. Sectors just happen.

How Overwatch picks the sector count

Orchestration should not mean more dials. The product selling point was always “draw, click, go”; we kept it. When you draw an AOI in Fleet Patrol mode, Overwatch computes the sector count and applies it automatically — no toggle, no operator math. The rule is explicit about what matters: prefer fewer sectors with continuous coverage over more sectors with coverage gaps. One drone always airborne per sector is the core promise of fleet patrol; any recommendation that breaks that promise should either be flagged or avoided.

The recommender reads four inputs:

  1. Fleet size. How many drones are available (1–100).
  2. Battery cycle. Flight time, charge time, and swap threshold together determine how many drones a single sector needs for continuous coverage. The math: drones_per_sector = ceil((usable_flight + charge_time) / usable_flight). For ANAFI XLR (70 min flight, 5 hr charge, 20% swap) that’s 7. For Standard (38 min, 2.5 hr) it’s 6. For X500 (20 min, 1 hr) it’s 5.
  3. AOI perimeter vs. drone endurance. One drone must be able to complete a full lap of its assigned sector within its usable flight time. If the AOI is too big for a single-sector lap, the recommender raises sector count until each sub-perimeter fits.
  4. Cruise speed. Combined with usable flight time, gives the lap-distance ceiling per drone.

From those four, the recommender picks the largest sector count whose per-sector drone allocation satisfies the continuous-coverage threshold. AOI endurance can force more sectors if a single-sector lap would exceed the battery; fleet size can force fewer if each sector needs the full drone population to stay continuous.

Concretely: fleet of 12 on ANAFI XLR covering a 17 km AOI lands on 1 sector × 12 drones (continuous, 7 needed per sector, 5-drone cushion). Drop the fleet to 6 and the card turns amber: “6 drones × 1 sector — expect coverage gaps during charge cycles (need 7 per sector for continuous). Grow fleet to 7 to lock in 24/7 coverage.” Switch to X500 batteries (shorter cycle, only 5 needed per sector) and the same fleet of 6 becomes optimal at 1 sector. Switch to a 40 km AOI and endurance forces 2 sectors — now the amber banner tells you to grow to 14 drones to put continuous coverage on both sectors.

The recommender returns one of four modes, colour-coded in the auto card:

  • Optimal (default orange) — every sector has continuous coverage. The recommendation is quietly correct; operator doesn’t need to think about it.
  • Discontinuous (amber) — fleet is below the continuous threshold for the chosen sector count. Gaps will appear during charge cycles. Operator sees the exact fleet size that would fix it.
  • AOI too big (red) — fleet can’t even do one drone per required sector. Recommendation caps honestly. Reduce the drawn AOI or grow the fleet substantially.
  • Single-drone — fleet size 1, no sectoring possible. (For SAR, see below.)

The recommender re-runs on every change that affects the math: polygon redrawn, fleet size changed, battery type switched, swap threshold tightened. One of the earlier bugs we shipped had the sector count freezing when the operator switched batteries — we fixed that; the card now updates instantly.

For operators who want to override, the Advanced disclosure reveals the manual 1 / 2 / 4 / 8 / 16 toggle with the recommended value flagged. One click and you’re back on auto. The toggle is not the default path — it’s a fallback for operators who know exactly what they want.

Equal-area partitioning

Every sector should have roughly the same battery-drain profile. A sector with twice the perimeter means its drones lap twice as slowly, drain twice as fast, and the relay cycle desyncs from the neighbouring sectors — which complicates handoff choreography and defeats the point of parallel patrol. So the partitioner doesn’t just cut at the polygon’s centroid; it binary-searches the cut position along the bounding-box long axis until the two halves have equal area. Twenty iterations converges to sub-metre accuracy for any realistic AOI, and applied recursively produces 2 / 4 / 8 / 16 sectors that are balanced to within < 10 m² even on irregular polygons.

Patrol route per sector depends on patrol type:

  • Perimeter — each sector flies the arc of the original outer boundary that falls inside that sector. Internal cut lines are partition artefacts, never patrolled. SectorPlanner.extractSectorArc() walks the outer boundary, filters to points inside each sector's sub-polygon, and stitches wrap-around; each sector’s sub-fleet flies one connected arc of the outer edge. Four drones airborne on Jersey’s 61 km coastline means each covers a ~15 km arc with a revisit interval of about 43 minutes — vs. 170+ minutes if a single fleet tried to lap the whole loop.
  • Area — each sector's sub-polygon is first inset inward by 15 m, then a lawnmower grid is generated inside the inset. The 30 m unpatrolled strip between adjacent sectors is the safety buffer: no two drones from different sectors can ever fly over the same ground, so there's no collision path on a shared boundary.

Safety: no mid-air collisions, by design

A fleet of 100 drones sharing a base and cross-crossing each other’s transit corridors is a collision problem waiting to happen. Overwatch defends in depth:

  1. Intra-sector altitude stagger (5 m). Drones within a sector fly at slightly different altitudes; handoff points never share vertical airspace.
  2. Per-sector transit bands (5 m per sector). Sector N’s returning drones climb to base + 10m + N×5m. Cross-sector return corridors through the shared base are vertically deconflicted by allocation.
  3. Takeoff stagger (5 sim-s). Sector 0’s first drone launches at elapsed = 0; sector 1 at +5s; sector 2 at +10s. Adjacent bay pads don’t clear the ground simultaneously.
  4. Runtime proximity sweep every 200 ms. The orchestrator scans all airborne drones every tick. Any pair within 20 m horizontally and 4 m vertically triggers the lower-priority drone (priority: patrol > returning > dispatched > standby) to climb 6 m. Backstop for anything the pre-allocated bands miss.

Collision avoidance is a core orchestration feature, not a side-effect. Read the deep dive.

SAR mode: the parallel-search suggestion

Single-drone SAR (Fleet Size = 1) stays single-drone. But when an operator draws a search polygon that’s clearly too big for one drone to cover quickly, a non-blocking blue info banner appears next to the Run Demo button: “Large search area ( ≈30 km perimeter). With 12 drones, Overwatch would split this into 4 parallel sub-searches, cutting time-to-complete by ≈4×.” The banner includes a one-click Set Fleet to 12 button.

It’s a suggestion, not a wall. A coastguard SAR team that has three spare drones on the shelf shouldn’t have to know the sector math to benefit from them — the system tells them and lets them decide. The same recursive-bisection partitioner that powers Fleet Patrol kicks in behind the scenes; four drones, one per quadrant, complete the boustrophedon grid search in roughly one-quarter the time one drone would.

This is the quiet value of sectorisation for SAR: the difference between “we found the person in 45 minutes” and “we found the person in 12.” Same drones, same detection pipeline, same ground station — just the area divided, searched in parallel, and reported up once.

What changes when an AOI gets big

Overwatch's original fleet patrol assumes the operator draws one shape and all available drones relay along it. That's the right tool when the route's round-trip flight time fits inside a single drone's endurance. Set Fleet Size to 7 on ANAFI XLR, draw a 20 km coastline perimeter: each drone laps the route in ~55 min, returns to base when battery hits the swap threshold, a standby pre-launches and takes over at the handoff waypoint. 7 drones is the continuous-coverage floor for XLR (see the planner's fleet-sufficiency banner); with fewer, coverage gaps appear during charge cycles.

Now draw an AOI that is 40 km across. A single drone can't cover its perimeter in one cycle. Relay overlap stops mattering because the active drone never makes it back to the segment the last drone left. Loop closure fails. You need more drones, sure — but adding drones to the same long route doesn't help if each drone's useful patrol time is less than one lap. You need to partition.

Recursive bisection, AOI-agnostic

Set Sectors to 4 and Overwatch partitions the drawn polygon. The partitioner is unaware of its input — no templates, no named places. It takes whatever convex-ish shape the operator drew and cuts it using repeated bisection:

  1. Find the largest remaining piece.
  2. Compute its bounding box. If the box is wider (east—west) than it is tall, cut vertically through the centroid; otherwise cut horizontally.
  3. Clip the polygon against the cut line on each side using Sutherland–Hodgman. Two sub-polygons come out.
  4. Repeat until the target sector count is reached.

For 2 / 4 / 8 / 16 sectors the partition is balanced by construction (each cut bisects an equal-area piece along its long axis). For other counts the algorithm still works — it just always splits the largest current piece, so the result is near-balanced.

Because the math is entirely local to the polygon's own coordinates, the same code produces sensible sectors for a 5 km² harbour, a 400 km² island, or a 4,000 km² stretch of ocean. There is no hard-coded location, no minimum or maximum size, no "shape library" to curate. Whatever the operator draws, the partition adapts.

One tick loop, N relays

Under the covers, Overwatch's orchestrator was already a 200 ms tick loop driving handoff state machines. For sectors we extended that loop to hold N sector state blocks, each with its own current patrol route, dispatched-standby, coverage-gap state, and initial-launch flag. Every tick does the global work once — weather, GPS, battery physics — then iterates the sectors and runs the per-sector relay logic independently.

Two consequences of doing it in one tick loop rather than spinning up N orchestrators:

  • Shared state stays shared. Wind is a property of the sky, not of a sector. A weather abort fires once and takes every sector's active drone home simultaneously. GPS dropout applies to every drone in range of the disturbance. Elapsed time is one clock.
  • Per-sector state stays isolated. A handoff in Sector 2 is invisible to Sectors 1, 3, and 4. A coverage gap in Sector 3 (no standby ready, sub-fleet cycling through charge) doesn't trigger a global warning — just a scoped "Sector 3: sub-fleet cycling" alert. Each sector's relay is as independent as the physical drones that fly it.

Fleet assignment and altitude bands

Given fleetSize = 8 drones and sectorCount = 4, the planner assigns 2 drones per sector. Anything divides cleanly enough — if you ask for 3 sectors with a fleet of 10, you get [4, 3, 3]. If fleet size is smaller than sector count (e.g. 3 drones across 4 sectors), the recommender returns a lower sector count that the fleet can actually populate — a sector with zero drones is a gap, not a sector.

Inside each sub-fleet, intra-sector altitude stagger works as before: 5 m between drones so handoff points never share airspace in the vertical. Across sectors, we add an extra layer: each sector gets its own transit-altitude band. Sector N's returning drones climb to base + 10 m + N × 5 m. Patrol altitudes stay the same across sectors (the patrol zones don't overlap in XY, so they don't need to), but the transit corridors do overlap — every returning drone heads back to the same shared base — so the bands separate them in Z. A Sector 3 drone transiting home flies 15 m above a Sector 0 drone doing the same thing.

That's the whole deconfliction story for single-base sector patrol. Bays, base, batteries, operator UI — all unchanged. The FleetManager's bay ring already scales to 16 pads. The Safety Gate still checks every advisor decision. Pre-Flight Health still gates launch drone-by-drone. Nothing about the sector layer changes the shape of a responsible deployment.

What it looks like

In the mission planner: draw your AOI polygon. The Sectors panel — below Altitude Separation — shows an Auto card with the recommended count. Vocabulary follows patrol type: “4 arcs × 2 drones each” for a perimeter patrol, “4 sectors × 2 drones each” for an area patrol. Colour-coded card: orange (optimal), amber (discontinuous — gaps during charge cycles, card explains the fleet size needed for continuous), red (AOI too big for this fleet).

Hit Run Demo. Drones launch in staggered pairs — 5 sim-seconds between sectors so adjacent bays don't clear the ground simultaneously. Timeline clock reads 24HR PATROL SIMULATION — 4 SECTORS. Each sector's active drone at its own patrol altitude; transit corridors banded per sector (40 m / 45 m / 50 m / 55 m for a 4-sector fleet). Fleet-card altitude readouts show the live state: "ALT 28 m · patrol", "ALT 45 m · transit", "ALT 0 m · ground".

The operator panels don't duplicate. One fleet card grid shows all drones. One timeline shows all relay events, tagged with sector index. One alert stream. No mode toggle, no "sector view" — just more drones handling more ground under the same UI.

What this unlocks

The obvious answer: coverage of patrol areas that didn't fit inside a single relay. A 100 km stretch of coastline. An entire small island. A border strip. Anywhere one drone's flight time is much less than one lap of the AOI, sector partitioning makes the math work again — you trade "bigger fleet" for "more independent sub-fleets" and cover an area that scales with sector count.

The less-obvious answer: sectorisation is how a large fleet gets useful. Adding drones to a single route hits diminishing returns fast (three drones relay cleanly; six on the same route spend most of their time either in transit or standby). Four sectors with two drones each gets every drone in the air more of the time, because each sub-fleet is sized exactly for its own patrol’s duty cycle. Fleet size and sector count are two independent dials the operator can balance to match the operation.

What's not here yet

Multi-base. One base for now. Every sector's drones take off, charge, and land at the same bay cluster. That caps practical AOI at roughly 2× drone one-way range — Malta-scale is comfortable, coastguard-zone Adriatic is not. Distributed bases with per-base charger pools and inter-base deconfliction corridors are a Phase 2 feature; they bring logistics problems (which sector's base is fogged in, which sub-fleet draws from which charger rack) that deserve their own design pass with real operator input. See the backlog entry under "Sector Planner — Multi-Base Deployment."

Per-sector stats in the UI. Aggregate patrol stats (total route length, longest sector's flight time) ship today. Per-sector breakdowns — "Sector 3: 8 km perimeter, 28 min flight time, 2 relays scheduled" — are a planned polish pass.

Non-polygon sectorisation. Sector partitioning today requires a polygon AOI (drawn perimeter or area-search polygon). Linear patrols — a polyline along a coastline, say — fall through to single-sector relay. Partitioning a 1D path into length-slices is a simple extension but wasn’t blocked on anything for v1.

Try it

Launch the Simulator →

Set Patrol Type to Perimeter and draw a rough rectangle around any island or coastline. Set Number of Drones to 8. Click Run Demo. The Sectors panel will show “4 arcs × 2 drones each” before you even think about it — four sub-fleets patrol different arcs of the outer boundary in parallel. Drop fleet size to 4 and watch the card go amber: “4 arcs × 1 drone each — expect coverage gaps.” Switch Patrol Type to Area and the card relabels to “sectors” and each sub-fleet now runs a lawnmower grid inside its inset sub-polygon instead of along the outline. Same simple workflow, different coverage semantics.

For SAR, set Number of Drones to 1 and draw a larger search area. The blue suggestion banner appears next to Run Demo. One click to accept, one click to ignore — you decide whether to parallelise or run single-drone.