The Admirable Admiral

Taking A Beating

In accordance with a new task sharing initiave between myself and one of the engineering students who is working on the control systems of the boat, I am now going to tackle one of the simplest, and yet most infuriating problems that needs a solution before we can take on a pond, let alone the Atlantic. The issue is beating, and not your wife.

Beating is the action carried out in order to sail upwind. That’s my definition, and I’m sticking to it. It’s simple, very simple. Here’s the problem:

This is a graphic displaying the simplest type of beat to compute, where the desired heading is directly into the wind.

You’re at point A, and you want to sail to point B. Unfortunately, the vector BA is parralel to wind direction, and you can’t sail upwind! Luckily, you can sail right up to 45 degrees to the wind direction, so the solution is to set waypoints (which are marked in red in the above graphic) and beat or zig-zag, towards your destination.

I call this the Simple Beating Algorithm:

1. Turn 45 degrees to port
2. Sail 10 meters
3. Turn 90 degrees in the opposite direction to the previous turn
4. Sail 10 meters
5. If arrived at desired location, break
6. Goto line 3

This is quite simple to implement: the boat already has a compass and a wind direction meter, and it will soon have a paddle wheel to determine relative speed to the water. That’s enough information, with the aid of an accurate timer, to sail a five or ten meter leg 45 degrees either side of the desired heading, before tacking ninety degrees and continuing the beat. Simple, as I said.

Unfortunately, that ain’t all there is to it, folks.

The complex part comes when the desired heading isn’t directly upwind, but is still within the dead zone. That is to say, the desired heading is greater than 315 degrees and less than 45, assuming the dead zone is 45 degrees either side of the wind direction. In this scenario, a simple equal length leg zig-zag approach is not suitable, as for every second leg, the bow would be pointing into the dead zone.

In this graphic, it can be seen why it is ineffective to follow a simple beating algorithm when the desired heading is inside the dead zone but not parralel to the wind direction.

The above graphic is an example of a heading inside the dead zone, but not parralel to the wind direction. For clarity, the desired heading is just inside the 45 degree dead zone, although the principle holds for all headings not parralel to wind direction. (I do feel I’m using the phrase parralel to wind direction an awful lot, but it’s necessary for clarity.) In the above graphic, the simple beating algorithm is used, however, it can be seen that the legs where the boat should be in a starboard tack, it is in fact in irons, or stuck in the dead zone. This displays why the simple beating algorithm is insufficient. It’s a shame, too, because the simple beating algorithm is damn simple!

This leads me into what I’ll imaginatively call the Complex Beating Algorithm. It’s clear that the angle to the wind must be taken into account to avoid deliberately tacking into the dead zone.

In this graphic, the desired heading is inside the dead zone. Theta is the angle between the desired heading and the wind direction Theta is positive if the desired heading is starboard of wind direction.

The above graphic shows the angles of the port and starboard tacks when beating. By using these angles, which are always at the edge of the dead zone (handy, that!), we can be sure that the boat never gets stuck in irons while while beating. So, we have fixed angles, which are the same as the simple beating algorithm, so what’s different?

Variable length legs while beating, that’s what. Using some good old fashioned trigonometry, the correct lengths can be ascertained.

This graphic show the course dictated by the Complex Beating Algorithm.

If the angle Theta is positive, the port tack leg can be the lengthened. To keep the boat on it’s overall course, the algorithm then also shortens the starboard tack. The situation is simply reserved is Theta is negative. Pseudocode time:

if (Theta <= 0) {
port_tack = 10/Cos(Theta);
starboard_ tack = 10 * Cos (Theta);
}
else {
port_tack = 10 * Cos(-Theta);
starboard_tack = 10/Cos(Theta):
}

The above algorithm falls down when Theta is  +/- 45 degrees, as there is a divide-by-zero error. However, when the boat is at +/- 45 degrees, the boat should be out of the dead zone, and so the complex beating algorithm would not be invoked.

I apologise if the above post is overly simple. I have tried to explain my logic clearly. - D.N.T. (01/11/08)

Engineering Seamen

Today, I had my first meeting with the engineers who are involved in the overreaching robotboat project. I was very impressed with their work to date, and especially with the model boat.

They have sensibly and authoritively divided the larger Roboboat project into roles, where each student has a clearly defined goal and they are focusing consistantly on integration and information sharing. I know from my own previous experience with autonomous vehicles that this is an emminently sensible approach.

