Autonomous Model Sailboat

Senior Project
Andrew Goldberg
General Engineering
June 2012

Goldberg 1

Introduction

The proposed goal of this project was to modify a model sailboat to sail semiautonomously. The resulting project exceeded this goal with additional features
and a higher level of sophistication. The project proposal stipulated a system to
allow the user to pre-program or remotely assign the boat a heading, which
would then be automatically maintained using data from onboard sensors and
control of the boats rudder and sail servos. Development progressed well and
allowed for the addition of more advanced features, including a real-time
Ground Control System (GCS) Graphical User Interface (GUI) running on a base
station computer, and the ability to navigate a course of waypoints with data
from an on-board Global Positioning System (GPS) receiver. This report will
discuss the design, implementation, and testing of the hardware and software
involved.

Hardware:

Original hardware proposal:

Microcontroller to read sensor and R/C data and control actuators.
o Including circuitry to read from various sensors and integrate itself
into the existing R/C electronics.
Wind speed and direction sensor (may need to be designed and built).
IMU inertial measurement unit for stability control.
Compass to detect current heading.
Possible water speed and direction sensor to detect stalls and correct for
current.
Possible inclusion of a GPS unit to maintain motion relative to shore.
Through testing and evaluation, the final list of control hardware was not far off
from the speculated requirements:
Seeeduino Arduino Mega with ATmega1280 microprocessor
XBee PRO 60mW radio module (in lieu of R/C signal decoding).
US Digital MA3 Miniature Absolute Magnetic Shaft Encoder, housed in
mounting bracket with wind vane, made with polyform plastic and
mounted on top of mast to detect wind direction.
Sparkfun Razor 9 Degree of Freedom Inertial Measurement Unit (SEN10736), incorporates stability control and digital compass.
Locosys LS20031 GPS receiver.
Custom designed Printed Circuit Board (PCB) to connect power and
sensors to Seeeduino Mega.
A custom built waterproof acrylic plastic enclosure mounted on the deck
to safely contain the electronics on the boat.
Seeeduino Arduino Mega
Through development, the project moved through several microcontroller
boards before settling on the Seeeduino Arduino Mega. From the start I knew I
would use the open source Arduino platform, for the ease of programming and
debugging, and wide availability of third-party contributed software libraries.
Initially, I intended to use the arduPilot, a small board with an ATmega328,

Goldberg 2
designed for easily converting model airplanes into drones. This board was
attractive for its I/O pins for R/C signal reading and servo control, and
impressive software. If I could modify the existing software to work for a
sailboat instead of an aircraft, I could use it as a base to improve and include new
features. However, I soon discovered that the arduPilot code base was far too
specialized for aircraft, with several aircraft-specific features that operated
interdependently, so I opted to work from scratch, with an Arduino Mega, with
an ATmega1280 microprocessor. The Seeed Studio Seeeduino Mega board was
perfect because it operates in 3.3 or 5 volt modes, with onboard regulators for
each voltage. My sensors all operate on 3.3 volts, except for the MA3 encoder,
which needs 5 volts. Using the Seeeduino saved designing an additional 5 volt
regulator into the project.
The most significant benefit to the ATmega1280 over the ATmega328 is the
inclusion of four hardware UART ports instead of just one. The boat electronics
make use of all four hardware serial ports:
1.
2.
3.
4.

Serial 0: Programming and USB debugging with computer.

Serial 1: GPS receiver at 57600 baud.
Serial 2: 9dof IMU at 57600 baud
Serial 3: XBee radio for GCS communications at 38400 baud.

The alternative would be software emulation of serial ports through regular

