In QGC we can send a NMEA sentence to the topside computer IP address on UDP port 14401 and have the boat/user position shown in QGC.
Is there any similar functionality in Cockpit yet, I have had a good look around and tried the latest Beta etc. But couldn’t see a way to do this yet - just checking I’m not missing something obvious. Aware we can send ROV location from USBL etc to 27000/1 to get ROV location in overlay - can’t see how to do for topside and ROV.
Cheers
Matt
Hey Matthew!
You’re running BlueOS, right?
In this case, you can use the NMEA Injector to send data from an UDP source to the MAVLink stream, which would them be consumable on Cockpit (for example), on a Very Generic Indicator or in the Map widget.
I’ve never tried that thought.
@EliotBR do you see that working or am I missing something?
Hi @rafael.lehmkuhl, yes, I’m using BlueOS, I’m not at sea at the moment so trying to test stuff dry and only have 1 gps to hand. But what I’m not clear on is if I feed two different positions to BlueOS via two NMEA injectors. How does cockpit maps widget differentiate between the two?
Just trying to get head around it now to save time on boat after we mobilise.
Loving the new video elements and the sync of Cockpit settings.
Best regards
Matt
I believe Cockpit’s map widget just makes use of the vehicle’s position estimate (via the GLOBAL_POSITION_INT MAVLink message), which will be based on whichever GPS the autopilot is considering as primary, fused with motion data from the other sensors onboard the vehicle.
There is checking for the GPS status/fix type, but only for the first GPS at the moment (and that doesn’t extract the reported location).
If you’re interested in accessing the raw data from each GPS then that will likely need to be done using Very Generic Indicator widgets at the moment, although the options for doing so may not be completely straightforward:
GPS_INPUT.gps_id but that field is currently hardcoded in the NMEA Injector, so won’t be usable at the moment.GPS_RAW_INT and GPS2_RAW MAVLink messages that get sent from the autopilot.@rafael.lehmkuhl we might want to consider allowing displaying raw position sensor location values (from GPS*_RAW / VISO) on the map, perhaps as an error radius around the estimated position, or as one or more ghosts of the vehicle to help with sensor debugging…
Just opened two issues to track those features:
Hi @EliotBR and @rafael.lehmkuhl
Keeping in mind that XYZ are only starting to move over to Cockpit and haven’t been able to test it on a job yet. Also apologies if I’m over explaining here, you guys are the experts, and this might be very obvious. But I don’t know how much my experience and use cases differ from other peoples.
I see you guys are working on showing the position of the ground control station, but would it also be possible to display heading of the GCS when data is available? On a boat, UDP NMEA heading data (HDG/HDT/HDM) is often available, as well as GGA.
Currently, we get around this by having physical compasses onboard, but this setup can quickly become complicated.
Blueprint Pinpoint (USBL software) allows taking in NMEA position and heading of the boat but doesn’t allow passing in ROV heading. Their unit designed for small ROVs (x010) just shows up as a dot rather than an arrow in the Pinpoint software, so it can’t be easily used for navigation.
Sonardyne Marksman is similiar (though there might be a way to send ROV heading data to marksman by converting Mavlink to NMEA).
If Cockpit can take in vessel position and heading via UDP, along with ROV position and heading (from the ROV), we would be able to use the Cockpit map as our only orientation source which would be fantastic.
| Type of Data | Source | Achievable in USBL Software | Possible integration in Cockpit |
|---|---|---|---|
| Vessel Position | NMEA | ✓ | ? |
| Vessel Heading | NMEA HDT/HDG/HDM | ✓ | ? |
| ROV Position | NMEA from USBL software | ✓ | ✓ |
| ROV Heading | ROV | ✗ | ✓ |
I see some great work by Willian in the qgroundcontrol github that solves this problem completely.
But the functionallity sees to have been disabled at some point.
Also @Boko has created a neat workaround in OpenCPN to solve this.
And @odedezra has a QGIS solution, which might be very useful as an ultra flexible GIS solution.
@XYZEng this is exactly the use case we are look for. Situational awareness of ROV position relative to vessel, being able to see both positions is great, but seeing heading of both as well is a huge benefit in terms of piloting the ROV, vessel and tether management.
This would be game changing in terms of operational efficiency and safety.
Note that while cockpit is technically able to show the position of the current device using the browser location API, that requires secure context (ssl) which we don’t have working on BlueOS yet.
It should work on the Desktop version of Cockpit, though. But it does require the OS to provide the location, as we don’t have a serial driver in cockpit to read the NMEA stream directly, yet.
That would still work ok, we can pass boat position to windows location API. It’s a bit of a faff but should work. But it wouldn’t allow boat heading which as @XYZEng stated, really is useful, especially when offshore with no real directional awareness from surroundings.
@mattcmgb @XYZEng are you using BlueOS?
I’m asking just because we are discussing those features here and thinking where to put them.
@rafael.lehmkuhl yes definitely using blueos, but open to either the cockpit extension or desktop app - personally I prefer the desktop app version of cockpit - more control over it compared to settings for entire browser etc.
I also use BlueOS, it’s brilliant.
Just a note I’ve been trying out the QGIS plugin with PosiView, as it would allow us to use technical drawings flexibly. It would allow us to overlay plan views of subsea structures or piers like the below one.
If a BlueOS map view could take in files from QGIS/ArcGIS (shapefiles / DXF / GeoTIFF / SVG / GeoJSON - I don’t know which ones would be easiest to develop) it would mean people could create exports from ArcGIS and QGIS.
I’ve got Posiview working with a NMEA generator input. It’s able to track multiple targets with different icons. But it’s quite quirky to get set up. More discussion on that here
We’ve experimenting with Posiview in QGIS, it does most of what we’d need but the GUI in posiview is a bit clunky, it uses a lot of screen real estate and it can’t be adjusted, so isn’t great on smaller screens. It definitely has potential and could be tweaked as it’s open source I think.
Ya I agree, posiview is very clunky, and I’m trying to figure out the quirks to make it repeatably take in data.
Also running QGIS may require CPU resources for it’s other GIS functions where a basic viewer is all that’s needed.
I’ll continue any discussion about getting posiview working on the other thread to keep this one more tidy.
Thanks - I’ve added a note about this in my initial map widget desired features list. Supporting custom maps and overlays has been one of the key ideas from the start 
Great, I should say that although I originally mentioned shape files, there are a lot of other formats that might be easier to implement.
I know GeoTiff is used for raster maps that could potentially be output from GIS. But there are other formats like KML and DXF that are sometimes used.
My knowledge isn’t great on GIS formats. And you guys will know a lot more about ease of implementation
