Autonomous Solar Boat Version 2
This project is a complete rebuild of my earlier autonomous boat project. It’s bigger, faster, smarter, and has more than 4x the power. This boat is called Gumption Trap II.
Build Video
This long video documents my design and build process for the project, and demonstrates a brief shakedown run at the end.
●Length: 65”
●Beam: 36”
●Draft: 8.5”
●Displacement: 60lb
●Max speed: 3.0kt
●Solar Power: 200W
●Configuration: Twin Screw Cat
I molded the hulls out of fiberglass using a mold built from a 3d printed skeleton and flat pieces of plywood. I reused the same mold for both hulls. The fiberglass hulls were lightweight and durable, designed to be molded easily from mostly flat faces. I embedded a stainless steel plate at the stern with threaded holes for motor mounting.
I layed up around 3 layers of fiberglass, using large continuous layers as much as possible to reduce the number of seams. If I could start over, I would’ve used a vacuum bag to help compress the composite and remove bubbles. In the end I had a significant excess of resin which made the hulls heavier than they needed to be.
I went through several iterations of leak testing in a makeshift test pond to find and fix pinholes before proceeding with assembly. After I was confident the hulls were watertight, I trimmed excess material, painted them, added gasket material, and cut plywood deck plates which I treated with water sealant before bolting them down for a test fit and final float test. Another notable design criterion of the hulls was the total lack of penetrations. I kept all necessary electrical connections in the deck above the waterline to mitigate the risk of leaks with my ultra low budget bulkhead connectors.
I designed the hulls for minimal frontal area to reduce drag, settling on a long and narrow dual hull layout which was also ideal for supporting a large flat solar array. A safety factor of ~2.1 ensures that one hull could completely flood, and the other would provide sufficient buoyancy to prevent the entire boat from sinking. The cross section shown above is tall and narrow below the waterline. It’s also short and wide above the waterline. This design minimizes the freeboard to reduce lateral surface area exposed to crosswinds while maintaining volume for my safety factor requirement. It also keeps the motor low enough to ensure the prop will never breach the surface. I mounted an additional fairing in front of the motor mount, not shown here, to streamline the flat surfaces hanging below the hull.
I predicted the position of the waterline by using the hull model to calculate the displacement and buoyant force. I modeled the hulls as solids with the density of water and sliced the hull at the waterline to experiment with resultant displacement values. This informed my design as I tweaked the geometry to accommodate my predicted weight and safety factor requirements.
I added a frame below the solar panels made of 2020 aluminium extrusions. These were bolted through 3D printed blocks adhered to the deck plates with marine structural epoxy.
With the main structural elements all assembled for the first time, it was back in the test pond to verify my water level and buoyancy calculations. I added weights to simulate the batteries and other heavy components.
The batteries could go anywhere in the hulls, I used their placement as a way of adjusting the list and trim to ensure the boat sat level in the water.
The brains of Gumption Trap II are reused from the same custom PCB I designed for Gumption Trap I. The microcontroller is a Teensy 4.0 which is connected to a GPS module, SD card reader, two voltage and current sensors, and an i2c hub for the remote magnetometer and future sensor additions. It also breaks out pins for the UART connection to the sonar module, PWM signals to the thrusters and rudder, signal input from the RC transmitter, and contains a simple voltage regulator system to distribute 5v and 3v3 power where needed.
I tested the solar power system by wiring the batteries and a few load resistors to the solar charge controller. This was to verify its ability to charge the batteries while simultaneously supplying an excess of current to power the load. I measured the current produced by the panels and consumed by the load resistors with a multimeter. These panels are nominally 100W each, and together they provided around 15A at 12V (180W) to the controller on a sunny day in ideal conditions. I already had a good model for the power consumption of the motors (see my propeller dynamometer project) and I knew the approximate draw of the rest of the components, so I was confident this system could provide enough power for continuous operation.
This data is from my first test run of the newly built boat. This was September on a partly cloudy day, less than ideal solar conditions. The panels provided around 12A, gradually decreasing as the sun got lower in the sky. My system draw was around 16A during full speed operation, a net deficit of 4A. With my 20Ah battery, This could’ve run for 5 hours in theory.
The battery voltage drops heavily due to system draw and back emf from the motors, but a gradual decline is evident. The final voltage after about 1.5 hours of operation was only 0.1V less than the full starting voltage of 14.4 on the LiPo’s.
This picture shows the majority of the important electronics. These were all mounted in the starboard hull for weight balance. The screw terminal distribution blocks supply power and ground to all the major components, as there is no chassis ground with the fiberglass hulls. a separate DC DC converter powers the rudder servo just aft of this image.
I used a Blue Robotics Ping2 echo sounder for this project. Over UART, it communicated real time depth readings to the microcontroller for bathymetric plotting. A closed cell expanding foam filled enclosure minimized drag and provided a little extra buoyancy.
This picture is a final stress test of the “finished” (there’s no such thing as finished) boat before I took it out for its first expedition on Town Lake.
I thoroughly tested every subsystem and tested the integration of every system together, but I missed a critical bug.
The microcontroller would wait for the GPS to report a valid latitude and longitude once during setup, but during the main loop from then on it would only read one byte per loop from the GPS. This meant that I would get a good looking GPS reading shortly after powerup, but it would only update at an astronomically slow pace from there. I didn’t catch this during my dry testing; I assumed the lat/lon values weren’t changing simply because the boat wasn’t moving. Lesson learned, in the next Gumption Trap II post on this portfolio, I demonstrate a bathymetry mission with this bug fixed.
The graphs to the right show the PID control response to a step input from the code which calculated the goal heading. As previously described, the GPS was not updating in real time during this first test. These charts show only the data while the boat was operating in autonomous mode, with manual driving cut out. This data was useful for PID tuning before my next run. Although the goal heading only updated once per power cycle, this blackbox data still served as a useful tool for characterizing the control response of the boat. The “Actual vs Goal Heading” plot shows the measured compass heading vs the calculated heading to point the boat directly towards its goal waypoint. The “PID Steering Output” represents a raw variable from ±100% representing a steering value from a hard turn to port through a hard turn to starboard.
Charts to the right show actual motor signal inputs for all three motors. The upper plot shows both motors pegged at full steam ahead for the majority of the mission, with one motor periodically reducing speed during turns. In this case, 2000-1000µs is full ahead to full reverse, with 1500µs as dead stop. My control system will keep both motors at full steam forwards most of the time while doing fine steering adjustments with rudder only, but it will use differential thrust for extreme steering angle adjustments when the goal waypoint changes suddenly. The lower plot shows the PWM signal to the rudder servo. It is constantly making fine adjustments to the steering. As shown in the plot, the equilibrium point changes significantly between starts and stops. This was due to the belt/pulley drive on the rudder skipping a few teeth during extreme sudden adjusments, requiring the servo to turn further to one side or the other to maintain a straight rudder.
The only mechanical failure during the shakedown run of Gumption Trap II was the rudder servo system. It was a belt and pulley with a 2:1 reduction ratio, so the 180° servo travel would translate to ±45 degrees of rudder range. This was problematic in practice, as the belt would skip teeth and it was difficult to keep it tensioned sufficiently to prevent this. I later replaced the belt and pulleys with a mechanical pushrod linkage.
Click the box above to view the code I wrote for this project on Github. All the code running on the boat itself is C++ on a single microcontroller. I also have python scripts and alternate C++ code that allow me to read and write data to between the internal SD card and a laptop without physically disassembling the hull to access the card. Additionally, I include the matlab scripts I use for data processing and all of the CAD for the project.