Raspberry Pi BlueROV Controller HAT

I have started a new BlueECS Controller project that will offer the ability to control/monitor 7 BlueECS thrusters, a pressure sensor, 9 axis motion tracking and power the Raspberry Pi. I have much more experience on the software side of thing and will be developing a full set of Windows IoT drivers for this controller HAT. I’m looking for any feedback you may have to offer on this design (including flaws). I have open sourced this project using Circuit Maker so feel free take a look. I have attached the schematic and board drawings if your interested.


bluerov-controller-2 (947 KB)


The biggest thing would be trace width / thickness if you had lines running a lot of current running on particular signal or LED lines. You have a lot of devices on there, such as LED’s, that can draw a certain amount of current and I see that the “power” lines to each LED is individual … which it should be since they all represent a certain indication but the common thread all over your board is GROUND.

Please remember that GROUND is not just some mystical point … power is running through that trace more so than everything else because it is your common return path for all of your chips. I would seriously add up all the power dissipation of each device on the board and make sure that whatever is going into each of those components … all added up is going to be able to go through that common trace.

That is one reason you will see people uses large unused areas of a board for a ground plane … but a lot of people still have tiny traces coming from ground plane regions to the pin leaving the board. Bad idea!

What weight copper is your board going to be?

Question time … I am looking at some of your components and have concerns or questions on how you plan on using the items.

The pressure sensor that you are using, data sheet at http://meas-spec.com/product/pressure/MS5837-30BA.aspx, is rated to 30 bar (435 psi) which raises the question or how do you plan on interfacing the sensor to “water” when it is a surface mount component? Basically, what is your game plan to allow the sensor to “sense” water pressure if you were going to use this sensor in your application?

Here is an excerpt from the data sheet:

In applications such as outdoor watches the electronics must be protected against direct water or humidity. For such applications the MS5837-30BA provides the possibility to seal with an O-ring. The O-ring shall be placed at the groove location, i.e. the small outer diameter of the metal lid. The following O-ring / housing dimensions are recommended: (I didnt’t had the chart etc. it is on the datasheet)

With that in mind … it appears that you are going to have to make a pressure proof interface that will run from the top of the sensor to outside pressure or this thing might as well be a paper weight. Now I do understand that you just have a connector for it, but I thought I would still bring up the question for someone else reading this thread. Also, I would add the decoupling capacitor on your board for the power line going to this unit as recommending in the data sheet. This will make life easier for the end user of the board.

A basic overall design comment would be to make the board as user friendly as possible. What I am refering to is such things as the decoupling capacitor that I mentioned for the pressure sensor. Anywhere that you can make it really simple stupid for someone to interface the auxillary devices hanging off this thing easy … the better your design will be in my opinion. Someone wouldn’t have to worry about doing anything with that sensor board other than soldering some wires to the surface mount pads, sealing it properly so it can sense outside pressure and they can then have a simple plug terminating their wires to plug into your board.

I know I might be nit picking, but I try to look at a product that I am designing to see what I can do to make life plug-and-play for the end user as much as possible. NEVER assume that they will ever read a data sheet in-depth etc. Murphy has a habit of running around all over the place.





Thanks for all of the feedback it is defiantly welcomed. The board currently has 0.03556mm weight copper. I see your concerns over the GROUND. I will retool the overall ground traces to make sure I’m accounting for all devices on each ground trace.

Regarding the pressure sensor I was theoretical planning on using a Bluerobotics cable penetrator and then epoxying the sensor right in to the tip of the cable penetrator. The sensor it’s self is 3.3 mm and the cable penetrator is 10mm so I should have plenty of room to properly epoxy around it. This way the pressure sensor will just be one more cable penetrator at the end of the watertight enclosure. Adding the decoupling capacitor on the circuit board directly is a great ideal. My first thought was to allow the 7th port to be a generic port that could run any type of I2C censor but I think I like your idea better.

In case your interested here is the entire BOM.







I have updated my BlueECS Controller project (see attached). I have revised the GROUND using a polyfill and also changed the 7th port to include decoupling capacitors for the pressure sensor.

I do have one question. I noticed it looks like the speed of the thrusters can be controlled with PWM or I2C using the “throttle: (write-only)” register. Is it better to use the I2C method over PWM and reserve PWM only for configuring the thruster?

bluerov (1.01 MB)


When I get a chance later today … I will check everything out and also to see what I might have had a senior moment on before! As far as the I2C method, others are going to have to chime in on that. I haven’t used that method with the thrusters yet. PWM is about the only thing I can say anything about so far.



Sorry it has been a while. Backlogged at work and finally got a chance to look at something.

I started reviewing the chips that you are using and have some concerns.

Here is an excerpt from the datasheet.
The PCA9685 is an I2C-bus controlled 16-channel LED controller optimized for Red/Green/Blue/Amber (RGBA) color backlighting applications. Each LED output has its own 12-bit resolution (4096 steps) fixed frequency individual PWM controller that operates at a programmable frequency from a typical of 24 Hz to 1526 Hz with a duty cycle that is adjustable from 0 % to 100 % to allow the LED to be set to a specific brightness value. All outputs are set to the same PWM frequency.</div>

The thing is the PWM frequency output being locked for all outputs to the same thing. Not a good thing when you are trying to control each motor individually.

Another thing is your power chip. The output current on the chip is supposedly 150mA. That is not a lot considering how much stuff you are powering on the board. I am also confused as to why you have +5V on the board when all of your stuff has +3.3V for power? Is the +5V only being generated and export off of the board?

Ok, think that is enough so far.



Thanks for your help. Yeah I don’t know what I was thinking with the power chip. I was thinking at first 150mA would be enough to power the chips and LEDs. I wasn’t thinking about the Raspberry PI required 650mA to run. I created a prototype board and it won’t even power the PI or anything else for that matter. Here is the chip I’m thinking of using it will support 1.3A.

I’m also thinking I should move the power and thrusters connections off to a junction board that can be mounted towards the back of watertight enclosure the in place of the standard power junction connection.

Regarding the PWM my plan is to use I2C to really control the thursters using the “throttle: (write-only)” register. Therefore, I would only really be using the PWM to configure the thruster and control the thurster LEDs if I’m understanding the ECS documentation correctly. If you have a PWM chip know of a chip that would allow for all 6 channels to be used on separate frequency I would love to check it out. The main reason I’m using PCA9685 is that it pretty common and it already has a lot of good code examples in C#. Cutting the development time way down. I’m also thinking of included two servo expansion headers. I can’t really think of a good use for them at this point but I have extra PWM channels and will have plenty of space on the HAT for the headers.




The chip that you are looking at requires a lot of outboard components. When selecting a voltage regulator … which is what you are hunting for … I would recommend just going with a LDO variant. I don’t know where you hunt for your chips are but I like Newark.com because their parameter search is more to my liking.

Here is a link to get to LDO, Fixed Voltage output.


Just select the different parameters that you are looking for and frankly I would concentrate on output current. If you are worried about what you are going to be using for battery voltage, then you can widen your input range but say you are using somewhere above a 11.1 V Lipo, then I wouldn’t worry about min input voltage I would just worry about the upper range.

Most, if not all, of these chips should work with just an input/output filter capacitor and you might get lucky and find the same footprint. You can select that too.

Please take a look at the chip that you have selected as a possible choice and you will see a TON of outboard components that it wants you to have. Always read the spec sheets.