Hello everyone,
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?
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?
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
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.
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.
@EliotBR Hello! We have a DVLA50 mounted to our BlueROV and really need to implement altitude hold for seabed surveys. Do you know if any progress has been made with this feature?
@EliotBR Hello! I am currently trying to get a DVLA50 that is mounted on a BlueROV2 to work as the rangefinder to help maintain a constant altitude above the seabed, so this forum seemed perfect to read. That being said, I was wondering if any progress has been made on the release of this feature and/or if there is anything you recommend trying if it hasn’t been released yet? Any help is much appreciated.
The BlueOS Water Linked DVL extension supports using the DVL A50 as a source of rangefinder data, but ArduSub does not currently have terrain hold/tracking built in.
I’m aware that @clyde has worked on implementing that, but I’m not sure how well it works or how close it is to being merged in. It looks like that pull request is waiting for reviews at the moment, so I’ve raised it internally in the hopes we can keep things moving on it
