PICAXE handling GPS for robot boat

Robin Lovelock

Senior Member
Thanks Folks. I've added some more words about this topic near the end of the experimental blog on www.gpss.co.uk/rbblogx.htm - near the picture showing Snoopy's last few waypoints past Cape Cod. In short, this may be of interest in the future - but will be used with great care.

"08M2+" sounds interesting - I'm guessing this is something better than the 08M2 we've used for years, in the AXE24 Servo Driver kit ?

Robin
www.gpss.co.uk

p.s. to answer my own question: "08M2+" is just the label on the 08M2. See http://www.picaxe.com/What-is-PICAXE/PICAXE-Chip-Labels/
 
Last edited:

Robin Lovelock

Senior Member
Hi Folks. Does anyone have a better crude approximation to the ATAN function, that I use in the old Picaxe 8M2-based Autopilot, still being used in Boat10, being prepared for a launch soon ? We've used this crude logic for years, and it gives results which are JUST adequate in accuracy, up to maybe 5 degrees out. It would be nice if we could use something which would only add perhaps 10 or 20 bytes to the 2K program. It just so happens that this function is within that to calculate direction, and described in detail on Snoopy's software page www.gpss.co.uk/rbsoft.htm This same page shows that we use the 28X2 ATAN in our (experimental) 28X2 based autopilot, working last summer.

If you wade through the code, you may see that the heart of the calculation is getting the angle from a scaled difference of longitude and latitude. The present approximation is VERY crude: w13 = w13 * 45 / w12

i.e. assuming (wrongly) a linear relationship of the angle with it's TAN. One approach might be to work in 15 degree segments instead of 45 degrees. However, I thought I'd post this, since I'm sure someone may have already done it :)

Robin
www.gpss.co.uk/autop.htm - latest news on Snoopy's robot boat attempt
www.gpss.co.uk/rbblog.htm - see bottom of this "Blog" for where this ATAN thing fits in.
 

AllyCat

Senior Member
Hi Robin,

See the code in my post #20 in this forum thread.

Sorry, I still haven't posted it as a code snippet. One reason is that I believe the "best" way to code trig function angles may be as "fractions of a revolution", not from values based on degrees or radians*. Thus, a right angle would be coded not as 90 degrees (360 / 4) but as 64 "units" (a byte, 256 / 4) or even 16,384 units (a word, 65,536 / 4). The advantage is that angles over 360 degrees automatically "wrap around" (over/underflow) to the correct value. But I do accept that it may be a difficult concept to understand.

* The results then can be converted to familiar degrees or radians by multiplying by an appropriate factor, e.g. 360 and (trivial) division by 256 or 65,536..

Cheers, Alan
 

Robin Lovelock

Senior Member
Thanks Alan. I visited your relevant link, not long after you did your posting above, but thought it best to delay this reply, until I'd got more urgent "work" out of the way, and updated that blog. e.g. the recent "tea tray road tests" of the direction calculation logic. The code extracts below should help to illustrate what we've already done, and tested on Bray Lake, and or in several attempts at sea. Anyone who has not already done so, should at least make a brief visit to those pages below. If not, they may waste a lot of their time, and maybe that of others - but I doubt it.

Code:
'COSLAT is used to scale difference in longitudes to similar scale of miles/km as difference in latitude
'ATAN functions used to calculate angle 0 to 45 from the ratio of lat and lon differences.
'The work of interest now (February 2015) is to estimate errors of approxiumations and find better approximation(s)
'in the (cruder) software used within the Picaxe 08M2, that does not have ATAN and COS functions, that are in 28X2.

'Typical code from Picaxe 08M2 autopilot, using crude approximations for ATAN and COS for calculation of direction:

 coslat: '09Feb15 returns COS(Lat) * 100 in b22. e.g. COS(50)=0.64. b22=64.
   'Average Lat between GPS in b0 and Destination waypoint in b14 is used.
   b22 = b0 + b14: b22 = b22 / 2 'average.
   b23 = 115: b22 = b23 - b22 'approximation in b22 is 115 - Lat in degrees. e.g. 65
   return

 atana1: '10Feb15 better approximation of ATAN from 0 to 45 degrees
   w13 = w13 * 45 / w12
   if w13 < 15 then 
     w13 = w13 + 5
   endif
   return 


'Typical code from Picaxe 28X2 autopilot, able to exploit COS and ATAN functions, working in summer of 2014 on lake:

  w27 = cos b0  '01Aug14 was b1 use Picaxe COS and ATAN instead of approximations.
' (would be better to use average latitude of GPS positiuon and destination waypoint)
' (following gives flavour of how ATAN function used in core of direction calculation)

   w13 = w13 * 100 / w12
   w13 = atan w13
So, right now, I'm seeking to quantify the errors between the crude calculation of direction, from Boat GPS Position, to destination Waypoint,
when compared with the direction shown by trusted sources such as google earth. If someone wants to wrap any of those code extracts
into a test harness, to quantify errors, they are most welcome. My current plan is to do a bit of "driving around", listening to the TTS
saying the direction, and do a few checks at particular places. Doing this on the road, at a range of a few miles, should be better than
walking around Bray Lake (that map in the Blog), where a small GPS error such as 10m will cause a big change in direction.

I look forward to any useful ideas.

Robin
www.gpss.co.uk
www.gpss.co.uk/autop.htm Snoopy's "front page" - latest news, and what's this is all about.
www.gpss.co.uk/rbblog.htm - "Blog" of work, day by day. See bottom and recent software work.
www.gpss.co.uk/rbsoft.htm - "Software" page: direction calculation is used as the example.
www.gpss.co.uk/rbdesign.htm - "Design" page - maybe Software section gives you a rough indication of where direction calculation is used.
 

Flenser

Senior Member
Does anyone have a better crude approximation to the ATAN function
If you have some eeprom free then you can store the ATAN function as a table lookup. A table of 56 values (0-55) resolves to 1 degree steps.

My eeprom values are calculated in a spreadsheet using =DEGREES(ATAN(A1/55)) for column A values 0-55
e.g. atan(0/55)=0, atan(1/55)=1, atan(2/55)=1, atan(3/55)=2, ...., atan(55/55)=45
This:
Code:
w13 = w13 * 45 / w12
Then gets replaced with:
Code:
eeprom(0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,24,25,26,27,28,29,29,30,31,32,32,33,34,35,35,36,37,37,38,39,39,40,41,41,42,42,43,43,44,44,45)
;
b0=w13*55/w12 max 55: read b0, w13
I calculate an extra 6 bytes each time you replace "w13 = w13 * 45 / w12" with "b0=w13*55/w12 max 55: read b0, w13"
 

Robin Lovelock

Senior Member
Wow! Many Thanks Flenser, for such an excellent answer. Before I respond in more detail, I'd better give an update on what happened over the weekend, and was only put into my Blog yesterday. See the end of www.gpss.co.uk/rbblog.htm for nitty gritty. In short, in last few days, I made a (slightly?) better approximation for ATAN, but - more significantly - made other improvements related to scaling and "adjustment" based on a test rig. The result seems to be reduction of the typical RMS (average) error in direction calculation from about 3 to 1 degrees. Also, the maximum error, from 0 to 359, seems to be reduced from 5 to nearer 2 degrees. In the longer term, this 08M2 based autopilot, will get used in Boat10 - for the next attempt soon, but will be replaced in later boats by my 28X2 based autopilot, that can use the trig routines like COS and ATAN.

However: I've never yet used eeprom, and it may become useful to me in the future, on 08M2 or 28X2. Even if I switch to using the 28X2 for the Autopilot, I still use the 08M2 for other things such as the SPOT tracker timer.

Roughly how many bytes* does your alternative ATAN cost ? I'm guessing, on the 08M2, such as used within my AXE24 servo controller board, the eeprom is the end of the 2k program memory ? So, if I have sufficient bytes free, after my code, I can use the rest of the memory for eeprom ? I don't rule out my using your code above for an update to that latest 08M2 autopilot: I'll certainly look at it more closely after hearing your reply to this.

Many Thanks again.
Robin
www.gpss.co.uk

p.s. * That eeprom array: one byte or 2 bytes per value ? i.e. +45 or +90 bytes, added to the +6 bytes per statement ?
I'm guessing your 45 values above are just for illustration ? i.e. I'd need to work out the correct values of ATAN corresponding to the value of w13*55/w12 ? With the values you have now, it seems to return the same value :)
 
Last edited:

Flenser

Senior Member
Robin,

The eeprom table returns one byte per lookup value. My code returns this byte angle value into w13 only to do the same as your atan angle code returning the angle in w13. I use a byte variable in the test code below.

In my example the full "eeprom (..)" statement I pasted into the posting has 56 entries for the lookup of atan(0/55) to atan(55/55). i.e. I have scaled the 0 - 1 range for tan() to be integer values 0 - 55.

The 56 values was chosen using a spreadsheet and trial and error to give a resolution of no more than 1 degree on the angle that is returned by two adjacent atan lookups. There are some angles where the truncated difference between two adjacent atan values is less than one degree, so the atan lookup returns the same value for the two adjacent tan lookups.

The cost varies, depending on the version of the picaxe chip.

For the current picaxe chips, which I read as including the 28X2, this data memory eeprom is 256 bytes of extra storage that is completely seperate from the program memory, so the "eeprom (....)" statement costs you no program memory at all. The extra cost is only the extra bytes for the longer "b0=w13*55/w12 max 55: read b0, w13" statement that replaces "w13 = w13 * 45 / w12" to lookup the angle value.

For the older picaxe chips, which includes the 08M2, your guess is correct and the manual describes this data memory eeprom as coming out of the end of your program memory. So the cost for my example is 56 bytes for the eeprom table plus the extra bytes for each "b0=w13*55/w12 max 55: read b0, w13" statement

Running this code in the simulator prints out the 56 atan results for looking up atan(0/55) through (55/55), returning angles in the range 0 to 45 deg.
Code:
eeprom(0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,24,25,26,27,28,29,29,30,31,32,32,33,34,35,35,36,37,37,38,39,39,40,41,41,42,42,43,43,44,44,45)
;
main:
for b0 = 0 to 55 ; start a loop
read b0,b1 ; read value from EEPROM
serout C.1,N2400,(#b1,13,10) ; transmit to serial LCD module
next b0 ; next character
stop
 

Flenser

Senior Member
Robin,

On your page rbsoft.htm you make the comment about the calculaton to the Bray Lake waypoint from your home "The autopilot says "353 degrees" (clockwise from north), but google maps says 348.7 degrees"

You are calculating your angle to the next waypoint using the GPS lat and long values but this will get less accurate the further you are from the equator. The distance along the ground in km for 1 deg of longtitude gets less as you move further north or south of the equator while the distance along the ground in km for 1 deg of latitude stays about the same.

Using this wikipedia page https://en.wikipedia.org/wiki/Geographic_coordinate_system as my reference I can calculate a value of 349.2 degrees, close to what you got from google maps

Waypoint A is at 51 29.970'N 0 41.460 W = 51.4995 N 0.6910 W
Your home is 51 23.818'N 0 39.597'W. = 51.3970 N 0.6600 W
Difference between the two waypoints = 0.1025 N, 0.0310 W

The values of km/deg:
110.574 km/deg Latitude Calculated at your Lat using the formula on the wikipedia page
69.47 km/deg Longtitude The value for Greenwich in the table on the wikipedia page
Difference between the two waypoints 0.1025 N, 0.0310 W = 11.333835 km N, 2.15357 km W
tan=2.15357/11.333835 = 0.1900, atan(0.19) = 10.76 deg = 349.24 deg


If I use the GPS lat and long values I get a value that is further to the west, which is what I would expect. I do not get a value that matches what you've recorded the autopilot saying. Any chance the "353 degrees" entry on the web page is a typo?

Difference between the two waypoints = 0.1025 N, 0.0310 W
tan=0.031/0.1025 = 0.3024, atan(0.3024) = 16.83 deg = 343.17 deg
 

Robin Lovelock

Senior Member
Thanks for those two extra postings Flenser. Sorry that, in my p.s. I should have seen that your table was NOT just a 1,2,3...45 sequence, but there were in fact some repeats. I'm down to the last few bytes, and I think what I have will probably be sufficient for the 08M2. But, in the longer term, if some problem surfaces on the 28X2, then I might use your method for ATAN, after releasing memory by removing code not needed for the autopilot function itself. e.g. range calculation.

On your second posting you say "...but this will get less accurate the further you are from the equator.." I've always used COS(Lat) as a means of scaling the difference in longitude. I'm guessing this approach of ATAN ( dlon*COS(lat) / dlat) gives a result in the ballpark of better than 1 degree - for latitudes in the range 25 to 50 degrees North. I guess Google Earth uses a more accurate calculation, allowing
for things like the earth not being a perfect sphere ? If you know a simple equation for calculating the direction from the two lat/lons, then maybe I could put it into my RINGRIG test rig, written in old Microsoft(?) BC7 code. This imports most of the Picaxe code without problems.

But, if you check my Blog on www.gpss.co.uk/rbblog.htm you will see that I'm preparing for a Bray Lake Test - maybe as soon as tomorrow. It will be interesting if I see any differences in the GPS Plots, in how straight those legs between waypoints are.

Robin
www.gpss.co.uk

p.s. thanks for your link. I also found this: http://www.movable-type.co.uk/scripts/latlong.html
 
Last edited:

Flenser

Senior Member
Robin,

http://www.movable-type.co.uk/scripts/latlong.html was an excellent find. Looks like it gives you a heading calculation you can consider for your 28X2 autopilot.

I should have taken more time to understand your code before doing that second post. I'm a little embarrased I added that noise to the thread.

If you are still interested in a better calcluation for atan I have this code that uses the polynomial curve fit atan(x) = (377*x - x^2)/606
Code:
b0 = w13*100/w12
b1 = 377-b0*b0/606
If my spreadsheet calculations are correct, the max error for this curve fit is 0.72 deg. The exact atan value ends up with a max error of 0.5 deg after the result is rounded to an integer angle so this curve fit only adds a max of 0.21 deg extra error.

The code size of this polynomial curve fit is 13 bytes more than your original calculation "w13 = w13 * 45 / w12".
 
Last edited:

Robin Lovelock

Senior Member
No Probs at all Flenser. I delayed the reply here until we saw the results of today's Bray Lake Test, where this software is in the boat. The details, including GPS Plots, are at the bottom of the "Blog" on www.gpss.co.uk/rbblog.htm In short: we did a test yesterday, but the steering was "all over the place". I was sure there was a software bug somewhere in the recently changed Picaxe autopilot program. The Blog explains how, after failing to recreate the problem, it was eventually tracked down to extra "test equipment" (e.g. GPS logger, FM transmitter, Mobius video camera), having been mounted (only yesterday) on the TOP of the same box that holds the autopilot GPS.
Shifting this test equipment to a different place was a very simple answer - and the software worked perfectly. If the wind had been from a different direction, the boat would have completed the test in record time. After the test, we removed the extra test equipment, and left Snoopy on 24/7 duty, reliability testing the whole boat system. You can see if he is still in the middle of the lake with the live SPOT map, linked from the Blog and other pages. While Snoopy does 24/7 testing, and we wait for a suitable Atlantic Launch Window, I can "play" with the "experimental" stuff - reported on BlogX. Mr Postman has just popped an envelope through my door..... Yes, it is yet another Picaxe 28X2, but this time, not for adding a compass, as we did last year, but to add only a GPS, to make the next version of our "production" autopilot: the same software, but running in a 28X2 "GPS only" autopilot. I'll be using tips from this forum, and direct emails from friends, for the software improvements. The first of these will be to exploit COS, SQRT and ATAN - so we don't need those horrible approximations. This will be easy, because we did that last year. Many Thanks again.
Robin
www.gpss.co.uk/autop.htm - Snoopy's "front page".
 

Robin Lovelock

Senior Member
Hi Folks. Can anyone see why this code doesn't work, including in the Picaxe Editor simulation ?

Code:
' TEST.BAS Test code for 28X2
 #picaxe 28X2 '18Feb15 was 08M2 
 w13 = 1
         b12 = 200 / w13 'e.g. b12=200 for w13 = 1 for Lat difference 51N-50N
         w26 = 60000 / b12 'e.g. w26=300 for b12=200 
         b13 = w26 'e.g. b13=300 for b12=200 (but get 44 in b13 ???)
         sertxd (10,13,"b12=",#b12," w26=",#w26," b13=",#b13, " (in calc)")
I couldn't believe it, when I got different values in b13 and w26 after that simple statement.
It HAS to be something stupid by me, but could it be a bug in the Picaxe Editor ?

Until this happened, I was making great progress on my new AP28X2.BAS, including long range calculation.
Robin
www.gpss.co.uk
 

Robin Lovelock

Senior Member
Thanks chaps. How embarassing ! - to find your two replies, when I woke up to it being a byte, and was about to edit my posting above :)
As Homer said "Doh!" :)
Sorry for wasting your time.
Robin
 

Robin Lovelock

Senior Member
Hi Folks. My local friend and Picaxe user has alerted me to the possibility of my autopilot program, under 24/7 reliability test on Bray Lake, having a bug which involves the stack. e.g. goto instead of gosub, resulting in the stack eventually overflowing. This could be a particularly nasty problem, if it is happening less frequently than every time around the main 7 second steering control loop. So far, we've only had one unexplained case where the autopilot had stopped.

If I cast my mind back to 1970, the less primitive computers we used then, had a reserved register for the "stack pointer". Is there such a beast for the Picaxe 08M2 (and 28X2 if different) ? If I could read this, I could "speak the stack pointer value" and hear that it was moving. Then, after fixing the bug, I could confirm it was fixed.

So far, I've found this useful document, but it does not answer my question: http://www.picaxe.com/docs/picaxem2.pdf

When I made the most recent changes, early this year, to AUTOP9TTS.BAS, I started to adopt CALL instead of GOSUB, assuming the code generated was the same. Is it ?

Robin
www.gpss.co.uk/autop.htm - Snoopy's page
www.gpss.co.uk/rbblog.htm - blog
 

srnet

Senior Member
First, I dont think you can read the 'stack pointer', and you should not need to anyway.

GOTOs out of a sub-routine (GOSUB\RETURN) should be easy to spot and fix in the code listing, difficult to assist further without seen the actual code.

