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?