My original plan was to use a traditional mast and mainsail, with Yannick Lemonnier of West Sails volunteering to produce the sail. Yannick is no stranger to mad schemes himself, having competed in far too many Figaro races. These days, he spends his time sailing his Moth winged-beast, or racing his International 14. That is, when he’s not making sails for everyone from Beoga Beag to the Volvo Open 70s.
Yannick had suggested using a Kevlar sail material, similar to the stuff they use for bullet-proof vests! However, after looking at the hull, he quickly decided that a solid “wing sail” was the only way to fly (pun most definitely intended). The OpenWing design has two wings which are hinged together. Usually, the wing is attached to the deck using a similar fitting to the average catamaran mast, with stays keeping the whole structure in place.
Each wing forms a NACA airfoil shape (similar to that used on the keel), with no camber. In other words, the airfoil is symmetrical. The airfoil I am using is the NACA0018, with a NACA0009 in the tail. The leading edge of the tail section is hinged onto the trailing edge of the forward section (for clarification, the CAD drawing here only shows the forward section, not the tail). The forward section pivots around a mast stub (shown as the vertical rod through the lower four struts). In my implementation, the mast is unstayed.
The two wings are coupled together in such a way that the incident angle between them can’t be greater than around 30 or 40 degrees. The idea behind a wing-sail like this is that it will fly through the air and balance itself. The tail allows the boat to adjust the sail trim.
While this is a more involved mechanism from the traditional “stick and rags,” it should be more robust than the alternative. Ideally, this structure would withstand a 360 degree roll, but that might be asking too much! If it doesn’t tear like a normal sail would, it will be a definite improvement.
I’m hoping to have the first version of this beast assembled and ready to fly within the next few weeks. Just like the wind direction indicator, my plan is to put this baby outside and let Mother Nature kick it around for a while.
I’m looking forward to sailing the boat (manually) with this contraption installed, just to see how it works. Who knows, I might even make one for my Laser II.
Due to other, exciting distractions (which I will mention in a later post), I haven’t had a chance to keep the blog up to date. Still, work progresses on the boat, and that’s the important part. Last month, with the keel now in its new position about 30mm further back along the hull, and sealed into place, it was time to add the electronics board.
This involves soldering the umbilical (ribbon) cable from the Sailboat Guidance System to the onboard wiring harness. It also involves soldering the two stepper motors to the harness, and fixing the rudder and sail steppers into place. There is still some work to do in terms of installing the temperature sensors and the tilt-compensated compass, but the key elements are in-situ. This includes the two Atmel boards based on the ATmega8, the PC Engines “Alix” board running FreeBSD, the current amplifier (measures the battery current and converts it to a voltage), the two stepper controllers, the mission key switch, and the deck plugs.
I am using an old Asus eeePC as an interface to the electronics, while it is under development. I will bring the Asus with me to each of the test launches, for any last-minute tuning or logging. As it happens, I once worked for Altos Computer Systems in California, and the company was bought by Asus. So, for the few remaining months before I left to go somewhere else, I was officially an Asus employee. Apropos of nothing…
I’ve also been working on the simulations of the GPS and Igor interfaces, and the Redis database. I am recoding the interface format to the Atmel to make it a bit less human-friendly, but a bit more machine-readable. Currently, the interface is comprised of text commands sent over the serial port. I am switching to a six-byte packet format.
I have also started converting the PID controller to C code on the Atmel chip, and hope to see the steering system kick into life any day, now.
All in all, lots of work has been done on the boat in the last few months, and February will mark the first anniversary of the project.
I have some exciting news which I mentioned above, and I will post on that in the next week or so.
I also have an update on the sail design – it’s quite a change from the original plans, and I will post more on that, soon.
Here’s a quick sneak picture of the hull with the wiring harness complete and the decks sealed in place.
The keel is still only temporarily installed so the main compartment is again flooding with sea water. The bow is still slightly down in comparison to the stern, but this is mostly due to the flooded compartment. Also, the keel still hasn’t been moved back, yet. That will happen this week.
The solar power connector and the masthead connector are visible just in front of the main compartment. The ugly brown tape is to seal up the deck fittings for the rudder and sail servo motors. The deck plates are taped to the hull using polyester resin and fibreglass tape. They need to be sanded smooth, ready for another final coat of epoxy and then a generous layer of antifoul. The antifoul coating will be one of the very last steps prior to the Microtransat. If you look at the previous blog posting on the SGS, the alu plate which supports the electronics will be mounted over the main compartment and secured in place.
A quick look at the almost-complete Sailboat Guidance System (SGS). The board on the left is Igor. Otto is on the right, and the main CPU (Mother) is hidden underneath. The ribbon cable brings all the I/O to and from the boards. The red insulating tape is to remind me of some of the last remaining wires which need to be connected. You can also just about make out the DC/DC converter which is just underneath the ribbon cable at the bottom of the picture.
On September 1st, we launched the hull in Aughinish bay, without sails, rudder or electronics. The purpose was to see how the hull performed in open water, with the keel attached. As the keel wasn’t properly attached or sealed in place, the main compartment flooded with water, but as the compartments are individually water-tight, this wasn’t an issue. It did lower the boat in the water somewhat, but not to any significant degree.
As the compartment wiring wasn’t completed, and the deck panels weren’t glassed in place, they were attached to the hull using duct tape. Not pretty, but it works.
The immediate good news was that the hull didn’t sink! That’s worth celebrating. Also, I was extremely impressed with how she moved through the water. The hull maintained a very straight line, with no noticeable turn to port or starboard. The bow and stern waves looked impressive, even when forcing the boat through the water at a faster-than-hullspeed rate. Overall, I was impressed with the seaworthiness of the hull and her ability to hold her course.
The bad news was that the keel is way too heavy, and too far forward. The boat is too far down on the water line, which makes it relatively sluggish, and the extra weight isn’t necessary. The long keel does a lot to keep the boat going straight, and resisting the lateral forces which will be imposed by the sails. The original design specification was for a keel of around 12kg and a hull of around 4 or at most 5kg. In fact, the hull is weighing in at 7kg and the keel is a whopping 18kg. This puts the total displacement at 25kg which is just too heavy. The keel is formed from two stainless steel threaded rods, covered by two sheets of marine ply, shaped into a NACA airfoil. At the base of the keel is a lead weight.
Since that initial test, I have removed approximately 6kg from the lead keel. I have also angled the keel back a bit by about 10 degrees, to soften the leading edge and move the weight back. Recent sea trials have shown this to have been quite effective, but there is more to do. I’m still not happy with the natural pitch angle of the hull, and would like to see more freeboard at the bow and less at the stern. The keel is bolted to a thick aluminium plate which distributes the load. I will re-drill the plate to move the keel back further along the longitudinal axis. I will also plane or sand back the plywood fin, to make it thinner and lighter. Structurally, the strength comes from the two threaded rods, so it is OK to reduce the width of the keel.
Overall, the hull still performs admirably, and it will be great to see her progress through the water under sail.
After a lunchtime conversation with a friend of mine, I ditched some of the earlier design considerations around message-passing and MQ-based systems in favour of the NoSQL database Redis.
Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets.
That’s according to the official blurb on the web site, at least. It has several interesting components which are useful for Beoga Beag. It has a rudimentary pub/sub architecture pattern, it is extremely lightweight, it stores its database in memory rather than on a disk (so it’s less likely to burn through the Compact Flash file system), and it has an “append-only file” (AOF) archive mechanism.
The AOF system means that updates to the database are recorded sequentially in a journal file. Normally this wouldn’t be a great way to operate as the journal file can get quite large. In this case, however, it’s ideal. By journalling all of the database updates, I can examine the database at any moment in time, and recreate the decisions made by the boat during its missions. Also, even though the journal can use a lot of space, it is only writing the disk blocks once. For contrast, imagine a traditional database which is storing the latitude/longitude at a particular block on the file system. If the lat/long is updated once per second, or 86,400 times per day, unless the OS does something clever then the lifetime of that particular disk block will be exceeded in a day or two.
I will still need to retain the classic Redis disk dump, but the write frequency of the dumps can be tuned to be no more frequent than every 60 seconds or so, which reduces the load on specific disk blocks. Furthermore, I will be looking to time-stamp the disk dump so that the system will use a new file for each day.
There are a number of language interfaces to Redis, which means I can use more than one language on the main system. For example, I can use C code to read and parse the GPS data, saving the latitude and longitude (in radians) directly in the Redis database. I can then use Ruby to process the GPS position and determine a new course.