Third, I would consider an external watchdog circuit, that resets the PICAXE in the event of the program stopping, to be absolutly essential in an application like yours.
 

Flenser

Senior Member
Robin,

The section for the GOSUB command in the basic manual gives the same details. i.e. for both the 08M2 and 20X2 chips you are allowed to include up to 255 GOSUB calls in your program and you can nest GOSUB calls 8 deep. If your code make a GOSUB call nested 9 deep you will likely be in trouble.

Section 3.4 in this doc gives more details of the internal details http://elecurls.tripod.com/filz/PICAXE-ProgramSizeOptimisationAndSpeed-Rev_D-1.pdf.It doesn't seem to have the info for debugging a stack overflow.

You can debug the GOSUB nesting level yourself. Dedicate a byte variable to counting the GOSUB nesting level. The first line in every subroutine increments it. The last line in every subroutine decrements it. You can speak the byte variable at any time to report the current GOSUB nesting level. You can test the byte variable any time to find out if you just made a GOSUB call 9 deep.
 
Last edited:

Robin Lovelock

Senior Member
Thanks Guys: both with useful ideas. I made a bit more progress today, and I've updated both blogs, "Blog" and "BlogX" (links are below).
I was hoping I might get some answers from Hippy on things like reading the stack pointer (e.g. with PEEK ?) or confirmation that GOSUB=CALL.
I looked for the means of reading the supply voltage, in the program, but some features are not available to the 28X2.

This problem of the autopilot being "frozen" has happened again, and almost certainly due to the supply voltage dropping, due to a fault in half the duplicated 5v supply. In a way, it's good we had that supply failure, or I would not have seen this problem.

Thanks Flenser - I've not got many subroutines, and no more than 1 deep, so should not be anywhere near those limits. Programming a test of stack depth is certainly an option.

Yes SRNET, an external watchdog is certainly an option, or some other simple way of the supply cutting off if it drops below a threshold voltage. However, I'd much prefer being able to recreate the problem, then fix it at source, if that is possible.

Whatever was added externally, I'd prefer something that needed almost no software change, since I have so few bytes free. Also, any change needs thorough testing.
Maybe an ideal solution would require no software change. e.g. something inserted in the 5v power path that shuts off power completely, if it drops below 4v, then switches it back on, when it climbs back to above 4.1v - or two other adjustable thresholds. We obviously need to avoid "oscillation" of power switching.

Robin
www.gpss.co.uk
www.gpss.co.uk/rbblog.htm - "Blog" of tests and repairs of Boat10 before next Atlantic Attempt.
www.gpss.co.uk/rbblogx.htm - "BlogX" experimental stuff, including effect on autopilots of low supply voltage.
 

eggdweather

Senior Member
"I looked for the means of reading the supply voltage, in the program, but some features are not available to the 28X2."

If this helps, this is how I read the PICAXE supply voltage:

Calibadc10 will give a result (Nref) which will depend on the reference voltage (Vref) and the PICAXE power supply vltage (Vpsu) as follows -

Nref = Vref * 255 / Vpsu

This can be rearranged to determine the power supply voltage (Vpsu) from the calibadc result (Nref) -

Vpsu = Vref * 255 / Nref

If the Vref were 1.024 volts then this will be -

Vpsu = 1.024 * 255 / Nref

Vpsu = 261.12 / Nref

Rounded to the nearest whole number -

Vpsu = 261 / Nref - See more at: http://www.picaxe.com/BASIC-Commands/Advanced-PICAXE-Configuration/calibadc/#sthash.QrvQY6Lz.dpuf

If works well for me and the manual says applies to the 28X
 

AllyCat

Senior Member
Hi Robin,

I was hoping I might get some answers from Hippy on things like reading the stack pointer (e.g. with PEEK ?) or confirmation that GOSUB=CALL.
In some microcontroller/processors the "Stack Pointer" is simply a pointer into the normal RAM. Also PUSH and POP commands which allow variables also to be put onto the stack. That gives great flexibility, but also the possibility of creating total havok!

