I’m new to the ROV world, and I’m sorry if my questions are trivial but it’s difficult to understand where to start.
I would like to use a blueROV to track the bottom of the sea and maintains a fixed atitude, and I have some questions related.
First of all, is it easy to include a new sensors in the platform? Is QGC already structured for adding different types of inputs?
The second big question regards how to control the engine to keep the distance from the bottom fixed; is it already included a modality in which the upper motors can be “self-guided” while the lateral motor are still in charge of the land pilot?
Thank you, any help would be appreciated!
I would also like to know if altitude hold using a pinger is already implemented on ardusub and how to use it
This feature is currently being worked on. It will likely be implemented as a new mode analog to depth-hold.
Has this new round of updates done anything for the ability to hold Altitude, using a Ping, instead of depth?
Maybe i missed it? Or has this already been done? Or is it on the cards?
Hi Matt and Marcus,
We’re working on adding altitude hold right now along with support for position hold with Water Linked’s new DVL. Hopefully that’ll be in the next big release
There’s an open issue here to address this feature. It should be in the next big release.
When the new release supports the DVL, will it be through UART and/or ethernet?
Is there any update on the auto altitude?
@williangalvani I am also interested in that feature. Are there any news or some code that can be used for testing already?
Hello everyone! Nearly 5 months have passed since the last post on this thread.
We are also working on a relevant project and we want to use a Cerulean DVL in order to maintain a fixed altitude with our BlueROV2.
Do we have a workaround or even better a stable version that already support this? @rjehangir @williangalvani I appreciate if you can give us an update about it.
Thanks in advance.
I spoke with @williangalvani about this and was told that our current plan is basically to set the DVL up as a range-finder (already an option with our waterlinked DVL integration, but not sure about cerulean), and change the altitude source for EKF3 to the Range Finder option, at which point terrain following will hopefully be possible using the normal depth hold mode.
We haven’t actually tried this yet, so don’t know how much additional setup is/could be required. From the poking around I did I only saw an option to change the altitude source within the parameters (
EK3_SRC1_POSZ, available in
master (“Development”)), so if it does work we’d still likely need to update some things so it’s not as clumsy to change modes (I doubt manually changing a parameter mid-dive would be a fun experience - much better to have something mappable to a joystick button).
I managed to use a ping sensor as a range-finder (instead of a DVL) and I am stuck an the phase of changing the altitude source to the Range Finder option. I guess I have to wait for a new ArduSub version. Anyway, thank you for your response! You helped me a lot.
If you’re using the ping you might not need the more advanced stuff required by the DVL. If you’re using ArduSub stable (4.0.3) try going to the parameters in QGC and see what happens if you set the
EK2_ALT_SOURCE parameter to the ‘Range Finder’ option. Not sure if it will work as hoped, but if you’re trying it please change the source while the ROV is disarmed, then arm while in manual mode, and then try depth hold and see if you can move down and hold a position above terrain. Be aware that it’s not something we’ve tested, and there might be strong thrust burst issues if the ping loses confidence in the distance measurements/if it’s operating too far from the bottom.
This is very much an “it might work, but try at your own risk” scenario.
Thanks for the prompt response!
I currently only have access to a small water tank so I dοn’t think it is the ideal environment to do this test. I will find a better environment, I will try it and come back with the results of my test.
I guess to some extent it will work but due to the sensor and its sensitivity to reflections the confidence level will be lost regularly so problems will be created there.
@EliotBR May I ask another question before procced with my test. If I also want to try the altitude hold mode using the python code that exist in the Ardusub Pymavlink documentation (accessible here: Pymavlink · GitBook (ardusub.com)) do I have to keep the
EK2_ALT_SOURCE parameter to the ‘Range Finder’ option? I suppose I do but I want a confirmation about this.
If you want to use normal depth-hold mode to automatically maintain a height above a terrain then the only way to potentially do that is to swap the altitude source, yes. Note that it’s also possible to set parameters in pymavlink if need be, although if you’re wanting to only use the terrain mode then you can just set the parameter once in QGC and leave it alone afterwards while you run your pymavlink code.
Another alternative would be to operate the ROV in stabilise mode, and then use pymavlink to command the vertical throttle based on the measured rangefinder distances. It’s not as elegant of a solution as using a built in control mode, and wouldn’t be as fast to respond as ArduSub’s internal control can be, but it could allow some extra robustness in the control logic if the ping distance drops out, and may be the easiest viable option if the altitude source method doesn’t end up working.