Motorized kayak for hydrometric data collection

[EliotBR (Eliot)]

@ArnoudC

The overlay is automatically: I am using QGis (free). There is a lot of documentation and tutorials online. It allows you to install plug-ins like Openstreetmap and Google Maps that load the tiles for your area of interest. You can easily add your own data (points, lines, etc.) as long as it is georeferenced, and, you can create your own data (like the interpolation map of the depth measurements).

Cool! That’s useful to know about, and will no doubt be helpful to others too

@ArnoudC

I saw for the first time a dredging boat exactly on the spot were I performed the measurements. Hence, the measurement data of the BR ping sonar are externally validated;). I plan to cross the river and take depth measurements to make a cross-section

Nice! Sounds like fun times ahead

@ArnoudC

His birthday is 6th of February, so I have no escape other than complying my promise!

Fair enough. At least it makes it easier to decide what to get for his birthday

---

Design Objectives

@ArnoudC

1. External components (motors, electronics, etc.) should be detachable for transport (save in a separate, shock resistant box?) but the set-up and deployment in the field should still be straightforward.

That’s probably a good idea for them to last well. Perhaps you can make some kind of slot-in/clip-on mounting, so it’s not necessary to put in a bunch of screws when setting up?

@ArnoudC

2. Platform should be compact and easy to transport (at least smaller than the current kayak) and to be handled by 1 person while setting into the water. It should however be still sufficiently big (heavy?) to maintain the maneuverability of the first prototype.

Maybe a ring-buoy or something for floatation, then a platform/tub on that for the electronics to sit in, and possibly some weights that hang in the water for extra stability?

@ArnoudC

3. One should be able to 1) follow-up in real time the position of the platform on a map (in order to navigate it correctly) and 2) check/see the measurements (to make sure the measurements are going well and avoid getting stuck in case of spots where water depth is limited). Real time visualization (on a smart phone?) is key.

Is it essential to be navigated by hand? Given it has a GPS receiver on it, it could potentially be set up to navigate autonomously to a set of pre-configured waypoints (in which case one person could also deploy multiple at once to more quickly survey an area of interest).

I agree that being able to check the position/status live would be useful, but if a low-latency data connection is problematic to achieve it may be sufficient if the vehicle operates autonomously but is able to send a “help” message if it gets stuck.

@ArnoudC

In case this would not add too much complexity/vulnerability to the project, a camera in front of the platform with live transmission could be interesting.

That could definitely be possible if the deployment locations have good mobile internet coverage, although it may not be cheap.

Current Questions

@ArnoudC

1. Maintain set-up with 2 motors: I am thinking of a robust catamaran maintaining the initial set-up of 2 motors. I like the maneuverability of the first prototype with 2 motors (See video) and I guess this set-up may also be useful in case of measuring flow in channels with a strong current. I notice several community members opt for 1 motor and a servo for direction. Do you consider it “overkill” to have 2 motors for a “relatively” small, unmanned platform (energy consumption)?

2 thrusters can move faster, and you can run them at a lower voltage and get the same thrust as 1 thruster but with higher efficiency.

Personally I’m more familiar with and prefer thruster-based control, so I’d stick with 2 thrusters, but alternative setups are definitely also possible. I may be slightly biased because I’m planning on using 2 thrusters for horizontal motion in StaROV

@ArnoudC

In case I would add an autopilot in the future, would there be a difference between the 2 previously mentioned set-ups?

ArduSub would support the 2 thrusters approach, but surface vessels tend to use ArduRover (which I’m less familiar with). ArduRover seems to be fine supporting thruster-on-servo control.

@ArnoudC

2. Building material for the entire platform=Stainless steel or aluminum: I want to avoid plastic and carbon fiber for building the hull

That may be a bit excessive, particularly given metal doesn’t tend to float in water. If you’re concerned about this kind of thing you can perhaps have a metal cage around the vessel to protect it, or just metal reinforcing/mesh around any external plastic/foam parts?

314-grade stainless steel is reasonably expensive, so I expect aluminium would be cheaper, but it might also depend on what form you want/need it in.

@ArnoudC

Protecting electronics navigation: Due to the rather small capacity of the lipo battery, I only tested the first prototype for a duration of +/- 10 minutes. In case of using a 15.000 mAh battery, I expect at least to be able to make the platform move during 1 hour. Should I worry about the electronics heating up? Reading the following comment in a recent post (Thrust required to propel an AUV?) " made me wonder whether 1 hour would already be considered very extended periods? I also read some members include a “heat sink” for their ESC.

Run-times depend significantly on usage conditions. Operating at full thrust moves faster but is less efficient to run and uses energy more quickly. Consider also that a platform for taking measurements may be stopped at various points, so that would also factor in to the run time.

From a previous post:

@EliotBR

The nominal capacity of the BR battery is 18Ah, and a T200 full throttle current at 16V is 24A, so 18 Ah/(2\cdot 24A) \approx 22.5\ mins of non-stop runtime (for two T200s).

So for our current 15.6Ah battery that would be a closer to 20 minutes. That said, from the T200 performance charts if you’re running at 2/3 of full thrust (pwm 1804) it uses only half the current, so it lasts twice as long and is at much less risk of overheating. Again, that’s continuous run-time - if you’re stopped for a third of the time then now your 40 minutes at 2/3 thrust becomes an hour of practical run-time.

On the overheating front, it depends on the enclosure you’re using and the thrust you’re operating at. If you’re using a black plastic enclosure in strong sunlight while operating at full thrust then overheating is very probable. It’s possible to reduce the heating risks by shading the enclosure from sunlight, providing heat transfer/ventilation (e.g. a metal heat sink that touches the water, and/or a fan to circulate air and/or bring it in and out of the enclosure), and not running at full throttle for extended periods.