Following the meeting, I was very kindly allowed the opportunity to observe the yacht sail under remote control and to even attempt (with some interference from UCD’s swans) to sail it myself. This experience has very much allowed me to properly appreciate the dynamics of the boat. The electronic engineers have done a very good job of installing the servos to control the main sheet and and rudder. In fact, that alone has solved some issues for me:

• The mainsheet is controlled by a servo motor. It has accurate stepping, and you can be sure of the length of the mainsheet once you’ve set it.
• The rudder is controlled, as expected, by a servo. It too can be set accurately, and the servo is more than strong enough to hold it in place.

The most important outcome of this meeting, and subsequent discussions with the very helpful engineers (No, I haven’t backtracked on my stance on engineers, but they may have their uses after all!) is that it became clear that there is a another student, Caoimhín O’Briain, who has been working on very similar elements to those that I was. We even had independently developed, but damn near identical, algorithms for the same problems. Great minds, and all that…

To avoid wasteful duplication of effort, we have agreed a dividing line and self-assigned tasks that suit our respective skill sets. In keeping with this, expect a post on a somewhat interesting problem quite soon. - D.N.T. (1/11/08)

Ship’s Log 30/10/08

Today, I am meeting with my project supervisor, Dr. Lorcan Coyle.

I can use this time to serenade him with reports of progress, ideas and possibly Erasure’s A Little Respect. The meeting will take place in CASL (pronounce castle or the dungeon…), which will be a bit of a trek in my current condition.

I intend to broach the following:

• Pseudo code algorithms for simple navigation based on two 2 known vectors (Angle from magnetic north and angle from wind direction) and possible one known scalar (wind speed).
  • How to deal with the Dead Zone
  • How to deal with running and the associate lack of control
• The arguments for and against direct control of the boom with a servo as opposed to indirect control via the main sheet
• My arguments for and against possible control systems
  • Expected issues with scalabiltiy
  • My inability to solder breaks another servo shield

What I hope to gain in this meeting is final decisions on the control system, some feedback on the suitability of my proposed control methods and discuss gaining regular access to the boat. I would stress that tardiness on my part is the sole reason I have not yet inspected the boat itself. I hope to rectify this at a meeting with the other students involved in the project on Friday afternoon.

I will post anecdotal minutes shortly after the meeting. - D.N.T. (30/10/08)

Under the Bridge

I am not one for micro-management. I’ve always believed that the best results are gained when clear, concise expectations are set, and people are left to use their initiative. Unlike my love life, however, this yacht needs a microcontroller.

How to pick the brains of the operations is always a hotly contested question. Elections, civil wars, even divorces: all the results of contests for control. On this boat, one man, or component, will have control, and the yardarm is ready for mutineers. The only question is who will be at the helm; Captain Arduino, the dashing Italian; Commodore Stix, and his sons Gum and Robo; or even the ever elusive pirate, Mister Handyboard.

Each has his advantages, but each also has the potential the sink this project, Arduino by his hesitance to act, the Stix family because of their obscure mind and Handyboard, because I simply can’t find the bastard son of MIT and lego. To elaborate, a profile of each is necessary.

First off the starting block is the Gumstix family. These are tiny computers running linux, with available bluetooth, and GPS and digital I/0 daughter boards. They are powerful, with 400Mhz cpus, flash memory and SD storage, and ethernet. It’s biggest problem is the OS. Although it’s runs on linux, during a project last year, the team I was in found it very difficult to get a stable buildroot for the gumstix, and when one was found, we could never get all the services to work at once. Cillian Murphy, who had the unenviable task of dealing with the gumstix for that autonomous dirigible project, wrote about some of his woes, and successes on his blog.

Thanks to the experiences I had during the aforementioned Project Hindenburg, I would be very hesitant to use gumstix/robostix. The problems associated with simply setting them up are quite daunting, which could waste valuable time during the project.

Next is the Handyboard. The handyboard was developed by MIT, for a Lego robot contest. It is quite expandable and has an LCD screen, the only option I have investigated which offers such. It runs a 2Mhz Motorola processor, and has 32Kb of battery backed SRAM. It can control four 1A motors and has an add-on board to support servo control.