digital pins, which would have lower maximum baud rates and impose a large
drain on system resources.
XBee PRO 60mW Radio
After the move from the arduPilot to the Seeeduino Mega, the idea of R/C signal
decoding became less attractive, compared to digital two-way communication
between the boat and user. This prompted the inclusion of a pair of XBee
wireless radios, one on the boat and one on a base station computer, running a
GCS. The radios operate at 2.4 ghz, 38400 baud, and have a specified range of
one mile, far more than a standard R/C hobby transmitter/receiver. While it is
true that the 60 mW radio is a large power drain, one of the benefits to the
sailboat platform is room and weight capacity for plenty of battery power.
The XBee radio is connected to Serial port 3, and transmits a new data packet
from the boat every 200 ms (5 hz).
MA3 Shaft Encoder (Wind Sensor)
One of the greatest design challenges to this project was detection of wind
direction. For the control logic to make decisions about rudder position and sail
trim, it must have an accurate reading of wind direction relative to the boat. To
accomplish this, I used an absolute rotary encoder with a ball bearing shaft for
minimum drag, mounted at the top of the mast with a wind vane secured to the
shaft. Because it is an absolute encoder, no reference other than a one-time
calibration based on the position of the encoder relative to the boat is needed; it
always outputs the same value for a given position. This value is an analog
signala voltage ranging from 0 to 5 volts, that linearly corresponds to 0 to 359

Goldberg 3
degrees. Because the Seeeduino Mega runs at 3.3 volts, a voltage divider circuit
was designed into the PCB to scale 0-5 volts down to 0-3.2 volts. Software then
reads the Analog to Digital Converter (ADC) to get a wind direction bearing.
Several iterations of wind vane were used, molded from polyform plastic, with
the goal to maximize area, minimize weight, and maintain balance on the
encoder shaft. Future improvements will use a different material for the wind
vane to further decrease weight.

Figure 1. Encoder bracket and first revision wind vane (left) and improved (right).

Sparkfun Razor 9dof IMU

The other difficult challenge is determining the boats real-time heading. A
magnetometer can be used as a digital compass, measuring the strength of the
Earths magnetic field in all three axes. However, this reading alone is useless
with any large degree of tilt on the platform. With a model sailboat, tilt is a
given. The cure is to add an accelerometer and gyroscope to get the physical
orientation of the platform and apply a tilt correction algorithm (described in the
software section) to get an accurate heading with any tilt.
Early in the development I acquired as three separate components a digital 3-axis
accelerometer, digital 3-axis gyroscope, and digital 3-axis magnetometer. I
feared the amount of digital pins, logic level conversion circuitry, and processing
overhead to read data from all three sensors and perform the tilt correction math
would be excessive, and replaced all three with the Sparkfun 9dof IMU, a

Goldberg 4
separate Arduino-compatible board that integrates the three sensors with an
ATmega328, performs the tilt calibration, and outputs Roll Pitch and Yaw (RPY)
angles over serial. An open source software project develops and releases an
Arduino program for the board that was modified and used in this project to
send data to the Seeeduino Mega. The two angles of interest are roll, or tilt, used
in software to prevent the boat from tipping, and yaw, which is the boats current
heading, and is needed to steer the boat toward a desired heading.
Integrating the IMU required both a solid mounting and the ability to disconnect
it to reprogram the board separately as necessary. Hard iron calibration of the
sensors can only be done with the board in its installed position, mounted in the
enclosure on the boat. This is done with a calibration routine built into the
boards software that lets me determine and record maximum values in each axis
for the accelerometer, gyroscope noise, and maximum values for the
magnetometer. This calibration is absolutely necessary to prevent yaw drift.
GPS receiver
The GPS receiver used is a 66 channel Locosys LS20031, capable of updating five
times per second (5 Hz). It uses an embedded antenna that is ideal for a moving
platform with a clear view of the sky. Data from the GPS is sent to the Seeeduino
Mega board over Serial port 1, using standard NMEA sentences. These
sentences are parsed into latitude and longitude in software.
PCB
In order to physically interface the various electronic components and eliminate
wiring between them, I designed and ordered a simple PCB with connections for
the servos and encoder, mounting holes for the GPS and IMU, and ports to
connect the Seeeduino Mega. It fits in the center of the enclosure and forms a
solid mounting base for the IMU and GPS while supplying power along 3.3v, 5v,
and 6v (battery) rails. A voltage divider is integrated to scale the MA3 signal to
0-3.2 volts, values safe to feed into the Seeeduino Megas ADC. There were two
inconsequential design flaws with the board: (1) the silk screen font as
manufactured was larger than designedthis should have been checked by
previewing the gerber files, and (2) the voltage divider circuit was set in
backwards, swapping the input and output ports for the sensor.

Goldberg 5

Figure 2. PCB design from EAGLE PCB.

Figure 3. PCB as received (right), and with headers and voltage divider soldered (left).

Enclosure
The electronics are mounted within a custom built waterproof acrylic enclosure,
attached to the deck of the boat. The primary design goal of the enclosure is to
be waterproof, with secondary goals to be lightweight, low-profile, and shaped
to fit on the deck with minimal effect on drag and sailing performance.

Goldberg 6
The enclosure is made with thin sheet acrylic cut and welded together with
acetone and sealed with silicone adhesive. Bars of acrylic are welded to the
outside of the top rim of the box, to accept screws that secure the lid and a rubber
gasket to the rim. The rim is topped with a bead of silicone adhesive to make a
watertight seal with the gasket.

Figure 4. Empty enclosure.

There is a single hole in the rear of the enclosure to run cables to the servos,
battery, and wind sensor, which is sealed with a small acrylic plate and silicone
adhesive.

Figure 5. Enclosure mounted on deck of boat with cables.

Goldberg 7

Figure 6. Electronics contained within the enclosure.

The servos and battery are located within the hull of the boat, underneath a hatch
in the deck. A small notch is cut in the side of the hatch opening to run two
servo cables from the enclosure. One of the servo cables is modified into a Y, to
allow it to connect to both the sail servo and the battery, providing power for the
PCB to distribute to the entire system.

Software

The project is run with two programs. The first, running on the Seeeduino Mega
on the boat is programmed in Arduino C++ and is capable of fully autonomously
controlling the boat. A second, optional program, written in Processing Java
runs a real-time GCS GUI on a base station computer to provide telemetry data
to the user and send commands to the boat. Communication between the two is
wireless, using two XBee 60mW PRO radios at 2.4 GHz with a maximum range
of one mile. Data is transmitted in binary serial to maximize bandwidth and
minimize transmission errors. Both programs have been documented with
Doxygen, with the documentation attached. The following is a brief description
of the function and design of each program.
Arduino
The Arduino program is the core of the project, and runs an efficient task/state
machine that cooperatively multitasks seven tasks to monitor three sensors,
control two servos, communicate with the GCS, and handle sailing control logic.
The tasks are thoroughly explained in the Doxygen documentation, so only brief
descriptions and state transition diagrams are included in the body of the report:

Goldberg 8
Control Task

Figure 7. Control task diagram.

The control task controls sailing logic and the boats autonomous actions. It
integrates sensor readings from the IMU and wind sensor with input from the
GCS to adjust the rudder and sail servos and maintain a target heading. The
control task idles in a manual state that allows direct user control over the servos,
so the boat can be sailed as a normal R/C model. To facilitate a smooth switch to
autonomous mode, once the GCS signals the switch to autonomous mode, the
current heading is set as the target, and the boat will continue on its current
course, wind permitting.
Once in autonomous mode, the boat continually reads the wind sensor and
compares the current wind direction to the desired heading (State 2). If the
heading is too far upwind to sail directly (less than a pre-defined tacking
constant from the wind direction), beating mode is initialized (State 4), in which
the boat will navigate upwind by beating successive tacks as close to the wind as
possible. Beating initialization determines the closest tack and sets the boats
internal steering heading to that bearing, without disrupting the primary target
heading. The rudder servo task maintains the boats course along this internal
steering heading.
Control always returns to State 2 to check the current target heading and confirm
the sailing mode. After the initialization of beating mode, it will pass through
State 3 (which was originally intended to update the rudder servo, but now

Goldberg 9
exists as a placeholder state for a more sophisticated rudder control scheme), and
then return to State 2. If the wind conditions and target heading havent
changed, State 2 will again determine that beating upwind is necessarybut
because the mode has already been engaged, it will transition to State 6 to
instead monitor the mode with a timer that runs each tack for a pre-defined
length of time. After the timer is up, the monitor state switches the current tack
(from port to starboard or from starboard to port) and transitions back to the
beating initialization state, to initialize the mode on a new tack, causing the boat
to turn.
An analogous control structure is used for running downwindif the boat were
to sail directly downwind, it would be forced to cross swells that could increase
turbulence and decrease overall speed toward the target point. To avoid this, if
the target heading is too close to directly downwind, running mode is engaged,
in which the boat will jibe back and forth downwind, in the same way that it
tacks upwind.
Lastly, if the heading is not too far upwind or downwind, State 2 sets the sailing
mode to normal, and passes heading control directly to the rudder task without
the use of the internal steering heading.
Rudder Servo Task

