When we integrate DVL into BlueROV2 via companion, set disable exteral GPS at Ardusub parameters.
EK3_GPS_TYPE 3
Is there any way to use both DVL and underwater GPS (eg. using EKF)?
When we integrate DVL into BlueROV2 via companion, set disable exteral GPS at Ardusub parameters.
EK3_GPS_TYPE 3
Is there any way to use both DVL and underwater GPS (eg. using EKF)?
Hi @yuki,
Iām not sure if using the Water Linked DVL and Underwater GPS at the same time is available yet, so Iāve asked internally and will get back to you.
From a quick forum search, I found this mention in 2020 (when the DVL was released)
but Iām unsure how the situation has changed since then.
As I understand it the DVL measurements are sent as visual odometry readings, so you may be able to set the EK3_SRC Parameters to meaningful values yourself that allows automatically combining the GPS and DVL results in the EKF (noting that there are parameters available for setting noise/confidence estimates that can reduce/increase the weighting of the GPS results).
EDIT: EK3 Parameters ā EK3_SRC Parameters (with new link)
Following up on this, combining these devices isnāt yet supported in ArduSub/Companion. As mentioned it may be possible to set the EK3 parameters yourself to enable it, but it may not work very well, particularly where there are discrepancies between the estimates.
If you send USBL position to Ardusub, does it automatically add it to the Kalman filter along with the IMU values and the DVLās velocity measurements to give the best position?
Hi @gcelec,
Iāve moved your comment to this thread because itās more relevant than the thread you initially posted it in
As above, Water Linked was/is planning to make it possible to integrate them directly with each other, but thatās not yet available. As for ArduSubās EKF combining the readings automatically, it may be possible to enable by setting appropriate parameter values, but itās not something weāve worked with or tested so I canāt comment on how well itās likely to work (if at all).
Have you integrated these sensors yet?
If not, do you know any implementatin pose estimation from the velocity(DVL), IMU(Pixhawk) and position(SBL) data by using Extended Kalman Filter?
Hi Yuki,
We havenāt gotten to it yet. It should work by setting the EK3_SRCN_POSXY
to GPS and EK3_SRCX_VELXY
to DVL. But last time I tested the results were not great.
If I implement EKF myself, in the state prediction model, do I need to remove the gravity acceleration component underwater when predicting from IMU acceleration and angular velocity?
In the SCALED_IMU2 data, a value of about -1000 is observed in zacc when stationary (about -9.80665 m/sĀ² because the unit is mG)
I checked the Pixhawk specs and thought the z-axis was positive downward, but the observed value is negative.
In this case,
acc_input = -acc_observed*10^3*g - Rć»[0,0,g]
acc_observed : observed acceleration(mG)
acc_input : acceleration to be input to the prediction model(m/sĀ²)
R : Rotation matrix by observed roll pitch yaw(rad)
I can calculate as above?
Hi @EliotBR would you please give us an update on this?
Additionally, I have a few technical questions I would like to clarify, basically they are quite closely related to each other.
From my understanding, the current setup of DVL a50 with BlueOS uses a docker implementation on bootup, where navigator/pixhawk reads velocities from the dvl-plugin and feeds to the system as visual odometry data.
Nurjan
Hi @yuki I donāt know if youāre still trying to get the Kalman filter to work, but the behaviour youāre describing regarding convention sounds correct to me.
The force of gravity is acting down, making the sensor āfeelā like itās accelerating upwards.
E.g. If you imagine the accelerometer as a mass on a spring in a box, an upward acceleration of the box causes the mass to press downwards.
Which is the same thing gravity does when it acts on the mass.
So gravity force looks like a constant upward acceleration on the sensor.
As the z axis is oriented down, it means grav acceleration measured on the Z sensor will be a negative number.
Hi @williangalvani and @EliotBR ,
Regarding the EKF3 sensor fusion with GPS and DVL (and INS).
I found the following in the arducopter documentation:
https://ardupilot.org/copter/docs/common-optical-flow-sensor-setup.html#for-ekf3
Do you think it could work? Or is this what was referred to earlier in this thread by @williangalvani?
I notice thereās a parameter for disabling fusing of velocities. Could that help with the problems Willian described earlier?
And is there anything else that could be done to make the Kalman filter work with these datasets?
For background:
We have a DVL A50, which is great. But they donāt have a USBL system, or any mention of sensor fusion online.
Also, the boats weāre on usually have their own USBL systems (so we generally have to mount their beacons and send the position data over the NMEA injector).
If BlueROV users could do sensor fusion using data from their own DVL with any USBL system it would be an amazing value add.
It would mean sensor fusion isnāt proprietary to the USBLs and DVLs, but built into the blueROV.
The more accurate data would be a big benefit for surveying and photogrammetry.
Keen to hear your opinions, I really appreciate how much you guys contribute to these forums!
Kieron
Hi, Kieron:
TL;DR AFAICT, the code is there to support USBL + DVL fusion, but getting it work well is tricky, and possibly buggy.
I ran some simulations to play around with different parameters and posted the results here: GitHub - clydemcqueen/ardusub_localization: Tools to run ArduSub localization experiments
Inspired by the simulation results we ran a test with a BlueROV2 equipped with a WL UGPS and A50 DVL off the Seattle Aquarium dock. We never got fusion or missions to work, but we learned a lot, and we have a workaround that we hope to try soon.*
I suspect that getting fusion to work well will take some experimentation. The EKF assumes Gaussian noise, and the USBL error isnāt Gaussian in X and Y, and in fact increases as the ROV moves away from the receivers. There may also be EKF bugs to work through, including this one: External navigation measurement noise is overwritten by GPS reported accuracy in EKF Ā· Issue #24020 Ā· ArduPilot/ardupilot Ā· GitHub
This is high on our list for 2024, so we will keep plugging away at it. Good luck!
/Clyde
*Since we had the UGPS antenna deployed off the dock, we werenāt really paying attention to the G2 box after we got the initial lock. It turns out there wasnāt a good view of the sky from our location, so the G2 box did not keep the fix. Log analysis revealed that the GPS_INPUT.satellites_visible field was always 0, and the EKF origin was never set. Thus, fusion never happened, and we could not run missions.
This is a common test environment for us, so we will try again with a modified extension that is more forgiving: Comparing waterlinked:master...clydemcqueen:clyde_num_sat Ā· waterlinked/blueos-ugps-extension Ā· GitHub
For those interested, I have been doing some experiments with running a regular GPS on a 10cm antenna with the dvl. It worked well using a lua script. More testing is welcome. I have the script and some notes here:
https://williangalvani.github.io/ardupilot-kb/ArduSub/WIP/DVL-GPS%20integration.html