The PIC(axe) is different, because it has a small dedicated RAM used only for the stack (return adresses). I was quite surprised that with a "raw" PIC it is possible to read the stack pointer as a "Special Function Register" (it's in "Bank 31"). However, there are two major issues: Firstly, the PICAXE's PEEKSFR command does not give access to Bank 31 (only selected registers in banks 0 - 7 or 15). But also, I suspect that PICAXE BASIC doesn't actually use the base PIC's hardware stack for return addresses anyway, but emulates it in another area of RAM. That might (partly) explain why a PIC "return" takes 2 us (@4MHz) whilst a PICaxe Basic "return" takes ~2,300 us. ;)

But AFAIK calibadc{10} should be usable on a 28X2, however you might need to check the exact reference voltage setup. And yes, CALL is identical to GOSUB (I prefer the former).

Cheers, Alan.
 
Last edited:

Robin Lovelock

Senior Member
Thanks Alan and Eggd. I guess what is not yet clear to me, is if I need to provide a reference voltage of some kind, to use Calibadc10 ?
If this is needed, I can imagine it might be provided by a low voltage zenar, on some pin, well below the lowest supply voltage. e.g. ~ 1v to 2v.
Or is there some simpler way ? It would certainly be useful, to know when supply voltage is running low. e.g. below 3.8v.

Right now, and not yet reported in Blog or BlogX, I have two systems running in the house: Boat10, checking out the replaced battery (in the Blog) and - relevant to this - the "tea-tray" autopilot, running at ~ 3.7v, near the threshold for the picaxe, which means it often restarts. This is partly due to use of the servo causing voltage reduction as it draws current. The battery is obviously slowly going flat, so in the morning, I will see if the autopilot has "frozen". Sadly, I expect it will not. i.e. raising the voltage will restart it. But if it has frozen, I've recreated the problem, so there is scope to diagnose and fix it.

Robin
www.gpss.co.uk
 

premelec

Senior Member
Not sure if you've got what you need - FVRSETUP can give you an internal voltage ref which will be applied to READADC commands... this makes the READADC independent of the power supply voltage and therefore can read battery voltage. good luck with it all...
 

srnet

Senior Member
running at ~ 3.7v, near the threshold for the picaxe, which means it often restarts. This is partly due to use of the servo causing voltage reduction as it draws current
3.7V is a long way above the threshold for the X2, they will run quite happily down to around 2V, although other stuff may well stop working long before that.

So if your getting restarts, it unlikely to be caused just by the PICAXE supply volts going below 3.7V..........................
 

eggdweather

Senior Member
Thanks Alan and Eggd. I guess what is not yet clear to me, is if I need to provide a reference voltage of some kind, to use Calibadc10 ?
If this is needed, I can imagine it might be provided by a low voltage zenar, on some pin, well below the lowest supply voltage. e.g. ~ 1v to 2v.
Or is there some simpler way ? It would certainly be useful, to know when supply voltage is running low. e.g. below 3.8v.

Right now, and not yet reported in Blog or BlogX, I have two systems running in the house: Boat10, checking out the replaced battery (in the Blog) and - relevant to this - the "tea-tray" autopilot, running at ~ 3.7v, near the threshold for the picaxe, which means it often restarts. This is partly due to use of the servo causing voltage reduction as it draws current. The battery is obviously slowly going flat, so in the morning, I will see if the autopilot has "frozen". Sadly, I expect it will not. i.e. raising the voltage will restart it. But if it has frozen, I've recreated the problem, so there is scope to diagnose and fix it.

Robin
www.gpss.co.uk
No need for an external reference, there is an internal one, thus:
0.6V for parts 20M, 28X1, 40X1
1.2V for parts 28X2-3V, 28X2-3V
1.024V for all other parts that support this command, but note this command is not available on 28X2-5V/40X2-5V, I think you have the 3volt variant.
On my picaxe 18M2 it reads the picaxe supply voltage very accurately after I calibrated in software against my a Fluke DVM and if I turn the PSU up and down it tracks it near perfectly, it certainly makes this a very versatile chip for battery powered devices and being able to shutdown and store values before power fails, or switch power sources or WHY.

You could include a series diode in the feed to the picaxe with a storage capacitor such that the diode prevents large picaxe supply perturbations, when the servo pulls the main supply down the picaxe supply is isolated by the diode being switched off.
 

Flenser

Senior Member
what is not yet clear to me, is if I need to provide a reference voltage of some kind, to use Calibadc10 ?
Robin,

