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.
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.
1Single point of failure
Lose the coordinator and the fleet has no plan and no way to make one.
2Replanning is a round trip
Every change of circumstance has to travel to the centre and back before anyone acts.
3Scaling is the coordinator's problem
Adding UAVs adds load and latency exactly where you can least afford it.
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 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.
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
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.