Figure 8. Rudder servo task diagram.

The rudder servo task is responsible for both controlling the rudder servo and
maintaining the lowest level of heading control. When in manual mode, the task
simply continually writes the desired rudder position to the servo. If the user
updates the rudder position through the GCS GUI, the rudder servo task will
write the new value and move the rudder. When the boat is switched to
autonomous mode, the task also makes use of a second state that determines the
error between the current and desired headings, to make a correction to the
rudder position proportional to the error. Greater error makes for a harder turn
from the rudder. Future improvements may include the addition of an integral
calculation (PI control) to slow the rate of response, smoothing the control and
conserving battery power.

Goldberg 10
Sail Servo Task

Figure 9. Sail servo task diagram.

The sail servo task works very similarly to the rudder servo task. In manual
mode, it passes the user-updated sail servo position directly to the sail servo. In
autonomous mode, it uses a linear function to calculate an appropriate sail
position based on wind direction and current heading, intended to maximize sail
efficiency and boat velocity under any conditions. This function can be
improved with testing, and perhaps replaced with a lookup table of more ideal
values.
GPS Task

Figure 10. GPS task diagram.

The GPS tasks primary role is simply to receive and parse data from the GPS
receiver. Data is output from the receiver over Serial port 1 in NMEA sentences
that are parsed by Mikal Harts TinyGPS Arduino library, and then saved into

Goldberg 11
latitude and longitude variables to be transmitted to the base station GCS. In the
event that the boat loses contact with the base station, an emergency homing
state is activated that calculates a bearing to a home location and directs the boat
for retrieval. To minimize processor load, this is the only position calculation
that is carried out on the Arduino. For normal GPS-based sailing, the
calculations are done on the base station computer with the GCS program,
described later. Accurate position math requires high precision floats and
several trigonometric calculations that are too slow on the ATmega to use in
normal circumstances.
IMU Task

Figure 11. IMU task diagram.

The simplest task, the IMU interface simply reads data from the IMU over Serial
port 2, using the EasyTransfer Arduino library to efficiently transfer roll, pitch,
and yaw angles in a binary stream at 20 Hz.
MA3 Task

Figure 12. MA3 task diagram.

The MA3 task reads the analog voltage of the MA3 absolute rotary encoder
through the Seeeduino Megas analog pin 0, maps the voltage to 0-359 degrees,
and then uses the boats current heading to calculate an absolute wind direction
and heading. Wind direction is the bearing wind is coming from, heading is the
opposite bearingwhere the wind is going. (Wind direction is more convenient
for control math when beating upwind, heading is more convenient when
running downwind).

Goldberg 12
User Interface Communications Task

Figure 13. User Interface task diagram.

In an early implementation, this task communicated to the user in plain ASCII

text over a serial port, read in a terminal. With the addition of the GCS GUI
running on the base station computer, the task was greatly simplified and now
simply serves as the communication conduit between the Arduino program and
the GCS, sending and receiving binary data through the XBee radio connection.
The XBees work as a serial port replacement, so all data is sent and received
through Serial port 3.
Every 200 ms, the UI task assembles a new data packet of the following structure,
leaves State 1 (idle) transitions to State 2 to transmit the package in binary:
Byte
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Variable
Header
Header
Packet ID

Type
char
char
int

rudder_pos

