Magnetic Coupling Version 2 - new Magnet Layout

Magnetic Coupling - New Improved Design

What's the optimum layout for the magnets in the magnetic coupling for allowing a servo to operate through waterproof barrier. ?

After some prototyping and testing, I think I have a reasonable solution.

The main performance attributes of a magnetic coupling are:

• Ambiguity; and 
• Holding Torque.

Holding torque can be maximised by having many magnets or many poles; increasing the strength of the magnets and reducing the distance between the coupling disks across the waterproof barrier.

Ambiguity refers to whether the coupling has multiple detent points. That is, can the external disk be forced into other stable positions, other than the intended position.
The problem of ambiguity can be reduced by reducing the number of poles.

A servo operating a rudder does not need to travel more than 180 degrees.
This means that ambiguity will be eliminated if there are two detent positions per 360 degrees (with one being eliminated by a 180 degree restriction).
This can be achieved with a 4 pole magnet layout, as shown in the following image.

4-Pole Magnet Layout, with neighbouring magnets sharing the same orientation. This is my preferred layout.

Tests were performed on a variation of the layout of magnets shown above, where the neighbouring magnets were setup with opposite orientation. The aim was to see if there was any measurable difference in performance.

4-Pole Magnet Layout, with neighbouring magnets having opposite orientation. Holding torque reduced by 15%.

The method of comparing holding torque of different magnet configurations was to use a simple spring scale.

The spring scale was pulled gently, while observing the maximum load before the coupling yields (or breaks free).

This provides relative values for comparing maximum torque values for different magnet arrangements. These are not actual torque values of course.

Measuring Relative Holding Torque using a Spring Scale.

This is part of the ongoing development of a low cost autonomous oceangoing sailing drones, utilising a self-trimming wingsail. This is the Voyager series of sailing drones.

More Lake Trials

More Lake Trials

The last few weeks have been spent running short trials to test minor updates to boat, and also in preparations to go to sea for a short offshore voyage.

Coming home after an hour of autonomous sailing around the course.

A short mission, generally navigating a good track.

Note: This is part of the ongoing development of a low cost autonomous oceangoing sailing drones, utilising a self-trimming wingsail. This is the Voyager series of sailing drones.

Waterproofing a Standard Servo

Waterproofing a Standard Servo (well, splash proofing it at least)

The post describes a process I used to protect a standard servo against water.
The servo was a Hitec 919, but most servo use the same basic construction 

The main entry points for water below the mounting flange are protected by a spray coating.

The splined shaft is protected using grease on the inside of the casing and an O-Ring on the outside.

Details of the steps follow.

Step 1.
Partially disassemble the servo by removing the 4 screws from the bottom, and remove the top and bottom casings.

Step 2.
Slide out the Motor and PCB assembly.
Apply a Conformal Coating to the PCB to improve its resistance to water.
I didn't spay it directly, because I wanted to avoid any moving parts, but rather sprayed a few millilitres into a small container, and applied it to the PCB using a wooden ice cream stick.

Step 3.
Apply grease to the bearing area just below the splines.

Step 4.
Reassemble the servo.

Step 5.
Add an O-ring  (1mm by 4mm) to splines.

Step 6.
Use a file on the bottom of the servo arm splines, to increase the gap between the top of the servo housing and the servo arm.
The gap needs to be increased so there is enough room for the O-Ring when the Servo Arm is screwed down, without it being too tight ,and causing undue friction.

Step 7.
Apply a protective spray coating lower part of the servo below the mounting flange.
I used masking tape and Red Plasti Dip.

Unfortunately, I forgot to take a photo before installing the servo back into the Wingsail, and this photo is not good.

Magnetic Compass Errors Revisited - Wingsail Angle Sensor/Magnetic Disk

Magnetic Compass Errors Revisited - Wingsail Angle Sensor/Magnetic Disk

