We are having communication problems (COMM LOST) with the USV.
My USV has a suitcase on it with a PC. There is a Wi-Fi router that provides internet to the PC via cable, and to the Raspberry Pi via Wi-Fi. Since when Comm Lost happens in QGroundControl we remain connected to the PC via remote desktop, I would like to know if it is possible through the LOGs to find out whether we really lost communication because the Raspberry Pi restarted (which already happened to us with a defective ESC that was replaced) or if it is really because the Wi-Fi is being lost. If it can be seen in the LOGs, which parameters should be looked at?
I think we need a bit more information to provide useful feedback. Is your USV custom, or what model is it?
If I understand correctly, you’re using a Raspberry Pi with Navigator to host your autopilot? It reaches your control computer by connecting to a WiFi router on the vessel- does your control computer connect to the same WiFi network as the Pi then?
How have you configure a BlueOS Mavlink Endpoint to point at your control computer? Is connecting the pi to the WiFi router on the vessel via ethernet cable not an option?
The .BIN logs on the vehicle capture autopilot telemetry, things like GPS location and orientation, and messages that would be sent to a GCS - regardless of connection status. The BlueOS logs (assuming you’re using BlueOS) may capture some elements of networking? What type of WiFi hardware are you using? Mikrotik?
My USV is like the one you sell (BlueBoat), but a suitcase has been added on top that carries a PC and has communication with a multibeam probe (I explain this in previous messages). The Raspberry with the Navigator uses BlueOS and gets internet through the wifi provided by this router:
The PC gets internet directly via cable from the router.
When we are doing the bathymetry, I have two monitors: one with QGroundControl to see the USV and give it the commands, and another monitor with remote desktop to the PC that is in the USV case. I am on land connected to another Wi-Fi that I have on land. Well, during the mission, it happens that QGroundControl several times shows “COMM LOST” but the PC in the case remains connected, so I understand that either the Wi-Fi connection between the Navigator board and the router (which is just above, less than 40 cm) is lost, or BlueOS may be restarting for whatever reason and everything is starting up again.
That is why I wanted to know if there is any message in the LOG that I can see: - ardupilot restarted, Wi-Fi connected again, etc.
Could you run a script on your windows computer onboard to ping the Pi WiFi IP? That would show you if it is losing connection… I don’t think the system is restarting, or you would lose all control of the vessel during start-up!
I’m a bit confused if you’re intending to access the autopilot via WiFi, or 4G cellular? Are you using ZeroTier?
Yes, I am using ZeroTier. The USV is 192.168.25.24 and the PC that goes in the case above the USV is 192.168.25.23. There is a TP-LINK router with a battery that provides internet to the PC via cable and to the USV via WiFi. But when there are communication errors, QGroundControl stops, pinging 192.168.25.24 does not respond, however, I am connected via remote desktop to 192.168.25.23, which is the PC in the case.
Could it be that the WiFi is failing? On some bathymetry runs when it returned, the antenna had come out of the WiFi connector, and they had told me that the WiFi in the USV can burn out if the antenna is not connected.
When you say the WiFi antenna came out of its connector, do you mean the primary WiFi antenna on the BlueBoat connected to the Mikrotik? This is NOT the antenna for the Pi WiFi icon in BlueOS - that is the onboard WiFi radio. I had thought you were using the Pi WiFi to connect to your TP-Link? However, if the Mikrotik is powered on with no antenna, this WILL damage the radio and make long-range connection to the BaseStation (or even short range) poor…
If you can ping the PC via zerotier, but not the Pi, the zerotier process may be switching from routing over the internet to routing over the Mikrotik radio connection, or vice-versa. This process can take 2-5 minutes typically…Zerotier always finds the “shortest” route between devices!
Remote desktop uses significant bandwidth! I would guess the data usage may be “squeezing” the Pi out of the connection. Generally I discourage installation of additional Windows PC in BlueBoat, as it’s typically possible to connect whatever hardware directly to the Raspberry Pi and log the data onboard… What is driving your use of the Windows PC?
I am referring to the antenna that should go into that connector that is at the top left of the image, and that goes to that gray cylinder which is a wifi radio, right?
I mainly use a Windows PC because the multibeam probe we use runs a program for Windows (it’s old) and I need the PC to record the data. For remote desktop, I use UltraVNC with fewer colors to use less bandwidth.
Yes, that Mikrotik radio is used by the Pi for long-range communications. It shows up as an ethernet connection in BlueOS. The WiFi icon in BlueOS controls the built in radio on the PCB of the Raspberry Pi!
If you have used that gray cylinder without an antenna, it may be damaged - are you still able to get a connection via the Base Station at long range?
Note that your WiFi connection from the Pi to the TP-Link does not use that, unless you configured the connection at 192.168.2.4 (the Mikrotik radio on boat interface, .2.3 is the BaseStation.)
Okay, so the WIFI connection that the Raspberry uses to connect to the TP-LINK router is a wifi that is built into the Raspberry on its board, right? And that wifi doesn’t have an antenna, can the coverage be improved?
This gray cylinder is only used for connection with the base station radio…
I communicate with the Raspberry through Zerotier by forming the private network.
Correct, the onboard WiFi is what is connecting to your TP-Link router, and there is no way to improve that signal - at close range, it shouldn’t have any issues!
As I’ve tried to explain, I think what is happening is that your ZeroTier connection is switching between using the BaseStation and the internet provided by the TP-Link - this process takes some time and can be annoying! To avoid this switch, don’t connect to the BaseStation at all! That way, the ZeroTier route will consistently go over the internet, rather than the shorter “path” via the BaseStation. If both the BlueBoat and your computer have internet access, but also can reach reach each other via the BaseStation, ZeroTier will always choose to use the BaseStation as it is the shortest route. However when signal from this connection fails, the transfer to using the internet route can take 3-5 minutes to switch too - I believe this is what is happening when you lose connection to the Pi, but can still remote-desktop…
But one thing, I don’t have the base connected. I mean, in fact, the person who sold me the BlueBoat told me not to even set it up, that it was better to use only 4G. So, I have it stored away.
Do I need to disconnect anything else via software on the Raspberry? And if this doesn’t matter, what else could be happening?
That the bandwidth drops, preferably to the PC that is connected by cable to the router?
