Two ExploreHD cameras on a BlueBoat (BlueOS, Navigator). Connecting one causes the whole vehicle connection to drop — not just video, MAVLink/Cockpit too. Unplug and it recovers instantly. Happens with both of our units; a different USB camera model (BlueROV’s) works fine on the same Pi.
Ruled out today: power/undervoltage (vcgencmd get_throttled = 0x0), USB autosuspend (disabled, no change), CPU thermal (~50°C), BlueOS version (updated, no change), kernel (updated from a 2021 5.10 kernel to 2023 6.1, no change), stream count/bandwidth/resolution (tested every combination).
dmesg consistently shows the same signature: camera enumerates, then disconnects itself a few seconds to a couple minutes later, followed by a burst of uvcvideo: Failed to resubmit video URB (-19) and xhci_hcd: ERROR Transfer event for disabled endpoint. Watching top during a failure shows mavlink-camera-manager spiking to 100%+ CPU and ballooning in memory, with zerotier-one (our remote link) spiking right alongside it.
The key test: we ran this over both our cellular/ZeroTier link and a direct Ethernet connection from the Pi to a laptop. In both cases, the exact same dmesg errors appear — the underlying USB glitch happens regardless of network path. The difference is only in the consequence: over cellular, the resource spike has enough impact to starve zerotier-one and drop the whole connection; over direct Ethernet, there’s enough CPU/bandwidth headroom that the same glitch never visibly breaks anything. So testing over Ethernet looks “fine” but doesn’t actually mean the camera issue is gone — it’s just not being felt.
Is this a known ExploreHD issue? Any recommended fix?
I can confirm that this is not a software issue, but most likely a hardware one. The Pi on the BlueBoat doesn’t have much spare current capacity for connected devices, so to use one more cameras you’ll need to connect them to a dedicated 5V source. This is done by removing the red 5V wire from the JST connector at the PCB USB adapter, and connecting it to the 5V supply output. A multimeter should show that the Pi USB ground is tied to the auxiliary 5V power supply output ground as well.
What version of BlueOS are you running? The MCM in the 1.4 beta versions has significant updates, so may handle this flaky power issue a bit more gracefully - however I at the end of the day I think @CA_BlueBoat 's recommendation matches my own - you need a dedicated 5V power source!
We thought about this solution but ruled it out since it all worked fine once we tested the system with a direct ethernet line connection as opposed to mobile comm. Using BlueOS 1.4.3.
Anyway we’ll try both solutions of using an external power and updating to beta version.
I think the issue is USB power, and when working with ZeroTier it makes itself more apparent? But the dmesg errors mean the camera is having power issues, and they don’t go away over Ethernet.
Keep in mind the default camera stream from the exploreHD is 10Mbit - you’ll get much better performance if you lower that to 2Mbit, which you can do via a slider in the DWE OS extension.