Loss of communication during dive

Blue Robotics Software
1

hello there ,

we have a problem with our rov ,

*during the last 2 dives after about an hour of work under water .
we experienced lost of communication .

here are the things i started doing:
i tried to deal with it by replacing the battery and the communication returned .(the voltage was14.3 before i replaced it )
i replaced the twins wires that come from the thetter to the fadom X
im thinking maybe its a question of temprature in the pixhawk ?

i will be happy for some guidance.

2

Here’s an ArduSub Troubleshooting Guide that’s useful for troubleshooting communication; Troubleshooting · GitBook

Whenever I don’t have communication or I lost it with the BlueROV2, I first check the connection by pinging the IP address of the BlueROV2 Companion Computer with “ping 192.168.2.2”.

3

hey there,
I have encountered some issues of losing video after about an hour of dive - when i use the thrusters it seems it has an affect on the video streaming .

4

Hi @roy.astral, welcome to the forum :slight_smile:

This seems quite odd. I can think of three potential reasons the thrusters could cause video stream issues:

  1. thrusters drawing a burst of power that causes the camera (and possibly other electronics) to be under-powered and lose connection - this would be more likely to occur as the battery voltage drains, so could be possible - we recommend a 5V6A BEC for powering the 5V electronics
    • are you using a less powerful BEC?
    • which battery are you using, and do you know the voltage it was at when the issue occurred?
    • did any other electronics stop at the same time? (e.g. did you also lose connection with the autopilot?)
  2. vibration wobbling/pulling on a strained connector (e.g. if the camera wire is very tight) and causing the camera to lose power - unlikely to occur, especially if this is consistently happening after about an hour of use
    • how many times has this happened?
    • do you have a custom ROV that vibrates quite a lot?
  3. the thruster wires causing signal noise that messes with the camera stream signal - this is unlikely particularly because if it was an issue it should occur for the whole dive, not after an hour
    • does your camera cable go close to the thruster wires (the blue/white/green wires from the ESCs)
    • does your camera cable have a twisted pair of wires for data (green/white pair assuming you’re using our USB camera)
5

@roy.astral I’ve merged your two posts because they seem to be about the same issue.

It seems like my point 1 in my response above is the issue you were experiencing, so it would be helpful if you could answer the follow-on questions I wrote there:

This is unlikely to be the problem. If anything overheats it’s more likely to be the Raspberry Pi companion computer, but it should thermal-throttle before that’s possible (slow itself down to avoid overheating). If that occurs there should be a ‘Throttling has occurred’ warning on the System page of the companion web interface.

6

hey eliot .
i wrote you last time that we had a lost of video connection . i stand correct it was total lost of communication after an hour of dive. i had to pull the rov by hand from the water .
and after i washed the rov and replaced the battery it worked again.
the voltage dropped to 14.3 at the time before i replaced the battery so i dont think its the battery fault.

for your questions :

  1. we are using the blue robotics BEC
    the battery max voltage is 16.4
  2. we have a new problem with the electronics - we have now lost one thruster functionality( the left up vertical) and the other vertical thruster start to work on their own once i armed the robot .
    3.the temprature i see in the display of the QGC is is for the pix hawk or the rasbbery pi ?
    and if it not the rasbbery pi how can i add i to the display >?
  3. do you have any suggestion in order to cool down the rasbbery pi ?
    5.it seem that the data conversion from the fadom x to the usb does’nt work well the communication doesnt linked at all using the usb conection . only when i use the rj45 network cable it seems to work smooth .

best regards roy k.

7

Agreed, 14.3V for a blue robotics battery should be fine.

Are you able to turn the propeller with your hand while the ROV is off? If not, it’s jammed and probably has something stuck in it (e.g. fishing line), if you can turn it then you have a broken connection between the thruster and its ESC or between the ESC and the Pixhawk, or your thrusters aren’t set up properly for your selected frame configuration.

Did you arm it while in depth hold mode? If so that’s a known occasional issue that we’re waiting on some logs for so we can confirm what’s going wrong. I’d suggest arming in manual mode and then turning on depth hold mode when you want to start maintaining a depth below the surface.

The Temperature (1) variable is the Pixhawk temperature. Temperature (2) is the external temperature measured by the Bar30, assuming you have a standard setup.

The companion (Raspberry Pi) temperature isn’t currently accessible from QGC - it needs to be accessed via the System page of the Companion Web Interface.

You can use an aluminium enclosure and/or install a fan in the enclosure to improve cooling, but it can also be helpful to avoid things getting hot in the first place by not running the thrusters at high throttle for extended periods (because the ESCs heat up), and reducing Raspberry Pi CPU load where possible (are you on the latest companion software?)

You mentioned earlier that you replaced the twisted pair from the tether to the Fathom-X. Did you also change the pair in the FXTI at the top? Only the blue-white twisted pair is connected by default (the other pairs are intended as expansion options for other purposes), so if you change the wires at the bottom but not the top then you’re relying entirely on parasitic capacitance along the tether for your signal transfer, which is understandably not as effective as having a wired connection.

If you only changed the bottom ones then I’d suggest you try changing that back to the blue-white pair, and running a network test of the tether connection. If the upload and download speed are both above 50 then your connection is fine, and if they’re over 20/30 then it should at least be workable. It may be worth doing a comparison with the direct network cable connection to see what kind of values you get with a short and very stable connection.