I am trying to share the NMEA location data from an external GPS mounted to the ROV.
Present setup is an external GPS mounted on a mast connected to the Navigator board Serial3. The location data is appearing on the Control Station Computer (QGC) as gps2. Which is great!
I would like to forward this data as a UDP broadcast so it can be picked up by a second computer running OpenCPN, with the appropriate UDP port input setup.
Can this be done using an existing BlueOS feature, like MAVLink endpoints? I thought maybe using the Serial bridge to send the connected data to NMEA Router, then setup the broadcast there to port 27000 for the NMEA Injector, and OpenCPN?
Maybe someone has done something like this with BlueBoat already?
1 Like
I neglected to mention. This is for a super shallow <2m survey of sea grasses. It seems that the ROV Locator doesn’t work well at these shallow depths.
Hi,
I don’t think I’ve seen this done before. but it should be doable, if using a navigator. The Navigator allows you to define “fake” serial ports.
So you can set Serial2 to be an udp output (make sure you put the IP and port of your OpenCPN machine):
and then set the protocol to NMEA output:
Let us know if this works!
It seems the Serial Port Configurator of mine doesn’t like the udp config. The box turns red, and indicates unknown format.
@k-deboer
What version of BlueOS are you using?
I was running version 1.2.6 (stable) But with your prompt Tony, I went ahead and loaded 1.3.0 beta 10. That did it! OpenCPN now shows the GPS status.
I can’t say enough about the team at BlueRobotics. Awesome!
The survey is this Tuesday. Confidence is high
2 Likes
Alas. When I returned to the system today, not much worked. The vehicle was unresponsive, no GPS data forwarded. The BlueOS screen shows 1.3.0 beta 10 running, but on the lower left summary it’s back to the bootstrapped 1.2.6. I can recover by reverting back to 1.2.6, then going up to 1.3.0 beta 10. But I had to re-cal the sensors. Upon power-cycle, it reverts back again to the odd state with no response from vehicle.
Hi @k-deboer -
That’s very strange! You could try updating the boostrap to the 1.3 beta 10 too see if that helps, but it sure seems like something else weird is going on.
Your screenshot seems to indicate that you’re not connected to the vehicle - the broken heartbeat in the upper right shows the autopilot is not communicating with BlueOS, and the notifications in the very corner may indicate similar. You may want to try clearing your Chrome browser cache and seeing if things behave better?
When you say the vehicle was unresponsive, do you mean after it finished start-up and you heard confirmation tones from the thrusters, you did not get a connection in QGround Control on your usual control computer?
It is definitely strange. It does not seem to matter which version I bootstrap. Upon power-up it goes to this state. The autopilot boots up, normal sounds, yet Cockpit can’t resolve the IP, QGC connects with video, but the gyro/compass,voltage/current readings float all over the place. It fails pre-arm, and the joystick has no control. The temperature readings seem normal…
The only way to recover at this point is to apply 1.2.6. Then, apply 1.3.0 beta. As long as the system does not power-cycle it holds stable. I tried Appling 1.2.6, bootstrap that and deleting 1.3.0 beta 10. But Apon power-cycle, it starts up again in this state, where I then have to download and apply the beta version, re-apply 1.2.6 to recover. Then I can apply the beta for stable use…Ghosts!
I’ll clear the Chrome browser and give this a go.
A fresh load of 1.3.0 beta 10 on a formatted SD card did the trick.
1 Like
1.3.1 stable is out now @k-deboer ! Glad updating this way fixed things for you.