I hoping someone can help. I have always had glitches on the video stream and no matter what I tried I am unable to get rid of this. It doesn’t happen when on my desk but as soon as it goes in the water I get a grey blocky screen. I have checked my settings and as far as I can tell it’s all setup as it should be. I have also tried running QGC with Nvida graphics processor and no change.
I have also noticed that sometimes my recording automatically stops but I have not selected this in the settings?
I am currently using: The latest companion V0.0.26 and QGC rolled back to V4.0.11 and companion is V4.0.3. (I was getting same issue with the latest QGC but rolled back due to other instabilities)
I have an inspection job coming up and need resolve this issue
Hi!
Have you tried different settings of graphics in QGC?
In version 4.0.x you can choses between “software”, “hardware” and “Force Directx3D”
For me “Force Directx” has no glitches where “nVidia hardware” have some minor.
Also i have seen BR still recommends QGC 4.0.6 of some reason, but i use 4.0.12
I’m assuming this isnt a setting in QGC program itself but more when you open the QGC by right clicking the program and the clicking run with graphics processor? Originally I was running the intergrated graphics (default) but had glitches, I then selected open with high performance nvidia graphics but still get the same results.
If this is not where you choose it can you advise where it is for you? I have checked my setup and currently running Direct X12. After opening up the the nvidia control panel I have an option in the MSI afterburner to change the master graphics processor selection to the Intel UHD Graphics. I will try this and provide an update
Hi! @Blizzard257
The graphics settings I’m talking about is within QGC 4.0.x
Upper left corner, Klick the “Q”
Chose “Application settings”
In the top section you have a scrollbox “Video decode priority”
Try the different settings here
I do not know if this QGC setting can override what you do when you select graphics before starting QGC as you describe above, but try change that to if needed.
Strange I don’t have the option within my current QGS for “video decode priority” ?
Changing the graphics setup prior to opening has however made it a little better. I will download the latest QGC and see if this also resolves the remaining few glitches, maybe the option to change video decoding priority will show up in the newer version of QGC for me. And will provide feedback on here too.
Yes exactly, I don’t have this option on mine on any version previously had.
I did have the latest QGC but had to roll it back to an slightly older version of QGC as it wouldn’t communicate with the bluerov2 so maybe if reload the latest QGC it may show up will re attempt to download the latest one and will post an update.
@Boko
Using the same versions as you I no longer experienced any glitching every few seconds. Do you also constantly get the no gps lock in the middle of the viewing screen.
Did a pipe inspection full length of 300m tether out with no issues, the following week a pipe inspection of 80m but had to return to physically reboot the rov by unplugging the battery. sent up up the pipe and and had same issue at 80m although the feed came back on its own, have you experienced anything similar?
Are you aware of the rebooting functionality available in the companion web interface? You can restart the companion raspberry pi from there if you need to - just be aware that you won’t have control over the ROV, or any telemetry data or video/audio stream while it’s restarting.
Assuming you’re using a standard BlueROV2 electronics setup, the companion computer will automatically restart the video stream within 5 seconds if it drops out for some reason but is recoverable. That’s done here in case you’re interested
@Blizzard257 Back onshore…
I do have "“no GPS lock” display on 4.1.2, but as soon as I start Underwater GPS it disappears.
No restarting of ROV needed for video stream reasons, running like 30 hours last week.
The issue is for ROVs that don’t have a GPS connected the message comes up anyway and doesn’t go away. There’s a fix in the thread I linked to, although it’s not yet in a release so requires building from source. With a GPS actually connected the message is working as expected.