The Wingsail Angle Sensor incorporates a magnetic disk. Its located around 300mm from the Magnetic Compass. I thought this was a reasonable distance, but perhaps its interfering with compass.

Wingsail Angle Sensor Magnetic Disk

I set up a test to measure compass error versus wingsail angle and plotted the results.
They were bad.
The plotted results below, show that the wingsail angle is responsible for large errors of around 25 to 35 degrees  with a wingsail angle of 45 degrees.
Negative wingsail angle represents port tack.

The image below shows a successful completion of a course of waypoints, with a northerly wind
The reaching leg across the top of the course shows the vessel heading about 30 degrees to port of the desired course. It is pointing higher than necessary by about 30 degrees, due to compass error.

This is consistent with the measurements recorded in the graph above.
On the port tack the error is about +30 degrees.
Hence the vessel must reduce the heading angle by about 30 degrees to maintain the desired magnetic course.
Hence, in this case,  on the reaching leg, it is steering about 30 degrees to port.

Course Demonstrating Compass Error

Conclusions: 

It will be difficult to increase the separation between the magnetic compass and the magnetic disk on the wingsail on a vessel of this size (1.2m LOA).
It is likely that the wingsail magnetic disk is unnecessarily large and strong. So it will be necessary to test a smaller disk with a reduced number of magnets, to reduce the field strength, yet still maintain reliable operation of the wingsail angle sensor.

Note: This is part of the ongoing development of a low cost autonomous oceangoing sailing drones, utilising a self-trimming wingsail. This is the Voyager series of sailing drones.

Waterproof Steering Coupling - Magnetic Coupling

Waterproof Steering Coupling - Magnetic Coupling

A magnetic coupling is used to transmit the Steering Servo movement out of the water tight compartment to the rudder pushrod.

This has been successful.

In the correct configuration, all six magnet pairs are engaged.

It can suffer the problem that the outside disk can be forced to detent in the wrong place, one sector in either direction.

In this position, two magnet pairs are attracting and four are repelling. 

It is a semi-stable state, but it can easily be pushed back to the corrected alignment.

The pattern of magnetic orientation has an effect on behaviour, and more study is required to determine the best arrangement and quantity of the magnets.

Perhaps less magnet pairs are better, because the angle to next detent point would be greater with a reduced number of magnets.

This would need to be balanced against the reduced magnetic coupling with the reduced number of a magnets.

Lower Magnetic Coupling Disk fitted to the Rudder Servo

Complete Magnetic Coupling Assembly

Wingsail Angle Sensor

Wingsail Angle Sensor 

The vessel does not have any explicit wind sensors for measuring wind speed or wind direction.

All sailing navigation decisions rely on knowing the angle of the self-trimming wingsail against the hull.

The wingsail angle is measured using the MPU9250 IMU as a magnetic sensor, and magnetic disk attached to the wingsail.

The MPU9250 may be an overkill for a magnetic sensor, however they do have benefits:

• I2C bus, so it easily interfaces to the Arduino microprocessor.
• Sensitive as a magnetic sensor, allowing good separation distance to the magnetic disk
• The MPU9250 was difficult to use as an actual magnetic compass because it was difficult calibrate and use. They are easy to use as a magnetic angle sensor however. They are not expensive and I have a few to spare.

Wingsail Angle Sensor with Wingsail Magnetic Disk

 The housing for the Wingsail angle sensor is a 3D printed shape that is integrated with the Mast Tube deck plate. 

Magnetic Sensor Housing fixed in place. 

The magnetic disk is attached to the wingsail, so that the magnetic field created by the disk rotates with the sail The disk consists of a 3D printed holder for an array of about 60 cylindrical magnets 2mm diameter, 10mm long. Its obviously important that all of the magnets have the same orientation.

3D model of the Wingsail Magnetic Disk 

Future design changes:

•  Integrate the Magnetic Disk more tightly with the Wingsail, possibly by incorporating it with the bottom foil section.
• Add a duplicate MPU9250 Wingsail angle sensor for redundancy. 

Note: This is part of the ongoing development of a low cost autonomous oceangoing sailing drones, utilising a self-trimming wingsail. This is the Voyager series of sailing drones.

Compass Heading Error Correction using GPS

Compass Heading Error Correction using GPS

(or GPS/Magnetic Compass Fusion)

Magnetic compass calibration is constant problem, but if we assume the GPS Course of Ground (COG) represents the actual heading of the vessel, then we can establish a difference between the two sensors, and apply a correction to the compass.
Of course, we can only assume the GPS COG is correct if we assume there is no movement of the water. That is, no tidal flow or currents.

The GPS COG is only valid when the GPS is moving. The COG provided by a stationary GPS device tends to point in all directions is has little meaning.
Hence, the COG can only be used to establish a Compass heading error if the GPS Speed of the Ground (SOG) is above a reasonable level.

The procedure below is currently in use, and forms Compass error value based on the GPS COG, when the SOG is greater than 0.2 m/s.
The resulting error is passed through a low pass filter to dampen its movement and then applied to the measured Compass Heading.


void NavigationUpdate_FastData(void)
{
 // Calculate True Heading From Magnetic Heading.
 // This is expected to be called from a fast loop .
 // about 50ms
 // V1.0 31/10/2016 John Semmens
 // V1.1 6/4/2019 added CompassOffsetAngle for handling mounting orientation
 // V1.2 11/7/2019 added Heading Error calculation and correction.

NavData.HDG_Mag = int(wrap_360(myIMU.heading + Configuration.MagnetVariation + Configuration.CompassOffsetAngle));

 // calculate and error value from the GPS and dampen it using low pass filter
 int RawHeadingError;
 if (NavData.SOG_mps > 0.2) // if the SOG is reasonable then assume the
 {
  RawHeadingError = wrap_180(NavData.HDG_Mag - NavData.COG);
 }
 else
 {
  RawHeadingError = 0;
 }

 // apply a low pass filter
 NavData.HDG_Err = HeadingErrorFilter.Filter(RawHeadingError);

 NavData.HDG = int(wrap_360(NavData.HDG_Mag - NavData.HDG_Err));

}



The GPS based compass correction has made a noticeable difference on the water.
The image below depicts the longest mission to date for the vessel. The wind is from the NNW.
The image clearly shows that the vessel has steered accurately to the waypoints on the downwind legs.

The longest course so far, incorporating GPS Based Compass Correction

The image below shows a similar, but shorter course, that was completed prior to the GPS based compass compensation.
The image shows that the vessel is steering significantly to the left as it approaches each waypoint that it can sail to without tacking.

A previous course successfully completed, without GPS compensation for the Compass 

And of course a photo from today's sailing...

Note: This is part of the ongoing development of a low cost autonomous oceangoing sailing drones, utilising a self-trimming wingsail. This is the Voyager series of sailing drones.

Wingsail in Strong Winds - Photos

Strong Wind, Flat Water Sailing - Photos 

These are just some photos from testing today in gusty winds up to about 20 knots.

Consideration will be given to using an average roll angle (heel angle) as a control over the Wingsail Trim Tab angle as a means to de-power the sail in strong winds, in future updates.

Beating off a lee shore

Laid flat by a bullet

Well behaved while beating with a constant wind direction

This sailing trial included the new Wingsail Bluetooth controller built using the dedicated PCB. The new Bluetooth controller behaved well.

This is part of the ongoing development of a low cost autonomous oceangoing sailing drones, utilising a self-trimming wingsail. This is the Voyager series of sailing drones.

New PCB for Bluetooth Sail Controller

New PCB for Bluetooth Sail Controller

The sailing trials continue in fresh water, but the aim is to put to sea.
The electronic systems need a lot of hardening to survive a saltwater environment.

One step in the process is the development of a dedicated PCB for the Wingsail controller.
The new PCB incorporates:

•  On-board ATMega328p with the Arduino Pro Mini bootloader, rather than a separate Arduino module.
•  Support for a Dual Servo Outputs, although only one is populated.
• Support for switching an auxiliary 5Vdc load. I'm thinking of an LED Strobe or lights to aid night time operations.
• Solar Charging circuitry using the LTC3105, also currently not populated.

The justification for adding solar charging to the Wingsail Controller is not great.

Testing suggests that the Wingsail Controller cells can operate for about 8 days on a single charge. The current Voyager Controller for can only operate for a couple of days in the current configuration. There will be more discussion on that in future posts as efforts are made to improve battery life, prior to engaging solar charging for the vessel.

The competed PCB operated faultlessly There were no errors in the PCB design, which is what is was worried about of course. For some reason, the Arduino takes an extra second or two to boot up when compared the prototype design using the Arduino Pro Mini module. It doesn't really matter, but I'd like to understand the reason, when I have time to investigate.

The competed PCB was sprayed with about a dozen coats of Conformal Coating to provide some protection from the environment.

 The new production Bluetooth Sail Controller PCB with conformal coating and mounted ready for installation in the wingsail.

Image of Wingsail showing the original prototype controller in situ.

Note: This is part of the ongoing development of a low cost autonomous oceangoing sailing drones, utilising a self-trimming wingsail. This is the Voyager series of sailing drones.

Sailing the Course with a Calibrated Compass

Sailing the Course with a Calibrated Compass

48 hours after the successful first completion of the sailing course, we're back to repeat the course; but this time, with the compass calibrated (better than it was previously, anyway).
The sailing performance was much better.
The wind was about 10-12 knots from the NNW.

Sailing the course much more efficiently this time.

The current settings for minimum Apparent Wind Angle (AWA) while beating to windward is 45 degrees. The log results show that this resulted in tacking angles of 105 degrees.

Sailing the last leg in about 10 knots of wind.

The next steps in development should include preparing a polar diagram of performance of the vessel.

First Completion of a Sailing Course - No Hands!

First Completion of a Sailing Course - No Hands!

After recent revisions of the onboard software I was able to run another test after work and this time successfully completed a sailing course with no manually intervention.

At any time, while in range, I can switch on an RC Transmitter and take over manual control of the boat, and then revert back to following the mission or several other options. I've often needed to do this previously to recover the boat from situations caused by errors in my software.
This was the first time that the boat has completed a course while sailing, with no manual intervention.

The course involved 6 waypoints with running, reaching and beating, with a light wind from the NNE.

The Short Sailing Course just completed. 

I'll need to study the logs very carefully, but the initial impression is that the software behaved ok, but compass calibration is a big problem, with errors of up to 40 degrees.
The large compass error meant that the course sailed was not very good. The marks were overlaid and underlaid, causing excessive tacking. But at least the software was resilient enough to get it around the course.

Nearing the Last Waypoints after Sunset

Monitoring Progress in Real-Time through the Telemetry

Note: This is part of the ongoing development of a low cost autonomous oceangoing sailing drones, utilising a self-trimming wingsail. This is the Voyager series of sailing drones.

Electronic Compasses for Voyager

Electronic Compasses for Voyager

I'm losing count, but I think its about 5 different compass devices I've trialled during the development of the Voyager Controller - so far.

The image below shows a mild case of the problem of compass accuracy.
The leg with a bearing of about 350 degrees from first to second waypoints shows the boat heading off on a bearing of about 330 degrees with about 20 degrees error.
It still gets there, but its not good.

A successful voyage under motor, but poor compass accuracy

Measuring the boat's heading accurately has been quite difficult.
Overall, I suspect it all comes down to calibration, and the built-in mechanisms to manage calibration in a way that actually works in the environment in which it will be used.
The following is a list of the different compass devices that made it into the Voyager Controller and my thoughts about them.
These notes represent my understanding of what's going on. If I can be corrected, then good.

MPU-9250 - August 2016

This is quite a good low-cost IMU device for measuring 9 degrees of freedom including 3-axis magnetic sensing. It requires all sensor fusion and calibration management to be handled by the host processor.
The problem I had was that I could not get any sensor fusion and calibration software sample that I could find to work satisfactorily. (This may be attributed to my impatience or incompetence).
I'm sure it may be possible, but there are more complete (and expensive) devices available which perform the sensor fusion and calibration maintenance on board.

Note: I now use the MPU-9250 device as magnetic rotation angle sensors. This is where a rotating device (like the Wingsail) has a magnet held near the MPU-9250, and its angle is measured. The magnet can easily swamp the effect of the earth's magnetic field and the resulting accuracy of the rotational measurement seems to be within 1 or 2 degrees.

BNO 055 - October 2017

This was the first IMU I tried with built-in sensor fusion.
The sensor fusion worked quite well, but magnetic calibration was not being maintained and it kept drifting off.

BNO 080 - October 2018

This seems to have improved accuracy over the BNO 055. Its built-in calibration processes continuously seem to perform calibration of the compass as it moves.
The problem that I could not solve, was that it continues to perform those calibrations when its not moving then starts drifting off for no apparent reason.
The end result seems to be that with the boat sitting stationary on ground, and after preforming some calibration motions to achieve a high-level of calibration, it simply starts to drift off by 20 or 30 degrees.
My understanding is that this behaviour can't be controlled.

Ultimate Sensor Fusion Solution - LSM6DSM + LIS2MD - April 2019

https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution-lsm6dsm-lis2md/

This device has been the most successful yet.
It incorporates onboard sensor fusion processing and calibration management.
One key point is that the calibration is well controlled, and seems to be better behaved.
Small movements of the boat seem to be enough to maintain the compass calibration.
It is also possible to save a calibration state, and reload it for a warm start.
I found the documentation and sample code to operate this device couldn't be directly used in my environment without the need to gain a better understanding of the operation of the device. Once I had gained enough understanding of the device, I was able to alter the sample drivers software to suit my requirment. This wasn't really necessary with most of the other devices I've used.

Lots of Sailing Trials

Lots of Sailing Trials - February to June 2019

The sailing hardware and electronic hardware has been quite stable for several months while I work on refining the sailing algorithms. The nearby lake has a good fetch from the North West, and so NW winds are the best for sailing trials. Each week I make changes to the sailing software, and perform trials, trying improve the sailing and tacking decisions as the boat moves through its waypoints.

On-board camera showing the back of the Wingsail Electronics

Sunset Trials after work

Programming a mission before commencing a run

10-15 knot breeze 

Many of the parameters from the onboard controller are transmitted in real-time back to the base station for visualisation. More parameters are recorded on an SD Card that can be reviewed in greater detail back at home.  I found it quite difficult to analyse the masses of data I was collecting by simply studying the raw log files, and so an additional Log Analyser was developed where the log files could be visualised and played back (both backwards and forwards) to study the details of the sailing decisions that were being made.
I found this vital to moving forward and resolve some the bugs in the sailing algorithms.

Log Analyser for replaying details

Note: This is part of the ongoing development of a low cost autonomous oceangoing sailing drones, utilising a self-trimming wingsail. This is the Voyager series of sailing drones.

Minimal ATMega328P - common error

Minimal ATMega328P - common error  - won't run at 3V3.

I've started using ATMega328P as a minimal version  of the Arduino Pro Mini operating a 3Vdc.
I have been breadboarding circuits using the various articles published on the Internet as a guide for the minimal wiring required for running an ATMega328P as an Arduino.

The problem I suffered was that the circuits would happily run at 5Vdc, but stop running as the voltage was reduced to 3.3Vdc.

There seems to be a lot of discussion about the problem on forums; with almost none of it relevant to me.

