After careful assembly over several days and testing in my office, I recently went for a gentle first test run with my Blue Boat in QGroundControl manual mode. The result was (1) at first, normal response to the XBox controller set up in mode 1, then (2) a loss of control or connection (ie. no thruster), then (3) restoration of control and my attempt to return home, then (4) thruster going on high speed all of the sudden, maybe with some slight input by the controller. The result was getting pinned to the dock at high thruster speed, breaking a prop blade, and, finally, a shutdown. I was able to get the boat out of the water and shutdown the power. I was able to get the thrusters to turn again with an out of water test, so hopefully the thruster is OK.
My main question is why did this happen? I was using the standard antenna on the base station but the vessel was only about maybe 30 - 40 feet away from it. I think I walked away from my laptop with the controller - probably instinctively being used to aerial drones with built in transmitters. But only maybe 15 - 20 feet from the laptop. Anyway, if connection was lost, why would the throttle or thruster suddenly go way up?
Also, what should my response have been with the throttle stuck on? My thought was to try to power the vessel off at the boat. Maybe I should have disarmed on my laptop but didn’t want to leave the vessel. I have not fully set up my failsafe options, but I didn’t I needed them for this simple test. Maybe that would have helped. I had done several quick dry tests in my office and everything was normal. I did several dry tests at the dock before launch and everything was normal.
Thanks for any answers or advice. Obviously I want to avoid this in the future. On the positive side, my sensors (Cerulean Omniscan 450, Ping, DeepwaterHD cam) were working great. But now I have to replace the prop. I ordered three just to be safe.
If the BlueBoat / ArduRover is receiving manual control input, and the control signal is lost, it keeps doing that action until the failsafe timeout is reached - typically 5 seconds. Could you have placed the vehicle in another mode, or bumped the joystick at a time when signal was lost? If a joystick disconnects while sending signals, those signals also continue to be sent I believe…
I assume you checked the box for center-stick = 0 throttle in QGC joystick / Advanced settings?
It’s tough to say what happened without a vehicle log - please share the .BIN log from that test and we can take a look at the “black box” recording.
If such a thing occurs again, clicking disarm is definitely the fastest way to stop the motors. With that said, turning off the on/off switch also works - thats why it is there! QGC requires you to “slide to disarm” which is always a bit panic-inducing in the heat of the moment. It is possible to turn off this requirement if you’re using Cockpit, which is nearing readiness for stable BlueBoat usage!
It’s also worth noting that props come as a pair, so if you ordered 3 on the Blue Robotics website you might have 6 total coming!
Thanks, Tony. That’s good to know the last command will stay active for 5 seconds and then it will go to failsafe. I had tried to regain throttle control, and appeared to briefly, and then lost again. So it could be the throttle stayed active I guess. It was definitely running for more than 5 seconds though - more like 30 seconds. I’ll check the failsafe settings on that.
Yes, center-stick = zero was set and previous tests reflected that. It was working fine.
I don’t have access to the .bin logs right now. It looks like I have to connect to the vessel to download those and only the .tlog files auto save.
For the future, I’ll try to stay right next to the laptop / base station. Maybe I’ll connect the controller via USB to be safe even, which I think is possible. I may try some further tests with the single prop blade (one blade is left on the port prop) until I get new props. Good to know they come in pairs. I looked for that but didn’t see that.
The largest log there shows the issue - the vehicle entered Smart RTL mode! This occurs if it has lost connection with the GCS software while not in auto mode (at least in the default configuration of Failsafes.) You could change this to “hold” which will just turn the motors off in the event of no connection. The BlueOS failsafe interface is just changing the FS_ACTION and other associated parameters.
Check your signal strength at the Mikrotik radio interface at 192.168.2.3 - maybe your antenna is damaged and you had weaker signal than expected? Or, when launching significant blocking of the signal could have occurred? As bags of saltwater, humans interfere with radio waves pretty effectively!
I’m not a fan of Smart RTL and try to plan missions intelligently so if a vehicle goes out of radio range, it will get around to returning on its own. I’ve been pushing for loiter to be a failsafe action, and it is in the latest ArduRover beta (FS_ACTION set to 6.) This would still have run the motors in your case, but maybe less violently as your “launch” point the boat was trying to return to in QGC may have been on land!
Great info, Tony. We have to fail to learn, so I’ll chalk this up to good experience and will know what better to do next time. I don’t think there is any antenna damage or any problems like that. It all seems pristine. I’ll test again after the holiday weekend though.