Hello guys,
Is it possible to connect ping straight to the RPi or Pixhawk and have an altitude hold mode on QGC?
Is it possible to display altitude in QGC?
Also, is it possible to output a serial string with altitude along with depth, heading to a UDP for 3rd party software?
Cheers,
E.
Hi,
Regarding use with QGC + altitude hold, these functions are currently not supported, but planned for the future.
Right now it’s only possible to connect Ping in the RPi, this will start a service called pingproxy, this service will provide data to ArduSub and Ping Viewer.
Yes, future support will be provided.
Yes, to accomplish that will be necessary to get the information with pymavlink.
Hi @etienne,
The future support as an altitude hold device for the BlueROV2 and integrating with QGC Patrick has mentioned the software team is working on is one of the reasons why the Ping launched in “Beta”. 
-Adam
That’s great guys. Keep up the good work.
I will buy one on my next client order.
Cheers,
E.
Hi Adam. Will the collision avoidance function also be able to handle distance-hold off an object?
-Kieran
@UnderseaROV - That’s certainly something we’ve thought about. It would be great for inspections so that you could keep a constant distance from the target while maneuvering. We’ll be working on the terrain-following feature first and this would be an added feature some time after that.
What would really be something is holding station with video.
@rjehangir Hey,
I was wondering if there was any movement on this.
Currently we have the sub and pingviewer working fine, but we want an altitude hold mode. Looking in the ardusub code I see that there are .cpp files for it; however, I dont see an option to switch to it in QGC. Perhaps I should note that it doesn’t recognize a rangefinder and its address in the parameters was set to 0.
So could you please tell me if this is supported in piloted mode, and possibly walk me through setting it up.
Thanks for any help you can give
Hello Justin,
Unfortunately, using the ping for Altitude Hold is not currently supported.
There is some code in place but it is aimed at multicopters, so it needs some attention before we support it.
Well, we kinda need it. I guess I’ll have to figure out. Do you have any idea if this will be crazy difficult to write?
Also if I’m gonna do this i’ll need a simulated environment since physically testing this is not feasible to me. I already have SITL simulation running for other testing; however, it will not work for this since it doesn’t know where the seafloor is, and thus a sensor cannot sense distance from it. If I was to use gazebo along with the simulator would it’s 3D environment allow me to test this fully?
If that won’t work, would you give me some ideas on how to test this without physically taking the ROV2 out?
Hey, @williangalvani
after some more searching I got to this page in the documentation. According to it
Ardusub supports the use of an altimeter or range measurement input. If the range measurement is downward facing (altimeter), then the altimeter will be used to assist depth hold. When the altimeter measurement is valid, depth hold mode will automatically begin following the altimeter measurement and hold a distance above the bottom, as opposed to a distance from the surface when the pressure sensor is used.
To be clear, does this mean that depth hold mode can be used to keep it a certain distance off the bottom? If this is the case, what is altitude hold mode?
Hello Justin, take a look at the issue here. While there is some support, it needs upgrade.
To enable it, I believe changing this line of the companion should do the trick: companion/.companion.rc at master · bluerobotics/companion · GitHub
My 2 cents on this is that the beam of the Ping is too wide for auto-altitude. It is very cool with the river image it can produce but hits way too many targets close to the ROV.
That is what I have observed from my trial anyway. I would get a lot of false reading even when the accuracy was 100% because of beams/pipes etc that was close to the ROV although not “directly” underneath.
yeah actually that’s kinda the problem with it right now and why it’s been disabled. I’m looking into somehow handling this variation programatically. TBH I don’t know too much about sonars, but hopefully I can figure something out.