Eventually I realised the silly mistake that I was making, by taking minimal circuits from Internet without checking the details for myself.

Many articles for minimal ATMega circuits leave AVCC open, rather than tying it to VCC.
If AVCC is left open, the ATMega will work at 5Vdc but will stop working at around 3.5Vdc.
Once connected to VCC, the ATMega will work below 3Vdc.

In my case, it worked down to about 2.7Vdc, which is one of the settings for the Brown Out Detector, so I suspect, that is what has come into play.

Slave I2C Interface for Serial GPS using Arduino Pro Mini 328P

Slave I2C Interface for Serial GPS using Arduino Pro Mini 328P

This post contains the code for creating a slave I2C device using an Arduino for a GPS receiver.

Hardware serial ports are precious on ATMega devices and I don't have enough available in my project to use on a GPS receiver, despite using an ATMega2560.

Software serial ports are often ok, but can suffer compatibility issues with other libraries in larger projects, and this has been prohibitive for me.
You can buy I2C GPS devices, and I do prefer to use them, but the one I was using failed, and I needed a quick solution to get my project back on the water without having to wait the 2 or 3 weeks for a replacement I2C GPS to arrive.

So, after an evening's research I was able to create a working I2C slave device using an Arduino Pro Mini 328P and integrate it with a regular serial GPS receiver.

The Arduino Pro Mini 328P running is at 16MHz and 3V3. Yes, I know its outside of specification with that combination of voltage and clock speed.

Overview

This simple sketch uses the very excellent TinyGPS++ to parse the GPS serial data and load the GPS object. Then we copy individual field values into our GPS structure which is mapped to linear Data buffer using UNION statement.

The Data buffer is then written out to the I2C interface in response to an I2C request.

Wiring

The Tx Pin from the GPS is connected to the RX pin of the Arduino Pro Mini 328P using a 1k resistor. This provides isolation to allow the Arduino to be programmed over the serial interface while the GPS is connected. If this were a direct connection, serial programming of the Arduino would not be possible without disconnecting the GPS.

Slave I2C GPS sketch

/*
    Name:       I2C_GPS.ino
    Created: 2 May 2019
    Author:     John Semmens

 Slave I2C Interface for Serial GPS using Arduino Pro Mini 328P
 ----------------------------------------------------------------
 Interface for converting a serial GPS to allow it to be used on an I2C bus.
 This uses the Arduino Pro Mini 328P running at 16MHz and 3V3. (Yes, i know its outside of specification!!!).
 This simple sketch uses the very excellent TinyGPS++ to parse the GPS serial data and load the GPS object.
 Then we copy individual field values into our GPS structure which is mapped to linear Data buffer using UNION statement.
 The Data buffer is then written out to the I2C interface in response to an I2C request.

 Wiring:
 The Tx Pin from the GPS is connected to the RX pin of the Arduino Pro Mini 328P using a 1k resistor.
 This provides isolation to allow the Arduino to be programmed over the serial interface while the GPS is connected.
 If this were a direct connection, serial programming of the Arduino would not be possible without disconnecting the GPS.
*/

#include <SPI.h>
#include <Wire.h>
#include "TinyGPS++.h"

// The TinyGPS++ object
TinyGPSPlus gps;

static const uint32_t GPSBaud = 9600;

#define  SLAVE_ADDRESS           0x29  //slave I2C address: 0x01 to 0x7F
#define  REG_MAP_SIZE            18 

// GPS variables
typedef union {
 struct {
  long Lat, Long;     // 2 x 4 bytes
  uint8_t Year, Month, Day;  // 3 x 1 bytes
  uint8_t Hour, Minute, Second; // 3 x 1 bytes
  int COG, SOG;     // 2 x 2 bytes SOG is in m/s
 };
 uint8_t Data[REG_MAP_SIZE];   //  = 18 bytes
} buffer_t;

buffer_t gps_data,buf;

boolean newDataAvailable = false;

void setup()
{
 Wire.begin(SLAVE_ADDRESS);
 Wire.onRequest(requestEvent);

 Serial.begin(GPSBaud);
}

void loop()
{
 while (Serial.available() > 0)
 {
  if (gps.encode(Serial.read()))
  {
   LoadRegisters();
   newDataAvailable = true;
  }
 }
}

void requestEvent()
{
 if (newDataAvailable)
 {
  for (int c = 0; c < (REG_MAP_SIZE); c++)
  {
   buf.Data[c] = gps_data.Data[c];
  }
 }
 newDataAvailable = false;

 Wire.write(buf.Data, REG_MAP_SIZE);
}

void LoadRegisters()
{
 gps_data.Lat = gps.location.lat() * 10000000UL;
 gps_data.Long = gps.location.lng() * 10000000UL;
 gps_data.COG = gps.course.deg() * 100;
 gps_data.SOG = gps.speed.mps() * 100; // m/s

 gps_data.Year = gps.date.year()-2000;
 gps_data.Month = gps.date.month();
 gps_data.Day = gps.date.day();
 gps_data.Hour = gps.time.hour();
 gps_data.Minute = gps.time.minute();
 gps_data.Second = gps.time.second();

 // Copy gps buffer to buf buffer
 for (int i = 0; i<REG_MAP_SIZE; i++)
  buf.Data[i] = gps_data.Data[i];
}

Master I2C Code Excerpt

void GPS_Read() {
 // V1.1 27/4/2019 Temp GPS reader for Temp I2C Arduino interface to a serial GPS


 Wire.requestFrom(0x29, 18);       // Ask for 18 bytes

 long Lat=0, Long=0;     // 8 bytes
 uint8_t Year =0, Month=0, Day=0;    // 3 bytes
 uint8_t Hour=0, Minute=0, Second=0; // 3 bytes
 int COG=0, SOG=0;     // 8 bytes

 for (int i = 0; i<4; i++)
  Lat = Lat | (long)Wire.read() << (i * 8);

 for (int i = 0; i<4; i++)
  Long = Long | (long)Wire.read() << (i * 8);

 Year = Wire.read();
 Month = Wire.read();
 Day = Wire.read();
 Hour = Wire.read();
 Minute = Wire.read();
 Second = Wire.read();

 for (int i = 0; i<2; i++)
  COG = COG | Wire.read() << (i * 8);

 for (int i = 0; i<2; i++)
  SOG = SOG | Wire.read() << (i * 8);

 NavData.Currentloc.lat = Lat;
 NavData.Currentloc.lng = Long; 

 // get the date and time from GPS into CurrentTime object.
 CurrentUTCTime.year = Year;
 CurrentUTCTime.month = Month;
 CurrentUTCTime.dayOfMonth = Day;
 CurrentUTCTime.hour = Hour;
 CurrentUTCTime.minute = Minute;
 CurrentUTCTime.second = Second;

 // get course and speed directly from GPS
 NavData.COG = ((float)COG/100);
 NavData.SOG_mps = ((float)SOG / 100);
};

Voyager 2.0 Wingsail Behaviour - Instability and Oscillation

Voyager 2.0 Self Trimming Wingsail Behaviour - Instability and Oscillation

When the Self Trimming Wingsail on a monhull is caught in irons (head to wind) it is prone to severe oscillation as depicted in the video below.
There’s a number of factors that may affect this, and some testing needs to be done isolate these factors.

Reduce the Rotational Inertia of the Wingsil Assembly.

The rotational inertia of a body is related to the mass x radius squared. Hence, the static balance could be maintained by doubling the counterbalance mass, reducing its distance on the counterbalance arm to half. This change would have the effect of halving the rotational inertia.
A test to see if this change reduces the instability is reasonably practical to perform.

Monohull versus Multihull

Many Self Trimming Wingsail implementations are done using Multihull vessels. Multihulls have much different stability curve compared to a monohull. A Multihull exhibits maximum stability at zero angle of heel, which is completely the opposite of a monohull which has zero stability at zero angle of heel, and progressively increases as the angle of heel increases reaching a maximum at 90 degrees.
It’s possible that the effect is not apparent in Multihull because they are so stable at low angles of heel.

Lower the Centre of Effort

Lowering the Centre of Effort of the sail may reduce the rolling effect. This could be done by tapering the sail shape with a reduced chord length at the top compared to the bottom of the sail.

Avoid Going Head to Wind

One way to avoid the situation is to always perform a gybe when changing tack.
This has been the most effective solution, by far.

Avoid Going Dead Downwind

It turns out that heading dead downwind can result in the same rolling effects as pointing too high.

Hence, its important to tack downwind, and avoid sailing too square.

The rolling effect while sailing downwind is not as pronounced as when sailing too high to windward. The boat can still sail downwind while rolling, but it is likely that the rolling effect could induce unnecessary wear and tear on the vessel and the rig.

Also, although I haven't verified it by preparing polar performance diagrams yet, but its likely to be faster to tack downwind.

Update... 

Wingmill, Flutter Pump or Oscillating-Wing Power Generator

It turns out the instability that a monohull with a wingsail can exhibit, can be used for benefit.
The oscillation effect can be used for devices such as pumps, as demonstrated in this video:

Note: This is part of the ongoing development of a low cost autonomous oceangoing sailing drones, utilising a self-trimming wingsail. This is the Voyager series of sailing drones.

Voyager 2.0 First Sailing Trials

Voyager 2.0 First Sailing Trials

Voyager 1.5 Follow up - 6 Months Later

Voyager 1.5 Follow up - 6 Months Later

About six months after Voyager 1.5 was lost, I received an email containing photographs of the boat.

The sender advised that they had found it in the car park  at Broadwater beach (between Ballina and Evans Head) on 18th January 2019.

Approximate path of Voyager 1.5, 1200km over 7 months

It was found in the car park. This implies that someone else had found the boat on the beach and carried it up to the car park.

Voyager 1.5 soon after retrieval from the car park, half covered in sea life.

The SPOT GPS Satellite transmitter was missing from the vessel.
It was housed in 1 litre container that had been lashed down in the equipment bay.
The photo appears to show that lashing cord has been cut, and hence the SPOT GPS Satellite transmitter has been removed after the vessel left the water. (The cord would have washed away if appeared like this and was in the water.).

By coincidence, this device had only just been removed as the active device on the SPOT GPS account about 3 days prior, on the 15th Jan 2019. This was done, because no signal had ever been received since July the prior year, and the elapsed time was approximately the expected life span of the batteries.

The 3D Printed Label with the Return Email Address 

Transom area with remnants of steering gear

Observations

Beaching in Northern New South Wales, near Ballina.

This was unexpected. It appears to have travelled North against the East Australian Current.

The most likely explanation is that it has travelled offshore, outside the East Australian Current and then come inshore again near the border with Queensland.

Bent Keel

It appears that the aluminium fin may have been bent, causing the hull to lean over, there by stopping the satellite transmitter from gaining a clear view of the sky.

The photographs showing the discolouration of the components and the coverage of sea life, suggesting that the hull was lying at an angle of about 90 degree heel.

Missing SPOT GPS Transmitter

This appears to have been removed by someone, rather then being lost at sea. The photo appears to show a lashing string that would not have remained if it failed at sea.

Missing Rudder

The plywood rudder, with stainless steel shaft and 3D printed plastic tiller are not present.

Steering Vane Vertical shaft and Steering Gear Frame

This all appears intact. The vane has gone and steering arms have gone.

Steering Vane Aluminium Counter Weight Arm

The Aluminium tube is broken and counter weight is missing.

I suspect that this was lost when the vessel was beached.

Broadwater is long beach that does not appear to have nearby rocks.