Lost contact with rov and blueos

hello

good morning.

after a dive, the next day, to make a new dive, i plugged in the battery and couldn’t connect. no response to the ping.

i had to flash the micro sd card, reinstall everything and calibrate.

auto-tuning of motors with qground control ok, short dive to 5m to check everything, all ok.

i left everything connected and switched on, and once on the dive site, connection lost again.

i changed the battery. rebooted the pc, no contact with blueos …

we came back this morning from sicily, i have to try again

we copied the sd card on the computer. flash again the sd card with blueos 1.4.0 for rasberry.
still green flashes on the rasberry.
we had put the sd card into another rasberry, it works and no green falshes…
are you thinking of a rasberry problem like me ?

tomorrow we connect the other rasberry on to the fathom and serial cards to test

Hi @deny -
Sorry to hear of your issue! Could you perhaps need to wait longer for the Raspberry Pi to boot and BlueOS to be possible to load at 192.168.2.2? It will generally take 1-3 minutes to start up, and you’ll hear a confirmation beep from the thrusters when this “ready” state is reached… if this beep (after the initial beeps on connecting batteries) never comes, then the Pi may indeed be failing to start up.
If you’re able to connect a micro HDMI to HDMI adapter to the Pi 4, you could monitor the boot-up sequence with a monitor or TV, and see if something is going wrong… If nothing is displayed, the Pi may be damaged.

the second beep come but nothing … no response at 192.168.2.2

Hi @deny -
Are the traffic (green/orange) lights flashing on the Raspberry Pi Ethernet port?
If the second beep is coming, have you tried connecting an ethernet cable directly from the Pi port to your computer, to eliminate the tether interface as the source of your issue?

hello.

we copy the micro sd card. Could you load the log files from this copy ?
https://we.tl/t-f1HNs1148P

we can connect to blueOS with an ethernet cable connected onto the rasberry card.

we have no connexion when use the fathom and the FXTI box.
on the FXTI box, the green led “LINK” switch off after few seconds when we plug it onto the computer.
the network adapter in windows no longer appears when the FXTI box is plugged in

cordially

Hi @deny -
The log files are much smaller than an SD card image - and I’m not sure if we can retrieve them from the copy of the entire SD card you made!

It seems like your issue isn’t with the Pi at all if it works with a normal ethernet cable - but with the tether connection. You can check (and please share) the resistance of the tether pair used, and verify it is similar for both wires in the twisted pair that is connected.

You can try using another pair, making the switch in the ROV and the topside FXTI box. Also, the BlueOS extension “Tether Diagnostic” communicates with the Fathom-X tether interface - a screenshot of that can be helpful in troubleshooting.

You simply won’t have connection unless the link light comes on, and never goes off!

i didn’t find the “Tether diagnostic” :slightly_frowning_face:

i will check tomorrow.

have a nice day


Hi @deny -
The Tether Diagnostic installation must be installed from the Extensions manager - its icon looks like:


If your tether isn’t connecting, you can reach the vehicle via its WiFi connection / IP on your local network.

ok

thanks

hello

