You may have noticed that this website has been changing in appearance recently. That is because we are updating it to reflect our new direction! As such, there will probably be some things which look/act a little oddly in the next few weeks. Some pages that currently exist will stop existing, and some new ones will be added. If there are any problems, please feel free to comment on this post to let us know.
After a nice, relaxing summer, our team has reconvened with new members and a new purpose. We have decided that we are no longer affiliated with the Sailbot Competition, and instead are pursuing the idea of a trans-Atlantic robotic sailboat more thoroughly. If you are interested in learning more we will be attending the MIT Mini Maker Faire this coming Saturday October 4th, and we invite anyone in the area to come and see our new boat Damn Yankee!, and talk with members of our team.
More updates will come as progress continues.
Over the past two semesters, Olin Robotic Sailing has worked to build our latest boat, Damn Yankee! Due to the support of our wonderful sponsors, we were able to make this boat a reality!
Our boat this year was designed for robustness, simplicity, and repeatability. Damn Yankee! is a meter long boat modeled off of Frank Russell’s Gothic 10R design. Our hull has a carbon fiber outer shell and a core of CNC machined foam and hard wood. The keel has a maple spine and a bulb filled with lead shot and pourable polymer, all covered in carbon fiber. Our fabrication process allows for repeatability, allowing faster design iterations, leading to a better end design.
This is the first year that we’ve made our own sails. The design we choose is a Marconi Rig, with the large mainsail and the small jib sail independently actuated for greater control and maneuverability.
Our electrical system has been redesigned to easily integrate any future additions to the sensor network. We are using the National Instruments’ new myRio as our processor and Dynamixel motors to actuate the boat. Our sensor system includes a Hemisphere GNS V102 GPS system, and an encoded wind vane to give us wind direction.
This year, the software system was completely rewritten. It has more modular architecture that can be easily modified for future changes in overall system design. This will also allow for future implementation of programming languages that are better for specific tasks.
All of these subsystem innovations have allowed us to design and build a robotic sailboat that will serve as a robust testing platform for robotic sailing research moving forward.
Given all of the progress that we’ve made this year, we are very proud to announce Damn Yankee! as the newest member to our fleet. However, we are not going to compete in the International Robotic Sailing Competition this year. Our team came to the conclusion that we wanted to focus on producing a quality product rather than rushing to finish something adequate. We are very proud of all of the hard work we put into developing this boat, and we will continue to develop and test it over the course of next year. Keep an eye out for an announcement from us about Damn Yankee! testing! She’ll be beautiful on the water.
Thank you for your interest and support.
As you may have noticed, this blog has not been updated in some time. The reason for this is Finals and the general conundrum that comes with the end of the year. However, there is some very good news on the Robotic Sailing front. Namely: we have a boat!
The first unveiling of this boat took place at Olin College’s Expo presentation on May 12.
As you can see, the sails and keel are attached. The hull has not yet been fully polished, but is expected to be finished by the end of the year, and the rudder is currently in production. The electronics package is finished, however we have to widen the cavity in the hull in order to finish installation. The transmission has been installed, and the code has been extensively run on our testing rig to determine any problems with it. So far, it seems to be working well.
We are hoping to take Damn Yankee! out to Lake Waban at least once before the end of the year, to test on the water and make sure that all of our systems integrate in the way we expect them to, but otherwise we have completed our goal for the year. We have a new boat, and isn’t she a beauty?
There will be one more announcement regarding the team before the end of the year, so stay tuned!
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 should have a lovely prototype of Damn Yankee that we can take out to Lake Waban and test by April 13th.
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.
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.
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 (http://en.wikipedia.org/wiki/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.
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: http://olinroboticsailing.files.wordpress.com/2012/05/sailbot-code-summary-2011-12.pdf
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: http://olinsailbot.com/2013/10/28/new-code-format/), 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.
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.
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.