Ping 1d depth value

In BR environnent, I understand that Ping1D value can be visualized on the top side computer using Ping Viewer. Simply put, the configuration is Ping to RPI to Ping Viewer.
Ardupilot documentation also show a Ping1D connected directly to the PixHawk serial 2 port and with the good configuration (RNGFND Baud, type etc…), one can access the depth reading directly in Mission Planer.
Here: Ping sonar on Pixhawk serial 2 and mission planner

Will this also work in QGC (non blueOS upgrade)? I am sorry if it is said somewhere. I did not find a definitive answer on the forum.
I am aware that the whole waterfall data will be lost together with the possibility of tuning the ping signal with respect to the bottom response.

Thank you

Hi @Charles,

We haven’t used that option with ArduSub very much, and it’s not something we officially support, but it should work at least in theory. Note that the interfacing cable provided with the sonar has a JST-GH connector, whereas the Pixhawk uses DF13 connectors, so you’ll need your own cable.

Once it’s physically connected you’ll need to set the ArduSub parameters as relevant, making sure to restart after you’ve set SERIAL2_PROTOCOL = 9 (Rangefinder) and RNGFND1_TYPE = 23 (BlueRoboticsPing) in order to access the other rangefinder parameters.

Once everything is set up I believe it should show up in QGC’s telemetry widget via the ApmSubInfo / RangefinderDistance option, but it’s possible it shows up via DistanceSensor / RotationPitch270.

In case it’s relevant, the latest master update of BlueOS now has Ping1D MAVLink support, which can be accessed via the new “Pings” page:


The waterfall data is still accessible in Ping Viewer even if the MAVLink Distances toggle is turned on :slight_smile:

Both show the same value and this value is the same in PingViewer. Tested and approved! So I would say it is reliable in my lab.

I tried disconnecting the sonar. In this condition, the ROV show a " not ready " state and don’t want to arm. It say " Laser Based Position : Error " in the arming check.

Other than that, could the laser position start to make depth hold or stabilize mode doing weird thing?

Thank you @EliotBR as usual!

You should be able to disable the arming check in QGC’s Safety page, in the checkboxes at the bottom.

Possibly depth hold, if it’s being treated as a valid altitude source or something. I’m not sure, because I haven’t tried it, and it would depend on how your parameters are set. Stabilise should be completely unrelated. If you’re having issues with those I’d suggest you go to the Motors page, double check each thruster is connected to the correct ESC, and has the correctly assigned direction.

No problem yet. My ROV is guts out at the moment. So I just ask before going to the field for testing. If I loss the Depth hold function and there is nothing I can do about it, then connecting the sonar directly on the pixhawk is not a solution for my application.
When I saw the “laser error”, I realized it could be used (expected by the autopilot) at some point.