The PIC has an internal reference and this is what you would normally configure the ADC to use as its reference voltage when measuring an external voltage.

Some microcontollers also allow you to use the microcontroller supply voltage (Vpsu in the doco) as the reference for you ADC and measure the voltage of the internal reference. This is what eggdweather is suggeesting.

The reference voltage is fixed so the raw value Vref*1023/Vpsu returned by calibadc10 will increase as Vsupply drops.

Check the calibadc/calibadc10 command in the basic manual. This is where eggdweather and I have gotten our info from.
 

Robin Lovelock

Senior Member
Thanks Chaps. I'm keeping my Blog and BlogX updated, and now that I replaced one 5v battery, in the duplicated 5v supply, the Boat is back on Bray Lake doing 24/7 testing. I've not yet recreated that "frozen autopilot" problem, and - since it probably only occurs at very low voltages, under special circumstances - this should happen even less frequently, as our days become longer here in UK. But I will certainly look into some of these things in the later 28X2 version of the autopilot. I had considered adding a big capacitor, across the picaxe, after the two dodes that combine the duplicated 5v supplies (batteries and solar panels). However, I'm not sure what the MTBF of the capacitor would be (against risk of short). As I think is obvious, we are looking for MTBF of components to be in years rather than months, to give a system MTBF consistent with a fighting chance of survival at sea for 6 months ! :)
 

srnet

Senior Member
Adding a capacitor may be the right thing to do, but only if you know what causes the original problem.

It really is essential when testing stuff like this (that need to be autonomous for long periods) to full understand how well the circuit and power supply is operating under all conditions. Either the test system needs telemetry to report back to the bank what is going on, or you need to add something like an openlog logger to record whats happening to the power supply, the servo, the GPS etc. Then if it fails you should have a reasonable idea as to what was hapepning when it went wrong.

If you think it malfunctions at circa 4V, then there is something amisss with the power supply, the X2 will keep working on a relativly noise free supply down to around 2V, so if is in fact failing then the power supply must have has significant issues.

One simple thing you can do, is at program start, add 1 to a reset count and store it in EEPROM and print the running total to terminal. Then when you get the boat back you can start it up and see on the terminal what the current reset count is, if its increasing significantly, then you have problems that need to be investigated.
 

Robin Lovelock

Senior Member
Thanks Stuart (SRNET): all good advice, and similar to that from my local Picaxe expert, who pointed out the similarities in requirement, of reliability, on your own 50$SAT project, well published on the Picaxe pages. If I could focus on just the Picaxe part of Snoopy's robot boat, more time might be put on this important question of making sure the autopilot ALWAYS recovers from a low power condition. It will certainly take priority in my experimental work on the next 28X2 GPS-Only autopilot.

I obviously have to spend time on much wider practical issues, including the solar power system itself, and other things that can break including on/off switches, corroded wires, and servo linkages. Hopefully that foam inside will stop further sinkings :) I guess you would have the same problem as me if you had to widen your efforts beyond the Picaxe based subsystem, to the remainder of the satellite, or even the Dnepr launcher - I remember, back in 1971, my NATO workmates would have referred to that Russian ICBM as "SS-18 Satan". I doubt if the guys who I played darts against, at ESTEC in Noordwijk, Holland, would be of much use now :)

I love your page that I found on https://ukamsat.files.wordpress.com/2014/07/50-dollar-sat-pocketqube.pdf with those pictures, including your "cleanroom" - and in particular, your philosophy that "you can't add simple" - not unlike KISS on my "Design" page, credited to that American military aircraft designer :)

This posting may have been a bit of a diversion, but it's always nice to know with whom one is chatting: I'm gussing you are the guy wearing glasses and ebola kit in those piccys ?

Robin
www.gpss.co.uk/autop.htm

p.s. I've just added this to both Blog and BlogX on www.gpss.co.uk/rbblogx.htm :

DIAGNOSIS OF "FROZEN AUTOPILOT" PROBLEM ? It was only today, and after repeated failure to re-create that "frozen autopilot", reported in this Blog last Friday and Sunday, that I woke up to the likely cause of the problem: poor GPS reception due to the situation of the boat: leaning over, and in a position where GPS signals could be screened. Last Friday's blog entry mentions those large ~90m SPOT GPS errors, with the boat near the drain. Look at that picture from Friday, with the boat leaning over, beached. I've just put up that picture from yesterday, on the right, showing where the boat was when I found it, after the rescue. If, on either occasion, I had simply lifted the boat into a better position for GPS reception, and waited a minute or two, that autopilot would probably have started moving the rudder again !
 
