Loss of communication as soon as AUTO is selected

is possible to pass the internet connection using a cable? Rj45 or USB

from the survey pc to the BlackberryPi?

Hi @juanjepalomeke -
ZeroTier can take 2-5 minutes to find a new “route” between devices. If you were connected via the BaseStation connection, but then lost this connection at extreme range, ZeroTier will no longer have the “shortest path” route it identified between the vehicle and your computer - the BaseStation WiFi. If left alone for that search period, it will find a route via the internet to your zerotier device, and connection will be automatically reestablished.
My suggestion is to use 4G communication for the entirety of your mission, so that a switch from WiFi to 4G doesn’t cause a period with no communication! To do this, you would point your mavlink endpoint in BlueOS at your computer’s ZeroTier address, and NOT connect BaseStation to your computer. Alternatively, you could do this with a cellphone running ZeroTier and QGC, and have the computer use the BaseStation - this way if connection is lost on the computer, you still have another device that can control the system. You could do this with another laptop instead of a phone too!

LOITER mode on loss of connection failsafe is only available on ArduRover 4.7 beta - HOLD mode turns the motors off and lets the system drift away! I’ve had no issues with the continue if in Auto mode failsafe option - the system collects data onboard, and I maintain visual contact, so while there is the risk that I can’t stop the boat in this state, it at least will continue mapping and return to radio range if the mission was correctly planned.

If your survey PC is connected to the 4G internet router with an ethernet cable, then another ethernet cable could connect to an ethernet switch in the BlueBoat, but the IP addresses would need to be correctly configured. It is simpler to use the Pi WiFi as you mentioned, or whatever generic router in the boat to connect via WiFi - I don’t think that connection is causing your issue.

Hello there,

We use the Blueboat’s Wi-Fi connection only to share internet between the suitcase mounted on the Blueboat and the Pi; the BaseStation is not being used. Communications between the ground and the rover are done via ZeroTier over the internet. The communication loss problem is between the pelicase and the Blueboat, at a distance of barely 30 centimeters, hence the inquiry.

We need to solve the lost of coms from the pelicase to the wifi of the boat…

We dont know from where comes the problem, maybe excessive UHF noise within the port or microwave emissions—I have no idea about this. What we need is a safer option to prevent these problems. If it could be a cable, perhaps we could eliminate the uncertainty…

But it’s just a thought; maybe we’re simply doing something wrong.

Whats your suggestion?

Thanks

Hi @juanjepalomeke -
My apologies, I didn’t realize you weren’t using a base station.
It’s very strange the WiFi is blocked at such short range.
If you fit the BlueBoat with an Ethernet switch, and connect the Pi, Mikrotik, and your suitcase internet source via ethernet cables, the connection will only fail if the cellular data connection is lost!

Using the BaseStation with an antenna mast and directional antenna can easily reach 1-2km line of sight - this may be a good fall back option?

Good morning Toni.

I’m sending you the logs of what happened to us on Friday. The communication was constantly dropping, it would come back for a few seconds and then drop again, although in the logs it doesn’t appear that clearly.

Let’s see if you can give us a hand and clearly see what is happening to us.

Then, aside from this, I have other questions that I want to address to see if we can alleviate the problem a bit.

1. I want to configure the internal GPS of the Blue Boat to have it as support in case the external GPS fails. I wanted to know if, even though I have the external one set as primary and indicating that I want to use only the primary, if it stopped sending data, would the primary switch to the internal one?

2. Is it possible to know in the USV LOG which WiFi it is connected to? Just to know if we had problems because it connected to a different WiFi…

3. I see some messages in the LOGs about altitude and other things, but I wanted to know, do the elevations affect in any way whether it could cause problems? When you define a mission, does it matter what elevations you set at the waypoints, should they all have the same elevation? It’s just to deactivate all this since this is a boat.

Thank you very much for your help, truly, we are having problems but we are learning more and more about the Blue Boat and honestly, when it works well, it’s wonderful.

Hi @Pulsar79 -
Thanks for the logs, we’ll review them! The .tlogs should show when heartbeat connection was lost…
Is your own connection to the internet stable? Running “ping 8.8.8.8” would let you monitor your local connection to the internet - if it is missing pings, that may explain why you’re losing connection on occasion.

In answer to your questions -

  1. Yes, you can simply setup the internal GPS as GPS2, and configure it to be used as fallback. Checkout the gps autoswitch parameter.
  2. The WiFi information is likely not recorded, but if it is it would be in the BlueOS system log - download via the gear icon in the lower left of BlueOS.
  3. Elevations for waypoints do not affect the BlueBoat navigation. The GPS elevation is recorded by SonarView, but newer versions allow you to lock the data to 0 altitude when reviewing.

Okay Toni, there’s no interference problem, it’s true that sometimes the Internet is slow, but that wasn’t what happened to us.

Today, when going to test, we set the propellers to MANUAL, and the communication was lost right when I did that. I tested the propellers individually and the port one works, but the starboard one doesn’t move when I activate it and the communication is lost.

Could it be that it got damaged and is generating a current spike that causes the Raspberry to reboot? What usually breaks, the motor or the ESC?

Hi @Pulsar79 -
I don’t think a problem with the motor or ESC would cause the Raspberry Pi to reboot. Did the Navlight stop flashing when your lost communications? If not, the Pi is continuing to function just fine.
Can you confirm what version of BlueOS you’re using? 1.4.3 stable?
Is the starboard motor still not functioning? Does it turn easily by hand?

Hi Toni, sorry for not having replied.

Last week I was in Barcelona to change the motor, and being there on-site, when I moved the joystick the motor moved a little and then immediately stopped and lost communication, so we decided to change the ESC, which we also saw seemed to have a bit of salt, as if a little water had gotten in.

We changed the ESC and everything worked right away on the first try. Thanks.