Motorized kayak for hydrometric data collection

Dear forum members,

I created this post to share my motorized kayak building experience using several BR electronics components. Firstly, I want to set the context for the still ongoing project: as a water resources engineer living/working in Paraguay -a country blessed with an abundance of surface water resources- I almost always get confronted with a lack of available hydrometric data (flow, depth, etc.). Although there exist commercial survey packages for these types of measurements, locally there are additional challenges for which I prefer to build my own tool. Firstly, in addition to the already high cost of the commercial tools, importing them into Paraguay makes it a lot more expensive and cumbersome. Secondly, once one small piece breaks down or there is any need for reparation, you get stuck as locally there is no representation/support. The context of application is challenging, hence you don’t want to depend on sophisticated, third-party tools that you are not able to fix by yourself, particularly when you do not have access to spare parts (at a reasonable price and “as quick as possible” when you need them).

The majority of reservoirs, irrigation channels and rivers in Paraguay require a large and robust platform to cope with the waves. I have been following RB for already some years and I really like the compatibility and accessibility of their electronics components. Being inspired by earlier work on motorized kayaks presented and discussed on this forum, I decided to buy 2 T200 and a “kid” kayak. I decided not to drill holes in the kayak as I do not have experience with the waterproof closing afterwards. Both the propulsion part (on the backside) as well as the electronic cages are attached to an acrylic plate, which is connected at different points to the kayak by means of tie-wraps. In addition, bungee cords were used to increase the pressure. The sensors to be used can be attached on the bar foreseen on the frontside.


What took most time? The T200 were easy to connect/install due to the online tutorials. I spend quite some time in understanding better the “mixing” of channels of the RC control to operate 2 motors with one stick. I finally ended up using a V-tail mixer, so up to now I did not have to dig into the programming of the RC control. Secondly, it took me a lot of trial&error to be able to connect and run the ping sonar with Arduino MEGA (including local storage of measurements). My children allowed me to experiment in their portable swimming pool in our garden. During this period, I had a lot of issues with the data collection with the MEGA and ping sonar: it took a lot of time to initiate the ping sonar, and often it would never start reading although correctly wired. One hypothesis was that the water in the swimming pool was not deep enough (according to technical specifications BR site this is minimum 50 cm). However, sometimes it works surprisingly well, hence then it is always tricky to know what the problem exactly is. Although not having resolved this issue, I decided to take the kayak for a first trial in “open water”, being the Paraguay River the closest to where I am living (+/-1.000 m from the river side). I decided to firstly test the motorization. I did not have my swimming short with me and, although of a very short duration, this year winter is being very cold. But I had trust in the BR thrusters….Following short videos give some quick idea about the behavior of the kayak in the water:

There was some influence from waves generated from ships, but it performed well. Afterwards, I tried to get the ping sonar to work to test this as well (in deeper water), but I was not lucky and again the MEGA could not start reading the ping sonar. After checking today several recent posts on this topics, I guess the probability is likely that the software serial communication at 115200 baud rate is giving this problem, so I will try now with a hardware serial port. Once my “proof of concept” is functional, I would like to make a slightly smaller hull (for easier transport) and make the tool as “robust” as possible so it can serve for a challenging environment. I hope to come back soon to this forum and hear your suggestions/recommendations for this second step of the project….Thanks to all persons that in the past have shared their building stories: it really helped throughout the process when getting stuck.


As the story abuve was my first post, I was limited to 1 photo and 2 external links. However, I would like to share following video that contains the first testing done in the swimming pool in my garden

and the following picture of the platform during the test on the Paraguay River.

1 Like

Hi @ArnoudC, welcome to the forum! :slight_smile:

Thanks for this post, and the interesting information about your context, the process you’ve followed, and the challenges you’ve faced - it was an interesting read!

Hopefully switching to hardware serial solves this issue - it is known to be more stable, particularly at the higher baud-rates. If it’s still not working consistently after the switch, feel free to post about what you’ve tried and we can try to figure out what’s going wrong :slight_smile:

Beautiful photo - it’s always a bonus when testing takes you to lovely places

I’ve edited your post and comment so the videos are embedded, which lets us watch them from within the forum :slight_smile:

1 Like

Awesome project! (Video links are not working for me.)

1 Like

@ArnoudC you might need to allow embedding on the videos for the embedded links to work properly.

@hube268 in the meantime you should still be able to click the ‘Watch on YouTube’ link that appears when you try to play the video :slight_smile:

Dear @EliotBR, Thanks for the advice about changing the settings in youtube.

1 Like

Dear @hube268, Thanks for the feedback and pointing out the issue with the videos. It should be OK now.

