Working through the build…

As I started this project, I’ve found myself hitting so many unknowns that became really difficult to process through even one step of the project in a way that made sense. The immediate urgency of building a hull, acquiring parts, sizing the motor, and figuring out how the electronics all talk together was overwhelming.

For my own sanity, I hunkered down and tried to organize my thoughts and energy into logical steps which helped focus my energy and allowed me to learn enough basic information in order to begin work on the subsequent steps. Here they are in order of my priorities:

  1. Autopilot (Pixhawk and rudder control)
  2. Propulsion system (Motor, propeller, and speed controller)
  3. Companion computer (Are there any hardware/software limitations?)
  4. Satellite communication (Software library and wiring requirements)
  5. Power Supply (Power consumption of all of the above)
  6. Construction of boat hull (Design, material, and integration of all of the above)

1. Autopilot (Pixhawk PX4 Autopilot)

I tested the Pixhawk autopilot on a cheap RC motorboat (at Lake Siskiyou, Ca.) which after a few bugs and configuration issues, was able to track to pre-programmed way-points. One of the biggest issues I had with the autopilot was realizing the rudder was working opposite of how I believed it should be (rod mounted on wrong side of the servo arm), and wondering if the operation was due to servo trim, a compass issue, or bad GPS, none of which I knew was confirmed working (bought setup from ebay). Only being able to test functionality on the lake and trying to make sense of the data/rudder direction indoors when not moving towards any real direction was limiting to say the least.

Pixhawk 2.4.8

Once I was able to verify proper operation, I set aside the Autopilot till it came time for me to work on the companion computer (mind you, I had been researching the propulsion system and companion computer simultaneously, but until all the parts were in my hands, testing and real world configuration was not feasible).

2. Propulsion System

I know nothing about the radio controlled hobby world. Well, I do know a tiny fraction about it now that I’ve been scratching my head over it for the past few weeks. In selecting an RC motor for use on a boat such as LOCARB, it was not as simple as doing a quick google search for an “Autonomous RC boat motor” (which is another story in itself). Doing so led to discussions about brush-less vs. brushed motors, windings, poles, KV ratings, size ratings, and application – with the underlying goal of figuring out what size and type propeller would work best with the lowest power consumption.

My priorities for the propulsion system:

  1. Reliable motor which produces enough torque for a ocean-going vessel (motor selection)
  2. Lowest power consumption possible (motor selection)
  3. Highest thrust possible (propeller)


In trying to make sense which motor and propeller setup I should run, I found that many RC boat accessories were geared for fast moving speed boats, or replica scale models which were meant to duplicate the accuracy of the vessel vs being manufactured for the efficiency/power/performance. One is led further down the rabbit hole when sizing of an electronic speed controller (ESC) and its features are introduced while wading through the opinions found on the forums in relation regarding both…Oh the many many inconclusive opinions!

In the end I selected a Turnigy 4112-320KV brush-less out-runner motor which has 22 poles (more torque), because it would spin slower per V applied to its leads (the 320KV rating). The idea behind selecting a motor was that in a slowly moving autonomous boat application, one would want low power consumption, high torque, and low revolutions per volt because you don’t need high RPMS in a slow moving craft. If you did select a motor which has a high RPMs or KV rating, you may not have enough torque, or may need too much power to keep the prop moving. I suppose one could say that torque > speed in a case like this. So I looked for a motor with low KV per volt, and with a high number of poles to maximize power.


There is a calculator online which I used to input some assumed specifications of the finished boat. Weight, draft, length, size, etc can be input and a recommended propeller size is given. This calculator gave me a 7″ propeller as a recommendation with a pitch of 4 assuming a boat weight around 70lbs. I found a 7×6 dual blade airplane propeller which seems to provide a good amount of thrust but doesn’t bog down the motor when running under load at low voltages. I purchased several lengths (from hobbywing), some with a different pitch for testing, and I found that 7-8″ seems to be a good compromise between speed per volt (larger props spun slower obviously, and required a little more amperage). I hope to find a suitable carbon fiber alternative for the finished product.