int

sail_pos

int

next_turn

int

target_heading

int

yaw
roll

int

steer_heading

int

Byte
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

Variable
wind_direction

Type
int

AUTONOMOUS
sailing_mode
tack
lat

boolean
byte
byte
long

lon

long

checksum

long

Table 1. Boat to GCS data packet structure.

Goldberg 13
Between transmitting regular data packages to the GCS, the idle state monitors
Serial port 3 for incoming data. Data packages from the GCS are short, singlecommand messages of the following structure:
Byte
1
2
3
4

Variable
Header
Tag
Data

Type
char
char
int

Table 2. GCS to boat command packet structure.

An identifying tag is used to determine what the data is. The possible values
that can be sent are a change in autonomous mode, rudder servo position, sail
servo position, target heading, or a checkin pulse. The last is a regular
transmission sent from the GCS every second that is used to confirm the radio
link. If the boat goes for longer than a specified timeout without receiving any
transmissions from the GCS, it initiates its emergency homing routine.
Razor 9dof IMU Firmware
The project involves a third program, not written by me and therefore not
documented. Code on the IMU is written by Peter Bartz, and uses a tilt
correction algorithm originally implemented in the arduIMU project by Jordi
Munoz, part of the arduPilot code base. Using accelerometer and gyroscope
data, roll and pitch angles are calculated, which are then used to tilt correct the
magnetometer data and find the yaw angle, or heading. Given roll and pitch
from the accelerometer and gyroscope, the following equations are used to tilt
correct the three axes of the magnetometer into a single magnetic heading:

Corrected _ magx = magx cos( pitch) + magy sin(roll)sin( pitch) + magz cos(roll)sin( pitch)
Corrected _ magy = magy cos(roll) magz sin(roll)
Corrected _ magy
Corrected _ yaw = arctan

Corrected _ magx

Formula 1. Magnetometer tilt correction.

Processing
The Processing program makes extensive use of the ControlP5 library, written by
Andreas Schlegal, to display a user friendly GUI that quickly and effectively
displays all relevant data and allows the user to control the boat manually or
with three different levels of automation. The GCS is best explained with an
overview of its interface. The interface runs in a java application that liveupdates several displays with information received from the boat:

Goldberg 14

Figure 14. Overall GCS GUI.

The GCS handles two-way communication with the boat, using the data
packages described above in the user interface communication task discussion.
Every piece of data that may be sent to the boat is included in the data package
that is regularly sent back to the GCS, so it is very simple for the software to
confirm a data transmissionsimply check the newest value received from the
boat matches what was sent. Every transmission checks for confirmation in this
way, and resends if there is no confirmation.
The GUI is composed of a mix of input buttons, switches, fields, and sliders,
along with output/display objects that show the user useful data from the boat
in real time. Several of the objects serve as both input and output, and
depending on the automation mode may be locked from or available for user
input. An explanation of each object follows (objects are output-only unless
otherwise noted).

Goldberg 15

Figure 15. GCS GUI left panel.

1. Auto mode toggle: This is a user input switch that initiates a transmission
ordering the boat to enter autonomous mode, or to return to manual
mode. The GCS will remain in its current mode until confirmation that
the boat has received the transmission and switched modes.
2. Auto mode confirm toggle: This is an output-only switch that changes
when the boat confirms that it has changed modes. It serves as a quick
and clear visual indication of a radio linkit should quickly change to
reflect the position of the auto mode toggle. Once this switch changes
position, the rest of the GCS changes its autonomous mode, which
changes the purpose of several of the interface objects.
3. Rudder servo slider: In manual mode, this slider will directly control the
position of the rudder servo. The user can click and drag the bar, and
upon release the new servo position is transmitted to the boat. In
autonomous mode, this slider is locked from user manipulation and

