You can set vehicle parameters in the Parameters page of QGroundControl
@EliotBR A follow up to what I was asking about before. I am integrating a new DVL to another BROV using the new BlueOS “Companion”. I went through all steps to get it working and does. But when updating the parameters listed above, three of them do not appear at all, so I cannot update them. These are the parameters in question:
Do you know what these do and where I can find them? Do they go with new BlueOS? I think important because it seemed I couldn’t get position hold to work.
Hi @Jnyberg ,
Make sure you are using the latest Ardusub 4.1.0 beta. 4.0 doesn’t support DVLs.
Thank you for that. I updated to 4.1 beta and got the DVL connected. Now when I connect to ROV, the DVL and Ping 360 Sonar ae working, but position hold is still acting up and depth hold is not working at all. When trying to use position hold the sub starts rotating around. When I try to use depth hold, QGroundControl says that the depth sensor is not connected. Here is the error message for that:
When looking at the depth on the viewer, it is not changing at all either. The depth is titled as “Depth” but is actually registered under “altitude tracker”. Here i what that looks like:
Any insight at what I should do from here?
Can you confirm that
BARO_PROBE_EXT is set to 768?
If it’s not fixed by the depth sensor parameter, please confirm that the DVL has a good lock when attempting position hold. If there’s a good lock but it’s still not working, or working poorly, then it would likely be helpful if you can share a log
Vehicle/AltitudeRelative works correctly for me for the depth sensor
In addition to Eliot’s points, note that “stopped aiding” means the dvl stopped sending valid data. This probably means the dvl doesn’t have a good bottom lock.
Thank you that parameter seemed to be the problem!
For future reference, I was wondering if there is a new DVL Integration instruction page for the new BlueOS companion. I know there is this instruction page for the old companion (DVL Integration · GitBook and Networking - Documentation), but that doesn’t cover all steps needed to get the DVL working with new BlueOS, and it would be a lot easier to reference if I had a new one. I tried looking around here on the forum page but couldn’t seem to find one.
The DVL functionality is discussed in the External Integrations/Extensions topic, but isn’t yet documented in the main BlueOS docs.
The general extension system isn’t yet developed, so in the interim the simplest way to set up the DVL is to
- Connect to the vehicle and follow the getting started docs to connect to the vehicle and your wifi network
- Turn on pirate mode
- Open the web terminal
red-pillto access the onboard computer
- Install the dvl service with the following command:
sudo docker run -d --net=host -v /root/.config/blueos:/root/.config --name=BlueOS-Water-Linked-DVL --restart=unless-stopped bluerobotics/blueos-water-linked-dvl:latest
- Access the configuration options via the Available Services page
6 posts were split to a new topic: “No board running” - fixing broken ArduSub install
A new issue I am having is now when I’m testing in the tank. When trying to use position hold, I can activate it and it partially works. It is keeping vertical positioning but not horizontal. QGC also keeps giving me errors of “EFK3 IMU0, IMU1 stop aiding”.
So it seems that it can’t keep a steady connection. I also checked on the waterlinked page and it shows it not having valid velocity reason so that is part of the problem if not the problem.
But I don’t know how to go about solving this issue. I have the parameters set the reccomended way as said on the intergration page via: DVL Integration · GitBook.
As a note I am working with a different sub than before which is still on the old companion. I am running Beta 4.1 firmware as well.
Any help on how I can get the doppler to have a valid connection? It was mentioned above how you need to get a good bottom lock but I don’t fully understand what that means. Apologies for that.
If there’s no valid velocity detected by the sensor then ArduSub isn’t receiving values, so it can’t track or maintain velocity or position (just like when no sensor is connected). If the sensor is getting valid measurements intermittently then that would explain why you’re getting notes about aiding and odometry fusion repeatedly starting and stopping.
No need to apologise
The Water Linked DVL page includes a useful high level description of how a DVL works. A “good bottom lock” occurs when
- the sensor is receiving reflections, and
- the reflections it’s measuring “make sense”.
As obvious failure cases, if the water is very deep then the transmitted pulses the DVL sends out will never get back (so requirement 1 is missing), and if there’s an external source of sound waves then the sonar measurements the DVL makes may be completely inconsistent with the inertial movement being detected by its IMU (so requirement 2 is missing). Of course if one or more of the sensors (sonar receivers, accelerometers, gyroscopes, etc) are damaged that can affect either of those requirements.
Less obvious failures can occur if
- the materials being reflected off don’t have a consistent surface
- e.g. moving vegetation
- the surface is reflecting sound away from the sensors
- e.g. steep slopes
- there are multiple echoes occurring from each transmission
- e.g. from the walls or water surface within a small tank
I expect your issue here is with that last one, whereby multiple echoes occur spread out over time, and potentially with different frequency shifts, which could be confusing the sensor. It may be possible for a DVL to try to compensate for being in a small water volume by reducing the transmission and/or receiver gain (to reduce the strength of subsequent reflections), but not everything can be compensated for.
Do you have similar issues if you’re testing in a swimming pool or larger body of water?
On the DVL, “Velocity valid” is valid, but Ardusub’s DVL driver shows “timeout restarting”.
In the air, “valid velocity” is invalid, but Ardusub’s DVL driver shows the status as “running”.
When submerged in water, “Velocity valid” is enabled, but the status becomes “timeout restaring”. (If only the DVL is submerged, “Velocity valid” is enabled and the status remains “running”.)
Does this mean that “Velocity valid” is invalid in failure cases?
Currently, I have a Ping sonar 360 set up diagonally downward at a pitch of 45°, and the DVL is set up to emit sound waves directly downward.
I am wondering if it is due to
- interference between the Ping Sonar 360 and DVL sound waves or
- a mismatch between the IMU in the Ping Sonar 360 and the IMU in the DVL or ROV.
Interesting. I’m not sure whether that’s an issue with the driver (which seems unlikely to have not been picked up before now), or just some unfortunate timing when you happened to be checking each component.
A couple of questions:
- Was this on BlueOS or Companion, and which version?
- Is this behaviour repeatable (e.g. every time you remove it from the water the velocity goes invalid and our driver changes status from “timeout, restarting” to “running”)?
My description was for cases that may cause any DVL to capture sufficiently poor data that it can’t accurately determine the velocity. Whether it detects those conditions correctly depends on the particular sensor implementation (both hardware and firmware) - i.e. an ideal sensor would always correctly detect and report when its readings are and are not valid, but some sensors may fail to detect certain invalid situations (e.g. if the data seems valid but actually isn’t, which could occur naturally or by some intentional means to trick the sensor).
The Ping360 uses a 750kHz transducer, whereas the DVL-A50 uses 1MHz. It’s unlikely (but not impossible) for them to have some interference, depending on the receiving hardware and logic on each. You could quite easily test if the Ping360 is causing issues by turning it off / not connecting to it and seeing if that makes the DVL start working properly.
The Ping360 has no IMU, and does not communicate position or orientation, so that’s not possible. It is possible for there to be a mismatch between the DVL and ROV IMUs and/or between their predicted positions and orientations (which is discussed a bit here), but that would exhibit as an issue of unreliable position estimates, not something reported directly by the DVL itself or by our driver for it.
Note that our DVL driver does not currently report orientation at all.
Once “time out” occurs, it will not return to “Running” after waiting for a few minutes, restarting the dvl driver, or pulling up into the air.
(“Running” in the air → “time out” in the water → “time out” in the air )
This is on Companion 0.0.31
I have experimented with this before and had no problems.
Also, when the problem occurred this time, we turned off the power and rebooted several times, and in some cases it worked without any problem.
Just following up on this, we’re not really sure why your DVL is apparently timing out. It’s not impossible that there’s an issue with the driver, but it’s not something we’ve come across before which makes it seem more likely that your DVL is playing up somehow, or there may be issues with the setup (electrical or acoustic, as discussed above).
I’m curious whether switching to BlueOS would help, although I don’t have reason to expect it would make a particular difference since the driver code is very similar.
So after a lot of messing around with the DVL, I have myself going in a loop. I decided to double check that the DVL wasn’t malfunctioning. And when checking the DVL by itself, it does read a valid velocity. When connected back to the ROV, I decided to do a parameter reset because I kept trying to change different ones from what I’ve read recommended in the forum pages in hopes of it working. Now on the setup page, it says that it is trying to connect to the DVL, and then says that it is unable to, but the DVL page still reads valid velocity.
This is interesting to me because it seems to me that I am getting a valid velocity when not connected to BlueOS, but then lose that velocity valid reading when connected to it. So do you believe this would be a parameter issue? I wonder because I don’t know if switching from old companion or even the Beta companion to BlueOS would result in need of different parameters than listed in the ardusub DVL integration page.
I looked through the forum because I know people had this issue before, but all I found was answers to the problem I have already done. For example it needs to connect through firmware version 4.1.0, which I have. I am using QGC version 4.2.2, I had certain params like BARO_EXT_BUS on 1, BARO_PROBE_EXT on 768, and all parameter listed on integration age set as recommended. So while I do feel it has to do with maybe another parameter I am missing for new BlueOS, I am unsure what that would be.
@yuki I was wondering if you found a solution to your problem because it sounds slightly similar to my problem and could help with mine as well.
Hi! I am wondering its not possible to reach “velocity valid” when the DVL in air environment?
Hi @valeri2a, welcome to the forum
Most sonar sensors designed for use in water are unable to operate in air because of the drastically different densities (and corresponding speeds of sound, and sonar reflection boundaries) between water and air.
In their documentation, Water Linked recommend:
so the DVL-A50 definitely doesn’t seem like it’s intended to be used in air.
I am wondering if someone have tried to save the data from DVL in the Dead reckoning mode?
So far I am dealing with Water Linked DVL A50 - ROS Package from dvl-a50-ros-driver , but facing some issues with socket programming. Anyway, if there are someone who already completed the data saving and can share it will be extremely helpful.