Can BlueOS connect to two flight controllers and switch joystick control between ArduCopter and ArduSub?

Hi, I’m working on a senior design project involving a small hybrid aerial/underwater drone, and I’m trying to figure out the cleanest way to control it.

  • Our current idea is to use two flight controllers:

  • A smaller F405/H7 board running ArduCopter for four aerial motors

  • A Pixhawk running ArduSub for four reversible underwater thrusters

  • One Raspberry Pi running BlueOS

  • One CSI camera connected to the Pi

  • One Cat5e/Cat6 tether running to a topside laptop

  • One gamepad for both air and underwater control

We have access to Pixhawk 4, 5X, and 6X boards through our university inventory. What I’m hoping to do is connect both flight controllers to the same Raspberry Pi, probably through separate USB or UART connections. Each controller would have a different MAVLink system ID.

The general setup would be:

Topside laptop + gamepad

|

Ethernet tether

|

Raspberry Pi / BlueOS

| |

ArduCopter FC ArduSub Pixhawk

SYSID 1 SYSID 2

Both flight controllers could continue sending telemetry, but only the selected one would receive control commands. We would probably also use a separate hardware interlock so the aerial and underwater motor banks could never run at the same time.

My main question is whether BlueOS can maintain two autopilot connections at once and whether a custom BlueOS extension could switch or remap the joystick commands between them.

I understand ArduCopter and ArduSub interpret joystick inputs differently, so I’m assuming we may need separate mappings rather than simply forwarding the same MANUAL_CONTROL message to both.Has anyone tried something similar with two flight controllers connected to one BlueOS computer?

Would it be better to:

  • Let BlueOS connect to both serial devices and write a custom extension that routes commands?

  • Give each flight controller a separate UDP endpoint and handle the switching in a custom program?

  • Handle the switching at the topside computer instead?

  • Keep the aerial controller on normal RC and only use BlueOS for ArduSub?

Our other option is using one Pixhawk 6X with a custom ArduCopter build that switches between an aerial mixer and an underwater mixer. That would reduce hardware, but it seems like much more firmware work because we would need reversible thruster outputs, separate motor mixing, water-specific behavior, transition logic, and failsafes.

The two-controller option seems safer because ArduCopter and ArduSub would each handle the vehicle type they were designed for, while the Raspberry Pi would combine the tether, camera, telemetry, and operator interface.

Sorry if I’m misunderstanding how BlueOS handles multiple MAVLink systems. I’m mainly trying to find out whether this is a practical architecture before we start buying and configuring hardware.

Hi @Darkly, welcome to the forum :smiley:

Very cool project idea!

As I understand it the autopilot manager in BlueOS can switch between different autopilots, but doing so then reconfigures the MAVLink connections and the like, which is probably not practical for live control switching (unless it’s a rare event, and doesn’t matter if it takes a minute or so). That approach may simplify

It may be possible to have one autopilot configured as the “active” one, and then “manually” connect the other one via a serial MAVLink endpoint, though I’m unsure whether the joystick command routing to the desired system ID would “just work” or require some extra configuration or modification of the MAVLink router.

I suspect this would be easier than trying to handle it in BlueOS. Cockpit’s next beta will transition joystick axis inputs to using its data lake, so you should be able to set up a custom Action that sends MANUAL_CONTROL outputs to the other system ID when switched to, without needing updates to the interface.

You can potentially even make use of failsafe behaviour to automatically disarm the unused autopilot a few seconds after you switch to the other one.

That could also work, though may create some challenges with merging both sets of data at the topside.

Interested to see where this project goes!

Hi @Darkly -

On a purely hardware note - why a CSI camera? These aren’t particularly well supported by BlueOS, a USB webcam with h264 output may be better suited - the exploreHD is already small enough to not be to heavy for an aerial drone, and waterproof!

Thanks, this is really helpful. Handling the switch in Cockpit sounds much easier than modifying BlueOS itself.

We’ll likely use ArduSub as the primary autopilot, connect the ArduCopter FC through a separate serial MAVLink endpoint, and give them different system IDs. Then we can test switching MANUAL_CONTROL between them using the upcoming Cockpit beta. We’ll also keep normal RC available for aerial control as a fallback.

The vehicle will remain connected to the topside laptop through a physical Ethernet tether during operation. Would that simply behave as a normal wired network connection to BlueOS, or could having both autopilot MAVLink streams over the tether cause any routing issues?

Also, is there somewhere we can follow or test the upcoming Cockpit beta feature?

The CSI camera is mainly being considered because our university already has one available in inventory, so it would let us prototype the video system without adding cost right away.

That said, we’re not committed to it. We’ll definitely consider a better-supported USB H.264 camera for the final build, especially something compact and waterproof like the exploreHD, if the CSI camera gives us trouble with BlueOS.

BlueOS and its communication should be fine, but I’m unsure whether there’d be any issues with MAVLink routing for the non-primary system ID, e.g. if there’s ID-based filtering that’s applied or something. We should be able to help resolve that kind of issue if it occurs though.

Beta releases are available in the GitHub releases page.

The “axes in the data lake” feature was added in #2476, and was released in v1.19.0-beta.7 a couple of hours ago :slight_smile:

Noting that support for the original Raspberry Pi camera should work ok with the “legacy cameras” option in the Video Streams page, but more recent ones are currently non-functional. That said, there is ongoing work to add support for libcamera which should enable all the CSI cameras that Raspberry Pi boards normally support.