Dear @EliotBR, Good news: using hardware communication instead of softwareserial between the MEGA and Ping Sonar indeed solved the issue (reference code: ).

I hope to be able to go back to the river or another surface water to check it out.

1 Like

After 5 months I was able to continue with the motorized kayak…Since the beginning of testing in the field, a major bottleneck was the transport of the kayak from my home to the riverside. Finally, I made a simple transporting system (recycling the wheels of my son’s bike; I had to promise him he will get a new, bigger bike soon!) in order to be able to walk to the shore (+/- 1.5 km).

Following images show the final set-up of the kayak: 2 motors on the back and a sonar on the front. I am using an Arduino MEGA with Adafruit GPS and external antenna, while the data (X, Y and Depth) is saved on an Adafruit Feather M0 SD .

The BR ping sonar is working well now and I was able to do some depth measurements near the shore. Following images show the measurements taken and a simple bathymetric map made by interpolation.

First it was rather surprising that the depth already reached to 4-5m rather closely to the shore. This is explained (and confirmed by the locals) by the fact that in the past sand has been abstracted for filling up the nearby beach of the local club. Hence, it is not representative for the shore of the Paraguay River.

With these results, the objectives for the first prototype were reached (understanding the electronics and making a first measurement). Now the second stage of the project is starting that should result in a more robust/compact platform to be tested in another setting(remote farms in the countryside). I will write a second post with the new objectives/expectations/plans (your advice and constructive critics would definitely be welcomed at this stage!)


This is really cool to see @ArnoudC - thanks for sharing! :smiley:

Out of interest, how did you plot the data on the satellite imagery? Did you overlay and align that manually, or are you using a plotting library that automatically gets the satellite imagery for you and lets you plot directly on it? :slight_smile:

This kind of thing is always fascinating - just finding out unexpected information about the world around us, especially when it’s something nearby that’s normally hard to observe.

Hehe, good thinking, hope he doesn’t mind the wait too much :stuck_out_tongue:

1 Like

Thanks for the positive reply!

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).

Definitely…Yesterday I was shortly in the club and surprisingly 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 (just need to get the BR battery as now I only have a small 2300mAh battery)

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

Before sharing the design objectives for the build of the second prototype it is important to shortly describe what would be a typical data collection mission. Firstly, driving 200 km with an 4x4 to a ranch over a bumpy road with abundant potholes that often will make you brake suddenly (or fly in case you were not able to see them on time).

Once arrived on the location, riding on even worse internal roads towards a water reservoir. Getting the measurement platform out of the 4x4 and finding yourself without any easy access to the water surface in order to put it safely in the reservoir (due to irregular or inclined slopes). Most likely there will be a heavy wind, hence waves in the reservoir are expected. You have no time to wait for the best moment of the day (less wind) to make measurements.


Design objectives:

  1. Platform as robust as possible. 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.
  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.
  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. 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.

3 current questions

  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)? In case I would add an autopilot in the future, would there be a difference between the 2 previously mentioned set-ups?

  2. Building material for the entire platform=Stainless steel or aluminum: I want to avoid plastic and carbon fiber for building the hull and whatever moving components (like branches for the motor or sonar). I had a bad experience with plastic components with a fish feeder boat. Any advice on what to consider to assure the second prototype remains “floating”? For the first prototype, I did not make any holes in the kayak to avoid any problems with assuring impermeability (I have no experience with it).

  3. 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.

It’s worth noting that T200s and the control electronics aren’t designed/intended to be run at maximum thrust for very extended periods, particularly if you’re running at the maximum voltage (they can end up overheating and become damaged)

At this stage, all opinions and advice are welcome (not only limited to the 3 questions)! I focused first on the navigation part of the second prototype, hence maybe later I will post some questions regarding the electronics for measurement. Thanks in advance and I will keep posting any progress from my side…

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

Nice! Sounds like fun times ahead :slight_smile:

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

Design Objectives

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?

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?

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.

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

Current Questions

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 :stuck_out_tongue:

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.

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.

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:

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.

Hi ArnoudC!! This is super cool!! We would love to share about it on our socials if you wouldn’t mind?

Thank you!!

Dear Kristel,

Thanks a lot! Sure, feel free to share. I am following you on linkedin so I will keep an eye on that.

I really like the BR story, making the right electronics at an accessable price. Keep up the good work!


Hi Arnoud! Thank you so much for the kind words! I will post about this either this week or next :slight_smile:

1 Like

Hi, I am very keen on using a Ping Echosounder to collect depth data for specific locations. Can you please provide further information on the battery and GPS unit that you used as well as how you see the system up?