The Big Crunch

As everyone recently realized, we are rapidly approaching the end of the semester–which means that we need to have a fully functioning boat VERY soon.

Fortunately, we are well on our way to that point. In the last couple weeks, we have obtained a functional transmission, completed code that is being tested on a small retro-fitted RC boat, and a finished set of prototype sails. The keel and rudder are both also almost finished, and, barring a machining error, will be completed within the week.

So, we will have a lovely prototype of Damn Yankee that we can take out to Lake Waban and test by April 13th.

Airmar Testing

To determine what sensors we want to use next year, we decided that we needed to test the sensors we currently have – namely, the Airmar. We wanted to know two major data points: the precision (or lack thereof) of the GPS and how quickly it responded to changes in the wind.

To achieve the first, we took the testing package outside, and stood in place for 10 minutes, allowing the Airmar to gather data. The results looked like this:


(PB200 – the older sensor)


(200WX – the newer version)

Both of these show a spread of approximately 8 meters in the east/west direction and 3 meters in the north/south direction. For context, the robot must be able to go between two buoys 3 meters apart during the competition. This shows that by relying only on the Airmar GPS, we do not have the resolution we need to complete the mission.

The major reason we purchased the new version of the Airmar was because it reduced the wind measurement delay. However, we wanted to see if the change was actually significant.

The setup for this test was as follows:


The fan is on the right, and the Airmar is propped up on the left so that it feels the wind from the fan.

For each sensor, we did 30 second trials, cycling the fan off and on. Representative graphs are as follows:


(PB200 – old sensor)


(200WX – new sensor)

The new sensor shows a significantly faster response to the change in the wind, as can be seen by the much steeper slope at both the start and end of the wind exposure.

The conclusion we reached, therefore, is that we will definitely use the new sensor over the old sensor, and that it is certainly worth looking into a different GPS.

Simulation of the Boat

We had an old simulation of the boat, but it was difficult to understand and had some physics flaws. One of our freshman, Mike Bocamazo, took the leap into the old simulator and found a bunch of math that appeared to be first based on forces, but further in devolved into a series of messy ratio approximations for physics equations. He then essentially independently formulated a new series of equations to model the boat behavior, presented his methodology to the team, and will be soon implementing his model as our new simulator.


A cool part of the simulator setup is that the simulator takes in sail and rudder settings, and outputs GPS position, boat speed, compass heading, and angular velocity. This fits well into our architecture – we simply grab the commanded setpoints and port the return data in as sensor data. The GPS points get displayed on the same OCU (Operator Control Unit) as they would on the actual boat, so we can get very close to testing the entire body of code on the simulator.

Sail tester

When writing code that controls our sails and rudder to maximize the speed of the boat, a lot of it feels like guesswork, even after talking to members on the team who are experienced sailors. Translating what a sailor does into code is difficult, partially because of the intuition required and partially because a human’s “sensors” are very different from those on the boat.

To that end, we are in the middle of making a sail test apparatus that we can mount our rig on and test in front of fans. What we want is to drastically increase the amount of time we can spend testing our code in realistic conditions, while at the same time giving us the ability to control certain variables that we can’t control on the water.

Alex Crease and Eric Schneider are working on the first round of the sail tester, which will be a vertical pole held in bearings. A plywood deck with our sails on it will be mounted on top of the pole. The pole and deck can spin as if the boat were turning.