Goldberg 16
serves as a display of the current autonomously calculated rudder
position.
4. Sail servo slider: This slider works in the exact same manner as the rudder
servo slider, but for the sail servo.
5. Sailing mode indicator: This text field is updated with the current sailing
mode, which can be NORMAL, BEATING, or RUNNING, depending on
the current mode chosen by the control task on the boat.
6. Current tack: Displays the current tack (PORT or STBD) when beating or
running. In normal sailing mode, the tack will be NONE.
7. Next turn indicator: Field that shows the number of seconds until the next
turn when beating or running.
8. GPS latitude: Shows the boats current latitude in degrees.
9. GPS longitude: Shows the boats current longitude in degrees.
10. Target heading dial: An easy to read dial that displays the boats current
target heading. There are several dials representing headings, all set with
0 degrees vertical to be easily compared with each other. This dial is
updated from the boats data package, which allows it to serve as a visual
confirmation of a successful transmission of a new target heading.
11. Target heading input field: This is a text input field used to type in a
specific target heading to the boat. On pressing enter, the number is
verified to be within the range of 0-359 degrees, then if valid, is sent to the
boat to update its current target heading. This text field represents the
lowest level of automation availablefollowing a given bearing. This
field is only editable when the GCS is in basic autonomous mode.
12. GPS navigation toggle: A user input toggle that engages the second level
of automation, simple GPS-based navigation. Engaging this mode allows
the boat to attempt to reach a location pre-defined by latitude and
longitude. To do this, a bearing is repeatedly calculated in the Processing
program and automatically sent as a new target heading to the boat. In
this mode, the input target heading field is locked from user input. The
coordinates of the target point, the distance to the point in meters, and the
bearing the boat must follow to reach it are displayed in real time. A set
of radio buttons (on the right-hand side of the display) are used to select
from a pre-defined list of available waypoints.
13. Auto navigation toggle: This toggle engages the highest level of
automation. The processing program is pre-loaded with a set of five
waypoints stored in the order of a race course (maintained by the Laguna
Lake Model Yacht Club) on Laguna Lake. When auto navigation is
enabled, the boat will sail to each waypoint in turn, switching to the next
when it is within a specified distance of the current target waypoint. In
auto navigation mode, the waypoint radio buttons become display-only,
and update to indicate the current target waypoint.
14. Distance to target waypoint: This field updates to show the current
distance from the boat to the current target waypoint, in meters. The
calculation is done in the Processing program using the haversine formula
and represents the shortest distance between the two points, accounting
for the curvature of the Earth.

Goldberg 17

lat
lon
a = sin 2
+ cos(lat1 )cos(lat 2 )sin 2

2
2

c = 2 * atan2

a, 1 a

distance = R * c

Formula 2. Haversine distance calculation, R = Earths radius (6,371 km).

15. Bearing to target waypoint: The haversine formula can be manipulated to

givethe current bearing between two coordinates. This is calculated in
Processing and the result is sent to the boat as a new target heading and
displayed in this field.

bearing = atan2 sin(lon)cos(lat 2 ), (cos(lat1 )sin(lat 2 ) sin(lat1 )cos(lat 2 )cos(lon))

Formula 3. Haversine bearing calculation.

16. Target latitude: The latitude of the current target point.

17. Target longitude: the longitude of the current target point.

Goldberg 18

Figure 16. GCS GUI right panel.

1. Yaw dial: The current heading of the boat, displayed in real time.
2. Steering heading dial: The current internal steering heading. This differs
from the target heading when the boat is in beating or running mode, and
is useful for checking how well the boat is maintaining its desired course.
3. Roll dial: The roll (tilt) of the boat, useful for trimming the sail in manual
mode, and checking if the boat is in danger of tipping.
4. Wind direction dial: Shows the absolute wind direction, calculated by
subtracting the yaw from the relative wind direction measured by the
wind direction sensor.
5. Waypoint radio buttons: When in simple GPS navigation mode, these
serve as inputs that allow the user to select from a list of waypoints. In
auto navigation mode, it is a display of the current target waypoint and
updates each time the boat reaches a waypoint and targets the next in the
list.
6. Network statistics: Displays the number of received packets, the number
of missed packets, and the amount of time in milliseconds since the last

