Capstone: designing a multi-robot field mission

This capstone brings the course together in the design of a complete multi-robot field mission. The scenario is invented: a three-week summer survey of a stretch of Arctic coastline near a fictional community called Tern Bay, to measure shoreline erosion, map permafrost conditions and survey nearshore water depths. The same method applies to an agricultural, mining or offshore mission. You will work through requirements, the environment, the team, energy and logistics, localization and communication, task allocation, risk, approvals and community engagement, and a verification plan. Numbers are illustrative and chosen to exercise the methods of earlier lessons; a real mission would use measured data and local knowledge.

Step 1: mission requirements

Start with what the users need, not with the robots. Suppose the users are the community's land and environment office and a university research group. They want an orthomosaic and elevation model of 12 km of coastline in a strip 600 m deep, with 5 cm ground sample distance, to compare with earlier surveys; ground-penetrating radar profiles along 40 km of transects to estimate active layer depth over permafrost; and depth soundings out to 1 km offshore along 12 km of coast. Data must be delivered within two months, the field season window is about three weeks in July and August, and the community has asked that wildlife disturbance be minimized and that local people be employed and trained.

Step 2: environment and constraints

Place the mission on lesson 1's four axes. Structure is low: tundra, gravel beaches, eroding bluffs and shallow water, with little prior high-resolution mapping. Dynamics are moderate: tides, waves, drifting ice early in the season, wildlife and changing weather. Harshness is moderate in summer, with temperatures from about 0 to 15 degrees, fog, rain, wind and abrasive sand, but soft, wet active-layer soils make ground mobility hard (lesson 2). Remoteness is high: the nearest repair facility is a flight away, cellular coverage is limited to the community, and GNSS works but with high-latitude ionospheric effects (lesson 3). Continuous summer daylight helps solar charging and allows round-the-clock operation, although crews still need rest.

Step 3: choosing the team

Match platforms to tasks, using the trade-offs of lessons 2, 6 and 7. A hybrid VTOL drone suits the large coastal mapping task. A multirotor provides detailed imaging of eroding bluffs and serves as a communication relay. A tracked ground robot with low ground pressure carries the ground-penetrating radar along transects, where soft soils rule out heavy wheeled vehicles. An uncrewed surface vehicle with a single-beam or multibeam echo sounder runs bathymetry lines, avoiding the risk and cost of crewed small-boat survey. Two of each critical robot, or one spare across the fleet, gives the redundancy lesson 1 recommended.

# Team sizing: how many working days does each platform need? (illustrative performance values)
import math
tasks = {
  "VTOL mapping (7.2 km2 at 5 cm GSD)": dict(work=7.2, rate=1.6, unit="km2", hours_per_day=8, availability=0.85),
  "Multirotor bluff detail (12 km of bluff)": dict(work=12, rate=1.5, unit="km", hours_per_day=6, availability=0.85),
  "Tracked GPR robot (40 km transects)": dict(work=40, rate=1.2, unit="km", hours_per_day=10, availability=0.80),
  "USV bathymetry (12 km x 21 lines at 50 m)": dict(work=12 * 21, rate=6.0, unit="km", hours_per_day=12, availability=0.80),
}
weather_fly, weather_sea = 0.6, 0.5   # fraction of days suitable for flying and for small-vessel work
for name, t in tasks.items():
    hours = t["work"] / t["rate"]
    days = hours / (t["hours_per_day"] * t["availability"])
    suit = weather_sea if "USV" in name else weather_fly if ("VTOL" in name or "Multirotor" in name) else 0.85
    calendar = days / suit
    print(f"{name:42s} {hours:5.1f} h of work -> {days:4.1f} working days -> {calendar:4.1f} calendar days")

VTOL mapping (7.2 km2 at 5 cm GSD)           4.5 h of work ->  0.7 working days ->  1.1 calendar days
Multirotor bluff detail (12 km of bluff)     8.0 h of work ->  1.6 working days ->  2.6 calendar days
Tracked GPR robot (40 km transects)         33.3 h of work ->  4.2 working days ->  4.9 calendar days
USV bathymetry (12 km x 21 lines at 50 m)   42.0 h of work ->  4.4 working days ->  8.7 calendar days

The bathymetry is the longest task, because many lines are needed and only half of days are expected to be calm enough for a small surface vehicle. On average a single USV needs under nine calendar days, which looks comfortable within 21, but a single unit has no backup: one failure, or a long run of rough weather, stops the bathymetry. A second USV, or a wider line spacing agreed with users, would reduce schedule risk. The mapping and GPR tasks fit comfortably, leaving margin for repeat flights after poor weather or for extra transects.

Step 4: energy, logistics and field base

A field base near the community provides charging, storage, a workshop with spares, and accommodation. Summer daylight allows solar charging, backed by a small generator for cloudy periods. Size the energy system from daily loads: drone battery charging, the ground robot's batteries, USV batteries, computing and communications. Spares should cover the most likely failures from lesson 1's reliability analysis: propellers, drone batteries, tracks and drive belts, connectors and sensors. Plan transport of the robots, batteries (subject to dangerous goods rules for lithium batteries in air freight) and fuel to the community well in advance, because northern air and sealift schedules are limited and expensive.

Step 5: localization and communication architecture

