BlueOS on One Pi, ArduPilot on Another: How the ROV Companion Computer Architecture Works
The short answer
Yes, BlueOS on one Raspberry Pi and ArduPilot on a second Pi is a real configuration. Connect them, point BlueOS at the autopilot connection, open Cockpit from your topside computer, and the stack works. That said, understanding what each piece actually does will probably change how you want to build this — there are simpler paths depending on your goals.
How BlueOS fits into the picture
BlueOS is Blue Robotics’ open-source companion computer software. It runs on a Raspberry Pi (3, 4, or 5) inside the vehicle and handles camera streaming, MAVLink routing, web-based configuration, and extension management. Cockpit — the browser-based ground control station — connects to BlueOS over your tether network from the surface.
BlueOS is not the autopilot. It’s the layer that sits between the autopilot and your topside operator.
The autopilot — ArduSub, for underwater vehicles — is the firmware that actually drives the thrusters: stabilization, depth hold, motor mixing, and flight modes. In a standard BlueROV2 build, ArduSub runs on a Pixhawk flight controller connected to the companion Pi over USB serial, communicating via MAVLink. So the “two computers” concept is already baked into the conventional architecture. The only question is whether the second computer is a dedicated flight controller or another Pi.
Running ArduPilot on a Raspberry Pi
ArduPilot has a maintained Linux port, and ArduSub runs as a userspace process directly on a Pi. It’s not a hack — it’s a documented build target.
The practical caveat: a general-purpose Linux system doesn’t give ArduPilot the same real-time guarantees as a dedicated microcontroller. The OS can preempt sensor loops and motor timing. For a slow-moving ROV this is usually acceptable. It’s more of a concern for fast or dynamic vehicles where milliseconds matter.
How to connect two Pis
Both boards communicate using MAVLink — the same protocol BlueOS uses to talk to a Pixhawk. Three practical options:
- USB serial: The simplest path. A USB cable or USB-to-serial adapter between the boards. BlueOS scans for autopilot connections over USB and should detect the ArduSub Pi automatically at startup.
- UART via GPIO: Wire the TX/RX pins between the two Pi GPIO headers directly. You’d configure BlueOS to look on the right serial device (e.g.
/dev/ttyAMA0). Note that non-USB serial autopilot support in BlueOS has been an evolving area — check the current docs before designing a build around it. - UDP over a shared network: Both Pis on the same local Ethernet, routing MAVLink over UDP. More flexible, but requires manually configuring the ArduPilot startup flags on the second Pi.
USB serial is the path of least resistance for a first build. It’s what BlueOS expects by default.
A simpler alternative: the Navigator HAT
Blue Robotics makes the Navigator flight controller — a HAT that plugs directly into a Raspberry Pi 4’s GPIO header. It provides the sensors (IMU, barometer, dual magnetometers) and PWM output hardware that ArduPilot needs. ArduSub runs as a process on that same Pi, accessing the Navigator’s hardware through Linux drivers. BlueOS also runs on the same Pi and routes MAVLink between ArduSub and Cockpit over a local socket.
One board. No serial cable between two enclosures. No second Pi to power and waterproof. If you’re starting from scratch and want the full ArduSub feature set, this is the most compact and well-documented setup Blue Robotics offers — the Navigator ships with a 16 GB SD card preloaded with BlueOS.
What if you don’t want ArduPilot at all?
BlueOS has an “Other vehicle” option in its first-run setup wizard. In this mode it starts without expecting an autopilot underneath. You still get the web UI, video streaming, and Cockpit connectivity — but none of the ArduSub flight modes, depth hold, or autopilot telemetry.
If your current Python script already handles your thruster control, this might be appealing. The supported way to keep custom code running alongside BlueOS is through extensions — Docker containers managed by the BlueOS Extensions Manager. Your motor control logic would become a BlueOS extension: it starts automatically when the vehicle powers on, optionally gets its own browser-facing UI, and runs alongside everything else BlueOS provides.
That’s more work than a bare Python script on a plain Pi. But you’d gain BlueOS’s camera pipeline and Cockpit integration without handing vehicle control to ArduPilot.
Which path fits a basic ROV?
Two Pis add hardware — two boards to power, house, and connect. A few cleaner options to consider first:
- Want proper autopilot features (depth hold, stabilization)? Add a Navigator HAT to your existing Pi and run BlueOS on it. One board, full ArduSub stack.
- Want Cockpit and streaming but keep your own control logic? Run BlueOS in “Other vehicle” mode and move your Python code to a BlueOS extension.
- Already have two Pis and want to use both? Connect them via USB serial. BlueOS will treat the second Pi running ArduSub the same as it treats a Pixhawk.
Sources