You may have reached this "Software" page by accident. See
Snoopy's GPS Guided Trans-Atlantic Robot Boat
to know more.
I'm warning you now: this page is NOT to be read by the majority of you - including experienced software engineers !
But it may be useful in warning those considering use of a Picaxe computer, for their robot boat autopilot,
to think again, and use a computer that is less primiltive, and therefore easier to program.
Having said that, I'm now very happy to stick with the Picaxe computers, because I did the hard work years ago :-)
For those of you who have seen my cautious approach, when considering changes to my autopilot software, and my need for months of testing, my excuse is my having spent many years in defence systems. This was since the 1960s, working with the guys who were developing the onboard software for Royal Navy ships, the Arianne space rocket, the Tornado fighter aircraft, and mobile air defence systems for the British Army. Checkout my "history" page above, for more detail, including the 1992 "Barossa Operation" video. You may even enjoy it ! :-)
This page zeros in on one small but important part, of the Picaxe Autopilot program: that used to calculate the direction of the next waypoint. This will help some of you appreciate how primitive the Picaxe computers are.
At the bottom of the page is an extract from Snoopy's Design Page, giving you the "bigger picture" of the Picaxe software, so you will know where this part fits.
Why did I choose the Picaxe, years ago ? I could have stuck with use of an iPAQ Pocket PC, using the software I had already written for that. After a few years experimenting, we did get the iPAQ to sail the boat around "The Bray Lake Test" course of waypoints.
I might not have switched to the Picaxe, if I'd seen the Arduino, but I did all that difficult Picaxe software work,
years ago, with some help from others, and so I can have the benifit of a very small, low cost, and low power, computer.
That's the Picaxe 08M2 Servo Driver card on the left, that has been the "computer" in our autopilots for 2012,
2013 and 2014 Atlantic Attempts.
I'm experimenting with new electronics and software for next year's boat, and an important step was to
exploit the Picaxe 28X2 Module.
That's it on the right, with a GPS and electronic compass - suitable to connect direct to the rudder servo.
The problem with the Picaxe 08M2 is that it has no maths library, with functions like COS and ARCTAN, that make it so easy to prgram what would be a simple calculation of the direction to steer, based on the destination, and boat's GPS, latitudes and longitudes. The Picaxe does not have more than UNSIGNED 16 bit integers - not even signed ones, and certainly not the luxury of floating point, REAL numbers. So the code has to split into blocks, according to which value is greater, and take great care not to cause overflow.
One nice surprise discovered with the 28X2, is that it does have maths functions SQRT, SIN, COS and ATAN - but you still have those restrictions of having to work with unsigned integers !
Before we delve into that old Picaxe code, used here to show difficulties with Picaxe software, here are some of the things with which we have already had success, using the 28X2 computer on our experimental boat 6. This experimental autopilot program, AUTOPX1.BAS, has all the original logic for testing at Bray Lake, and the complete Trans-Atlantic route from the UK south coast, to the final destination in the USA.
On the right are pictures of Boat 6 after a minor "rebuild" in August 2014, including a higher box at the back,
the wind sensor put onto the box, moving the mast forward 6cm, to reduce weather helm (turning into wind) - due
partly to increased wind pressure on the box, and numerous software changes. These software changes include
doing a "jibe turn", through downwind, if unable to turn across the wind. e.g. when changing tack.
The Mobius video camera has a new position at the back, so it can see the wind direction sensor,
and hear information spoken by the Picaxe computer.
Typical speech heard by the camera, and over the radio, includes....
"Ahead.. Ahead.. Left.. Ahead.. Right.. Ahead.." - Steering based on compass, until the GPS is checked...
"Navigation check..." (pause for a few seconds, after GPS is switched on, before it gets good data and continues steering again)
"Time is 1135 ..." (GMT) "Speed is 1.2 knots... Wind is from North-West... Range 90 metres... Tacking to left... Steer 330 to Alpha ..."
"Right... Right... Ahead... Ahead... Ahead..." etc.
On the left is the GPS Plot from the Bray Lake Test of 5th August, showing tacking with jibe turns, and straight compass-based steering between waypoints that were not upwind. Click on the picture to see a bigger version, and read the details.
Here is the section that "zeros in" on the nitty gritty ....
The code I've released below, is my horrible approximate calculation of the direction the boat must steer, to reach it's next waypoint. It uses the latitude/longitude of the waypoint, and the GPS latitude/longitude of the boat. The differences between these enable the direction to be calculated. On a "proper" computer, with a maths library, it would be almost trivial: one or two lines, including the ARCTAN function call. But you can see, this is something else !
This code has been used, unchanged, for years, and is has been tested many times on Bray Lake and elsewhere. It is probably accurate to about 4 or 5 degrees, but it would be nice if it were more accurate - so long as it remains reliable.
A good example of inaccuracy, is if I listen to the autopilot speaking the direction to steer, from my home in Sunninghill,
to the default startup waypoint A on Bray Lake. The autopilot says "353 degrees" (clockwise from north), but google maps
says 348.7 degrees. Waypoint A is at 51 29.970'N 0 41.460 W, and my home is 51 23.818'N 0 39.597'W.
The map on the right, and the diagram below, show the triangle used for the calculation.
My crude approximation of COS does not explain the inaccuracy: if corrected, that would make the inaccuracy worse.
If one uses the same numbers for lat/lon, but in the easier solution, possible with a different computer:
Angle = 360 - ARCTAN ( diff in Long * COS (Lat) / diff in Lat )
- then you get 349.2 degrees, which is closer to Google Earth's 348.7, compared with my 353 degrees.
So the loss of accuracy is probably within that scaling, which needs to avoid 16 bit integer overflow.
Here is that code from my Picaxe Autopilot programs, which was unchanged* over the years, to calculate the target heading, into W1, from the differences in minutes of latitudes and longitudes. * In February 2015, I replaced the code below by that from the update reported in the Blog. The changes were minor, marked by "13Feb15" and "15Feb15", and made the direction calculation more accurate. This is for those helping Robin with the software. Please don't forget that this is code for the old, trusty, Picaxe 08M2 autopilot, which does not have COS and ATAN, available in the Picaxe 28X2. We had that working in the summer of 2014, but months of testing are needed before we switch from the 08M2 to the 28X2 based autopilot. Both suffer from only having unsigned 16 bit integers, which is one reason why the code below is messy. Another reason is that I wrote it :-)
I gave you fair warning ! :-)
'calculate approximate target heading based on difference in lat/lons.
'This based on just minutes if two positions have same lat and lon degrees.
'If different degrees, then scale minutes and modify based on degrees.
'Scaling is used to avoid overflow when a long distance appart.
'This arithmetic overwrites the values of GPS and Destination lat/lons.
'Temp variables available: w6,w11,w12.
'1v change minutes if not same values of degrees for GPS and Destination.
if b0 <> b14 or b1 <> b15 then 'NOT same value of degrees in lat or lon
'work with units of 0.1 minutes of lat/lon i.e. 100x less accurate.
w11 = b0 * 600: w12 = w4 / 100 '1t was *300 and /50 GPS lat/lon
w4 = w11 + w12 'latitude LSD is 0.1 minutes = 1/600th degree
w11 = b1 * 600: w12 = w5 / 100
w5 = w11 + w12 'longitude LSD is 0.1 minutes = 1/600th degree
w11 = b14 * 600: w12 = w8 / 100 'Destination lat/lon
w8 = w11 + w12 'latitude LSD is 0.1 minutes = 1/600th degree '26Jan15 Problem?
w11 = b15 * 600: w12 = w9 / 100
w9 = w11 + w12 'longitude LSD is 0.1 minutes = 1/600th degree '26Jan15 Problem?
endif
'09Feb15 use new COSLAT function near end of program, instead of earlier approximation.
'13Feb15 call coslat 'get 100 * Cos(Lat) where Lat is average of GPS and Destination latitudes.
'13Feb15 b1 = b22 / 10 'original code using b1 can now be used....
'now just the values of minutes (or scaled minutes) can be used ...
if w8 > w4 then 'Dest Lat > GPS Lat
w12 = w8 - w4 'Diff Lat
if w9 < w5 then 'Dest Lon east of GPS Lon
w13 = w5 - w9 'Diff lon
gosub scalew12w13 'scale if either more than 1000 to avoid overflow
else 'Dest Lon west of GPS Lon
w13 = w9 - w5 'Diff lon
gosub scalew12w13 'scale if either more than 1000 to avoid overflow
w6 = 359 ''12Feb15 was 360
w13 = w6 - w13 'was w13 = 360 - w13
endif
else 'Dest Lat < GPS Lat
w12 = w4 - w8 'Diff Lat
if w9 < w5 then 'Dest Lon east of GPS Lon
w13 = w5 - w9 'Diff lon
gosub scalew12w13 'scale if either more than 1000 to avoid overflow
w6 = 180
w13 = w6 - w13 'was w13 = 180 - w13
else 'Dest Lon west of GPS Lon
w13 = w9 - w5 'Diff lon
gosub scalew12w13 'scale if either more than 1000 to avoid overflow
'12Feb15 w6 = 180
w13 = w13 + 180 'was w13 = w6 + w13 'was w13 + 180
endif
endif
w1 = w13 'make this the target heading THIS MAKES THE METHOD ACTIVE
'15Feb15 experimental correction from RINGRIGX to try and make w1 more accurate
'ENDIF blocks added here in Picaxe basic to pass syntax checks
IF w1 >= 2 AND w1 <= 6 THEN
w1 = w1 + 1
ENDIF
IF w1 >= 11 AND w1 <= 39 THEN
w1 = w1 + 4
ENDIF
IF w1 >= 51 AND w1 <= 85 THEN
w1 = w1 - 4
ENDIF
IF w1 >= 98 AND w1 <= 129 THEN
w1 = w1 + 4
ENDIF
IF w1 >= 141 AND w1 <= 174 THEN
w1 = w1 - 4
ENDIF
IF w1 >= 186 AND w1 <= 219 THEN
w1 = w1 + 4
ENDIF
IF w1 >= 231 AND w1 <= 265 THEN
w1 = w1 - 4
ENDIF
IF w1 >= 271 AND w1 <= 312 THEN
w1 = w1 + 4
ENDIF
IF w1 >= 323 AND w1 <= 348 THEN
w1 = w1 - 3
ENDIF
goto afterscalesub '1t was x so subroutine near place called from - for clarity
scalew12w13: '13Feb15 scale w12 and w13 to less than 600 so can * by up to 100
IF w12 < 600 AND w13 < 600 THEN endscale
w12 = w12 / 2: w13 = w13 / 2 'make both smaller
GOTO scalew12w13 'repeat until both less than 600
endscale:
'13Feb15 if w12 > 1000 or w13 > 1000 then
'13Feb15 w12 = w12 / 100
'13Feb15 w13 = w13 / 100
'13Feb15 endif
call coslat 'get 100 * Cos(Lat) where Lat is average of GPS and Destination latitudes.
w13 = w13 * b22 / 100 '13Feb15 old code was w13 = w13 * b1 / 10 '1v b1 was COSLAT
if w13 < w12 then
w13 = w13 * 45 / w12
else
w12 = w12 * 45 / w13
w13 = 90 - w12
endif
return
afterscalesub:
'1v sertxd ( ", TgtHdg=",#w13, " " ) 'trace output back to PC
'1j w13 not used after here, so use it to hold speed
w13 = w3 '1j hold speed used for rudder logic
'sertxd ( " TgtHdg=",#w1, " " ) 'trace output back to PC
'(old tacking logic was here. Commented out in 2012)
aftercalchdg: 'W1 now holds the Target Heading that the boat must steer towards
PAUSE FOR1SEC '1v remove servo twitch ? 28Jan13 move here 1sec->2sec->1sec
SEROUT 2, T9600_16, ( #w1," degrees. " ) 'TTS output
'MOVE RUDDER TO TURN TOWARDS TARGET HEADING.
'calculate the rudder position for steering logic
'Integers are unsigned, so cannot have any negative numbers.
The approximated COS function appears later in the program:
coslat: '09Feb15 returns COS(Lat) * 100 in b22. e.g. COS(50)=0.64. b22=64. '13Feb15 COS=114-Lat e.g. 64 for Lat 51. Was 115 so less accurate at 51. 'Average Lat between GPS in b0 and Destination waypoint in b14 is used. b22 = b0 + b14: b22 = b22 / 2 'average. b23 = 114: b22 = b23 - b22 'approximation in b22 is 115 - Lat in degrees. 13Feb15 return
This was written in 2014 ....
Googling on "picaxe arctan" I find a nice surprise: it seems the Picaxe 28X2 supports SIN, COS and ATAN. See: Picaxe Trig.
I'll be trying this out soon, but as an example, the old code above might change from:
b1 = 5 if b0 < 56 then b1 = 6 endif if b0 < 50 then b1 = 7 endif if b0 < 40 then b1 = 8 endif if b0 < 31 then b1 = 9 endifto something more like:
b1 = cos b0: b1 = b1 / 10
... neater eh ? :-) Or perhaps keep the greater accuracy, without / 10, then apply different scaling when it is used later.
I look forward to checking this out, and ATAN, in our experimental 28X2 software. These trig functions are not supported on the old 08M2 hardware, but any program for next years boat, intended for a 28X2, would probably not squeeze into a 08M2 anyway, so no harm in exploiting these trig functions, and not be able to put the new program into old hardware.
Here is the experimental code, that has changed, now in Boat 6 to be tested again on Bray Lake:
b1=cos b0 '20July14 use Picaxe COS and ATAN instead of approximations.
if w8 > w4 then 'Dest Lat > GPS Lat
w12 = w8 - w4 'Diff Lat
if w9 < w5 then 'Dest Lon east of GPS Lon
w13 = w5 - w9 'Diff lon
gosub scalew12w13 'scale if either more than 1000 to avoid overflow
else 'Dest Lon west of GPS Lon
w13 = w9 - w5 'Diff lon
gosub scalew12w13 'scale if either more than 1000 to avoid overflow
w11 = 360 '10July14 was w6
w13 = w11 - w13 'was w13 = 360 - w13 '10July14 was w6
endif
else 'Dest Lat < GPS Lat
w12 = w4 - w8 'Diff Lat
if w9 < w5 then 'Dest Lon east of GPS Lon
w13 = w5 - w9 'Diff lon
gosub scalew12w13 'scale if either more than 1000 to avoid overflow
w11 = 180 - w13
w13 = w11
else 'Dest Lon west of GPS Lon
w13 = w9 - w5 'Diff lon
gosub scalew12w13 'scale if either more than 1000 to avoid overflow
w11 = w13 + 180 '20July
w13 = w11
endif
endif
w1 = w13 'make this the target heading THIS MAKES THE METHOD ACTIVE
goto afterscalesub
scalew12w13: 'subroutine near place called from - for clarity
if w12 > 1000 or w13 > 1000 then
w12 = w12 / 100
w13 = w13 / 100
endif
w13 = w13 * b1 / 100
if w13 < w12 then
w13 = w13 * 100 / w12
w13 = atan w13
else
w12 = w12 * 100 / w13
w12 = atan w12
w13 = 90 - w12
endif
return
afterscalesub:
sertxd ( "TgtHdg=",#w13, 13,10 ) 'trace output back to PC
Oh yes: instead of the autopilot speaking "353 degrees", from my home to Bray Lake, it now says "350 degrees",
which is a lot closer to google earth's 348.7 degrees ! The new code, using COS and ATAN, was tested on Bray Lake,
and Snoopy completed his "recce" mission well, completing the route from 24/7 waypoint, through B,C,D and back to Base.
However, I noticed he was heading several degrees to the right, when launched, and soon found and corrected a minor
bug in one of the blocks of code above.
We will see how well Snoopy does on his next Bray Lake Test :
The following extract is from
Snoopy's Design Page and gives the "bigger picture" on the Picaxe Autopilot software,
still running on the smaller Picaxe 08M2 Autopilots (Picture on right). This Picaxe Autopilot software
was used in Boats8, 9, and 10, for Trans-Atlantic attempts in 2012, 2013 and 2014. Few software
changes were made after development finished in 2012, and absolutely none since January 2013.
There is a difference between software that is to be USED, and that with which we are still experimenting or testing ;-)
In the summer of 2014, the same software was being run on the larger Picaxe 28X2 Module, including experiments with an electronic compass. Most of the software statements did not need to change at all, including the example code above, which does the step "4. calculate the true heading from current GPS position to the destination position. " below.
Here is the exctract ....
QUOTE
Please do not expect me to release the PICAXE software source code, or a PICAXE with our software in it, for use by other than Team-Joker. If anyone stumbles upon a PICAXE, such as in a Snoopy-Sloop lost at sea, or left on Bray Lake, I understand it is not possible to extract the source code from it.
However, I will describe the autopilot logic here, to help anyone deciding to write their own software, on a PICAXE or on some other computer. They could start with testing their boat with our GPSSppc based autopilot, if they do not expect too high a level of support. Many will consider the Pocket PC to be obsolete anyway :-)
The logic is intended to work if power is lost at sea and the system then restarts. e.g. too many days without a bright sky ?
The Autopilot logic may be described as:
The above cycle takes about 6 or 7 seconds, depending on how fast the boat is moving. Step 7 is done because the steering will be more sensitive if the boat is moving more quickly. This is to reduce "over-steering". Ideally the system should be tuned so that only one or two cycles are needed to turn the boat onto the required direction.
This picture shows use of Robin's "GPS Simulator" on his PC, to test the PICAXE autopilot software, particularly on it's planned route to the USA. The deliberately "wobbly" path, is created by clicking on maps with GPSS to make a file of NMEA GPS data. This data is played out of the PC COM1 RS232 port into the PICAXE, and also shown on the PC screen. The data is deliberately wobbly, to check that the Autopilot turns the rudder correctly, to reach the next waypoint. The PICAXE should beep out it's usual sounds, including range to waypoint and "Close Encounters" when in the waypoint "box".
Footnote in January 2013: Small changes have been made carefully to the PICAXE Autopilot software, and will get a lot of re-testing. There is always the option of using exactly the same version (1) of the autopilot software launched in 2012 after months of testing. However, it is hoped that this version (2) will be easier to test thoroughly, both on the water at Bray Lake, and sailing UK to USA with the GPS simulator. This is because Text-To-Speech (TTS) is used to speak more detailed information such as: "270 degrees" (waypoint is due west), "right 45" (turn right 45 degrees), "60 metres" (distance to waypoint) and "at waypoint". The other changes relate to additional waypoints near the UK south coast, to avoid the busiest part of the shipping lane, and also reduce risk of hitting the UK coast due to steering to a very distant waypoint. There is now a 6 minute video of the software being tested with the GPS simulator here.
Footnote in July 2013: here are typical statements from the PICAXE AutoPilot program, showing signal/pin numbers used
for things like reading GPS data, rudder servo output, and text-to-speech (TTS) output. I've put them here
to aid discussion, on the PICAXE forum, of experiments with the HMC6352 compass module. We need to find one or two spare signal pins !
This section provides more detail on the software action above, described as "8. move the rudder to turn the boat in required direction".
The autopilot steering logic has not been changed for years, including that used in boats 6,7,8, and 9. However, in September 2013, we've started to experiment with the "rudder trim logic", since this may result in improvements for future boats, for future years. See boat 6 on right.
The basic GPS-based steering involves the rudder normally being "straight ahead", but being moved to left or right, for a few seconds, every time around the cycle of typically 6 seconds. i.e. about 10 times per minute. The time it is held over depends on the boat's speed, so that it is not too sensitive at higher speed. Numbers used, for Speed in knots S, have been: 1.5 sec + 1 sec (if S < 1) + 1 sec (if S < 0.5). i.e. 1.5 secs if speed greater than 1 knot.
The ammount of movement is proportional to the error in direction, between the target heading, and the GPS heading. i.e. the rudder remains central if the boat is heading in the required direction.
The "gearing" between direction error (+180 to -180) and rudder movement, has used a software "MAXDERR" value of 120 for years, after first experiments with values such as 90. e.g. if the direction error is 120, full rudder will be applied: if 60, half rudder, etc. i.e. rudder = maxrudder * error / MAXDERR. If the direction error is greater than MAXDERR, it is limited to this value. i.e. full rudder. This MAXDERR value is being looked at again, for future boats. e.g. maybe smaller, to give "tighter" steering.
However, instead of the rudder being returned to an exact centre position, every cycle, it is given some trim, in the direction of the turn. This was introduced years ago, to aid "self-balancing" of the boat in a wide variety of relative wind directions and speeds. If the direction of the turn changes, then the rudder trim is reset to zero. So, if the boat is repeatedly trying to turn right, the autopilot will gradually apply right rudder trim, in addition to the regular "right rudder".
Parameters in the software have not been changed for years, and these are:
These parameters have worked well in a wide variety of boats, including boats 6 to 9, sailing sloops of 3 to 4 foot long, but also on the small, motorised "windmill boat" of only 1 foot long. This is because there is plenty of adjustment available between boats, such as the size of rudder, and where the servo linkage clips onto the rudder lever.
Experiments with the compass (see "Alternative Designs" below) have led us to experiment with this GPS-only steering logic. e.g. modification of those numbers above and/or adding logic such as a "turn through downwind" if maximum trim is reached. It is thought that this might improve the sailing ability of the boats, including turning between "tacking" directions, into wind.
We will add more detail here, if changes are found to be worthwhile.
UNQUOTE.
© 1991-2014 Robin Lovelock. Please credit www.gpss.co.uk if you use material from any of these pages. Thankyou.