Hello everyone- I recently tested my Blue Boat and experienced some troubling behavior. I used the standard Base Station wifi connection with the Base Station elevated approximately 3 m ASL. Initially the boat behaved properly but then I experienced non-stop ‘communication lost/communication regained.’ Of course this was after I piloted the blue boat 100 m from shore. Disconnecting and reconnecting was annoying but the troubling behavior began when controller inputs were not recognized. A small forward tap on the stick intended to produce a short burst of thrust instead resulted in a runaway full-throttle panic-inducing period that probably only lasted 5 seconds but felt like an eternity. During this time the boat did not respond to any controller inputs, though QGC kindly informed me that the vehicle failed to respond to the disarm command. Luckily the boat stopped, but the behavior continued when I tried to turn it around towards shore (my thinking was that a runaway boat pointed towards should would at least beach unharmed on the sand). Instead of a small turn the boat turned uncontrollably, completing ignoring the controller. I don’t know if this is a base station wifi connection problem, blue tooth between controller and laptop, or some strange ardupilot parameter issue? The most annoying part is that everything worked perfectly during the last deployment. What do I do?
Hi @nuballawalla
Losing communication at about 100m is typical, if you’re not using a directional antenna or antenna mast. When at the edge of range, the vehicle continuing to do the last command it was sent in manual mode is expected, until the 5 second default FS_TIMEOUT period elapses. It seems you may have FS_ACTION set to HOLD, which just turns the motors off. You may want to set this to RTL, or update to the latest beta ArduRover (under BlueOS Autopilot Firmware) so you can set this to 6, for loiter (need to click override checkbox to enter this value.) You can read more on this in the operators guide.
Generally, when operating at the end of range I prefer to let the boat drive itself, in either auto or guided mode. When in situations like what you describe, simply right clicking on the map and choosing “go here” can pull the vehicle safely back in range. It may take a few tries for the command to go through, but when it does the boat will navigate with confidence. I generally avoid operating the BlueBoat manually for more than launch and recovery! It is better at driving itself then a human pilot in most scenarios…
If you’ve operated either the BaseStation or BlueBoat with the antenna not connected, the radio may have been damaged, which would further impact the maximum range…
When you say things worked perfectly on the last deployment, were you operating at similar distances? The Mikroitk Monitor extension allows you to log signal strength vs distance to a point you enter for your BaseStation location - this may be useful to troubleshoot your connection quality in the future. Operating in environments with many other WiFi networks can impact range!
Hi @tony-white - thanks for responding so quickly.
The loss of communication is not the issue and my first post summarized the most terrifying part of the experience, which happened at the edge of range. Unfortunately, the controller response issues persisted even when the boat was close to the Base Station. I’ll attempt to give you the history of this boat and maybe we can identify the problem(s). Also- the Boat and Base Station have only been used 4 times now and always with the antennae installed before power was applied.
First test: In a small boat marina from a dock. The Blue Boat was never more than 5 meters from the Base Station. During this first test the Blue Boat exhibited the same controller response behavior. Controller inputs were not recognized/carried out by the Blue Boat. What should have been a slow movement forward either resulted in no motor response or an uncontrolled burst of thrust. Turning was erratic. At the same time, QGC kept crashing. I was using a Mac so I thought it was an OS compatibility issue. I also conducted this first test with only one battery, as I simply wanted to check basic functions (like motor response under manual control). I chalked up the issues to Mac compatibility issues and perhaps an under-powered boat.
Second test: Swapped the mac for a Windows machine. 4 batteries installed on the Blue Boat. Everything worked perfectly. No detectable controller lag and the Blue Boat responded to every controller input as expected. Proper behavior in Auto, Loiter, and RTL modes, in addition to manual performance. Connection dropped after 150 m on an auto mission, but that was expected. Good video tranmission while connected. After this test, I thought I was good to go.
Actual deployment: Buoyed by the successful test, I set out on an actual mission. Same setup: Blue Boat with 4 batteries, same Windows laptop, same controller. I programmed an auto mission but on site I saw a sandbar that I needed to navigate around manually before starting the auto mission. I switched to manual mode and then the troubles started. At this point the boat was maybe 20 m from the Base Station. QGC ‘connection lost/connection regained’ loop began. Controller input was ignored or erratic. When a stick command was received it was like it was stuck. A short push forward resulted in 5-10 seconds of uncontrolled thrust. I tried to get the boat back, but by then it was around 100 m away, bringing us back to the situation in my original post. Once we finally got the boat back and under control I attempted to diagnose the problem. The same situation from the first test repeated itself. With the boat no more than 5 m from the Base Station controller input was random or ignored completely. Power cycling every component, replacing controller batteries- nothing worked. When QGC stopped it’s connection loop I couldn’t get to the Blue Boat parameters because the full parameter list could not be loaded.
Unfortunately, right clicking on the map was not possible because QGC generated so many messages that I first had to clear.
Auto mode seems to work, but I can’t reliably use the controller for launch and recovery. At the moment I have zero confidence in this system and no idea how to fix it.
Hi @nuballawalla -
That’s very unusual sounding, and definitely worth investigation - the extra detail beyond “worked perfectly during the last deployment” is certainly helpful!
Can you confirm-
How are you connecting to the BaseStation? If via USB, could the issue be related to the USB cable or port? Was the BaseStation fully charged during the misbehavior?
What BlueOS version are you using?
What ArduRover version are you using?
What version of QGround Control are you using? Have you tried Cockpit to see if the issue persists?
Can you share a .BIN log from a time when this communications issue surfaced? To be extra thorough, system logs from BlueOS (gear in lower left) will give even more context.
For reference - everything Blue Robotics is fully compatible with Mac, Windows, and Linux. Issues with QGC 4.2.8 on Mac do seem to include frequent crashing, but this also seems to correlate with newer versions of MacOS - I have long abandoned QGC in favor of Cockpit, but from what I recall deleting the app on Mac and reloading it from the DMG can help with crashing.
While using only one battery in a BlueBoat is not recommended, this is not because this makes the system underpowered - the same battery runs 6-8 thrusters (at higher power levels) in the BlueROV2 by itself! The issue is more about weight and balance - and as long as the only battery loaded isn’t completely in the nose, things are usually ok, if a touch less efficient.
Hi @tony-white, I connected to the BaseStation via WiFi. Now that I think about it, both times I had controller issues I connected to the BaseStation via WiFi. The successful test used USB-tethering.
I’ll check BlueOS and ArduRover versions when I’m back in the office - but I updated both in April of this year so they can’t be that old.
I don’t know which version of QGC is installed and I did not have Cockpit installed on the Windows laptop. I’ll try that.
I downloaded the .bin logs and uploaded them. I asked Claude to analyze the .bin logs and I pasted the results below.
I analyzed all 7 .BIN dataflash logs using pymavlink. Here’s what the flight controller itself recorded.
Log inventory
All 7 logs are from a single continuous power-on session on 2026-06-26 (TimeUS is continuous across 46→51), except 00000052, which is a separate reboot.
Key finding: repeated GCS heartbeat loss in 00000051.BIN
During the auto-mission run, the flight controller logged three distinct GCS Failsafe → GCS Failsafe Cleared cycles:
- t≈1239.7s → cleared after 11.0s
- t≈1266.5s → cleared after 9.2s
- t≈1404.6s → cleared after 19.6s
FS_TIMEOUT=5 means each of these represents a real ≥5s loss of MAVLink heartbeat from the GCS to the flight controller — not a brief packet drop. This matches your
description of “connection lost/communication regained” looping almost exactly. FS_GCS_ENABLE=2 means the boat’s programmed response was to keep executing the current
Auto mission rather than stop, which is why it didn’t behave dangerously here — but this same setting means if the boat had been in Manual mode during a dropout,
ArduPilot would apply Hold (not necessarily explain a throttle runaway).
I checked RCIN (raw joystick/RC channel data) across every manual-mode log (46,47,48,49,50,52) for frozen values or corrupted spikes that would explain the “small tap
→ full-throttle runaway” symptom — none showed dropouts or anomalous jumps; RCIN tracked smoothly with only ordinary stick movements. That specific incident is not
captured in these particular files — it likely happened on a different session/day than what’s in this logs/ folder, or the fault occurred upstream of the flight
controller (BaseStation Wi-Fi ↔ laptop link) in a way that wouldn’t show as corrupted RCIN, only as the FC simply not receiving new commands.
What this points to
The common thread across the forum report and this log is a Wi-Fi link between the topside computer and BaseStation dropping for several seconds at a time, consistent
with your own observation that USB-tethering the BaseStation eliminated the problem. The flight-controller-side logs corroborate the “connection lost/regained” pattern
but can’t diagnose why the Wi-Fi link drops (RSSI/interference/roaming/power-save on the Windows Wi-Fi adapter) — that data lives in the BlueOS system log or the
laptop’s Wi-Fi driver log, not the .BIN file.
Suggested next step: pull BlueOS’s syslog/network logs from the Pi (or Windows Event Viewer Wi-Fi diagnostics) for the same time window as log 51’s three dropouts, to
see if they correlate with Wi-Fi disassociation/roaming events — that would confirm the link layer as the root cause rather than anything in ArduPilot’s configuration.
logs.zip (8.7 MB)
Hi @nuballawalla -
Nothing new to me in your update - I’d expect things to work fine with good comms, and in poor comms situations it is best to not be driving manually! Connecting via USB can yield more speed and leaves your computer’s WiFi radio free to access the internet on other networks - however if it has a bad connection at the port, it can take more than 5 seconds to reinitialize the network adapter, and thus trigger the failsafe.
The browser version of Cockpit also “disconnects” from the vehicle if it is not in focus - so if you switched to another window, it would also trigger the failsafe after 5 seconds. This could be what happened when you had your issue at close range? This is a limitation of the Chrome browser, and is the primary reason why the BlueOS extension version is now called Cockpit Lite - it is not a limitation on the desktop version.
Sorry, but you are essentially saying that there’s no manual control of the vehicle.
There should be ‘good comms’ when the vehicle is within 5 m of the Base station, whether I connect the laptop via Wi-Fi or USB-tethering.
I expect manual inputs to respond appropriately to manual controller input when the vehicle is that close to the BaseStation. If you are saying it does not, then I cannot use the Blue Boat safely.
I am now even more confused.
If the WiFi connection between the laptop and the BaseStation is blocked, overly distant, or otherwise poor quality then that will understandably impact the effective connection between the laptop and the vehicle, regardless of how well the BaseStation is connected to the vehicle. The connection is a chain - both links must be working well for data to pass through.
It’s also worth noting that the BaseStation to vehicle connection can be poor if the vehicle is too close, especially if the antennas are offset vertically from each other or aren’t oriented well, but that’s not what the rest of the conversation was about.
Thanks.
Let’s back up and try something basic.
If Laptop, BaseStation, and BlueBoat are each spaced out by approximately 5 m should I expect controller input to be recognized by the BlueBoat in manual mode? Yes or no only please.
Hi @nuballawalla -
I don’t think I’m saying that at all! Sorry for the confusion.
I’m saying that your original situation, loss of control at close range, with the vehicle in manual mode and continuing on for 5 seconds until the failsafe was triggered, could only have been caused by:
- Brief disconnection of USB port linked to BaseStation
- Brief disconnection of Bluetooth controller from your computer
- If using Cockpit Lite, selecting a different window/tab or minimizing the browser
If the vehicle is in auto mode, it isn’t vulnerable to this type of issue (assuming your failsafe is set to this, and the vehicle is in auto or loiter mode.)
As Eliot points out, the same condition most commonly occurs at the edge of radio range, when separation is large. That’s why the vehicle, at least in most use cases, is primarily used in autonomous mode - so that it stays perfectly on course, far better than a human could drive it along a line, without issues caused by brief connection issues. It’s much less stressful to right click and select “go here” then to judge the heading of the vehicle from afar and drive with joysticks!
In answer to your most recent question, Yes, at 5m range with both antennas vertical, and your controller and GCS connected to the vehicle via the base station, things should always respond to user input in manual mode. If you’re not finding this to be the case, you may have a hardware issue to troubleshoot. Is the connection in this case intermittent? WiFi from BaseStation to control computer?
Determining software versions being used is also critical!
Thanks - but that’s not the issue. Yes, that happened, and that’s fine.
The issue that needs attention: When controller inputs were received the boat behaved as if the stick was ‘stuck.’ A short push forward resulted in full, uncontrolled thrust and, during that time, all other controller inputs were ignored. This unpredictable response to controller input happened within 5-10 m of the BaseStation as well as at the edge of range. Range and comms drop-out do not appear to be the root cause of this issue.
Please do not be distracted by known issues with known explanations. Please focus on the unpredictable controller input. I need to figure that out or this boat will be condemed to sit forever on a shelf in the back of a warehouse.
Without information of what software versions you’re using, or logs that contain evidence of the issue occurring, it’s not possible to provide any additional useful feedback. Replicating your issue and capturing data on it is the only way to fix it!
What version of QGC were/are you using? Blue Robotics has only tested as far as 4.2.8 as noted here.
What type of controller are you using? Has it been fully charged?
What are the specifications of both the Mac and Windows computer you were using? Processor, specifically.
I updated BlueOS, ArduRover, and QGC in April 2026. Should be the latest stable version for all, unless there’s been a more recent release.
Windows 11 running on a Toughbook. No idea about the processor. Mac M4 - but I haven’t used the mac since the first test.
Xbox controller.
Everything setup following the Blue Robotics guides on the website. Everything stock. No modifications.
Every battery-powered device fully charged.
I have first-hand, eye-witness evidence of the issue occuring.
I’ll pull the BlueOS logs when I’m back in the office.
Still waiting on a simple yes/no → if all components are within 5 m of the BaseStation should we expect manual control to function?
From the .bin logs I see the boat is running ArduRover: V4.6.3
As already mentioned:
Hello again, with Claude’s help I believe I found the issue in the attached .BIN log. I have copied Claude’s analysis below.
RCOU (motor output) was pegged at the extremes for exactly 10.00s (06:25:11.34–06:25:21.34) — this is the dangerous part you experienced.
- RCIN (received input) was actually stale for 29.70s (06:25:11.24–06:25:40.94), not 10 — the danger ended early only because GCS Failsafe fired
at 06:25:21.38 and handed control to SmartRTL, which stopped blindly passing the stale stick value through. Input itself didn’t recover until GCS
Failsafe cleared at 06:25:40.98. - There’s a genuine 31.55-second gap in QGC’s heartbeat arriving at the Pi, bracketing the whole episode. Since heartbeats are independent of any
joystick feature, this is real evidence the whole link was down, not just the manual-control data — consistent with (not proof of) the
BaseStation WiFi fragility already documented, though it’s not fully conclusive (similar-sized gaps elsewhere in the same mission didn’t trigger
a failsafe, which is unexplained).
Root cause (exactly where in Bluetooth→laptop→QGC→BaseStation WiFi the ~31s dropout originated) is still not pinned down, but it’s now a much
narrower, testable question than before. The RC-transmitter swap remains the right mitigation regardless.
00000051.BIN (11.9 MB)
Hi @nuballawalla -
Claude’s analysis matches what we’ve suspected and communicated - you lost connection to the vehicle, while sending joystick manual commands, and these continued until the failsafe triggered. If you were connected to the BaseStation via USB cable, this could have corresponded to a drop-out “wiggle” of the connection, which can take your OS a moment to reestablish - about 30 seconds is typical? If you were connected via WiFi to the BaseStation, then the connection may have struggled due to interference of another form?
Setting up an RC receiver with SBUS and topside transmitter does provide a redundant control method that could indeed mitigate this failure mode. However in our experience, this isn’t typically necessary! The same mitigation could be accomplished with a cellular modem and ZeroTier!
In general, I think you’d be happy with Cockpit for controlling the BlueBoat vs. an old version of QGC that is prone to crashing… we’re working to update our documentation to make this GCS the default!