blueye.sdk Evologics USBL integration

https://github.com/user-attachments/assets/1d06004e-b0fc-4532-9704-7526766b992a

Hi Blueye Team,

We have successfully integrated our Evologics USBL system with the Blueye Mission Planner. We can see the NMEA status light activating, and the updated pings are correctly appearing on the navigation map — great progress so far.

However, we have one question and one issue we hope you can help us with: 1. Is there an EKF or any kind of filtering available that we can activate? At the moment, it seems that all USBL pings — including multipath returns — are being considered in the navigation estimate, which can cause significant deviations. Is there a built-in filter we can enable to mitigate this (can be seen in top left of phone screen)?

2. Compass fluctuations when NMEA messages are active: We've noticed that once NMEA messages are enabled, the compass readings start to fluctuate. Since the NMEA sentences we are sending do not contain any heading information, this behavior is surprising. Have you encountered this issue before, or do you have any suggestions on what might be causing it (can't be seen in the video)?

Thanks a lot for your help!

Best regards, Leo

Apr 28 '25 16:04 leoguen

Hi Leo, I'm very happy to see that you have managed to get the Evologics system into the Mission Planner.

1. Is there an EKF or any kind of filtering available that we can activate? There is an EKF on the position estimate you have there, but it heavily trusts the input position when you use the NMEA input. I can add an issue to improve the outlier filter for these large jumps when using NMEA position input. Maybe there is a setting in the Evologics software that applies filtering as well? I know that is available on the Blueprint Seatrac USBL at least.

2. Compass fluctuations when NMEA messages are active: I believe it's not the compass heading that is fluctuating, but the PositionEstimate.course_over_ground? The autopilot is using the course_over_ground to aim for the target. And this course will be affected by large jumps as it is relying on the position estimate of the heading.

You can also use the Attitude.yaw to get the compass heading before the EKF.

Apr 29 '25 09:04 aviggen

Hi Andreas,

Thanks for your response!

I will reach out to Evologics and check if they have something similar implemented, would it be still possible to adjust the weights of the trust in the NMEA messages ourselves?

Does that also imply that the EKF incorporates the DVL but just has no trust in its input, because we couldn't see any influence of it?

Or would it be possible to access and adjust the EKF ourselves in the SDK?

Apr 29 '25 15:04 leoguen

That is not possible as the weights are not exposed in the SDK.

The EKF is using the velocities from the DVL, but is still weighted quite a lot to the NMEA input to minimize delay and make it more robust (and a bit conservative, maybe). You can see all the Navigation sensors active listed in the Menu->Navigation->Status tab in the app. The sensors with a green label will enter the EKF.

It is not straightforward how to expose the EKF in the SDK, but I'll have it in the back of my head.

Apr 30 '25 08:04 aviggen

Hi Andreas,

going forward making the EKF accessible to us or even better, give us the option to plug in our own would be tremendous. This way we could work on specific implementations using our sensor setup.

However, regarding the current bug, I was able to capture it a bit better on video in our pool. As you can see in the terminal, we are sending the NMEA messages and they do not differ in position. However, we can see the robot glitching by a few meters. I do not think that this is a DVL issue, the robot was standing still on the surface and we checked the DVL website at the same time and could not see that behaviour.

https://github.com/user-attachments/assets/afc18839-dd71-4a0d-8671-ae80089dbf51

May 01 '25 14:05 leoguen

Hi again. I see what you mean. I will keep it in mind to see if we can develop something in the future.

It seems like the NMEA sentences are not coming frequently enough. The NMEA_IS_VALID_SMOOTHING_TIMEOUT is set to 3 seconds, which means if we get no new message within that timeframe, it will turn invalid. And then the "bug" you are seeing here is that it dynamically switches to the DVL position estimate applied on the same local frame origin, which does not match.

So, try to publish more frequently to make sure you do not hit the 3-second timeout. Worst case, you can oversample on the sending side.

May 12 '25 09:05 aviggen