Alternative use leak port Navigator

Blue Robotics Software
1

Hello,

I would like to use one of the ports to detect leaks on the Navigator for another purpose. Questions:

- There are two LEAK ports, J19/J20, for connecting sensors/sponges. Do they operate on different channels? In other words, is it possible to know which port is activated if water is detected?

- There is a port labeled AUX LEAK/J11 (-/+/S). Is this port for connecting the old SOS LEAK SENSOR? Is this signal independent of the other LEAK ports, J19/J20?

My intention is to use one of these ports to detect a BMS failure in a surface refueling system on an ROV that will operate permanently submerged and will be remotely controlled via 4G/5G.

It has a safety system such that if the battery voltage exceeds 16.8V, a relay close a circuit (my intention is to use “LEAK”).

This way, if the voltage rises above 16.8V, I would receive a notification that the BMS has failed, requiring inspection or replacement.

I would like to use one of the J11/J19/J20 ports for this purpose. I would also like to change the “LEAK DETECTED” alarm in BlueOS to “BMS FAIL” only on the port being used.

Is this possible?

Thanks in advance.

2

Hi @Andres,

From the schematic (available on the product page):

all 3 ports end up at the same LEAK_SIGNAL trace, so there’s just one combined electrical signal for leak detection.

If you happen to not be using the PWM0 port it may be possible to monitor that with a Lua script for the failsafe behaviour you want.

Otherwise if you have an unused Serial port it may be possible to stop the autopilot from using it, configure and monitor one of the relevant Raspberry Pi pins via a BlueOS Extension, and send MAVLink messages to report / act on the status as relevant.

1 Like
3

Hi @EliotBR

Thank you very much for your help and guidance, I really appreciate it.

After testing different approaches, we found that PWM0 in our setup appears to be effectively tied to ground (always reading low), and we couldn’t get a reliable or usable behavior from it as an input, so we decided not to continue down that path.

Instead, we moved to a different approach based on MAVLink through MAVLink2Rest in BlueOS. We are now reading the battery data (BATTERY_STATUS) directly from the system and applying our own logic in a Python script on the onboard Raspberry Pi.

This allows us to:

Detect overvoltage conditions with good precision (after calibrating the battery readings)

Filter transient spikes and avoid false positives

Trigger alerts reliably without modifying the hardware

Our plan is to use this MAVLink-based approach not only for battery monitoring, but also to extend it to other events such as leak detection and temperature.

When a fault is detected (battery, leak, or over-temperature), we will:

Send a MAVLink message to display a warning in Cockpit

Send an email notification

Trigger a persistent OSD warning on the camera until the issue is resolved

This way, we keep the hardware design clean and rely on software for monitoring and notification, while still maintaining hardware protection (BMS + external relay) as a safety layer.

Thanks again for your help, it really helped us explore the options and reach a solution that fits our system very well.

Regards

1 Like
4

Hi @Andres -

It’s worth noting that while Raspberry Pi GPIO can be used for input, this is only a digital input! If you need to be measure battery voltage, you’d need an analog input - that functionality is provided by a dedicated chip on the Navigator, which is how the battery voltage makes it to the autopilot.

I’m glad the MAVLink solution is working for you, that does seem more elegant!

Are you calibrating the battery readings with this extension? It was originally intended for the BlueBoat / ArduRover, but should work with ArduSub…

1 Like
5

Hi @tony-white

Thanks for sharing the battery management reference — it’s a very interesting approach.

In our case, just to clarify, we were not trying to measure battery voltage directly. The idea was to use the signal from our battery protection relay (triggered during an overvoltage condition) to generate a digital input by switching GND to signal. However, in our setup PWM0 appears to be permanently tied to ground, so this approach didn’t work reliably.

We’ve now moved to a MAVLink-based solution using MAVLink2Rest, reading BATTERY_STATUS and applying our own logic on the onboard Raspberry Pi. This allows us to detect events and trigger notifications without modifying the hardware.

Best regards,