@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.
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.
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?
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?
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.