On Stalling…

One thing to note is that with an ESC, when the motor is detected in a stall condition (enough force to stop the prop from turning), the ESC will just stop the motor. This requires a re-transmit of the desired speed to the ESC in order for it to resume operation. Apparently, most ESCs do not have a way to read RPM, some exist, but the ESC I purchased did not have one. I purchased an cheap $4 hobbywing RPM sensor and integrated it it into my sensor readings. In the future I will write a function to monitor RPMs in order to detect a stall condition.

Beginning the process of Integrating Satellite Communications

With the Pixhawk autopilot tested and after getting my Arduino to successfully initialize and run the RC motor with ESC, my next step was to see what was necessary in integrating satellite communications (and is where I am currently). This is where for me, it begins to get pretty complicated as it means tying in multiple systems to work as one. The biggest and I believe most time consuming part of this is actually selecting which configuration is the most appropriate, and by that I mean, which series of systems would be the easiest, cheapest, and most logical way of connecting them all together?

I came up with two ideas, both of which I am currently trying to get operational:

  1. Arduino companion computer as the main host to handle sat communication, power the motor, read all sensors, and monitor the environment. The Arduino should also be able to update the Pixhawk autopilot waypoints if necessary (given an instruction via sat modem) and be able to read the sensors on the Pixhawk as well (to give GPS, compass, speed, and heading data).

  2. Using a Raspberry Pi to interface with the Pixhawk using UV Radioroom (Formerly SPL Ground Control) which allows me to update the navigation waypoints and obtain data directly from the pixhawk using mission planner ground control software (installed on a laptop). The Arduino would send data serially to the raspberry pi which would then be packed into a message along with the data from the pixhawk and then be broadcast out by sat modem

I first began researching about integrating the sat modem and Pixhawk last year in 2018. At that time, an Arduino was supported as a platform to serve as host for something called SPL Ground control.  SPL Ground control served as a middle man to send MAVlink messages to and from the sat modem which connected to a server which Ground control software (program which can program the pixhawk) was connected to (essentially, two middlemen).  When I went to actually implement this solution in February of 2019, I found the Arduino was no longer supported and was replaced by a Raspberry Pi, running the renamed version of SPL Ground Control called UV Radio Room. Ok, no problem, I can work with that… So after some testing as to whether or not I could figure out how to send data from my Arduino to a RPi serially (such as sensor readings), I now have a Raspberry Pi, an Arduino, AND a Pixhawk…this seems to me a little unnecessary, especially considering the fragility a Raspberry Pi has with SD card corruption and excessive power use.

In my search to cut out the RPi, I found an Arduino MAVlink library, which seems to allow the ability to update and receive data from the Pixhawk using the MAVlink protocol. Unfortunately it seems as though there isn’t much in the way of examples in using it…

Honestly, if I can sort out what I think the Arduino MAVlink library says it can do, option #1 would be ideal. The only reservation I have with option #1 is that I don’t want to overload the Arduino with handling too many aspects of the autopilot as I feel it creates a situation where memory limitations and random lockups can occur.

I deal with this in more detail on this post:

Pow…Power what?

**Moved section to:

 The Boat Hull…dun dun dun…

Many autonomous boat projects I’ve seen on the internet design their own boat hulls using fiberglass and incorporate many custom made parts made out of carbon fiber, and for good reason. It allows them to maximize their space, build the boat according to their design specs, and allows for a “better” performing craft. I must admit that I have had several “THIS IS THE DESIGN!” ideas in the past three months, and they ranged from catamaran styled, to monolithic hull, to something that looks like Bullet Bill. However, I always come back to a design which features a Battery/motor pod, and a floating barge thing to keep the panels afloat (very much like the Seacharger design). It may not be the fastest hull in the ocean, but I really believe it will be the most robust as it should allow the vessel to be self-righting (stays in the correct orientation despite being capsized), allow the motor to be in the water nearly 100% of the time, and allow the panels to be above the waterline in a way that wont make the upper portion susceptible to staying capsized.

Well, that’s all there is for now!