BlueOS Compatible Flight Computer based on RPi Compute Module

Build Topside
,
1

I’ve been kicking around the idea of a raspberry pi compute module based autopilot board for a bit and I’d appreciate any feedback or thoughts you all might have on the idea. This would basically be a drop-in alternative to the current raspberry pi sbc + navigator autopilot hat. The design I’m working on will be open sourced as well, so if you have similar, but slightly different needs, the kicad design files will be freely available to tweak to your needs. I’m going through all this effort, so the more who can benefit the better.

If you’re not familiar, this is a compute module. Basically a tiny raspberry pi you can plug into a custom carrier: https://www.raspberrypi.com/products/compute-module-5/?variant=cm5-104032

Why am I so interested in a compute module based autopilot? The raspberry pi single board computer is a great little device, but as I’ve gone down the rabbit hole of creating my own systems, I’ve been struggling with a few core limitations. Specifically:

  1. Power: The raspberry pi SBC has always required 5V input. Depending on the platform, this can be a bit constraining as much of the marine world uses 12-24V power. Not only that, but the pi 5 in particular is a power hungry device, using a niche 5A usb PD profile. On the other hand, with a custom compute module-based carrier, I can build in a wide input regulator system and, if powered by >12V, resistive losses/heat between the BEC & FC will be reduced over half due to the drop in current needed for maximum performance.
  2. Form Factor: The desktop-grade connectors on the raspberry pi can be helpful when working at a desk, but they really constrain the overall design of the board. This is why most flight controllers swap USB/ethernet interfaces for JST-GH or similar compact connectors. Additionally, the raspberry pi foundation frequently shifts their connectors around slightly between generations. This makes upgrading an existing platform a little more complex as your USB & ethernet may need to swap internally for the new footprint. By using a compute module, the port mappings (aside from the WiFi antenna potentially) will stay the same as long as they keep using the current form factor.
  3. 2in Diameter Watertight Enclosure Compatibility: this one may be specific to me. I’ve wanted a narrower pi that can fit the smaller enclosures for a few random projects such as a scuba tank mounted ctd.

In short, I’m looking to build a more streamlined autopilot/data logging system while maintaining the software strengths of the BlueOS ecosystem. My current USV project uses a cube pilot and, while the hardware is robust for robotics projects & well supported, it lacks the flexibility of a full linux environment. A properly designed carrier board could go quite a ways to bridging that gap.

If you’re still reading and are interested, I’ve included a preliminary layout study to give a rough idea of what this would look like. While I can’t guarantee that every comment/suggestion makes it into this version, I do appreciate any thoughts you all have and it’ll be interesting to see what other folks have on their flight computer wishlist. Feel free to comment in this thread and you can also check out the design repo (with more info on potential specs) here: compactPi/README.md at main · loganrf/compactPi · GitHub

image
image1920×1072 249 KB

This isn’t my full time job, so the timeline is pretty fluid. That being said, I tentatively plan to finalize the initial design and get it prototyped through macrofab later this year (spring/summer). Once these prototypes are in-house, that’ll open up a second opportunity to help. If you’ve got an interesting application (or are willing to use your bluerov/boat as a testbed), I’d be happy to send out some of the spare prototypes for free in exchange for additional feedback/software help. After that, I may explore selling complete boards through the reef program or crowdsupply, but regardless, the design files will be available to build or modify your own!

Key Challenges:

  • Routing: I’m going to try to keep it to a 4 layer stackup (maximum compatibility with turnkey board houses like macrofab, jlpcb, etc), but this is shaping up to be a pretty dense board, so 6 layers may be needed to get this out in a reasonable time/with reasonable performance.
  • Software: I’m gratuitously copying the BR navigator board sensor selection & connections to minimize the amount of software modification necessary, but I expect the translation to the CM5/carrier board will still cause some issues.
  • Mechanical Compatibility: I still need to do a CAD export & see how this layout would fit in the current bluerov2 design. The proposed layout is 105mm long (about 20mm longer than a pi) and it’d require a custom some adaptions to the current bluerov harnessing.

