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.