We hope to estimate the center of lateral resistance for our boat and place the pole there. Simply put, the center of lateral resistance ( is the vertical axis about which the boat spins. Putting a pole there has the really cool effect of making the test rig spin about the same point as the actual boat, which means we can test out algorithms for balancing the forces on the sails so that they create no moment. Very exciting stuff!

The second round, very much in the future for now, would be mounting a planar force sensor in between the pole and the plywood deck and doing all sorts of cool tests to determine which sail settings result in the strongest forces and in which directions those forces are applied, for variable wind angles. If we can do it right, this will be an excellent chance to characterize our boats more than we ever have before, which is awesome.

MidBrain Think Structure

In the first two years of Olin Robotic Sailing, we used a “goodness function” based software architecture. In essence, the boat would constantly be looking in every direction asking “which direction would be best for me right now?” This was a pretty interesting approach, and it even led to emergent tacking behavior. We wrote a fairly in-depth report of that architecture here:

There were a couple problems with the code that became blindingly obvious to us over the two year span. First, the boat had no conception of time or path planning, which made implementing simple logic like “look ahead for rocks and avoid them ahead of time” impossible to do. Second, the complex nature of the intermeshing goodness functions (explained more in the linked pdf) made them very difficult to debug.

This year we are moving to a new code format (detailed here:, which uses is a MidBrain state machine. The MidBrain is the section of code that takes in a commanded compass heading from the ForeBrain (the upper level planner) and decides how to set the sails and rudder to most speedily sail on that heading.

The purpose of the MidBrain state machine is to cleanly divide the control logic of the boat. Eric Schneider and Bonnie Ishiguro have been working on a design that will let the boat will follow different logic in the ‘Tacking’ state as opposed to the ‘Running’ state. This will let us do interesting things that we were unable to do before, like set the sails according to different sensors in varying states. This might be important if wind shadowing or other effects were felt in some states, but not others. We can also somewhat hard-code in a few maneuvers, such as tacking.


An exciting point about the structure is that we can swap in different control laws for various states and evaluate their performance. The code should be clean enough that different ways to control the boat for maximum speed can be cleanly swapped in and tested.

Mold-able Materials and Making Hatches

As you know from the two previous posts, it is really difficult to make the bow of a boat out of carbon fiber, because the carbon fiber is really thick and doesn’t bend over the point. Due to this, we have decided to cut off the first 2 inches of the hull and replace it with solid polyurethane.

So far, we have tested this idea in a 3D printed ABS world and it works really well—we were actually quite surprised, since we thought we would have to do multiple repetitions to get good results. However, the test worked the first time round on small scale boat. Thus, it is reasonable to expect that it will have similar functionality on a larger scale.

Originally, we were planning on using very hard polyurethane for the bow, but due to a mistake we ended up using a softer version and discovered that it not only worked well for our intended purpose, but is also a decent consistency for bouncing off of things if we happen to hit them with our boat.


The next step is working on a polyurethane keel, which will be made of a very non-viscous polyurethane mixed with lead shot. This will be molded into a keel bulb, which means that we don’t have to spend time machining it and can just create the shape. The polyurethane actually just arrived today: it is extremely non-viscous and cures in about 10 minutes. For reference, the polyurethane used in the bow cured in 24-48 hours.

We are also working on figuring out how hatches and cavities are going to work. Mostly this just involves talking to all the individual subteams to learn how large the objects they want on the boat are, and where they want them to be. Then it’s simply a matter of creating pockets for them in the boat.

The hatches are also currently in development. Right now, the front hatch for the whaleback is expected to be very large—possibly up to ¼ of the boat. It may be set back a little from the bow, but will probably still take up a large portion of the deck. This hatch will most likely be magnetically attached, with a polyurethane gasket around the edge. We were originally going to mold it with a vacuum formed carbon fiber shell, but currently think that pink foam with a carbon fiber shell will be easier.

The back hatch will probably be made up of the ridiculously large Hemisphere sensor. We are still looking into how to waterproof this hatch, and other aspects of how it will function. This is the hatch which will host the electronics package as well.

Olin Sailbot Design Review

Recently, Sailbot had our mid-semester Design Review in order to present our current activities and get feedback from outside students and staff.

There are two ultimate goals for Sailbot as a whole: the first is competing at the International Sailbot competition, which is being hosted this year in San Francisco by the University of British Columbia. The second is a more long-term goal: sail a robotic sailboat across the Atlantic Ocean, which has never been done before.

To achieve these, we have a series of smaller goals for individual subteams to achieve this year. The software subteam was concentrating on making the boat sail like a human and less like a robot. This means that the boat can sense what it should do by taking data from more than simply a GPS and wind direction sensor. This, of course, means that we need more sensors for software to take data from, which is why the sensor subteam has been concentrating on identifying what data we need, and what the best sensors for that data are. The electrical subteam is working on developing packages that could be used on different sized boats in order to conduct more testing, and, finally, the mechanical subteam is concentrating on an iterative manufacturing method. Overall, the projects of the individual teams will come together to give us a design paradigm for long-term research into our ultimate goals.

One other important note before I delve into what each team is working on more deeply, is that we are concentrating on testing this year. We have plywood testing rigs for sails, actuation, and electronics, and are using both small-scale boats, and a retrofitted RC boat to test code. Once the lake finally thaws out, we should be able to begin testing on a bigger scale.


To begin with, another update on the manufacturing of the hull. We are currently using a Gothic 10R model, that will eventually be 2 meters long. This model is designed to slice through waves as opposed to go over them. The strategy to make this boat is using isolation foam construction, as mentioned in the previous post. However, something that has developed further since the last post is how we are manufacturing the keel box and other hard parts of the boat. These parts must be strong, especially the keel block, since it is the supporting structure for both the keel and the mast, and keeps these two pieces aligned properly. These have been manufactured in two ways: either machined out of maple and sealed with a thin layer of epoxy or lacquer, or machined out of structural closed cell foam and then sealed with epoxy.


Also residing under the topic of mechanical subsystems is the sail subteam. For the first time, we are actually attempting to create our own sails, which involves a lot more work than simply ordering. Currently, we are creating and testing prototypes of Gothic 10r sails, and attempting to integrate previous knowledge of sail design in order to determine their material and exact components. We expect that they will be made of Mylar, since it is very lightweight and reduces stretching.

We are also delving into new ideas about sail actuation, with the ultimate goal being more refined control. Last year, both the mainsail and the jib were controlled by a single mechanism, and this year we hope to control them individually.

One other mechanical problem we ran into last year was having the rudder reverse itself, and then be unable to direct the boat properly. This year, we are implementing a rudder position check so that we can compare the perceived and actual rudder position. Currently, we are waiting on a strain gauge, and then we will be conducting Instron tests on it.



On to the electrical subsystem: the goals for this year were to make the system modular, more reliable, more efficient, and cleaner. For the modular area, we have been working on a miniature system, whose details will hopefully be explored on a later blog post. We are also looking into using Dynamixel actuators because they are smart—they have servo position control AND continuous rotation, along with easy feedback on torque, temperature, and speed—and because you can daisy chain them relatively easily.

On a larger scale, we have started using a National Instruments myRIO, which so far has proved to be relatively useful. It allows for quick iterations using protoboards and enables us to easily separate power and signal.


In the future, we are continuing to work on miniaturizing the system, by using custom circuit boards and gradually integrating a microcontroller into the boards. We also learned from last year that waterproofing is a pain: working with epoxy is difficult, so we are looking into other possibilities like Plasti-Dip or Aquarium sealant. Finally, we are figuring out the power requirements of the batteries so that we can figure out which ones we want to use for this year.


On to our final subsystem: the software team. First, a little history: last year we used goodness functions and weighted the headings of the boat. That means that the boat reacted to events in the moment without any sort of planning—which led to interesting and unpredictable behaviour. This year, we have changed it to follow the architecture outlined below:

This means that the boat will have more planning ability, and hopefully overall be able to react better. We are also looking at optimization:


The implementation of the code has changed as well. The old implementation used global variables, which allowed for the possibility of simultaneous access and edit, and was thus unreliable overall. The new code uses queues and notifiers. Queues feed data when requested, and notifiers broadcast new data. Both are thread-safe and access controlled, which gives more reliable data.

In terms of testing, we have started with a basic simulation to check the algorithms. Moving on to the small-scale boats, we can test basic wind reactions, platform modularity, state switching behaviour, and waypoint behaviour. However, it is not until we are able to test on the large boat that we will be able to accurately test sensor behaviour, sail tuning, and long distance behaviour.

Overall, the design review was very useful as an overview of what the team was up to and of our progress this semester.

To Make a Hull

A quick note: this post dates back to three weeks ago, but was unfortunately not published until now.


CADing hulls

The goals of the fabrication team this semester are to make our sailboat manufacturing A+. The ultimate hope is that, when we show our boat, people will think that it was professionally made for thousands of dollars. Of course, the idea is not to actually spend thousands of dollars on manufacturing, but still have awesome quality and a good-looking boat. As a rule of thumb, things that look good function well, and that is what we want for our fabrication.

This concentration on manufacturing means LOTS of prototyping. The current approach is to make a male mold—basically cut a bullet shaped piece of solid boat out of foam—and then glue several smaller molds together to make the final shape. Then we cover this with carbon fiber/fiber glass, and carve pockets under deck to put in the guts, such as the electronics and sensors.


Preliminary fabricated hull


Carbon fiber pieces

It’s a little harder than it sounds to get this process efficient and fast. It involves figuring out how to cut the boat by properly working the CNC router,* and then you still have to get the pieces together, layer the foam in carbon fiber/fiberglass and get a good-looking finish. Obviously, this process is pretty difficult.

Right now, the fabrication subteam is focusing on smaller details as well as the final hull. For example, it’s really hard to make bows of boats. Generally, the nose of the boat comes to a point, and it is very difficult to put carbon fiber over a point and have it come out well. Thus, we are actually taking that piece entirely off and molding a solid polyurethane bow to the boat. Also, everything in boat needs to be fastened securely—the mast and keel can’t be moving around—and so we’ve been figuring out ideas for how to accomplish that. Currently, we are trying different approaches—for example, using woods and structural hard foams. We are also experimenting with everything on a small scale: we are making 1/3 scale boats that can be used to figure out the tech on a small scale allowing us to see how and if it works.

*A CNC router is a mill that is automatically actuated. This means that it moves the cutter in 3 dimensions and carves the material to get 3D shapes. This saves a lot of time that would otherwise be spent doing lots of sanding and extra work.

New Semester

As it is a new semester, there is a short update on what we have been doing recently. First of all, we would like to welcome back all of our members who were studying away last semester: we are extremely happy to have you back.

In boat-building news, given that we only have a semester left, we have begun cracking down, trying to make sure that all of our plans are completed on schedule. The team is currently working on figuring out the final prices for sensors, depending on which ones we decide to use, and how they will affect the different systems belonging to each subteam. Given this system, we hope to be able to bring all the subteams’ work together in an awesome, fully functioning boat.

Reappearance of the Sail Subteam

This is a brief update on what the subteam that is responsible for designing, ordering, and otherwise figuring out the sails has been up to.

Last year, this subteam worked with boat builders and sail designers to create two greatly improved sets of sails. These sails were extremely useful especially because they were different sizes: one very large set and one smaller set, which allowed us to use the best sails depending on the weather. This year, we are perfecting our previous designs and determining how we can manufacture them at Olin. It will be very useful if we can make them at Olin, since they are delicate and difficult to ship.


This is a basic design of our current main sail, done in a program which specializes in CADing sails.

Furthermore, we are making new designs to add to our sail system, which we will implement in the future to make our robot more capable of reacting to dynamic weather conditions. These include a method of furling our sails into the boom. We are still working on other ideas about improving our sails’ functionality, and making them easier to use and control.


A Hull of a Different Color

The software team walked out to the SailBot bay of Olin’s Large Project Building on November 13th to find a dark blue, long hull had appeared there. Between November 8th and 11th, Halie and Raagini of the Mechanical Hull, Sensing, and Jib Actuator team painted last year’s hull, Chaos Theory, in preparation for her to be used as a test platform for our new pitot tube sensors.


Team member Raagini stands with Chaos Theory in Olin’s paint booth after the first coat of paint was applied.

Pitot tubes are able to sense the speed of a body relative to a fluid surrounding the body. They do this through Bernoulli’s law which states that the faster a fluid moves, the less pressure it exerts on a body. Therefore, by comparing the ambient pressure with the pressure of the moving fluid, a relative speed can be obtained. Pitot tubes are frequently used as the speed sensors for helicopters and power boats.


A diagram describing how pitot tubes measure relative speed by comparing the pressure of the moving fluid with the ambient pressure.

When the team returns from Thanksgiving break, a small hole will be drilled in the bottom of Chaos theory, near the stern. Here, we will install a pitot tube. Once it is in place, approximately one inch of the plastic sensor will protrude beneath the body of the hull.


Halie paints the hull in the Large Project Building paint bay.

This sensor will let us know the hull speed relative to the water speed. We will confirm this through tests of the sensor in the Chaos Theory hull at the Babson pool before designing it into Damn Yankee. If combined with GPS data, we can extract any current’s direction and velocity, and thus determine the instantaneous hull velocity. We will use this for closed loop feedback checks of our software as well as to confirm the data our GPS is giving us. Overall, the addition of this sensor will allow us to know more about the physical situation of our boat in order to ensure that it functions properly.

%d bloggers like this: