BlueROV2 is four control layers sharing one tether

An expedition crew prepares a BlueROV2 fitted with MURAKUMO, an independent multi-camera photogrammetry payload, for work around Attu. The extra frame makes the stack's central virtue physical: new mission equipment can ride beside the vehicle rather than becoming the vehicle-control loop.[9]

A pilot nudges a joystick on a boat. Before the BlueROV2 moves, that intent has crossed a surface application, an Ethernet tether, a companion computer, a message router, a serial link, and an autopilot. The returning view takes another route: camera frames pass through video services and back up the tether while vehicle telemetry travels as structured messages.

That is why “open-source underwater robot” is less useful than it first sounds. BlueROV2 is not a single open brain inside a blue frame. It is a set of replaceable layers with different clocks, failure modes, and jobs. Cockpit or QGroundControl faces the operator. MAVLink gives commands and telemetry a shared vocabulary. BlueOS mediates onboard services. ArduSub remains close to sensors, motor outputs, and vehicle state.[1][4][7]

This ecosystem map follows those boundaries rather than treating openness as a feature badge. The practical question is not merely whether a team can modify the stack. It is where a modification belongs—and which layer must still work when that modification fails.

Follow one command, then one camera frame

The command path can be reduced to one line:

joystick → Cockpit or QGroundControl → tether/IP → BlueOS MAVLink endpoint → flight-controller link → ArduSub → motor mixer → ESCs and thrusters

The image path is different:

camera → BlueOS camera manager → WebRTC, RTSP, or UDP stream → surface display or recorder

ArduPilot’s own documentation draws the central division. The autopilot handles basic vehicle control and mission execution; a companion computer manages cameras and sophisticated peripherals, then communicates with the autopilot using MAVLink, often over a UART.[1] BlueOS implements that companion role. Its documentation describes a system running on an onboard computer between the flight controller, the operator, and sensors that do not directly measure control state.[4]

Keeping the paths separate improves diagnosis. A pilot can have healthy telemetry and a dead video stream. A recorder can fail while depth hold continues. A MAVLink route can break even though the camera is still producing frames. “The tether is up” is therefore not a sufficient health check; the command, telemetry, and video paths each need their own evidence.

Cockpit owns the operating picture, not stabilization

Cockpit turns a pile of signals into a pilot’s workspace. Its default ROV profiles include video or HUD views, telemetry, attitude and compass instruments, status messages, flight-mode controls, and a map view for positioned vehicles. When it discovers a BlueOS vehicle, it connects to the MAVLink2REST service for vehicle data and to a WebRTC signalling server for video.[7]

Those interfaces make Cockpit an operational surface, not the underwater control loop. Moving a widget, remapping a joystick button, or changing a view alters how intent is expressed and evidence is presented. It does not move attitude estimation or thruster control into the laptop.

QGroundControl still occupies a neighboring lane. Cockpit’s documentation says that it does not currently provide vehicle configuration or calibration and recommends doing that work through BlueOS and/or another control station such as QGroundControl.[7] This is an instructive kind of interoperability: two open clients can share a protocol without being interchangeable in every workflow. A team switching between them must recheck joystick axes, shifted button functions, flight-mode selection, stream discovery, warnings, and calibration access. Protocol compatibility does not make operator configuration portable.

The surface layer also defines a clean failure question: if the display application closes, what does the vehicle do next? The answer must live in the autopilot’s configured mode and failsafes, not in hope that the browser reconnects quickly.

MAVLink owns addresses and meanings, not the mission

MAVLink is the connective tissue, but calling it a “bus” can hide important detail. A MAVLink network contains systems—vehicles and ground stations—and components such as autopilots and cameras. System and component IDs range from 1 to 255. Messages may target one component, one system, or everyone; a zero or omitted target is a broadcast. Routers learn where systems and components have appeared, then use those observations when forwarding addressed traffic.[6]

That model is what lets a control station, BlueOS service, sensor bridge, and experimental autonomy process share vehicle state without all becoming one program. It also creates configuration risk. An incorrect ID can send a command nowhere. An unintended broadcast can reach more consumers than expected. A restarted component can invalidate routing knowledge. Open wire formats make these failures inspectable; they do not remove them.

BlueOS exposes the seam directly. Its MAVLink Endpoints manager can connect serial, UDP, and TCP endpoints, while the MAVLink Inspector shows messages moving toward the surface. The system can route internal services over loopback and send an external endpoint toward a topside address. BlueOS also offers different router implementations with different forwarding and logging behavior.[5] That is not background plumbing. Router choice determines who sees which evidence during an incident.

