High Current ROV Power Distribution Hub – Nexus Prototype

Hi everyone,

I’ve been working on a power distribution board for medium and larger ROVs, and I’d like to share the current concept and get some feedback from the community.

For now, the project is called Nexus — this is still a working name.

The idea came from wanting to simplify high-current power distribution inside an ROV. Instead of having multiple heavy cables, separate distribution points and additional DC/DC converters scattered around the enclosure, I wanted to integrate the main power distribution and low-voltage power into one compact module.

The current concept includes:

  • high-current battery input,

  • 8× ESC outputs, up to 32 A per channel,

  • 2× payload power outputs, up to 32 A per channel,

  • approximately 200 A design target for the main power path,

  • Hall-effect current measurement up to 200A,

  • battery voltage monitoring,

  • two separate 5 V / 6 A DC/DC power domains,

  • dedicated power for the Navigator / onboard computer,

  • a separate 5 V domain for payloads and accessories.

The two 5 V converters are intentionally separated. The idea is to keep the compute / control electronics on a separate power domain from payloads, cameras, sensors and other accessories.

Current and voltage measurements can also be passed to the Navigator, so the ROV can monitor the main power system during operation.

The high-current section is designed around solid copper busbars rather than relying only on PCB copper for the main current path. The busbars are not visible in the current renders, as they are located directly above and below the PCB.

This is still a prototype and the electrical and thermal limits have not yet been fully validated. One of the next major steps will be high-current testing at around 150–200 A, including temperature measurements of the busbars, PCB connections, terminals and current sensor.

I’ve attached a few renders of the current mechanical concept together with a simplified block diagram.

I’d be very interested to hear what you think about this approach to power distribution inside an ROV.

Is there anything important you think I’m missing, or any feature that would make this kind of module significantly more useful in a real ROV?

The goal at this stage is not to present a finished product, but to make sure I’m solving the right problem before finalizing the design.

Any criticism or suggestions are very welcome.

Hi @Marcin-

This looks really cool! I’m curious why you chose XT60 connectors for distribution - would screw terminals or lever locks make more sense and require less soldering / ESC prep?

Blue Robotics is working on something similar to this - however our new ESC plugs into the board, and each ESC has custom screw terminals to connect to the motor wires. The plug-in accommodates both power and PWM signal! The Navigator has jst-GH connectors for PWM signals 1-8, maybe that’s useful to your design? It can really clean up the wiring…

The “backplane” the R&D team has cooked up has the 8pwm inputs, 5V output via USB-C and a JST-PA connector, and the 5V power / analog signals for current/voltage monitoring. It fits nicely between the enclosure RAILS in a 4" enclosure - are you planning on mounting to RAILS or keeping this design as generic as possible?

Thanks Tony, really appreciate the feedback.

XT60 was a deliberate choice. I wanted to keep the PCB compact and make servicing as simple as possible. The idea is to terminate the ESC once and then have a plug-and-play connection, so an ESC can be disconnected or replaced quickly without touching screw terminals or reworking the power wiring.

I’m open to other connector families, but I’d like to keep the design based on pluggable high-current connectors rather than screw terminals.

For RAILS, the PCB itself will stay as universal as possible, but I’m planning a dedicated adapter for the Blue Robotics 4" RAILS system.

Your backplane approach is really interesting too. Combining power and PWM is a very clean way to reduce internal wiring. For this first version I want to keep Nexus focused on power distribution, protection and monitoring, but signal distribution is definitely something I’ll keep in mind for a future revision.

Small update after @tony-white’s feedback.

I originally planned to leave PWM signal distribution for a future revision, but after looking at the PCB again I managed to fit it into the current prototype without significantly increasing the board size 100x75mm.

Nexus now also includes buffered PWM signal distribution between the Navigator / flight controller and the ESCs.

I decided to use a buffer/repeater rather than simply routing the PWM signals across the PCB. The goal is to keep the wiring clean while also providing some isolation between the controller-side wiring and the ESC-side wiring.

Here’s the updated layout/render:

This should make Nexus much closer to a single connection point for the ESC wiring: power distribution and PWM routing on the same board.

Still very much a prototype, so feedback is welcome.

Hi @Marcin -

Very cool!

The PWM signals from the Navigator are coming from an I2C device, a PCA device. I’m a bit confused as to what your buffer accomplishes? Or if it’s necessary given the servo pwm lines are not connected directly to the Pi…

From an installation perspective, will the XT60s be pointed towards the back of an enclosure? Or generally along its long axis?

Thanks @tony-white

The XT60 connectors will be oriented along the axis of the enclosure, slightly below the centerline. This should make it easier to slide the whole assembly in and out of the tube while still providing comfortable access to the connectors and cables.

Unfortunately, with the current PCB dimensions I can’t mount it vertically with the outputs facing the rear end cap. I did consider that layout, but to make it fit I would have to give up the 5 V power section and essentially turn Nexus into a simple power splitter.

Regarding the PWM buffer — I agree that the Navigator PWM outputs are already generated by the PCA9685 rather than directly by the Raspberry Pi. The buffer is therefore not something the Navigator strictly requires; I see it more as a small additional engineering margin.

It acts as an additional buffer/repeater stage for the PWM lines, giving a clean and predictable output drive while also providing some extra protection between the Navigator-side electronics and whatever may happen on the external ESC wiring. The cost and PCB area are very small, so I see it more as cheap insurance than a strict requirement.

It would certainly work without it, but since it adds almost no cost or complexity, I prefer to keep it.