22 / THREE DRONES · REACTIVE EXECUTION · TASK RECOVERY
One drone retires.
The mission continues.
Three real ArduPilot SITL processes visit six supplied points. A central coordinator uses nearest-pair greedy assignment and one reactive Behavior Tree per vehicle. Withdraw A1 during its second task, then follow the unfinished work through cancellation, landing confirmation and reassignment.
Predict: should A2 take over as soon as A1 receives a LAND request, or only after A1 is observed landed and disarmed? Which event proves the six-task mission has finished?
Nearest-pair greedy + reactive Behavior Trees.
Know the methods ↗- Allocation algorithm / variant
- Repeated nearest-pair greedy
Choose the shortest available vehicle–task pair from fresh received positions. Reserve one task per idle vehicle. Reconsider pending work as vehicles become available.
- Execution / tree semantics
- Reactive fallback with priority withdrawal
Each tick checks retirement before normal mission work. Running task execution can be halted; an interrupted task stays reserved until landing is confirmed.
- Decision architecture / communication
- Central coordinator · three MAVLink routes
The coordinator owns the task ledger and all three trees. Three independent autopilots execute correctly addressed commands. No peer negotiation or distributed auction is implemented.
- Timing / information
- Recorded host ticks · received telemetry
One host clock orders decisions and reports. Position, speed and landing evidence come from each vehicle’s own messages. Setpoint messages have no command ACK.
Fidelity boundary: actual flight in three independent built-in SITL worlds, registered into one supplied ENU layout. The yard illustrates the estimates; no inter-vehicle collision physics, ORCA, shared localization or radio loss is modeled. Retirement is a controlled request, not a detected crash.
ALLOCATE → EXECUTE → WITHDRAW → RELEASE → REASSIGN
Follow the work through the handover.
THREE CONCURRENT ARDUPILOT SITL PROCESSESValidating task ownership and recorded execution…
Actual recorded runs. Playback observes their evidence; this page sends no flight commands.
Preparing aircraft0 / 3 landings confirmed
● A1 / SYS 1● A2 / SYS 2● A3 / SYS 3◇ Visit-and-hold target⊘ Reserved during retirement
Drag to orbit · scroll to zoom. Select a vehicle and follow its recorded flight.
Task ownership and execution are separate pieces of evidence.
EXCLUSIVE OWNERSHIP / THE HANDOVER RULE
A task belongs to at most one vehicle.
The coordinator releases A1’s unfinished reservation after observing fresh landing evidence.
- 1 · Withdraw
- 2 · Halt attempt
- 3 · Confirm landing
- 4 · Release task
- 5 · Assign new owner
SHARED COORDINATOR LEDGER
Six tasks, exclusive ownership.
| Target / ENU m | Owner | Status | Attempts |
|---|
Pending work is eligible; locked work is not.
Recorded allocation / task events
ACTUAL HOST EXECUTOR TICKS
A1 / reactive Behavior Tree
Only visited nodes get a status for this tick. Unticked branches provide no fresh decision.
Raw tick: visits, statuses and halted actions
PER-VEHICLE EVIDENCE
A1 / independent autopilot
Raw local position and heartbeat
Configured parameters and frame registration
REQUESTS / OBSERVED EXECUTION
A1 / command history
| Request / sent at | Destination | ACK / observation |
|---|
Inspect selected request
RECORDED MISSION EVENTS
Decisions and observations at this cursor.
Recording provenance and completion criteria
What counts as completion?
COMPLETE RECORDINGS / COMPARISON
Same six points, one controlled withdrawal.
These full-run results are visible independently of the playback cursor. Mission duration starts after all three takeoffs are confirmed; cleanup ends when all vehicles are confirmed landed. The timing difference describes these recordings, not a statistical performance claim.
| Recorded case | Tasks / attempts | Mission duration | Final landing | Handover |
|---|
KNOW THE METHODS
Allocation chooses an owner.
Execution must honor that ownership.
Nearest-pair greedy is the allocation rule.
The central coordinator measures horizontal distance from each idle vehicle’s latest fresh registered ENU position to each pending target. It chooses the minimum pair, removes that vehicle and task from the candidates, then repeats. Ties use stable vehicle/task order.
cost(vehicle, task) = √((Evehicle − Etask)² + (Nvehicle − Ntask)²)
Greedy matching is simple and inspectable; it does not optimize the complete route, balance future workloads or implement CBBA. Completed work is never assigned again. A reservation locked by retirement is excluded from candidates.
Reactive Behavior Trees organize execution.
The root reevaluates higher-priority conditions on every host tick. A withdrawal branch preempts a running visit action and issues LAND once. The vehicle’s unfinished task remains locked while it lands. Release follows confirmed on-ground and disarmed evidence; normal greedy allocation can then pick a new owner.
A tick returns Success, Failure or Running. These are executor statuses: a successful retirement branch means the vehicle retired, not that its interrupted task succeeded. The inspector shows the traversal actually recorded by the Python coordinator.
Three separate completion questions.
- Was the request admitted?Command messages can receive a COMMAND_ACK. Position setpoints have no such ACK; a sent target alone cannot establish arrival.
- Was the assigned task completed?Fresh position and speed evidence must satisfy the declared distance, speed and dwell limits during an active attempt. A canceled attempt cannot later complete its old task.
- Was landing completed?A LAND request and an accepted ACK are followed by fresh on-ground and disarmed reports. This evidence permits release of a retiring vehicle’s reservation.
The two remaining vehicles may finish their current tasks while A1 lands. They wait if only locked work remains. The handover uses a single coordinator and working links; it is not a consensus or network-partition experiment.
Replay a new local run
npm run record:recovery -- --output local/ardupilot-recovery.json
The optional Docker runner starts three isolated ArduCopter processes per case. Import its JSON above to inspect that recording. Normal browser playback requires neither Docker nor a live autopilot.
Try these inspections
1. Select withdrawal, then jump to Task locked. Inspect A1’s tree and the task owner. A halted attempt and a retained reservation should coexist.
2. Jump to Landed → release, then Reassigned. Find the old and new owner and compare the command timestamps with the recorded task events.
3. Jump to Six tasks done. Compare the task count with landing cleanup. Then switch to 2D: all three aircraft must stay at exactly the same recorded positions.
Primary sources and scope
Colledanchise & Ögren, Behavior Trees in Robotics and AI explains tree semantics and reactivity. The bounded tree, ownership ledger and greedy policy here are explicit application choices.
ArduPilot Guided command documentation describes the flight requests. MAVLink command protocol distinguishes command acknowledgement from completed application work. See the experiment specification and measured results for the implemented assumptions.