Home        Store        Learn        Blog

Leak Detector + Bar30 Firmware Pixhawk4

Hi,

I have been trying to get the leak detector and bar30 sensor working on my sub with a pixhawk4. I found this thread Baro30 Pressure sensor and Pixhawk4 which suggested that the Bar30 would not work with 4.0.X firmware but the issue was fixed on the dev build. After updating to the developer build, the Bar30 works, but the leak detector no longer works. Has anyone encountered this issue? Is there a fix or a config issue with the master that could change the way the leak detector connects? The leak detector will work with 4.0.X, but the Bar30 will not.

Thanks

Hi @manipogo, welcome to the forum! :slight_smile:

That thread discusses incorrect sensor readings which were fixed by reducing the reading frequency. I believe you intended to link to this thread which mentions that the selected I2C bus is hardcoded on ArduSub 4.0.X.

I take it that by “no longer works” here you mean “isn’t detected”? The leak detector is detected on a Pixhawk GPIO pin, so is unrelated to I2C. Before assuming this is a bug, my best guess is that this is a port assignment issue. On my standard setup (Pixhawk 1) the leak detector is plugged into AUX port 6, and that’s also what’s set by default in ArduSub (at least for Pixhawk 1).

It’s possible that the development build changes the default for Pixhawk 4 to be the last port or something (e.g. AUX port 8), so I’d recommend you check which port your leak detector is plugged into and make sure that it’s set correctly in ArduSub for the port in use. You can check and change it using QGC:

Yes, I linked to the wrong thread regarding the Bar 30. Sorry. It only currently works on the dev build.

I have the leak detector on Aux6 and the brd_pwm_count set to 4. This is pin 14 on the pixhawk4. It would not detect for me when connected to any of the ADC pins so using the Aux was the only option. Works fine in 4.0.X.

When I upgrade the the firmware to the dev build (in order to get the Bar30 working) the leak detector will no longer detect - with the exact same configuration. On the dev build I’ve confirmed that Aux6 is selected (value = 55) and the brd_pwm_count is set to 4.

Does the leak detector work with the Pixhawk 1 on the dev firmware? Does 4.2 change the way leak detector works or the aux pins are read? It’s getting power and sending the correct signal.

Hi,

I’m not familiar with the Pixhawk 4, but I just tested the leak detection in 4.2 and it works fine on a Pixhawk 1. I believe @jwalser has done some tests with it, maybe he can help.

About the Bar30, I suspect this is the relevant change: ardupilot/system.cpp at master · ArduPilot/ardupilot · GitHub
Have you tried setting GND_EXT_BUS to 0 in older firmware?

Edit: I missed the “2” in there. These changes are actually for the Pixhawk 2.

Upon further investigation, it looks like the Pixhawk4 is not handled here:

Pixhawk 4 is an FMUV5, so that explains why the leak detection doesn’t work.

Oh cool, thanks for finding this!

Seeing as how the pinouts are the same as the Pixhawk1, would it be sufficient to replace line 73 with:

#if (CONFIG_HAL_BOARD_SUBTYPE == HAL_BOARD_SUBTYPE_CHIBIOS_FMUV3 || CONFIG_HAL_BOARD_SUBTYPE == HAL_BOARD_SUBTYPE_CHIBIOS_FMUV5)

Quick follow-up. I forked the project, made that change to master and uploaded the custom firmware build to my Pixhawk 4. Works perfectly! Thank for pointing me in the right direction.

Are you guys involved in maintaining the Ardusub master? Just wondering if I should propose the change or if that’s something you will do.

Thanks again.

Our software team is in charge of ArduSub, which is a part of the ArduPilot project repository. AP_LeakDetector is a library in ArduPilot, so can be used by any of the vehicle types, but at this point I believe it’s only used by ArduSub (it’s possible ArduRover may use it for boat functionality, but not sure).

If you’ve got working code that adds or improves a feature without negatively impacting other components then you’re very welcome to submit a Pull Request. In this case you’re just enabling an existing sensor to integrate with another type of autopilot board, so hard to imagine there are any likely downsides from that :slight_smile:

If you’re not keen to do that then let us know and one of us will submit one instead.

1 Like

I’ll leave it to you guys. Thanks.

To anyone interested in tracking this, the pull request is here: