ICAR 2023 · SDU UAS Center

Decentralizedmulti-UAVtask allocation

Trajectory tasks, consensus instead of a coordinator, and what decentralization actually costs you.

Kasper Rømer GrøntvedUlrik Pagh Schultz Anders Lyhne Christensen
Open with the field-trial framing: the algorithm has to survive a day outdoors with intermittent radio, not just a benchmark run.
Part one

The operation, not the benchmark

What a wilderness search actually demands of a planner.

Motivation

Why multiple UAVs at all

Search and rescue is a race against a survival curve. Coverage rate is the whole game.

  • Parallel coverage. A search area is covered faster when several UAVs fly it at once — that is the entire premise, and it holds.
  • Terrain bias matters. Lost people are found near ditches, tree lines and water edges, not uniformly across a polygon.
  • The operator is one person. Whatever the system needs, it cannot need a second specialist on the ground.

The constraint that shapes everything

Radio links between UAVs drop. Ground stations lose sight. Aircraft abort mid-mission and come home on low battery.

A planner that assumes a reliable central coordinator is a planner that assumes the easy case.

Decentralized multi-UAV task allocation
This is the slide that justifies the rest. If they accept the comms constraint, they accept the approach.
State of the field

Coverage planning is mostly centralized

The results are strong. The deployment assumptions are optimistic.

1

Single point of failure

Lose the coordinator and the fleet has no plan and no way to make one.

2

Replanning is a round trip

Every change of circumstance has to travel to the centre and back before anyone acts.

3

Scaling is the coordinator's problem

Adding UAVs adds load and latency exactly where you can least afford it.

Decentralized multi-UAV task allocation
Be fair to the centralized literature here — the point is deployment context, not that the algorithms are bad.
Part two

Tasks with a direction

One change to the task model does most of the work.

The task model

Trajectories, not points

A task is a path between two points — and which end you start from is part of what the allocator decides.

Point tasks compared with directed trajectory tasks
Decentralized multi-UAV task allocation
Point at the right panel: the arrows are the contribution. Direction changes the cost of chaining two tasks together, so it belongs inside the allocation, not after it.
The algorithm

Generalizing CBBA

The consensus-based bundle algorithm, extended so a bid covers a directed trajectory.

  • Bundle construction. Each UAV greedily builds a bundle of tasks it thinks it can serve cheaply, scoring both traversal directions.
  • Consensus. Neighbours exchange bids and winning-bid timestamps; conflicts resolve locally, with no coordinator in the loop.
  • Convergence. The fleet settles on a conflict-free allocation, and any UAV can leave or join and trigger a re-bid.

What stays the same

CBBA's convergence guarantees and its communication pattern.

What changes

The scoring function, which now optimizes traversal direction as it bids.

Decentralized multi-UAV task allocation
Do not walk through the pseudocode. The audience needs the shape: bid, share, resolve, repeat.
Part three

What it costs

Decentralization is a trade. Here is the bill.

Evaluation

Results on benchmark problems

Simulation experiments against a state-of-the-art centralized coverage planner.

1.9%

Overhead vs centralized

Time to completion is essentially the same as the centralized planner — for that overhead cost.

benchmark problems
6%

Better than point allocation

Optimizing traversal direction beats treating the same coverage tasks as points.

same task set

Scales with fleet size

Performance holds as UAVs are added to the search effort — no coordinator to saturate.

the reason to bother
Decentralized multi-UAV task allocation
The honest headline: you give up 1.9% and you buy out the single point of failure. Let that trade sit for a beat before moving on.
Wrapping up

Three things to take away

1 · Model the task properly

Direction was free information sitting outside the allocator. Moving it inside was worth 6%.

2 · Decentralization is cheap here

1.9% overhead against a centralized planner, and no coordinator to lose in the field.

3 · Field constraints come first

The comms assumption decides the architecture. Everything else follows from it.

Code & paper

github.com/kasperg3/trajallocpy
ICAR 2023, IEEE
grontved.xyz/publications.html

Stop here. Questions usually go to comms range or to how tasks are generated in the first place — that is the TrajGenPy talk.