The biggest advantage of these is that UCD engineers have used them before, and (to continue with my anti-engineer bile) if they can use them…. They have low power consumption, are reliable and, as far as I can gather, the university already has some to hand.

Finally, onto Arduinos. This Italian-made microcontrollers is quite promising. It is much less powerful than the Gumstix,  as it is not a micro pc, but is a board based on the ATMEGA168 microcontroller.  It has 14 digital I/O pins, 6 of which are capable of Pulse Width Modulation, which is required for controlling servos. It has six analog inputs, a 5V linear regulator and a USB interface. There are available shields aimed towards specific applications, including servo control.

Programming for the Arduino is done in Wiring, a C-like language, and it supplies it’s own IDE in Java, which is available for Linux, Mac and Windows. Loading the program to the board is very quick, over a USB interface, as he Arduino has an inbuilt USB-to-RS232 chip. It has 14KB of available Flash memory to store code.

The fun part, now, conclusions. Years ago, I was told that the fastest way to lose money was to bet on every horse running. Usually it’s best to make a decision and put it into action, and, to paraphrase a popular Japanese children’s cartoon, I choose you, Captain Arduino.

I favour arduinos, for ease of use, lots of i/o and it has enough computational brawn to control the boat.

A close second is the handyboard, which has much of the above. The handyboards have less i/o ports, but do have a track record in the college.

Which will be picked by those in the higher echelons, like the fate of the tanks taken by the pirates of Eyl, has yet to be decided. - D.N.T. (29/10/08)

Common Sense

It has been decided by those on a higher paygrade than I that for the initial prototype, I will restrict myself to acquiring two types of environmental data only: Relative wind velocity and Vessel velocity.

First off, I need to determine wind velocity. I am tackling this first because it is considerably more difficult to discern than the velocity of the vessel. Of course, velocity is a vector and is made of two distinct pieces of information: direction and magnitude, so there is in effect two sensors required for this task.

An anemometer, of either the cup-on-stalks variety or the proppeller variety, and a weather vane, to determine the wind speed.

I have been advised to only (if possible) take into account off-the-shelf components for this build, as they would be significantly sturdier than any hardware that I, a computer science student, could put together. However, as commercial anemometers are quite expensive, it is likely that the engineers involved in this project will be respeonsible for the construction of a custom anemometer. It’s interface remains to be seen.

In order to determine the yacht’s velocity, I feel that a GPS reciever would be the ideal option, as it would allow accurate tracking of relative positions of waypoints and course logging as well as basic velocity information. By reading successive GPS co-ordinates, a bearing can ascertained. Driection by:

tan(Angle) = (currX-lastX)/(currY-lastY)

Speed by:

(((currX-lastX)^2 + (currY-lastY)^2))^(1/2)

Reading in the GPS co-ordinates from serial should not be difficult, depending on the platform chosen.

For the basic prototype, however, it is likely only a magnetometer will be available. This will mean I will be able to discern magnetic north. By knowing magnetic north, and relative wind velocity, it should be possible to set the rudder and sails so as to set the boat on a specific bearing.

Here is some very simple code to set the angle of the boom. Let alpha be the relative angle of the wind and setBoomAngle to be a function which sets the angle of the boom relative to the boat (where 0 is the boom parallel to the boat, postive is to port and negative is to starboard).

if (45 < alpha < 180)     setBoomAngle((alpha-45)*1.5);

else if (180 <= alpha <315) setBoomAngle((alpha-315)*1.5);

By using the rudder to steer onto a magnetic bearing and the above algorithm to set the sails, basic navigation should be attainable. A special case must be implemented to avoid the deadzone (which is 45 degrees either side of the wind direction) and to tack (or zig-zag upwind) towards any bearing in the deadzone.

The Points of Sail with the resultant boom angles from the pseudo-code snippet above.

The maths of the above is subject to confimation, and is based upon my trusty RYA notebook from when I was a budding sailor. The basis for the formula is that at close haul, the sail should be as close to parallel to the boat’s bearing as possible and when running the sail should be perpindicular to the bearing.

I’ll need to invest further study into this to ensure plane sailing (pun intended) - D.N.T. (14/10/08)

A Titantic Undertaking

First off, there’s going to be a lot of puns on these pages, and I won’t apologise for them, so here goes…

