GPS Distance Tracking
I am looking to make a simple program that can track the distance that is traveled with the gps from Parallax. The project I am looking to complete is a program that can track your distance when the program is started. The functionality would mimic a car odometer. It would continue to track the distance traveled until a reset button is pressed and then the distance would be set back to zero. Does anyone know where to find where a code like this could be found or know if this is a realistic project? I am very new to the GPS sensor and hoping to get some insight into how to work with it. Thanks for the any help!
Comments
To clarify the requirement, you want to recieve GPS sentences, extract the position, and log all the positions?
OR do a delta from the previous position?
There could be a LOT of positions, so you can include a requirement for large memory storage, SD card is a simple solution for that.
Summary: Collect your requirements, and subdivide each requirement unti you have something you can code.
Do experiments with the chunks of code until you know what it is you want the code to accomplish.
THEN write the final code. (I'm a process guy, I say this stuff a lot).
I'm also a forth guy. If you want to do this interactively (fast and fun, with lots of immediate gratification) download propforth and install it on you prop board. The serial comms and SD support are included, all you have to do is follow the GPS datasheet, and the solution pretty much jumps out at you. (At lest it does for me and a couple other folks, your experience may chance during actual gameplay).
In any case, continue to post your evolution of requirements and code and we will try to help.
Please try it in forth, so I can use your code.
(59.0117,-117.5814)
(59.0117,-117.5815)
(59.0116,-117.5819)
(59.0119,-117.5822)
Then, you'll need to find the difference between each consecutive sets of numbers, and sum that distance into a result variable.
You'll need some sort of minimum distance before adding consecutive readings. Since the GPS readings are inaccurate if you add the distances between each reading you could end up logging a lot of movement while sitting still.
You also need to compute the great circle distance between the two readings you wish to log.
I was going to let him figure that out on his own
I doubt it really matters unless he is trying to compute distances from a small series of widely spaced points. If he takes the readings often enough it's a bit of a Riemann integral:
* filter for lat, log
* figure delta
* reject below minimum distance threshold due to GPS inaccuracy
* calculate great circle
* log way points
* calculate total distance
These are just the first pass. As you continue to examine the application, each of these gets further refined. Eventually, each requirement gets expressed as something thats obvious to enough to code and verify.
Of course, while you doing this, you are messing with actual code experiments, to see if you can code anything now, and see how it works out. So you end up working top down from the requirements and bottom up from the code experiments till you meet in the middle.
The other issues are testing and documentation.
Each thing you code, you want to determine yes or no, does it do what it needs to? You want to be able to test stuff when something changes, so you don't break stuff that was already working.
Documentation is usually neglected. If you do a bunch of work, then set it down for a week or a year, or give it to the new kid, will their be enough information to get back up to speed when a change is needed, or will this wheel need to be re-invented again? (Effectively doubling at minimum, the cost in your time). Most folks learn the hard way, if at all, that every minute spent on documentation is an hour saved in rework next year. Surely some folks will pipe in to contradict this, thus an example of the hard way in action.
Now that we started the analysis, this doesn't look so hard. Maybe I'll get off my butt and work on this too!
I guess my point is that you have to decide what "distance" is before you measure it. That said, however, there might be a very easy way to do what you want: just integrate the GPS ground speed data over time. If it works without accumulating too many errors, it will be easier than converting lat/long to distance.
-Phil
Propeller-Based-Handheld-GPS-with-Full-Code
http://forums.parallax.com/showthread.php?133806
GPS-Datalogger-Using-Google-Earth
http://forums.parallax.com/showthread.php?115552
GPS-Logging-Reporting
http://forums.parallax.com/showthread.php?133514
Google-Earth-GPS-SD-Card-Logger-COMPLETE!
http://forums.parallax.com/showthread.php?104049
Propeller-Based-Reverse-Geo-Cache-Birthday-Present-Project
http://forums.parallax.com/showthread.php?118830
@phil: very good point, it would be much easier to calculate distance from speed. You will have a slight margin of error still (since the GPS needs to be getting valid data to determine speed, causing a lag), but the code to get distance from the speed will be much easier to dial in. Great circle math and the propeller can be a bear.
That sounds funny at first! But brings to light another possible requirement, and function to code.
So now you have two choices to track, Lat/Long Delta, or speed over time. Both are valid, and suitable for different purposes, I would suggest including both. How cool would that be! Then you can have the general "waypoints path" distance, and compare it to the speed over time distance,and it might tell you something interesting.
I'd think there would be times the speed approach wouldn't work well. I started work on a GPS pedometer but I stopped work on it (for now) since the OLED display I was using with it died.
My plan was to compute distances between turns in the route. Since I wanted to log evening walks with my wife through our neighborhood, I thought the way to keep most of the errors out would be to measure the distance between each turn (most would be 90 degrees) of our walk.
I doubt we walk fast enough to use the speed approach to distance measurement.
The functionality of the odometer in a car is the best example I can come up with. Press restart to begin measuring from a start point, and then measure the distance traveled from the point while displaying it and then go back to zero when the reset button has been pressed.
-Phil