Thanks in advance!

5 Likes
2

Hi @loganrf, welcome to the forum! :smiley:

Great project - I’ve been considering doing something similar pretty much since the Navigator released, but haven’t found the time for it. That said, I’ve also been tossing up between something compute-module-based vs doing a ‘lite’ barebones variant of a Navigator for use with a RPi Zero2W or similar…

Worth noting that the BMP280 is EOL, and is recommended to be replaced by the BMP390 (which the ArduPilot Navigator driver already includes support for). You’ll need to make sure you ground the SDO pin to set its I2C address to 0x76, so it can be detected properly in the existing Navigator definitions.

In a similar vein, the AK09915 is EoL, and is recommended to be replaced by the AK09918. Thankfully the existing 0x0C address option the Navigator uses for the AK09915 chip is the only possible option for the AK09918 chip, and there is already driver support for the board in ArduPilot, so I believe a working hardware setup should mean it automatically works as expected for Navigator support in BlueOS.

In case it’s relevant, this user was also working on a custom Navigator board with those sensor replacements, and I’m unsure whether they ended up resolving the issues they were having at the time.

I am unsure whether there are any bus changes a compute module requires compared to the standard board config. Outside of that (assuming you get a board with wifi support) things should hopefully be pretty normal, but I’m not sure we’ve done any testing with compute modules so it remains to be seen.

We’re at least happy to help resolve issues that arise, to the extent we’re able in the absence of hardware on hand :slight_smile:

3

Very cool project -I’m exploring a similar direction and I’d be happy to share lessons learned as you iterate. :slightly_smiling_face:

Using a Compute Module instead of a full SBC makes a lot of sense here: better mechanical robustness, smaller envelope, and fewer “loose” connectors. The only trade-off is needing a dev carrier/IO setup on the bench, which is usually manageable.

A few technical questions / considerations that might help de-risk the design:

1) Ethernet / USB bring-out (SI + harness realities)
Are you planning to expose actual Ethernet (100/1000 via PHY + magnetics to twisted pair), or an internal interface like RGMII to a remote PHY? Also, what’s the intended harness?
For 1GbE especially, small board-to-wire connectors can be fine if the full channel is controlled (impedance, return paths, common-mode, and a known harness). USB is generally more forgiving than 1GbE, but still benefits from controlled differential routing and a clean return path → lock on PC motherboard and internal USB 2.0.

2) PWM outputs
Many BR-ecosystem devices expect “Pixhawk/Navigator style” PWM, so I’m curious how you see end users wiring this up. Your approach looks space-efficient, but my only concern is average-user friendliness: if it requires custom harnesses, it might help to provide a small adapter board or a ready-made cable set as part of the kit.

3) RS-485
Personal preference: I’ve found RS-485 very practical for sensors/accessories, and CAN is great for more robust networks. Even a small header/port option could make integrations easier for a lot of users.

4) Input voltage range (system simplification)
Have you considered supporting a wider input range (up to ~48 V)? In many builds that simplifies power distribution a lot. Modern buck solutions can handle it without a big footprint penalty (e.g., FAN65004B / MP4575 depending on cost and current needs).

5) IMU/compass placement
This is always a trade-off, but providing an option for an external IMU/compass PCB can help with EMI/magnetometer performance, especially in compact enclosures with switching regulators and high-current paths nearby.

On the layer count: 4 layers still sounds feasible to me with a good stackup and careful partitioning (HS routing + power/ground integrity).

If you want a second pair of eyes on layout/SI/EMI details (Ethernet/USB routing, return paths, connector choice, harness assumptions), happy to take a look. I’m doing a similar project myself — HW is my comfort zone, while SW/integration is where I’m expecting the most learning.

4

Thanks all!

Eliot, that helps a lot actually. The software aspect is the piece most outside of my comfort zone, so knowing that there are some more modern sensors already in the system is very helpful. I’m hoping this project actually forces me to get a little more familiar with the ardupilot code base.

