Hello BlueRobotics Community,
I use a BlueBoat for surveying purposes and would like to use it in tidal regions. As I don’t want to use the BlueBoat when there is a current, I only use the BlueBoat one hour before and one hour after high tide. This also means that my survey time is limited. I would therefore like to make maximum use of the survey time and would like to survey at 2-2.5m/s for a period of 2 hours (with short interruptions due to turns and change of lines).
Can the BlueBoat run manually at this high speed for a longer period of time or is this not recommended?
Hi @Arne1 -
You can certainly set the cruise_speed autopilot parameter to a higher value to reduce survey time (no need to run any tuning, or use Mission Planner- simply navigate to the autopilot parameters menu in BlueOS or Parameters in QGC.) At full speed, the boat uses exponentially more power than at 1 m/s, you may only see an hour of battery life (with 2 batteries installed and fully charged.)
The larger issue may be the performance of the sonar - for all types, faster speeds can mean interference from bubbles in the flow, and a general “spreading” of the beam over the terrain faster. What type of sonar are you planning to use? An Omniscan Sidescan really starts to lose resolution above ~1.2 m/s, and the Ping single beam can handle 1.5 m/s, but surface conditions can obviously affect this as well…
The times you mention would seem to have the highest tidal currents - would not during the “trough” of the not-lowest / highest tide have the lease water movement?
Hey Tony,
thanks for the quick response.
The main task is to survey long lines perpendicular to wadden flats. As I don’t know exactly where it gets shallow I feel more comfortable to control the vessel manually. Therefore, I will not use the Autopilot. I will work with a single beam echosounder. The SBES is manufactured by Echologger and is designed for survey speeds of up to 5 knots. The speed is of course limited if the SBES is disturbed by air bubbles or pitching.
As I haven’t mounted the SBES yet, I don’t know how the sensor performs in combination with the BlueBoat at higher speeds.
I currently have two batteries installed, but will probably increase this to four or possibly six. I will use 3D printing to build a hydrodynamic hull for the echo sounder so that the SBES doesn’t slow down as much. Nevertheless, the additional load from the SBES (500g) and the batteries, as well as the water resistance due to the SBES, will slow down the boat and the motors will have to run at almost full load if I want to achieve 2-2.5m/s.
I was unsure whether the M200 will survive this for long.
At high water there is the least current. We have the strongest current velocity 3 hours after high water and 3 hours before low water.
Hi @Arne1 -
I think you’ll find that driving the vessel manually is not a practical idea, at least if you want to drive long straight survey lines with any accuracy. You may have some success operating manually in Acro mode, where the vehicle will automatically hold its heading. But generally, a human can’t achieve the “on-rails” navigation performance of the BlueBoat - automatically adjusting its heading so that despite prevailing winds and currents, the unit slides along at a consistent speed perfectly along the survey lines set.
If you’re concerned that the water is shallow, a simple Lua script could react to a threshold depth you set, and put the vehicle in loiter mode. In this way, if things get to shallow, the vehicle will pause and you can navigate around the obstacle. That said, running the BlueBoat aground isn’t an issue unless the mount you create for your single beam sonar protrudes below the keels?
The Ping sonar mount is just recessed from the keel for this reason. Have you compared its performance specifications to the unit you’re using? It seems to have comparable range, but maybe slightly better accuracy (.15 vs 0.3m)
What temperature water are you running in? Running the M200s sustained at full power shouldn’t cause issues unless the water is prohibitively warm, more than 28C?
How do yo plan to connect the SBES and log / view the data being collected in realtime?
Hey @tony-white,
I have already thought about a script to activate the loiter mode. Especially because the area will not be completely free of currents. I’ll deal with that once I’ve integrated the SBES.
I decided to use the Echologger because an accuracy of 0.5% is not sufficient at a water depth of up to 15m. The client would not accept that. The Echologger also has an integrated roll/pitch sensor with an accuracy of 0.1 degrees, which will be required for most of my projects I am dealing with.
I will mount the sonar between the keels, so it won’t be the deepest point of the vessel. My bigger concern is, that if I run aground, the BlueBoat could stuck in the mud and won’t be able to turn back. If that happens to me during high tide, it would be problematic.
But your tip with the script is good. I will try that.
The water temperature in the river Elbe in Germany won’t be much higher than 18 degree in summer.
I am going to use Beamworx, installed on a small windows computer (5W power consumption), which I will mount inside one of the hulls. I will access the Windows computer via TeamViewer. After the mission, when the BlueBoat is back on the mother vessel, I am planning to transfer the data via WiFi.
Hi @Arne1 -
I’m always a bit confused why installing an additional computer is required when working with a payload that talks serial. You could connect the Sonar to the existing Pi 4 (via USB serial adapter), and route the data to Beamworks via virtualHere or USBIP. The disadvantage is that this data flow will be lost if you lost WiFi connection to the BlueBoat. You could develop an extension that logs the raw (NMEA?) data onboard, and then forwards it to your topside computer, but if you don’t want to muck about with software installing an additional computer isn’t that terrible I suppose…
Hey @tony-white
the idea was actually to create redundancy. If the Pi stops responding, I would restart it via the secondary computer or vice versa. I would want to avoid real-time transmission, firstly because of connection interruptions and secondly so as not to overload the bandwidth.
But I could actually install a more energy saving second Raspberry instead, which I could use to log the data. I could transmit the data sampled at 1Hz, for example, to NavAQ so as not to unnecessarily load the bandwidth. For processing I would use the data logged onboard.
Hi @Arne1 -
I’m glad you brought up redundancy, it lets me share why just one Raspberry Pi is likely all you need!
Especially on the BlueBoat, the Raspberry Pi 4 is only using 10-20% of its computing capacity to run BlueOS and the ArduRover autopilot process. Thus, code can be executed onboard the vehicle without impacting the mission! The docker container architecture of BlueOS means that if your code, or an extension, or even the autopilot crashes, the rest of the system will be unaffected. Everything is operating within its own sandbox in the software!
This guide details how simple it can be to use Node-RED to log serial data. If you prefer python, developing an extension is pretty easy too - here is a recent example of an extension that logs Dissolved Oxygen from an attached sensor.
The Navigator breaks out TTL serial ports, so once you convert (assuming you have RS232 output?) you can connect directly to the unit.
I’ve run the BlueBoat for well over 50 hours of survey, with multiple payloads and never had the Pi stop responding - even when using the latest beta version of BlueOS! Our software team recognizes that vehicles can’t just go crashing all the time… I have screwed up parameters in a lua script that caused the autopilot to crash before, but simply fixing the mistake and restarting the autopilot (remotely) made the experience barely a speed bump in development. The data from a single beam sonar can barely be considered a trickle compared to side-scan and multibeam data - the Pi / BlueBoat handles transmitting & logging all this, while monitoring a solar charge controller and cellular modem without breaking a sweat!
Finally, using a secondary computer to restart the main Pi as you suggest could be quite tricky to implement… it would require re-wiring the supply with a FET switch that could be controlled by your watchdog device.
Hello @Tony,
thanks for the detailed answer. I have been investigating Node-RED over the last few days. It sounds really versatile, but also quite user-friendly. I will now do as you recommended and log the survey data via the Raspberry. I’m really looking forward to the integration of the sensor and GNSS and the first deployments with the Blueboat in the survey area. It’s cool that you invest so much time in the community and give detailed and helpful tips.