Sorry you’ve had an issue. It’s worth noting that it is NOT ADVISED to use master BlueOS and expect stable or normal function! This is where development happens, and as a result things, especially combinations with other software, don’t always work.
The DWE extension in BlueOS currently only allows for adjustment of the bitrate, are you using it for another reason?
Are you using Cockpit or QGround Control? What version?
You should see the camera stream in the Video Streams menu in BlueOS, and if configured for RTSP adjust for this in QGround Control (it just works in Cockpit). UDP is the default.
If you continue to have issues, please check if it is potentially the hardware by going to the Terminal (in pirate mode in BlueOS), take the red-pill and then type dmesg and press enter. Look through that log to see if a USB device is connecting/disconnecting - if the data wires aren’t twisted properly, the connection can have issues and the Raspberry Pi is particularly sensitive to this!
I’m curious what aspects of the older method worked better for you - have you always been using master instead of the stable branch of BlueOS?
I’m currently rebuilding a new electronics enclosure for a Blue Robotics–based ROV and revisiting this topic with some updated understanding.
In earlier testing, what initially appeared to be latency with the DeepWater Exploration (DWE) cameras turned out to be primarily severe pixelation / image corruption, especially when used alongside a Blue Robotics USB camera on the same Raspberry Pi / Navigator system.
For the new build, the intended setup is:
Two DeepWater Exploration (DWE) HD cameras
One Blue Robotics USB camera
Raspberry Pi + Navigator
BlueOS in use (with other required control software running in parallel)
Before finalizing the electronics and software architecture, I’d like to ask:
Has anyone, as of 2025/2026, successfully and reliably run one or more DWE cameras together with a Blue Robotics camera on the same ROV without pixelation or stream instability?
Hi @SDI -
Yes, 2x exploreHD + standard USB low-light has been tested as functional and stable. The biggest potential limitation is bandwidth - before setting up the camera streams, measure your tether bandwidth with the network test. The number that results should be higher than 35-45 Mbps if you’d like to stream at full resolution. Using a Pi4 is also important for this application.
If you have issues, installing the DWEOS extension and lowering the bitrate should help. Additionally, setting up the video streams as RTSP instead of UDP streams will mean they only consume bandwidth when streaming to Cockpit. QGC does not support multiple video streams.
Tony, Happy New Year and thank you for the reply. If I understand you correct, we have to say goodby to QGC and start using Cockpit? Is the DWEOS extension ready available inside the BlueOs Add-ons ?
Hi @SDI -
Happy new year!
Blue Robotics stopped testing QGC after version 4.2.8, and has been focused on developing Cockpit as a far more capable and easier to customize platform - with support for multiple simultaneous video streams being rock solid in my experience. If you’d like to view (and record) all the streams at once, Cockpit is indeed required.
Yes, the DWE OS extension is in the BlueOS Extension store, and it should recognize each of the connected cameras. It only functions to adjust the bitrate between 1 and 15 Mbps.
Ok, understood. 15Mbps setting creates pixelation in our current set-up. We have it on VBR. Have you sucsessfully tested DWE cams through cockpit with 15Mbps ?
Hi @SDI -
I’ve not tested that specific setup. Does mowing t the bitrate or removing a stream resolve the issue? What version of BlueOS and Cockpit are you using?
We recently purchased a new Raspberry Pi 4 and a Navigator before Christmas, and we are not sure what is currently on the SD card.
Speaking from experience—starting from the beginning of this thread—our operational ROV is running QGroundControl 4.2.8 (as far as I recall) and uses BlueOS and DWE OS running side by side. The system has one Blue Robotics camera and one DWE camera connected.
However, getting this setup to work reliably has been a challenge, to say the least. It has been almost 2years since I first combined BlueOS and DWE OS, and a significant amount of time has been spent troubleshooting.
As Im now in the making of a new project I was hoping that by now more people would be running a similar setup and that a stable, more plug-and-play solution would exist.
Hi @SDI -
How did you install DWE OS? Doing so without the extension from the store is not recommended or supported…
Results of a network speed test on your tether would be informative!
Blue Robotics has sold over 350 exploreHD cameras, so I imagine most people are following the setup guide and not having any issues!
It’s worth noting that Qground control runs on your laptop, not the ROV!
When I originally struggled with this setup almost two years ago, there was no consolidated, supported workflow for running a DWE exploreHD alongside a Blue Robotics camera on BlueOS. At that time, there was extensive back-and-forth in this thread, and DWE was directly involved in the troubleshooting. The only way we were ultimately able to get a workable system was by running two operational systems in parallel, which was clearly not an ideal or sustainable solution for real-world operations.
I now see that there is a new, well-structured setup guide, published in June 2025 and updated in July 2025, that clearly documents a supported approach for integrating the DWE exploreHD with BlueROV and BlueOS. That represents a significant improvement and helps explain why the experience today is very different from what it was back then.
This isn’t about questioning whether the camera works — it’s about acknowledging that the ecosystem and documentation have matured substantially since that earlier timeframe.
Thanks for pointing me toward the updated guide. This is exactly the kind of stable, repeatable, field-ready solution I was hoping would exist by now, and it gives me confidence moving forward with the new build.