Pages: [1]   Go Down
Author Topic: GPS Navigation :: From -> To  (Read 1719 times)
0 Members and 1 Guest are viewing this topic.
0
Offline Offline
Newbie
*
Karma: 0
Posts: 36
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

hello folks
In my autonomous land vehicle project, I am looking to incorporating GPS navigation logic.

I have a Parallax GPS module where I have been able to extract Lat/Lon/Alt, Speed, Heading details.

I wanted to ask this group for suggestions on navigation logic.  If I have the origin coords and destination coords, what would be a good logic to implement in getting the vehicle from A->B.

I read thru the thread here.  But, could not get any of the poster's links to work.
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1197693328

any recommendations, pointers, comments are highly appreciated.

thank you in advance
Logged

Phoenix, Arizona USA
Offline Offline
Faraday Member
**
Karma: 40
Posts: 5570
Where's the beer?
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I can't give you a real answer (because I don't honestly know; but I am interested in good answers too), but I do know that if points A & B are far enough apart, you will have to start taking the curvature of the earth into account in order to get accurate positioning. I am not sure what that amount would be, but I would suspect greater than 1-2 km...

[edit]Here's a possible start:

http://stackoverflow.com/questions/365826/calculate-distance-between-2-gps-coordinates[/edit]

[edit]This might also help:

http://en.wikipedia.org/wiki/Geographical_distance[/edit]

[edit]Another interesting discussion:

http://mathforum.org/library/drmath/view/55417.html[/edit]
« Last Edit: May 05, 2010, 11:39:58 am by keeper63@cox.net » Logged

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

Offline Offline
Edison Member
*
Karma: 3
Posts: 1001
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I've developed and debugged code for autonomous GPS navigation, but I'm not sure that sharing the code will do you much good. To get some ideas on developing code you may want to consider the following:

- Given GPS coordinates for A and B where A is your starting position and B is your desired position

- Calculate direction from A to B

Then repeat the following in a loop:

- Get current position from GPS
- Calculate direction from previous GPS position to current (this is your direction of travel)
- Calculate the angle difference between desired course line and current course
- Use the angle difference to determine if you need to turn vehicle left or right
- Then drive on and repeat above steps until you reach target

There is of course much more to this to get smooth steering control (using some sort of PID algorithm, adding a Z-gyro and calculating distance from initial course line will help a lot), but I think you're better off getting the basics down first. See your vehicle deviate from the course line and actually compensate to move towards the course line is sign of good progress.

The math for doing above is somewhat involved and an additional challenge is only having floats (less precision) to work with. A good source for formulaes you need can be found here:

http://williams.best.vwh.net/avform.htm
Logged

Phoenix, Arizona USA
Offline Offline
Faraday Member
**
Karma: 40
Posts: 5570
Where's the beer?
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
The math for doing above is somewhat involved and an additional challenge is only having floats (less precision) to work with.

Understatement of the year?

 smiley

Could you get away with using long variables and fixed point math to gain more precision (and possibly speed in calculations), or would that be more trouble than its worth? What other suggestions do you might have to increase the precision?

Does anyone make a floating point co-processor for microcontrollers? I seem to recall one for the Basic Stamp (but that could've been a dream, too)...

 smiley
Logged

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

0
Offline Offline
Newbie
*
Karma: 0
Posts: 36
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

thank you cr0sh and BenF.  Appreciate the great links.  As I read thru these, I can tell, I will be spending a lot of time in digesting what the authors have to say (let alone putting some code behind them ).

thank you - I will ping back on any hurdles (of my own) that I come across smiley

thank you
Logged

Ross-on-Wye (UK)
Offline Offline
Newbie
*
Karma: 0
Posts: 29
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Does anyone make a floating point co-processor for microcontrollers?

Floating Point Co-Processor uM-FPU v3.1 (~$20.00)
18-pin DIP, SOIC-18 or QFN-44 packages.
http://www.sparkfun.com/commerce/product_info.php?products_id=8129
http://www.sparkfun.com/commerce/product_info.php?products_id=8450

(Living up to their name).
Logged

Phoenix, Arizona USA
Offline Offline
Faraday Member
**
Karma: 40
Posts: 5570
Where's the beer?
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Floating Point Co-Processor uM-FPU v3.1 (~$20.00)

Glad to find out I wasn't crazy...

I wonder how well such a chip would work for 3D math (you know, for a KS0108-based LCD HMD, of course)?!

 ;D
Logged

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

Offline Offline
Edison Member
*
Karma: 3
Posts: 1001
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Could you get away with using long variables and fixed point math to gain more precision (and possibly speed in calculations
Floating point math is the preferred choice for these calculations.  Also, contrary to what many believes,  calculation speed is typically as fast or faster with floating point compared to long integers on the AtMega's we use in our Arduino's.

Fortunately a lot of the published algorithms on celestial navigation were written at a time when double precision was unheard of and the source I linked to above include some good implementation notes on this topic. A main design factor is to avoid converting intermediate results. Rather it makes sense to convert GPS coordinates to radians and use radians throughout (also for distance). There is no need to convert back to "meaningful" (metric/imperial/nautical) other than for display/print/presentation purposes.
Logged

Pages: [1]   Go Up
Jump to: