GPS navigation with Javelin
Paul Ring
Posts: 16
I started this project some time ago as a test project - I wanted to see how far I could go with the Javelin. What I wanted to do was to build some kind of GPS navigation device for my sailing boat. I was either thinking of purchasing a GPS or building my own. So, since I had a Javelin microcontroller from an earlier project – I decided to give it a try a see if I could do what I wanted to.
I started in January 2006 with planning and finding components. You can find all the components I used in the GPS.zip. The project was ready by the end of May 2006 just before the sailing season started. Check out the pictures GPS_pictures.zip. During the summer I had great use of the GPS device. I had no crashes and everything worked just fine - but I feared the oposite because of the memory problems I runned into during this project. Check out the memory_problems1.gif. When the project was ready there were only around 200 bytes of free memory in the Javelin RAM.
Much of the help classes used in this project can be reused in other projects. The “NMEA0183” class can be used in other GPS projects and there are bunches of other code snippets to use for your own projects.
For the math calculations and navigation formulas I used the code embedded into the “xls” (Microsoft Excel) file found at this address: williams.best.vwh.net/. The code has been implemented into the “GPSMath” class. Unfortunately, the uFPU I used (check the Components&Costs.xls) can only do Float32 operation which is not accurate enough in order to calculated cross track distances – but accurate enough to calculate distances between waypoints and bearings.
You'll need Microsoft Visio to see the hardware diagram. Check out GPS.vsd file.
If you don't have Vision, open the GPS.pdf file.
If you have any questions about this please let me know.
/Paul
Post Edited (Paul Edfeldt) : 11/6/2006 12:44:20 PM GMT
I started in January 2006 with planning and finding components. You can find all the components I used in the GPS.zip. The project was ready by the end of May 2006 just before the sailing season started. Check out the pictures GPS_pictures.zip. During the summer I had great use of the GPS device. I had no crashes and everything worked just fine - but I feared the oposite because of the memory problems I runned into during this project. Check out the memory_problems1.gif. When the project was ready there were only around 200 bytes of free memory in the Javelin RAM.
Much of the help classes used in this project can be reused in other projects. The “NMEA0183” class can be used in other GPS projects and there are bunches of other code snippets to use for your own projects.
For the math calculations and navigation formulas I used the code embedded into the “xls” (Microsoft Excel) file found at this address: williams.best.vwh.net/. The code has been implemented into the “GPSMath” class. Unfortunately, the uFPU I used (check the Components&Costs.xls) can only do Float32 operation which is not accurate enough in order to calculated cross track distances – but accurate enough to calculate distances between waypoints and bearings.
You'll need Microsoft Visio to see the hardware diagram. Check out GPS.vsd file.
If you don't have Vision, open the GPS.pdf file.
If you have any questions about this please let me know.
/Paul
Post Edited (Paul Edfeldt) : 11/6/2006 12:44:20 PM GMT
zip
242K
525 x 1137 - 32K
Comments
Could you convert the visio file into a pdf?
One free utility to do that is pdf995 from www.pdf995.com
When you print your schematic from within visio, select the pdf995 printer
and it generates a pdf.
regards peter
I converted the file into a pdf file.
Regards
/Paul
You said float32 is not accurate enough to calculate cross track distances.
Float32 range is about +-10^38 to +-10^-38, which seems enough
to represent any distance. What units do cross tracks use that makes
Float32 inaccurate to calculate those cross track distances?
Or is it the required time (or memory use) to calculate these, that makes it unusable?
regards peter
I used PrimoPDF.
The accuracy I was refering to was accuracy for doing trigonometric calculations. Asin, Acos, Atan functions for very small angles are not accurate enough to calculate cross tracking distances. For example Asin(X) for small X-angles yields the same value X. The cross-tracking distance is how far from the bearing/course line you are sideways so to speak. I had a discussion about this with a developer at Micromega (which developed the uFPU) and he said that they are "aware" of this problem and that there is no solution for this right now. I was asking if they're not planning in a v3 or the uFPU which will support double accuracy floating point but they said not at this time.
The accuracy of the GPS math calculations (otherwise speaking) is around 2 meters which is more than enough.
Regards
/Paul
remember sin(x)/x for x reaches near zero, becomes 1
so sin(x) = x for very small x
and so arcsin(x) = arcsin(sin(x)) = x
This·relation is only valid when using radians for x.
So I really don't see how Float32 is inaccurate enough,
unless they perform calculations in degrees, then rounding
might turn sin(x) = 0 where x is still > 0.
The real question is what units (mm?, 0.001mm??) you want
to use for cross track distances (certainly not 10^-38 m units),
and what resolution you use for angles.
sin(0.001) = 0.0010000001666667416667113095541915
Float32 has about 7 decimals
and so sin(0.001) = 0.0010000 using·1/1000 radian resolution.
regards peter
I agree with you - but I could not make it work. It's probably the method itself that requires double precision. I was debugging into his code (the guy with the xls form) and I was comparing the results of the Asin and Acos. The uFPU respoded with the same small X angle value while the results produced by the computer were yielding "correct" values. I spent a lot of time on this and could not make it work. Maybe you know how to go around accuracy problems with the "single float".
The funny thing is that if you imagine a straight line, say point A and B and you move from point B towards point A the distance calculations are yielding correct values until you reach ~2 meters. If you come more near point A than 2 meters you'll get an increased distance. And this while you're moving towards A. Funny, huh?
There are a lot of things that can be improved.
Regards
/Paul
Post Edited (Paul Edfeldt) : 11/5/2006 5:02:21 PM GMT