Hi all,
I ask for some help for a video problem. As you can see in the link below at 10sec and 20sec (but also further on and in most videos) there is a pixelation and sort of lost of imaging. I was wondering if there is anything we can do to fix it.
Also as soon as you touch the joistick to move it left and right the response is very sudden and quick, not very gradual (pilot gain 25%), while watching the other videos in the forum i didn’t noticed it so if you could help me or direct me to dome other topic that would be great.
We are using windows 10 with 8G of RAM and a i5-7200U CPU
Have you checked the “Low Latency” option in QGC options?
If it’s checked, try to uncheck it and see if you have any improvement. As the name indicates, you will have a little more latency in your video feed, but it will run smoother.
Otherwise, you have the same problem we are experiencing here. I have just come to the forum to check if somebody has the same issue we have, and found out your post.
So, I tried to uncheck the low latency mode option and do few tests. Watching at the videos afterward it seems that I don’t have the pixelation and the delay, BUT, it was almost impossible to pilot the ROV as the video stream was really bad, jumpy and delayed.
If the recorded video do not show such behaviour can I assume its a laptop problem, maybe graphic card?
We have been working on the same problem, lags in video and pixelation, that was most pronounced when we also viewed using goggles plugged into HDMI port. We upgraded our i5 Dell laptop with 8GB RAM to 16 GB RAM and a 1 TB SSD, suspecting that the laptop was the limiting factor. On the next trial with goggles we had the same problem, less so w/o goggles just the screen. BR support suggested “If the video is jittery, that is likely due to video rendering issues. If your laptop has a discrete GPU( it’s not immediately clear if it does with the provided manual), please try forcing QGC to use the discrete graphics card for video rendering with these instructions: https://www.addictivetips.com/windows-tips/force-app-to-use-dedicated-gpu-windows/. Make sure to update your graphics card drivers if they are outdated. You can also switch the video decode priority in the QGC Application Setting to determine if one works better. My colleague with a windows computer finds that forcing the DirectX option performs the best on their laptop. QGC also adds two additional shortcuts to launch it in GPU compatibility mode and a GPU safe mode; try both modes to see if there is any difference.” Those last settings in Fly View menu.
At the other end of the data stream, there have been problems with cameras, we currently are swapping out our second for a third.
Support has been… very supportive.
onward,
jj
It’s likely worth checking your umbilical to ROV interface, both internal and external.
If you can share logs of your video stream that will help.
If there is an abraded pair, or a loose connection on the internal JST connectors, this is the type of video behaviour I would expect.
If you run it up in an IBC (water container or pool) can you replicate the behaviour by putting some tension on the cable? Or playing with the thimble?
If not, then we can look at line noise or software. But the above would be my go to troubleshooting.
I brought this up internally and it was suggested that it may help to reduce the ACRO_YAW_P parameter, although that generally shouldn’t be necessary. Maybe try updating to the ArduSub 4.1.1 beta firmware first, and resetting your parameters, and if that doesn’t help then try adjusting ACRO_YAW_P
It doesn’t look to be a continuous issue, which means there’s likely something going on in software or hardware that’s causing reduced video communication bandwidth. Potential causes for that would be
it may be worth running a network test to see your general bandwidth availability
maybe try a different tether pair (if you have one)
maybe try bypassing the Fathom-X boards and tether entirely, with a direct ethernet connection from the onboard computer (Raspberry Pi) to your control station (topside) computer / to the ethernet-USB converter in the FXTI
excessive use of resources elsewhere on the onboard computer
I’d be interested to know whether you have the same issues using BlueOS instead of Companion
power supply issues
the camera and/or onboard computer may have issues when several thrusters are on strongly, especially if they turn on suddenly
visually that doesn’t seem to be what’s happening here, but if you’re concerned it could be helpful to limit maximum thrust
strong electrical noise
could cause communication signal issues when thrusters turn on, although that’s unexpected for differential signals like used by the Fathom-X
electronics overheating
the camera or onboard computer could be throttling or having occasional failures due to high temperatures
especially relevant if you have an acrylic enclosure and are operating in warm water
There could also be decoding issues at the surface (as @Jotakajota discussed), but I’d expect them to be more consistent, rather than decent performance for a while that momentarily goes bad from time to time.
If those suggestions don’t prove fruitful, feel free to reach out to our support email (support@bluerobotics.com), to let them know what’s going on, what you’ve tried so far, and how the vehicle has been used and stored. If possible it’s best to also specify your order number (or rough order date), so we can add the issue to our internal tracking and try to prevent similar issues happening in future (by quality testing, or by revised designs). If it turns out something is defective then you may be able to get a replacement or refund of the relevant part(s).
Agree, what made me think off the cuff it’s tether/connection is that when the fault appears on the video provided, it seems induced on yaw left, and yaw right, not particularly high demand moments, but certainly puts the umbilical in a certain orientation each time.
Then whilst at depth the increased drag on tether is heavier than when trying to replicate it on the bench. I’ve seen basic troubleshooting overlooked, as umbilical drag wasn’t factored in when the tech was attempting to replicate.
Hi everybody and thanks for the support and help.
Today we tested the ROV again paying attention to your suggestions and we found out two main issues; 1 if the laptop is not plugged in and we just work with the battery the live video stream is poor and jumpy; 2 on our fxti the usb port type B is a bit loose and this could have cause the pixelation.
Unfortunately due to bad weather condition we couldn’t test for too long the ROV but with theese informations in the next dives we ll try to understand if the issue is solved.
Thanks again
Good to hear you’ve found a couple of potential culprits.
If those don’t work out, you might find something else in this list from our troubleshooting page. I had forgotten about that, or I would have linked you to it in my original comment.
Thanks again, we did another test and it seems that if we power the laptop with external power source we don’t get the problem. We’ll LL keep testing
Thanks for the help