after two days of test … :thinking:
when we connect the Rov fathom board directly to the fxti fathom board (with two wires between green terminal blocks, we can connect to blueOS and the graph in tether diagnostics rise and stay at 150 Mbps.
when we connect with the 300m tether (directly from the rov board because we cut the “suspected” cobalt connector, to the fxti by the binder 770) we have the connexion with difficulties, and speed fall at 50mbps with cuts.

when we use the 300m cable on the spool, and the “binder cable” between the spool and the fxti, it does’nt work… no conexion.

could the fathom be involved ?

Hi,
I’m experiencing a similar issue as @deny. In my case, I was able to connect to my BlueROV2 R3 earlier today (both BlueOS and QGC were accessible). However, after disconnecting and reconnecting the battery within a 30-minute span, I suddenly lost access to both BlueOS and QGC.

Ping 192.168.2.1 gives the following outputs (the first one more frequently):

I have my network set up correctly (192.168.2.1 static ip address on the ethernet port). The ROV powers up and makes the right sounds. I’ve gone through the troubleshooting guide - in particular I’ve done the following:
→ turned off antivirus and firewall software
→ rebooted computer (windows 11)
→ made sure that QGC is configured to automatically connect to UDP and USB links

I’ve also checked that the SD card of the RPi is detected in my computer, as suggested here.

  • Pixhawk 1 LED behaviour is as follows:
    FMU PWR=solid green
    IO PWR=solid green
    ACT=flashing blue
    Main LED=flashing blue

  • FXTI has solid green Power and Link lights.
  • Raspberry Pi 3B has solid red PWR light and flashing green ACT light.

RPi ethernet port LEDs don’t seem to be flashing (see video). As I understand, a steady green light means there’s no data traffic:

How can this be done? I’ve connected the RPi to a TV and it appears to boot (see photo), but when I connect it to my computer via HDMI, I’m still unable to access BlueOS. I would imagine this is because of no data traffic through the RPi.

I have also tried to access BlueOS from a different computer without any success.

I find it really strange that in just 30 minutes I went from being able to access the ROV to completely losing connection. During that time, I was making some modifications to the Newton gripper outside (in a shaded area), and two things might have happened:

  1. I may have stepped on the tether cable once or twice, but nothing serious.
  2. I left the battery connected for a brief period of time (10-15min?)

I see both as unlikely causes of the connection loss with the ROV, but nothing significant happened aside from that. Any idea of how to revert this? What could have caused this??
Thanks.

Hi @deny and @eri3t -
Both of your issues are definitely related to the tether or Fathom-X tether interface module. A solid link light is necessary for TCP/IP communications over the two wires - without it you have no way of communicating !
The ~40 ohms @deny is seeing is expected for 300m Fathom tether - have you tried using an alternative tether pair in the Fathom-X tether? The orange, brown or green pair may be sufficient to establish a link…
@deny please share the lower half ot he page of the tether diagnostics extension - generally the graph you shared indicates that connection is intermittent, so I’d guess something is loose somewhere! You could disconnect the slip ring, and connect the tether from the center of the spool straight to the FXTI to see if you have an issue on the spool.

@eri3t give that tether diagnostic extension a try and share your results!

Hi @tony-white ,
I installed the BlueOS image on another microSD, and I was able to access to blueos.local through the tether connection. Some strange things happened (e.g. I was able to access to BlueOS when I choose “Obtain an IP adress automatically” on my computer, instead of 192.168.2.1), but now this is back to normal. I still can’t access with the microSD I was using before. Maybe it got corrupted? What are the reasons that can make this happen?

The teather diagnostic is the following. Do you still think this issue is related to the tether or the Fathom-X tether interface module?


I believe the low fall of Mbps of the pink line happend when the computer entered in sleep mode.

Because I installed BlueOS on a new microSD card, I had to reinstall the ArduSub firmware and reload my parameters. I ONLY have a video feed in QGC, but not in Cockpit. I can still control the camera, lights, thrusters… in Cockpit, but there’s no video.

In QGC, I no longer see the dropdown menu I previously used for camera settings—I can’t choose between H264 or RTSP anymore, only the file format mkv, mov, or mp4.

In Cockpit, I’m also seeing additional video devices (?) that I hadn’t seen before (I used to see only my H264 USB camera option: /dev/video2).

Despite having a video feed in QGC, the joystick controls are all messed up. The worst part is the left stick—it’s usually used to move forward, backward, and laterally (left/right), but now it’s controlling the lights and gain. I don’t know how to change the stick functions. At the same time, the directional pad is currently controlling the thrusters, but there’s no modulation.

In the photo I shared in the previous post (when the RPi was booting), there’s a line that says: “IP address is 192.168.1.40”.
Update: I’ve connected the RPi to a monitor, and confirmed that the IP is correct (192.168.2.2), but I’m still confused why the other IP showed up.

Hi @eri3t -
The 1.40 IP may be related to the WiFI IP of the system on your local network, if you’ve connected BlueOS to it before?

As your issue seems to be intermittent, the tether diagnostic graph looks ok, except for that drop in the pink line. Unless the USB port power was turned off when the system went to sleep, that should have no impact on the connection. I’d recommend moving your connections around, particularly the USB cable, to see if the connection can be affected and the bad link point isolated…

What version of QGC are you using? Note we only recommend / support version 4.2.8.

I’d bet that additional video streams were created, perhaps due to a flaky USB connection. You should be able to get video in Cockpit going by selecting other streams for the video player widget under the edit interface menu?

The control mapping issue you describe is quite bizarre! What type of controller are you using? Loading the default vehicle parameters (under the vehicle setup menu) may correct this?

Hi @tony-white ,
thanks fo the assistance, it solved the problem.

I use v4.2.4. Since it’s now working, I’ll leave it as it is.

How strange… Can/should I delete the ones I’m not using? Video in Cockpit was recovered after changing the stream to UDP Stream 0 :+1:.

I’m using the f710 logitech controller. After reseting the parameters to the firmware default, and loading the recomended parameters (heavy), everything came back to the usual control setup.

Just to know for another time, could my problem be related to BlueOS getting corrupted? Can this happen after systematic overheating of the RPi?

Thanks for the help,
Eric.