Video reinforces the boundary. BlueOS can detect H.264 streams, expose multiple stream endpoints, repackage compatible streams as WebRTC for Cockpit, and advertise streams so QGroundControl can select them. The pixels do not become ordinary MAVLink telemetry merely because MAVLink helps describe the camera service.[5] Capacity tests must therefore exercise video load and command traffic together: a clear picture is not proof of a healthy control path, and responsive telemetry is not proof that the operator can still see.

BlueOS owns mediation and extension

The companion computer is the stack’s integration workshop. BlueOS manages firmware and parameters, MAVLink endpoints, logs, network tests, cameras, serial bridges, and supported sonar services. It can translate a Ping sonar range estimate into a MAVLink DISTANCE_SENSOR message for the autopilot while also leaving richer sensor handling to an onboard or topside application.[5]

This is the natural home for mission logic that needs Linux libraries, storage, network services, or rapid iteration: tagging video, coordinating a payload, transforming a sensor feed, or providing a custom operator page. BlueOS extensions can add that functionality without folding it into the flight-controller firmware.[4][5] The distinction protects both development speed and ownership. A photogrammetry service may decide when to capture; it should not silently become the only process capable of keeping the vehicle level.

The companion layer is not free capacity. A CPU-heavy vision extension, an overproducing logger, or several high-bitrate cameras can compete with routing and video services. A serious integration test therefore constrains the experiment: observe processor load, tether latency, packet flow, and video behavior under the worst simultaneous workload, then confirm that restarting the extension does not strand the basic control path. Modularity contains failure only when resource budgets and restart behavior are tested.

ArduSub owns vehicle state and motion

ArduSub runs where sensor readings become estimates and desired movement becomes motor output. Its mode table makes the ownership visible. MANUAL provides pilot control without stabilization. ALT_HOLD adds automatic depth control and requires a depth sensor. POSHOLD, GUIDED, and AUTO require position and depth; SURFTRAK requires a rangefinder to hold distance above the seafloor.[2]

The names are compact contracts. Selecting POSHOLD in a polished UI cannot manufacture a trustworthy underwater position estimate. Sending GUIDED commands does not waive the depth dependency. Adding a sonar to BlueOS is not complete until the measurement’s frame, timing, validity, and loss behavior reach the autopilot in a form its estimator and mode actually understand.

Failsafes belong at this layer for the same reason. ArduSub documents separate responses for lost pilot control, lost ground-station contact, battery state, leaks, internal pressure and temperature, estimator faults, crash detection, and watchdog events.[3] Those mechanisms do not guarantee recovery—an underwater vehicle has no universal “go home” behavior when position is unknown—but they give each loss a vehicle-level state transition. The surface UI should report that transition; it should not be the only place where it exists.

This is also the boundary to respect when a research controller needs more exact authority. Patrick Ng and Michael Krieg’s BlueROV2 Heavy work did not treat the stock stack as a magic abstraction. They used real tests to improve the software-in-the-loop model, replaced a manual-control allocation approach for quantitative automatic control, and placed a higher-level controller in ROS.[8] The open seams made that hybrid possible. They also exposed the validation burden: a new controller still needed hydrodynamic measurements, a better simulation, and experiments tied to the particular vehicle.

The stack is open so responsibility can stay specific

The MURAKUMO rig in the lead photograph is a useful physical analogy. Its five-to-eight cameras and strobes form an independent photogrammetry payload mounted on a BlueROV2 for an expedition around Attu. The payload can change with the research need while the vehicle remains the carrier.[9] Software extensions should aim for the same clarity.

For a small field team operating the standard vehicle, the safe path is deliberately conservative: keep stabilization and loss responses in ArduSub, use BlueOS for mediation and payload services, and make Cockpit or QGroundControl prove the complete operator workflow before launch. A lab adding autonomy can place planning or perception on the companion computer, but it then owns latency, resource isolation, simulator fidelity, and a degraded mode when that process disappears. A team changing thrust allocation has crossed into vehicle-control engineering and should test accordingly.

Four questions reveal whether the boundaries are real. If Cockpit exits, does ArduSub enter the intended state? If an extension hangs, do routing and basic telemetry remain available? Can the operator distinguish video loss from control loss? If the surface application changes, have every axis, button, warning, and mode transition been exercised in water? A “yes” based only on a bench demo is not yet an operational answer.

The value of this ecosystem is not that open code lets any feature live anywhere. It is almost the opposite. The stack gives experiments a place to attach without pretending that an interface, a message router, a companion computer, and a motor-control loop share the same safety domain. Follow one command down and one camera frame back. The route tells you where to build—and where to leave the boundary intact.

cronfeed.work