Hi,
We are integrating our BROV with a UGPS using a U1 locator. We have a R4 Heavy (300m), and we’ve added 2 OS450FS, 1 Ping360 and Ping Altimeter. We are using a 300m tether.
Before network bridging, as noted in the integration guide, we see everything working correctly (both ROV and UGPS independently). After the network bridge, our video cuts out, but it screencaps can still be seen through BlueOS on H264 video camera, sending out via udp://192.186.2.1.5600 , /dev/video2.
Has anyone encountered this? And is there any recommended troubleshooting procedure? We can fly blind with just our acoustic nav, but we’d prefer to stream that video. It cuts out on both QGC and Cockpit.
Hi @tritonkeller -
That’s pretty unusual! It might be worth changing your camera stream to be RTSP instead of UDP (done on the video streams page.)
Are you running the latest stable BlueOS, 1.4 that just came out?
I’m assuming your USB camera isn’t being affected by Technical Bulletin 12, as things return to normal when you remove the network bridge?
Windows networking is terrible. I would suspect that something is off - maybe not the right subnet mask set on your network bridge? You could avoid needing a bridge if you connected an ethernet switch to the output of the Fathom-X in your FXTI and the ethernet connection from the Water-Linked hardware (on the topside.)
Hi Tony, thanks for the message. I gave the RTSP a shot. Here’s a screencap of QGC, Cockpit, Video Streams Page and network when bridged at 192.168.2.1 at default subnet mask
Then, when the bridge is deleted, less than 5 seconds later:
That was on 1.3.1. When on 1.4:
UDP H264
Network bridge
No bridge:
RTSP same thing, and UDP265 breaks the stream:
& no camera shows up in video streams.
When setting the bridge and refreshing cockpit, I get the following:
I’m not sure if that means that it see the stream but fails to put it up.
I’m going to try to view the stream in VLC. I don’t know much about subnet masks, but it’s set at 255.255.255.0, as the BROV is when connected alone.
Oddly enough, it also fails in VLC. I couldn’t get it to work over UDP on VLC, but RTSP works fine without bridge; then, as soon as it’s bridged the video disappears.
I have to assume that others who use UGPS with U1 locator manage to get the video to work after bridging. It may be a problem on our end.
I will add: regarding the ethernet switch, we will have to give that a shot once back at our lab. I just wanted to know if anyone had encountered this issue, or if there was a known problem with network bridging camera streams. I can mess around with versions to see if previous supported BlueOS versions may have worked.
If there’s another way to pass the NMEA output from Waterlinked to Mavlink, we’d love to hear. I worked on the MicroNav system and had success passing that along UDP to port 27000, but it seems like I am failing at using the NMEA bridge furnished by WL. For that, I tried to pass it along 192.168.2.1:8000, but the ROV saw nothing once red-pill and nc -ul 8000.
Also, I have seen that the video stream tab in BlueOS goes to “No video streams available” and I need to refresh the page to see the snapshot of the camera once bridged. When I refresh, it seems as though the ROV is trying to send camera input to QGC, as it turns grey; in the end, it still cuts out.
I’m wondering if the network is just too busy that it can’t handle a video stream in addition to the GPS.
On another note, does the WL UGPS extension work over wifi? We have had success seeing position on WL’s UI (192.168.2.94) while connected to the UGPS wifi with QGC video via FXTI. Really, we just need to pass the UGPS data to Sonarview to get georeferenced side-scan data. We are happy to use WL’s UI for navigation, and we’d like to see vieo while doing so. In an ideal world, mavlink would collect all data and pass it to sonarview, but the lack of camera in our current setup is disconcerting.
Hi @tritonkeller -
It may worth reaching out to WaterLinked, as Blue Robotics doesn’t sell this device and they may have encountered this issue before. It definitely seems related to something going on with the Windows bridge, and IP addresses - potentially a conflict or forwarding rules that are preventing communications. When the bridge is active, you can reach both BlueOS and the WaterLinked interface at their respective IP’s, correct?
If you could download the BlueOS system logs, from the gear icon in the lower left, and share them here we could see if MavLink camera manager is behaving strangely.
Theoretically, when using a bridged connection your computer should essentially be acting as an ethernet switch - have all the Windows Firewalls been disabled?
With the WaterLinked device not connected, but the bridge still active in Windows, does the video work nominally?
Hi Tony,
I am happy to share the BlueOS logs once I get back the laptop we used on deployment. We actually tried a Mac, and the network bridge worked perfectly. I was thinking of attempting to use WSL to bridge the connections and try again, but that’ll have to wait until our equipment gets shipped back to our lab.
To answer your question: yes, both Waterlinked and BlueOS are reachable at their respective IP’s when bridged. I will test if the bridge active, but WL disconnected, will still fail to send camera feed. All Windows firewalls were disabled when testing.
Thanks!
1 Like
