How Far did your Autonomous Boat Sail?

Our goal was to build a boat that could autonomously sail itself from Lynchburg to Richmond along the James River. That’s roughly 150 miles of winding​ river fraught with narrow passes, dams, jagged rocks, loose branches, and bridge pillars among many other obstacles. And after roughly 70 hours of work spread over 5 months, our boat (Botteau), on it’s longest attempt, made it 300 yards down river. Needless to say we came up short. Really short. Here’s why, and what we learned from our experience.

Boats are simple. They’re just objects that weigh less than the water they displace. It’s factually true, but it turns out that like most things, the details of implementation are much more complex. And while our initial ideas weren’t quite this naive, there were a number of boat building details we underestimated.

The first was size constraint. Our primary consideration when sizing the boat was buoyancy. We weighed all of the components ​that needed to ride in the boat, determined the depth of draft we wanted the boat to have, then calculated the volume of water our boat profile needed to displace. Thanks to Archimedes, we were incredibly close with this calculation, ending up with a draft depth within half of an inch of our target. What we failed to consider; however, was the practical challenge of fitting two motors, 35 pounds of wheelchair batteries, and a computer accompanied by various electronic components inside the boat. Once everything went it, it was impossible to access the motors, and the batteries never came back out. So when the connections between our batteries came loose, we never knew it, and when we burned out three different motors, we had to cut through our fiberglass hull in order to replace them. It wasn’t the failures that caught us off guard, just the amount of time necessary to fix them.

The second major design flaw was the location of the fins and the instability that resulted. Fish have fins on the rear, and so do most boats. So why would we deviate from what works? When a boat propels itself through water, the water drags on the surface of the boat, producing a force that pulls toward the rear of the boat agaist the thrust force that pushes forward. As long as these two forces don't oppose one another around the boat’s moment of inertia (the point about which it spins), the boat remains stable. And this is how most boats function. The problem was that our boat was designed for energy efficiency. Even with 40 amp hours of battery life and a 100 watt solar panel, we knew that our batteries would risk being completely drained every day, so we decided to use as little energy as possible, so when the boat wasn’t at risk of crashing into an obstacle, we decided we’d cut power to the motors and let the river carry our vessel. The problem comes when the water starts moving faster than the boat, causing the drag force to change direction, making the configuration unstable, sending the boat into a spin from which it struggled to regain control.​​

Then came electronics. And in this realm it wasn’t so much the computation that set us back, but the basic electrical components that served as the boat’s drive train. These were the batteries, voltage regulators, computer, and motors. And among these four major components, one way or another, we destroyed them all. The batteries were damaged by leaking water and short circuits, the computer was destroyed by connecting the batteries backwards, the voltage regulators and motors fried and melted their wires by drawing more power than we expected, in their tight, enclosed, very warm space. When your most expensive budget item is destroyed beyond repair before the boat ever touches water, it’s tough to start over again. But we did. We migrated everything not just to a new computer, but to a completely different architecture (Jetson to Raspberry Pi), requiring that we rewrite our code with completely different libraries for GPS navigation, LIDAR range finding, motor and servo control, wifi communication, temperature monitoring, and camera operation (along with the need for interfacing with a new physical camera).​

Our focus was on computation. It was the aspect that made this project unique and innovative. We thought it would be the greatest source of difficulty, but it turned out that we were wrong. It was the more fundamental aspects, well understood by boat builders and electrical engineers, that challenged us the most. Although that’s not to say that the code was easy. Teaching a computer to differentiate water from land is no easy task, and frankly, our 8th grade student’s implementation was impressive. The image on the right shows how it worked. The top image was the original taken by the camera on top of our boat, just below is the filter applied by the computer, and on the top left is the resulting instruction for which direction to turn the boat, along with confidence values that the left, center, and right sections of the image contain an obstacle (lower numbers are more likely to be obstacles).​

So after months of work and repeated setbacks, we found ourselves at our favorite boat ramp, an all too familiar meeting spot, ready to deploy our boat on another test voyage. Except we noticed that the weather had changed. We had gotten used to the hundred degree temperatures on all those summer days at the river, and now here we were in October, no other kayakers in sight, and none of us thrilled at the idea of getting in the water. So despite knowing we weren’t ready, we agreed to make it our last attempt, cut the tether and let our boat go. And off it went, like sending your child to his first day of kindergarten, it took off, and there we were proud and excited. It didn’t even look back, it just sailed as it was born to do. And just when we thought it might really work, the boat suddenly lost its heading, the nose pointed toward the shore, and it slowly drifted aimlessly until finally being grounded among sticks and mud. Determined to figure out what went wrong, I took to the water, more treading mud than swimming, until I was finally able to reach the boat and tow it back to the ramp. We took it back to Vector Space for diagnosis and found that the computer had simply crashed, a regular run of the mill kernel panic, and one that we had seen multiple times before. And though we had more than one idea on how to prevent it from happening again, realizing that the show can go on forever, we decided it was time to accept defeat, and honorably retired Botteau to the ceiling of Vector Space, where it hangs today.​

We often caution students at Vector Space that failure is an option. This isn’t an indication of inability or a suggestion to shy away from challenge, it’s a reminder that interesting and ambitious things are not easily accomplished, by anyone. Simply showing up and putting in the hours might be a winning recipe for completing worksheets or finishing chores, but it’s no guarantee that your boat will sail or that your rover will land safely on Mars. For many, it’s an idea that’s difficult to accept. Few of us were raised to deal with failure, myself included. But why not? What’s the alternative? To not even try? To only take on the things we can knowingly succeed in? Ask these students if they would have rather spent their time in any other way and I think you’ll find a common theme throughout their responses. Regardless of how far their boat sailed, they accomplished things they never imagined they could, made friendships and memories that will last a lifetime, and experienced an adventure unlike any other.

The Autonomous Boat Project was sponsored by Cognizant’s Making the Future Grant.