Making a decision without a central planner
Each boat runs its own copy of the allocation app, builds a proposed route, and exchanges messages with the others until their plans agree. I implemented baseline CBBA, an asynchronous variant, and a coupled-task variant in MOOS-IvP. The algorithms come from published research; my work is the marine implementation and the experiments around it.
Baseline CBBA handles a shared pool of tasks. The asynchronous form has to cope with messages that arrive late or out of order. Coupled tasks introduce relationships such as prerequisites or work that needs another vehicle. Putting all three behind the same MOOS app let me compare their behavior inside missions.
Coordinating work between boats
I built a three-boat simulation around a detect → sample → verify sequence. Each boat must finish its part before the next can begin. These simulated tasks represent a coordinated survey workflow, where assigning routes isn’t enough: the team also needs to know when earlier work is complete. I added software that tracks task ownership, work performed at the task location, and confirmation received by teammates.
For work that needs both boats at once, I built a separate two-boat mission where they reach their task locations, exchange readiness messages, and agree on a future start time. The software checks their actual start times and whether they stay in position for the required duration. I tested both kinds of coordination with deliberately delayed, dropped, duplicated, or blocked messages to see how communication affects the work itself.
From task requirements to boat behavior
A task can specify which vehicles can perform it, when work may start, and how long it takes. My implementation uses those requirements when building and bidding on routes, so boats plan sequences of work rather than simply choosing the nearest destination. The coupled-task mode also represents prerequisites, alternative tasks, exclusions, and timing relationships between tasks.
I wrote the allocation engine in C++ and integrated it with pCBBA, a MOOS app running on each boat. The app exchanges bids with teammates and connects assigned destinations to travel and station-keeping behaviors. Position updates establish whether the boat has arrived and remained at the task long enough to complete its work. Keeping the engine separate from MOOS lets me test the allocation rules directly, then run the same code in multi-boat missions.
Communication tradeoffs
Marine robots often coordinate over constrained links, so I measured message traffic alongside mission completion. A larger 828-mission study compared the three implementations across six- and twelve-task workloads and clear, mildly impaired, and severely impaired communication.
Across the comparisons without task dependencies, my asynchronous implementation used about 86–95% less application-message data than my baseline implementation. It sent changed task records, while the baseline continued full rounds of updates. That result highlights how the choice of messaging strategy affects coordination costs. I’m using these simulations to study task allocation, vehicle movement, and communication together, from agreeing on a plan to finishing the team’s work.