The project is called roboboat, and it’s essentially a robotic sailboat. Yes, sailboat. I know, cool. I thought so too. I’m the software guy, I think. I’ll be working with a postgrad computer scientist and some engineers. (I know, but I can’t hold it against them, since, like Somali pirates, they have the yacht and aren’t likely to give it to me.)

The project as I see it, is as follows:

There will be some sensors to determine variables like wind velocity and the velocity and pitch of the yacht, which is a one meter model of a large sailing yacht.

There will be some motors to keep the mainsheet taut and a servo to control the rudder. Depending on the model yacht, another may be required for the centre/dagger board. To keep the boat balanced, either a weight attached to a servo or a liquid pumped from side to side can be used as the equivelent to a sailor hanging off the side. I’ll need to speak to the engineers working with the physical boat to see what’s needed there.

The motors and servos will be controlled by an Arduino microcontroller with a fitted motor shield. It can easily handle the required number of motors and servos and has accurate timers and lots of pinouts. You programme for it in C, with lots of nice libraries available. It’s own supplied compiler then converts it to machine code. I have had the misfortune of working with gumstix and robostix before, and while they have significantly more processing power, they are not very user friendly. Sure they can do the maths fast, but trying to talk to them is painful. Arduinos are eager kids. They do what you want, when you want it, as long as it’s simple enough to be explained in crayon. In that respect, they’re similar to the copywriters of the News of the World.

For an added challenge, try to read the original:

J ibwf ibe uif njtgpsuvof pg xpsljoh xjui hvntujy boe spcptujy cfgpsf, boe xijmf uifz ibwf tjhojgjdboumz npsf qspdfttjoh qpxfs, uifz bsf bvujtujd qspejhjft. Tvsf uifz dbo ep uif nbuit gbtu, cvu uszjoh up ubml up uifn jt qbjogvm. Bsevjopt bsf fbhfs ljet. Uifz ep xibu zpv xbou, xifo zpv xbou ju, bt mpoh bt ju’t tjnqmf fopvhi up cf fyqmbjofe jo dsbzpo. Jo uibu sftqfdu, uifz’sf tjnjmbs up uif dpqzxsjufst pg uif Ofxt pg uif Xpsme.

I’m not sure yet if there will be a need for a gumstix on the boat, or if I can unload the maths to a landlubbin’ computer. Actually, I’m not 100% sure of anything in this project yet, except that I need to obtain an eighteenth century Royal Navy Admiral’s hat, and fast. I’m not sure appropriate headdress will count when grading, but it can’t hurt to show commitment.

Now, down to the knitty-gritty that every computer scientist purports to revel in but secretly can’t stand. The maths. The environmental forces acting on a sailing vessel are quite complex. The idea for this yacht is to have it sailing around UCD’s lake autonomously, which has very flat water and no currents. That’s nice because currents and waves and bad weather requires a human sailor, that beast I’m trying to obsolete, to have a good feel for the boat. How a boat “feels” is going to be hard to ascertain with limited sensors, so sailing on flat water will is a real advantage. That’s an assumption though, and anyone who’s met assumption’s children knows how dangerous getting in bed with her is.

Even if I do hop in with her, there’s still a lot going on, though. The basic problem is:

1. Find yacht velocity.
2. Find wind velocity.
3. Adjust rudder to correct yacht velocity’s direction component.
4. Adjust sail to obtain maximum force from wind engaging the sail.
5. Goto line 1.

There’s other things to take into account, like controlling the speed of the yacht by loosing and tautening the mainsheet, the effect of the jib, the use of the centre board, actually working out the yacht’s position and how to beat, or sail upwind.

This is not to mention the physics of the sail, which is actually an airfoil, which generates lift, not dissimilarly to a wing.

I’m thinking that I will have to:

1. Write control systems for the boat (and possibly build them) (codename: Engine Room)
2. Write a control loop for the microcontroller to:
   - Read in sensor data (codename: Crow’s Nest)
   - Process data or send it to shore for processing (codename: Captain On Deck)
   - Set the pinouts (codename: Helmsman)
3. Write a shore based interface (codename: Haulbowline)
4. Work out how to wirelessly talk the yacht (codename: Semaphore)
5. Test (codename: Sea Worthy)
6. Goto line 5.

How it actually shapes up remains to be seen, I’ll sea you later (pun intentional). - D.N.T. (01/10/08)