Corrupt or missing depth readings in Waterlinked AND in QGroundControl

Blue Robotics Software
1

Hi!

After updating QGC, Ardusub, Companion and Waterlinked software there is error in how depth
sends from Companion/Ardusub to Waterlinked.
That makes the positioning useless.
I am not sure where the problem is.
(Problem also occur with Waterlinked UW GPS gen 1.)

Two problems, never at the same time, that could be related, In Positioning and in QGC.
I have a system running on land with NMEA simulator etc that can be used for fault tracing.
System is: BlueRobotics BR2, Waterlinked GPS Gen 2, (and Waterlinked GPS Gen1)
Software: QGC 4.1.2, Ardusub 4.0.3, Companion 0.0.26, Waterlinked 3.2.0

Problem 1
Depth from Companion is not working more then 1 to 30 minutes.
Instead received depth in Waterlinked is close to 0 or missing.
That makes the positioning useless.
Hardware, Python scripts etc are the same that have been working earlier.

In test environment (my system is online) it is possible to track:
Starting system without sending NMEA to Waterlinked.
Offset parameter “GND_ALT_OFFSET” to -2 meters to get a depth value other then “0”
Manual start of Companion WL script.
WL is now getting correct depth and temperature.
Starting to send GGA for position and HDT for heading by Python to Waterlinked.
After a while depth reading either stops or is 0 meters.
I can not define why there is two responses for the same problem, all is done same way.
If depth is 0 meters, the temperature from Companion still reads right in WL
If depth stops reading in WL, Waterlinked reports “missing external depth”

In Companion Waterlinked page Driver is still “Running”
Restart Companion only does not help.
To get depth received in Waterlinked I have to restart Companion AND Pixhawk.

Could it be a bug in Companion that makes 1 old and 1 new problem:
-WL Script do not autostart for Waterlinked Gen 2 (but works for Gen1)
-Driver function hangs after a while, or makes Pixhawk hang, as described above.
Or is the new Waterlinked 3.2.0 having trouble?

There is also an old case regarding no autostart of BR Companion Driver still active: Waterlinked UW GPS Gen2 not autostarting Ardusub driver - #3 by Boko

Problem 2
QGC shows wrong depth sometimes.
After a long time operating ROV, QGC starts showing depth that is offset by 5 to 10 meters.
After surfacing, depth reads correct.
This has no connection with problem 1, Waterlinked system shows correct depth at the same time.
Could these troubles be related to problem 1 above?

Bo

1 Like
2

More tracking of problem:
Main problem seems to be communication between Companion and Waterlinked API
In my mind there is problem in both Companion and WL API.

By not sending position by Python to WL API, Companion WL Driver works more stable
(But useless fix due to no positioning doing that)
Also, Python script communicating position to WL API is more slow (skipping several seconds) when Companions driver is communicating to WL API at the same time.

One way to make Companion work again by “only” use Companion WL Driver button in BR UI:
In WL UI one status in: “Diagnostic”, “Stats for Nerds” is “acoustic:depth_missing” Value = 1
Stop sending NMEA position to WL API by killing Python script
Wait until WL UI reports “NaN” as Locator position (about 10 seconds)
Press “Restart” button in Companion UI
Now WL UI reports correct depth again and “Depth missing” disappear
Unfortunately, when starting sending position by Python to WL API problem occur all to soon.

So, Companion WL Driver has at least the problem of not autostarting.
On the WaterLinked side, API do not handle position input at the same time as communicating with Companion. Could be depending on what Companion is doing?

1 Like
3

Problem also related to UW GPS Gen 1.
I had call from customers using Gen 1 and could verify at dry test.
That means probably all waterlinked systems is affected by new versions of Companion and Ardusub.

1 Like
4

We got in touch with @Boko and were able to find two issues.

The cause of the Waterlinked UGPS G2 not automatically starting is that the mDNS name was changed from waterlinked.local to waterlinked-ugps.local. restarting the driver made it use 192.168.2.94, which made it work.

The second issue we are still not sure of what caused. but seems to be related to a missing cast to float in the driver.

Both these things should be patched soon.

1 Like