Goldberg 19
packet was received. The number of failed packets is calculated by
comparing the packet ID of the current and previous packet. Lag between
packets provides a quick visual confirmation that data is being received
under ideal conditions it never exceeds 200 ms and is hardly readable,
when there is interference or loss of signal it grows and indicates a
problem.
Software Documentation
Doxygen was used to generate html documentation of both the Arduino and
Processing programs, and is included with this report. It is also available on the
project website at (http://rpg.dosmage.net/project).

Testing

I began the project by testing the boat unmodified under remote control. Once
the control system was added I was able to conduct two autonomous tests at
Laguna Lake in San Luis Obispo. From each test I was able to greatly improve
the hardware and software, and continued improvements and testing will
further improve the project past its current state.
Test 0 (unmodified): May 8, 2011
The initial test gave me a good idea of what to design for. I learned that even
under light winds the boat will rock a lot, and take water over the deck, so the
direction and tilt sensing would need to be fast and accurate on an unsteady
platform, and the electronics waterproofing would need to be perfect.
Test 1: May 11, 2012
The first autonomous sea test was a qualified success. I launched the boat in GPS
mode targeted for the first waypoint, and almost immediately lost wireless signal
between the boat and base station computer. Without receiving a new bearing
from the GCS, the boat continued on its initial bearing and sailed across the lake.
Given the wind direction during the test and no bearing corrections sent to the
boat, it appears that the control algorithm very successfully followed its initial
bearing, drifting some with the wind to end at its final location across the lake.
Because of the connection failure, I experimented with new antennas and
orientations and was able to move the boats wireless module to a new location
within the enclosure that significantly increased the signal strength and
transmission range. I also added code to the Arduino and Processing programs
to detect a connection failure and initiate an emergency homing routine that
would bring the boat back to the launching dock in the event of a similar
problem.

Goldberg 20

Figure 17. Sea test 1 waypoints, intended route, and actual route.

Test 2: May 15, 2012

The second test was much more successful. The boat perfectly maintained its
wireless signal throughout the test, and followed several specified bearings. The
beating and running routines worked exactly as expected in software, but the
actual sailing was very slow and inefficient due to fluctuations in the wind
direction reading. Because the test was conducted in very light wind, the boats
rocking caused the wind vane to swing about 20 degrees from the actual wind
direction. The steering heading and sailing mode are continually updated based
on the wind direction, so this made it very difficult for the boat to maintain
beating mode when sailing upwind. The root of this problem is that the wind
vane is made of thick plastic and has significant inertia compared to the very low
rotational resistance of the ball bearing shaft encoder, causing it to stay stationary
relative to the moving mast as the boat rocks, resulting in a changing reading.
The fix for this problem is to replace the wind vane with one made of a much
lighter material, such as very thin sheet PVC, that will be more responsive and
accurate in light winds.
Another problem occurred, that again ended the test prematurelythe battery
leads shorted, melting through some of the servo cables inside the boat. I
initially thought the battery had drained due to overcorrection of the servos, and
for that reason intended to add integral control to the rudder correction loop,
which will slow updating and conserve battery power.

Goldberg 21

Attributions

Several third-party code libraries were used in the Arduino and Processing
programs, the following is a list of what was used:
GPS data parsing is handled by Mikal Hart's TinyGPS Arduino library
(http://arduiniana.org/libraries/tinygps/).
Binary data transfer between the Arduino Mega and IMU, and from the Arduino
Mega to the GCS uses Bill Porter's EasyTransfer Arduino library
(http://www.billporter.info/easytransfer-arduino-library/).
The IMU runs a slightly modified version of the firmware written and
distributed by Peter Bartz, released under GNU GPL (General Public License)
v3.0 Copyright (C) 2011 Quality & Usability Lab, Deutsche Telekom
Laboratories, TU Berlin, available at (http://dev.qu.tu-berlin.de/projects/sfrazor-9dof-ahrs).
GPS positioning math (distance and bearing calculations) is done with the use of
Latitude/longitude spherical geodesy formulae & scripts (c) Chris Veness 20022011 (http://www.movable-type.co.uk/scripts/latlong.html).