Introduction Hardware: Seeeduino Arduino Mega

Transcription

1 Autonomous Model Sailboat Senior Project Andrew Goldberg General Engineering June 2012

2 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 boat s 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 (SEN ), 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,

3 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. Serial 0: Programming and USB debugging with computer. 2. Serial 1: GPS receiver at baud. 3. Serial 2: 9dof IMU at baud 4. Serial 3: XBee radio for GCS communications at 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, 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 signal a voltage ranging from 0 to 5 volts, that linearly corresponds to 0 to 359

4 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 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 boat s real-time heading. A magnetometer can be used as a digital compass, measuring the strength of the Earth s 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

5 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 boat s 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 board s 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 volts, values safe to feed into the Seeeduino Mega s ADC. There were two inconsequential design flaws with the board: (1) the silk screen font as manufactured was larger than designed this 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.

6 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.

7 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.

8 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:

9 Goldberg 8 Control Task Figure 7. Control task diagram. The control task controls sailing logic and the boat s 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 boat s internal steering heading to that bearing, without disrupting the primary target heading. The rudder servo task maintains the boat s 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

10 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 haven t changed, State 2 will again determine that beating upwind is necessary but 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 downwind if 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.

11 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 task s 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 Hart s TinyGPS Arduino library, and then saved into

12 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 Mega s analog pin 0, maps the voltage to degrees, and then uses the boat s current heading to calculate an absolute wind direction and heading. Wind direction is the bearing wind is coming from, heading is the opposite bearing where the wind is going. (Wind direction is more convenient for control math when beating upwind, heading is more convenient when running downwind).

13 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 Variable Type Byte Variable Type 1 Header char 19 wind_direction int 2 Header char 20 3 Packet ID int 21 AUTONOMOUS boolean 4 22 sailing_mode byte 5 rudder_pos int 23 tack byte 6 24 lat long 7 sail_pos int next_turn int lon long 11 target_heading int yaw checksum long 15 roll int steer_heading int Table 1. Boat to GCS data packet structure.

14 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 Variable Type 1 Header char 2 Tag char 3 Data int 4 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 _ mag x = mag x cos(pitch) + mag y sin(roll)sin(pitch) + mag z cos(roll)sin(pitch) Corrected _ mag y = mag y cos(roll) mag z sin(roll) Corrected _ yaw = arctan Corrected _ mag y Corrected _ mag x 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:

15 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 transmission simply 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).

16 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 link it 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

17 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 boat s current latitude in degrees. 9. GPS longitude: Shows the boat s current longitude in degrees. 10. Target heading dial: An easy to read dial that displays the boat s 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 boat s 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 degrees, then if valid, is sent to the boat to update its current target heading. This text field represents the lowest level of automation available following 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.

18 Goldberg 17 Δlat Δlon a = sin 2 + cos(lat 2 1 )cos(lat 2 )sin 2 2 c = 2*atan2( a, 1 a) distance = R *c Formula 2. Haversine distance calculation, R = Earth s radius (6,371 km). 15. Bearing to target waypoint: The haversine formula can be manipulated to give the 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(lat 1 )sin(lat 2 ) sin(lat 1 )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.

19 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

20 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 ( 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 boat s 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.

21 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 boat s 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 prematurely the 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.

22 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 ( Binary data transfer between the Arduino Mega and IMU, and from the Arduino Mega to the GCS uses Bill Porter's 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 ( GPS positioning math (distance and bearing calculations) is done with the use of Latitude/longitude spherical geodesy formulae & scripts (c) Chris Veness (