Last edited:

Robin Lovelock

Senior Member
Hi Folks. Just a message to say that Snoopy is now over 7 days into his latest attempt, and is currently nearer France than UK , on his path along the Channel.
Robin
www.gpss.co.uk - just follow the links to see where Snoopy is now.
 

rq3

Senior Member
Hi Folks. Just a message to say that Snoopy is now over 7 days into his latest attempt, and is currently nearer France than UK , on his path along the Channel.
Robin
www.gpss.co.uk - just follow the links to see where Snoopy is now.
GO SNOOPY!!! Robin, you have the patience of a saint. Just think where the world would be if the 36 billion man hours spent every year on social networking were spent on solving real problems. My hat is off to you! I can envision self-steering, un-manned, cargo ships crossing the major oceans in my lifetime.
 

ZOR

Senior Member
Very dodgy thing to do - puting up email addresses. You should break it up into a line of text that does not look like an email address. Maybe someone or you can change it to prevent robots crawling over it. People could send you private messages on the forum
 

MartinM57

Moderator
Robin doesn't seem to mind a bit of self-publicity now and again, and if you Google for the email address you will find it in many places on the Internet - no moderator edit justifiable.

Martin
 

ZOR

Senior Member
Hi Martin, just found all the information you were saying, thanks. Certainly an interesting challenge he has with snoopy and is all well documented and he deserves to achieve his goal.
 

Robin Lovelock

Senior Member
Hi Martin, just found all the information you were saying, thanks. Certainly an interesting challenge he has with snoopy and is all well documented and he deserves to achieve his goal.
Hi Folks. Another long gap since I last looked at this forum. I'll repeat that stuff earlier: latest news about Snoopy on www.gpss.co.uk/autop.htm with him sat ready for this year's attempt here. Also the recent arrival of a toy boat from USA without an autopilot - just the tracker. I'll also repeat that email address of robin@gpss.co.uk - and add a bit more on that subject. Very wise being cautious about the Net: I knew about GPS and the Internet (Arpanet) when they were secret and I worked as a NATO scientist in the 1970s. All my details, including email address have been public for over 20 years on my www.gpss.co.uk contact page, and I get little more spam than the rest of us. It does not take long to check spam folders for stuff that is mistaken for it. I don't use online banking, the cloud(s), and assume our emails may get parsed for anything useful. But no need to be paranoid about it: I usually don't worry about who is sat near us, when swapping yarns in the pub about our earlier defence career - so long as we are not putting lives at risk :) You will find a lot about me on my web sites that may surprise you: send me an email direct, with your nearest town and country, what interests you, and I'll send you some links on my site: or - if you have the stamina - you might browse and find what interests you anyway :)
Take Care All - Best Wishes from Robin and Snoopy :)
Robin
www.gpss.co.uk and www.gpshobby.info and www.nhscare.info
 
Last edited:

Robin Lovelock

Senior Member
Picaxe Autopilots for Snoopy's Robot Boats and the MicroMite

Does anyone have experience with the MicroMite ? Please see my www.gpss.co.uk/micromit.htm
This looks like a good product, with scope for collaboration between Revolution Education (the Picaxe Guys)
and guys like Phil who sells MicroMite bits in the UK. Here is an extract from an email to Phil and Roy:
.... The door is still open for Phil, or anyone, to supply a 28 pin chip based solution, on a suitable board,
with flying leads so I can easily add those specified devices. I'll then follow on from Roy's good work on software testing....
Ideally, since soldering might be a problem (I note the health warnings), flying leads might be useful, and information like any 1K Rs needed for 5v protection.
Requirements are the same as in www.gpss.co.uk/micromit.htm ( now has counters at bottom ),
with it needing to take serial data at 4800 from the 5v BR355-S2 GPS, I2C with a CMP11 Compass, drive TTS as serial text out, and drive a 5v servo.
Power input would be 5v, but it looks as if that could be via that USB connector.
Unlike some people, I don't enjoy spending many hours building model boats or soldering, or even writing software.
I prefer to spend my time testing, and doing other things: www.gpss.co.uk/bigpic.htm :)
Robin
www.gpss.co.uk - my "Home" page - see bold text near top about me.
www.gpss.co.uk/autop.htm - the prominently linked "Snoopy" page, about my Robot Boat hobby.
www.gpss.co.uk/rbblogx.htm - my "BlogX" page, with history of experimental work, with menition of the MicroMite near the end.
www.gpss.co.uk/micromit.htm - my new "Micromite" page - yes, only first 8 characters :)
 
Top