Survey accuracy requirements drive localization. An RTK base station at the field base, with its position determined by post-processing against the national reference frame (for example with a PPP service), provides corrections to the drones, ground robot and USV within radio range; the drones also record raw GNSS for post-processed kinematic correction if the link drops, and ground control points checked by the survey team validate the mapping. The USV combines RTK with an inertial unit and must correct depth soundings for tides and vessel motion. The GPR robot localizes with RTK and dead reckoning when it passes behind ridges, using lesson 3's drift analysis to set how far it may travel without a fix.

The communication architecture follows lesson 11. A LEO satellite terminal at the base provides backhaul for supervision, weather data and remote expert support. A 900 MHz telemetry network carries commands and status from all robots back to the base over several kilometers; a mesh network at 2.4 GHz carries higher-rate data when in range, with the multirotor acting as an airborne relay for the ground robot behind bluffs. Bulk data, such as tens of gigabytes of imagery per day, is offloaded when robots return to base rather than streamed. Each robot has a defined link-loss behavior: the drones return home after a timeout, the ground robot stops and waits, and the USV holds position or returns along its last safe track.

# Mission success over the season: Monte Carlo with weather, failures and spares (illustrative)
import numpy as np
rng = np.random.default_rng(2026)
days, trials = 21, 4000
def run(n_usv):
    done = 0
    for _ in range(trials):
        work_needed, work_done = 4.4, 0.0          # USV working days required
        units = n_usv
        for d in range(days):
            calm = rng.random() < 0.5
            failures = rng.binomial(units, 0.04)    # 4 % chance a unit fails on a given day
            units -= failures
            if units == 0:
                break
            if calm:
                work_done += min(units, 2) * rng.uniform(0.7, 1.0)   # partial days happen
            if work_done >= work_needed:
                done += 1; break
    return done / trials
for n in (1, 2, 3):
    print(f"{n} USV(s): probability of finishing bathymetry in {days} days = {run(n):.2f}")

1 USV(s): probability of finishing bathymetry in 21 days = 0.64
2 USV(s): probability of finishing bathymetry in 21 days = 0.91
3 USV(s): probability of finishing bathymetry in 21 days = 0.98

The simulation supports the earlier judgment: one surface vehicle gives only a moderate chance of finishing in a season where half the days are rough and units occasionally fail, while two vehicles make success likely. A third adds little. Monte Carlo analyses like this are cheap and make risk visible to funders and users; they should be updated with real weather statistics and failure rates from earlier campaigns.

Step 6: task allocation and daily operations

Each day begins with a planning meeting that reviews the weather, robot health and progress. Survey blocks, transects and bathymetry lines are divided among available robots, using optimal assignment (lesson 9) for the morning allocation and auctions to reallocate work when a robot fails or a weather window opens. Flight and vessel plans respect buffer zones around wildlife and the community. One supervisor monitors the drones and one the ground robot and USV, with a field technician for maintenance; with neglect times of tens of minutes and interactions of a few minutes, lesson 11's analysis suggests each supervisor can handle two or three robots with spare capacity for clustered events. Data is checked for quality every evening, and gaps are re-planned for the next day.

Step 7: risk assessment

A risk assessment, using the methods of ROB-450, covers people, wildlife, equipment and the mission. Hazards to people include polar bears, which require trained wildlife monitors and safety plans for anyone outside; cold water near the shore; and handling of lithium batteries and fuel. Hazards to wildlife include disturbance of nesting birds and hauled-out seals by drones and vessels; mitigations include flight altitudes and buffer distances set with biologists and the community, and avoiding sensitive areas at sensitive times. Hazards to the mission include fog and wind grounding drones, icing in early-season fog, soft ground stopping the ground robot, and loss of the USV in surf. Each hazard gets controls and an owner, and the plan includes a decision process for stopping work.

Step 8: approvals, community engagement and data governance

Field missions require approvals from several authorities, and in northern regions research is subject to licensing and community agreements. The robotics team should plan these months ahead.

In an equivalent Alaskan scenario, the team would need: permission from landowners, which may include Alaska Native corporations, tribes and state or federal land managers; permits under wildlife law, including the Marine Mammal Protection Act for activities that may disturb seals, walrus or polar bears, the Endangered Species Act where listed species are involved and the Migratory Bird Treaty Act; FAA authorizations under Part 107 and any waivers for beyond-visual-line-of-sight flights, as summarized in ROB-450; FCC-authorized radio equipment; and consultation with tribal governments. The CARE principles for Indigenous data governance (collective benefit, authority to control, responsibility, ethics) are widely used alongside open data principles. The team should agree in writing with the community how data will be owned, stored, shared and used, and how local people will be involved.

Community engagement is not a formality. Local knowledge about weather, ice, wildlife and safe travel improves the mission, and community members trained as robot operators and technicians add capacity and leave lasting skills. Data sovereignty matters because coastal and land data can affect hunting, travel, infrastructure and land claims.

Step 9: verification, validation and metrics

Before deployment, verify each robot and the whole system: bench tests of sensors and communications; a full rehearsal at a southern test site with similar terrain, including link-loss and fault scenarios; checks of mapping accuracy against surveyed control points; and testing of the data pipeline from robot to final product. During the mission, track the metrics from lesson 1: availability, interventions per day, area or line kilometers completed per day, data quality rejections, and incidents. After the mission, hold a review with the community and users, compare results with requirements, and record lessons for the next season.