So you have both a UGPS2 and the Waterlinked DVL? How do you “switch” between them?
I suspect the issue is that while using the UGPS2, the ekf is not happy, we need to check why. Can you provide some bin logs?
To add some extra context here, it’s possible this can work in theory but it’s not something we’ve tried extensively or established as a supported functionality for even the most recent autopilot versions, let alone old ones.
This thread includes some relevant discussion, and this Issue is the latest discussion I’m aware of around fusing those data sources.
The Issue I linked to may cover a potential conflict between the device drivers because of the parameters that they currently set automatically.
I’ve just updated your trust level so you can upload files.
More information about the error:
There are 8 mode that can choose. The first four modes works well. The same error pops up when we choose any of the last four modes.
We looked up the MAVLINK command and found some parameter related. I wonder will that helps for solving this problem?
This log file is very short, but also doesn’t include any position information in the GPS messages or AHRS estimator, which may be the source of your problem.
The failing modes in this case are the position-enabled ones, which only work if the vehicle has a sufficiently stable position estimate. If the position measurements aren’t frequent or consistent enough then the autopilot doesn’t know where it is, so it can’t meaningfully perform position-based actions or missions, and it rightfully refuses to enter a mode that requires such an estimate.
If you check the MAVLink Inspector for the lat/lon fields in the AHRS2, GLOBAL_POSITION_INT, and GPS_RAW_INT messages, that should hopefully provide a sense of what the autopilot is estimating and receiving. I’d also recommend checking the status of the UGPS system and/or the DVL (depending on what you’re trying to use), to see whether at least the sensor thinks it has a valid position lock.
Thanks for your reply! We did try a lot different settings recently and have some interesting findings.
The MAV_CMD_DO_SET_MODE command failed problem solve by downgrading QGC to 4.2.8 because that is the latest version that Ardusub support. (Ardusub webpage says the latest version they support is 4.2.3 but the download link they provide is actually 4.2.8)
However, the auto mode still cannot work with the new GPS. When we park our ROV in a known point, both the Waterlinked page and QGC appears to oscillate. The error level is about 4 meters.
Although the ~4m error exist, we still try to run the auto mission. But QGC said fail to change to Auto mode or any position-enabled modes, which you mentioned above, only work if the vehicle has a sufficiently stable position estimate.
I also check the MAVLink Inspector for the [lat/lon] fields in the [AHRS2], [GLOBAL_POSITION_INT], and [GPS_RAW_INT] messages, all the lat/lon are constant while depth does change in real time. It seems like the QGC doesn’t receive the real time GPS data/ have a valid position lock.
Hi @yl1999 -
The issue is likely fundamental to your operating environment - a large tank! The acoustic GPS system can struggle with multipath in such environments…
Hi!
Since you have problem in the Waterlinked UI there is acoustic problems.
Check Waterlinkeds diagnostics and try to find the problem: http://192.168.2.94/#/diagnostic
Waterlinked has a demopage online where you can check functionality display in open water: Water Linked Underwater GPS
