I hope everyone is doing well. I’m currently working on a project that involves integrating Sonardyne’s Sprint Mini H-NAV, a hybrid acoustic-inertial navigator, with BlueOS for positioning hold mode. you can check out the Sprint Mini H-NAV here: Sonardyne Sprint-NAV
Specifically, I’m interested in connecting the highly coupled INS and DVL sensor data from the Sprint Mini H-NAV to BlueOS for data fusion purposes and integration with MAVLink for use in positioning hold mode. Has anyone had experience with this particular sensor? I would greatly appreciate any insights, tips, or best practices for efficiently integrating and fusing the data to enhance positioning accuracy and reliability.
Any tips, advice, or pointers would be immensely valuable to me and my project. Thanks in advance for your help and support!
It sounds like you are working on an interesting project with survey-grade sensors! Here at Mission Robotics we have been working with multiple customer vehicles running the SPRINT-Nav Mini. Not only does the SPRINT-Nav Mini have far superior sensor performance compared to the typical low-cost MEMS devices built into most Pixhawk-like flight controllers, but it also has more accurate and robust sensor fusion capabilities for underwater applications (arguably just as important as the individual sensor performance). Our customers wanted better control-loop performance from these higher quality data sources, but found that it was not straightforward to fully integrate this into the Ardusub stack, so they gave us a call.
For the past few years our software has successfully been running vehicles in commercial settings using survey-grade INS data (such as from the SPRINT-Nav Mini).
Our software stack is a complete replacement for Ardusub/BlueOS/QGC and also requires an electronics upgrade. I am not sure if this is an option for you, but if you are looking for a control stack with native integration for the SPRINT-Nav Mini, feel free to message me or reach out via the contract page on our website.
Thank you for your detailed response and for sharing your experiences with the SPRINT-Nav Mini. It’s great to hear about Mission Robotics’ work in this field.
I completely understand the benefits of using survey-grade sensors like the SPRINT-Nav Mini and the challenges of integrating them into existing control stacks like Ardusub/BlueOS/QGC. While your offer to switch to Mission Robotics’ software stack is intriguing, I’m exploring options to leverage the capabilities of the SPRINT-Nav Mini within the current setup.
You mentioned that your customers desired better control-loop performance from the higher quality data sources but found it challenging to integrate into the Ardusub stack. I’m facing a similar challenge and was wondering if there’s a way to utilize BlueOS with MAVLink for integrating and fusing the data from the SPRINT-Nav Mini without requiring a complete firmware overhaul.
I’m aware that creating a new control stack with native integration, such as using ROS1/2, is an option, but considering ease of use and deployment at the customer’s end, I’m inclined to work within the existing Ardusub/BlueOS/QGC framework.
Hi @williangalvani,
Regarding your mention of an External AHRS driver. Forwarding external sensor data using MAVLink without firmware modification, do you happen to have any insights or pointers on how this could be achieved?
I found that cerulean, waterlinked, and Nortek DVLs have BlueOS extension support, unfortunate that Sonardyne’s Sprint Mini H-NAV might not have it. Since I might have to create my own BlueOS extension, I found from BlueOS DVL Nortek and CeruleanBlueosDVL VISUAL_POSITION_DELTA packets have been used to send velocity data to the ROV for positioning hold.
Given the sample Sprint Mini H-NAV decoder code, could you perhaps advise on which specific data elements I would need to extract in order to generate VISUAL_POSITION_DELTA? Any guidance on this front would be immensely helpful as I dive deeper into this integration process.
Thanks again for your assistance and support! Looking forward to your insights.
I’m curious about the feasibility of using MAVLink’s GPS_INPUT PyMavlink GPS_INPUT message as an alternative method for forwarding external sensor data. Do you have any experience or insights regarding the use of GPS_INPUT for this purpose?
Hi folks, John here from Sonardyne, I’m the Product Manager for our Navigation solutions.
It’s great that people are beginning to use our survey grade systems on Blue ROV platforms, we know lots of users have integrated SPRINT-Navs onto Blue ROVs for high end photogrammetry/mapping. As I’m slightly new to working with Blue ROVs it feels like the most accesible way for our systems to work in your ecosystem is to publish a BlueOS extension?
Our vehicles have a Linux-based onboard computer that runs BlueOS, and a flight controller board running an ArduPilot autopilot firmware (ArduSub for our ROVs, and ArduRover for the BlueBoat).
Somehow the data from the device needs to get to the autopilot, which can be achieved via one of:
A direct serial/I2C connection to the flight controller board, with a corresponding (C++ or Lua) driver in the ArduPilot codebase
@williangalvani’s suggestion of an external AHRS driver would likely be the most appropriate and straightforward way of doing this
this approach offers the lowest latency, but requires any relevant configuration to be done either automatically as part of the driver, or via autopilot parameter values
A serial/USB/ethernet connection to the onboard computer, using a BlueOS Extension to talk to the device and send appropriate MAVLink messages to the autopilot
This can have an optional browser-based interface, where a user could see whether the device is connected, and perform relevant configuration and/or calibrations
As this is less direct, there is some additional latency involved, and the available data pathways may be more restricted by the messages present in the MAVLink protocol
A combination of the two, whereby the main connection and driver are handled by the autopilot, but an optional BlueOS extension could provide an interface to help with setting parameters (perhaps with options for some different pre-sets)
For vehicles using our Navigator flight controller[1] it is possible for the BlueOS user to determine whether a serial-compatible port is owned by BlueOS or the autopilot, in which case a BlueOS extension could potentially be used for complex calibrations and configuration before access is switched to the autopilot, which could then have a more basic driver that only needs to interpret the sensor / position estimation data
This is the case for the vehicles we currently sell, but not all our older vehicles, and is not guaranteed to be used if some other company makes a water-based vehicle, even if they choose to use ArduPilot firmware and/or BlueOS. ↩︎
Hi @John_Sonardyne / @EliotBR / @williangalvani
Apologies for the late update. I have used the $GGA NMEA messages data produced by SPRINT-Nav. By employing the NMEA injector from BlueOS, the autopilot can now estimate GLOBAL_POSITION_INT, which enables it to successfully execute the position hold mode, also known as loiter.
However, sometimes the SPRINT-Nav position quality is high, causing the ROV to drift while trying to hold its position. The main reason for this issue is that the DVL cannot detect the bottom when it is too close. Currently, I am working on implementing an automatic mode change that switches to depth hold mode when the position quality is too high.
Hey @ryan354 Awesome, good news you have the GLOBAL_POSITION_INT working.
As you mentioned the SPRINT-Nav position will drift when outside of DVL bottom lock in line with the error estimated in the output INGGA message. Switching to depth hold would certainly help you maintain your vertical position, however the only way to maintain the SPRINT-Nav position over long durations is either external aiding or DVL bottom lock. You will find that the drift will be slower at the start before increasing to a point whereby it starts to flatline again when we hit a velocity error limit which lines up with the maximum velocity of a normal subsea vehicle.
As an update we are currently working on the BlueOS Extension as suggested by @EliotBR . Whereby we will take in our HNAV message and output GLOBAL_POSITION_INT + another message for velocity/position delta. Once tested and published in house we’ll publish this so it can be used. I don’t have a time estimate yet but it’s in active development, so weeks not months. As a teaser I’ve added below an example of the current browser based interface for connecting and monitoring status.
Thank you for the update! I’m looking forward to the new features and improvements. I’ll be sending you an email shortly to get the latest firmware update.