Marcin, appreciate the thoughts as well. I should have my kicad project on that GitHub repo this weekend once I’ve massaged a couple more details which should give a more complete picture of the proposed architecture. Also, I’m more than happy to review anything you’ve got! As a fellow hardware guy, I know good reviews are invaluable, particularly when packing in a lot of digital/analog in a small space.

Regarding your specific points:

  1. The intent is to provide a magnetically isolated ethernet port matching the pin out used on other products (5-Port Ethernet Switch for the BlueROV2 and Fathom-X). If all else fails, I’ll probably just nix the connector and users can leverage one of the USB ports for a gigabit adapter off board.

  2. If I can make more space, I’d like to provide at least a few pixhawk style ports, particularly for servos. The JST-GH doesn’t carry as much current as a pin header. Regarding ESCs, since those require only the signal and ground reference, it should be much more straightforward to build a custom harness. I also heard a rumor that blue robotics is considering a new digital interface to their ESCs and I’ve been looking into CAN bus units myself.

  3. Good note! There are some really small transceivers out there, so I’ll throw one down and see how it looks

  4. We’ll see. I need to play around with some of the newer parts to see what’s possible in the footprint I’ve got. Finding compact x7r capacitors rated for 48V can be a little tricky I’ve found. And with a potentially noisy bus, good input filtering will be important. That being said, I’m not opposed to opening up the range if I can manage it in a reasonable footprint/timeframe.

  5. Good note!

1 Like
5

Alright, a few quick updates:

  • Power architecture is basically done. As I feared, going much higher got a lot more challenging from the decoupling capacitance/isolation standpoint. On the plus side, I was able to add provisions for a redundant auto-switching DC inputs as well as 9V+ USB-C PD
  • I’ve completed initial routing of the HDMI, USB, & ethernet interfaces. @Marcin if you have some time, I’d definitely appreciate your eyes on that. Kicad files are up on GitHub or I can also generate some gerbers/odb++ if you prefer that route. I still need to work out intra-pair skew matching on the ethernet, but HDMI/USB-C should be close to final
  • I’ve gotten updated symbols/footprints in for the sensors. One wrinkle is that the suggested replacements bias toward 1.8V supplies/interfaces. I’ll be converting those signals to 3.3V via level translators, but still need to nail that down

Goals for the rest of this month are

  • Finishing up the schematic/layout draft
  • Cleaning up the schematic hierarchy and adding/updating block diagrams to the root & power pages

As always, I appreciate any input you all might have!

2 Likes
6

Hi Logan — thanks for the update on your side.

I’ll try to review the project this afternoon (CET/PL). By the end of this week I should also have more time to help with a deeper review.

Quick question: what exact PCB stackup are you planning to use? Ideally, could you share a link to the PCB manufacturer and their stackup table/spec — it’ll be key for a proper HDMI/USB/Ethernet review (impedance targets, reference planes, vias).

I’ll also look at the sensor changes. I might be able to suggest 3.3 V-friendly alternatives; and even if we stick with 1.8 V + level shifting, I’m fairly strict about keeping sensor supplies “clean” — I’d recommend a dedicated clean rail (e.g., separate LDO + filtering) for the analog side and a clear power distribution strategy. At the same time, I’d keep a continuous ground/reference plane (no split GND plane) to avoid breaking return paths.

I’m new on the Blue Robotics forum — is it typical to collaborate openly in the thread, or would you prefer moving to a private channel for detailed reviews? Either option works for me.

— Marcin

7

There’s no standard for this - depends on what the people involved prefer. Open discussion is welcomed (for commentary, and to give others insight into development processes), but it’s also understandable if sometimes things are better handled as direct messages (which you can start by clicking someone’s name in the forum, or through some other platform) or calls or the like, depending on the nature of a discussion.

8

Hi Logan,

I was working on a very similar project to you a while back, but progress stalled due to motivation and time constraints. I still have my old KiCad project if you like to check it out and I’d be interested in helping with this project.

If there’s anything you’d like help with feel free to reach out, I’d also be down to test prototypes or assemble initial PCB’s if required.

1 Like