There are plenty of projects out there that deal with GPS and microcontrollers, many of which make use of the data for such things as navigation. The RoboMagellan competition is one such application. But what if you wanted to visualize the path your robot took through such a course? Better yet, what if you wanted to log the path of a bike or car trip? You can with this project and Google™ Earth.
Plotting a Course
Google Earth is a virtual globe program that can show you, at a continent, state, city or even street level, various locations on the planet, including satellite images. You can follow streets as well as see popular locations.
From within Google Earth, I can see my house, including the garden in the back yard. I can even see a close-up of Parallax, Inc. One interesting thing about Google Earth is it is available free and supports Keyhole Markup Language (KML) which is an XML-based language for expressing geographic annotation, maps and even 3D objects. One feature of KML is the ability to plot a path using GPS coordinates. So if you have a source of coordinates, such as a GPS module, you can create a KML file with a little help from a BASIC Stamp® microcontroller module and a Parallax Memory Stick Datalogger.
Data Portability
On a PC with Google Earth installed you need only double-click a KML file and Google Earth will launch and plot the data. The trick is getting the data from your mobile GPS system into the PC in the correct format. Parallax manufactures a Memory Stick Datalogger, which is essentially a USB host bridge using the Vinculum chip from FTDI. The Memory Stick Datalogger allows you to use a portable storage device such as a USB thumb drive to store the GPS data. Since the FAT file system is supported, you can save the file in the native format and it will be directly readable by the PC and Google Earth. Since KML is an XML-based language there are a lot of tags similar to those used in HTML. For now we’ll simplify things by saying that the important parts of the file we are creating are pretty much always going to be the same.
Decoding KML
Google has an extensive specification for KML at http://earth.google.com so I won’t go into all the details. The language is very powerful and warrants a look if you’re interested in creating files for Google Earth. For our purposes we will only want to create paths. In order to do this we will need three pieces of information. First we will need what I call the header information. This is essentially all the information Google Earth will need to know, such as the version of the language, source URL, line types and colors, mode, etc.
Next we need the coordinates themselves. Oddly Google Earth expects the data as Longitude, Latitude then Altitude. Conversely, http://maps.google.com uses Latitude then Longitude. In any event this will be the part of the data we will be supplying as we go. Finally the file will need the closing tags, or what I call the footer data. The trick now is to get a BASIC Stamp to put all this data onto a USB thumb drive in a format so it can be read by a PC using Google Earth.
BASIC Approach to KML
The BASIC Stamp module has 2K of EEPROM available for program and data. I originally tested the concept of doing this by hard-coding the data into SEROUT statements. However, this left no room for making the program do anything other than writing the data straight from the GPS Module. I decided to create a data table in EEPROM of all the header data used to create the KML file. In order to do this, quotation marks had to be coded into ASCII values since quotes are used to enclose text used by the KML file. To trim a few more bytes instead of using a CRLF for each line I used a single null (zero) byte and had the program replace that whenever encountered. I also needed to be able to change the altitude mode easily. I tried several methods but ultimately decided to hard code the text section of that one command based on a mode constant being 0 or 1. Since this creates a break in the header block I used the value 255 to separate blocks of KML code. When the subroutines read the 255 they terminate and return so the program can write out the next block of data to the Datalogger.
The program is very straightforward and includes many pieces of code from other programs I have written for the various hardware used. The Parallax Memory Stick Datalogger and Parallax GPS Modules are used so the first thing that happens is the program initializes and establishes communication with the Datalogger. A bi-color LED is used to indicate status and blinks green while the Datalogger is initialized. If no USB drive is connected the program will wait until it is connected before moving on. Once the Datalogger is initialized and the drive is identified the program will write out the KML header data. This will take several seconds since it is being read byte-by-byte from EEPROM and written out to the drive. While this is happening the LED will be fast-blinking red.
Once the data is written the program will attempt to get the satellite signal status from the GPS module to see if the signal is valid. During this the LED will slow-blink red. Once the satellite signal is valid the LED will turn solid green to indicate that the system is ready to start logging data. There are two pushbuttons on the GPS Datalogger Board. Pressing the first one until the LED turns red will start the logging process. The GPS Datalogger writes data to the USB drive at a fixed rate of about 1 sample every 3 seconds. If the GPS signal is lost during logging, the last coordinates are written at the same rate. This makes it possible to estimate how long the data was accumulated, even during times when the signal is not valid.
At any time once the USB drive has been initialized you can hold down the second button until the LED starts blinking red. This will write out the KML footer data and close the file. When it is safe to remove the USB drive the LED will blink red/green alternately. It is not advisable to remove it at any point before this since corruption of the data or even the file system is possible. This means you probably would have to reformat the USB drive.
I took a short drive around the vicinity of Parallax. A screenshot of the Google Earth plot of my journey is shown here. The KML file of this trip can be downloaded with the source code and is called LOGDATA.KML. You can load it into Google Earth for a look at my trip or you can open it using Notepad to see the structure of the KML data. Note that due to the margin of error in accuracy of GPS as well as differences in the Google Earth terrain map, at some points it looks like I was driving off the road or in the oncoming lane. Rest assured I was driving safely.
Building the GPS Datalogger
This is the schematic for the GPS Datalogger, but to simplify building the prototypes I used the Parallax Super Carrier Board. A complete parts list is attached below.
Here you can see that I have pre-drilled a mounting hole for the GPS Module and installed a 4-pin SIP socket. While not required, this is recommended. You will also need a ½” threaded standoff between the board and the GPS Module. A rubber foot from the Super Carrier Board was cut in half and used as a pad to hold up one end of the Memory Stick Datalogger so that there is extra support when inserting a USB drive into it.
This photo shows the remaining support components as well as the Memory Stick Datalogger module installed on the Super Carrier Board. At this point it is a good idea to run the test programs included in the source code package. I will often want to test individual subsystems of a project while building it to simplify debugging if there is an issue. There are programs for testing the GPS, Datalogger, LED and buttons. The GPSTest.bs2 file is a modified version of the GPS Demo program. The DataloggerTest.bs2 file is a modified version of the Datalogger Demo program and the ButtonLEDTest.bs2 program was quickly written for the purposes of testing those components. Downloading the ButtonLEDTest.bs2 program will blink the bi-color LED red 5 times, green 5 times, then alternate red/green 5 times. After that it will report whenever either of the buttons is pressed. You should run these programs to make sure all the hardware is functioning before moving on.
Final Assembly
This photo shows the completed assembly. If you plan on installing standoffs on the Super Carrier Board as I did, you will want to make sure you do this before securing the GPS Module as it will block one of the holes. Once everything is assembled you can download GPS Datalogger V1.0.bs2 and start logging data. The Super Carrier Board powers everything from its own 5 volt regulator, so for testing I used a cable which plugs into a cigarette lighter or auxiliary connector in a car and then powers the board. Placing the board up in the center of the dashboard nearest the window gave the best results and I never lost my signal. Be sure not to obstruct your view when placing the unit up near the window.
During the test I did have to grab the unit several times to keep it from flying one way or another, so my advice is if you’re going to test it like I did, get some Velcro® or temporarily tape it in place. The whole system consumes about 200 mA of current depending on the USB drive used. This causes the voltage regulator on the Super Carrier Board to become quite warm. Be careful of grabbing the board near the regulator. Another note about this is due to current consumption this unit cannot be powered from a 9 volt battery. You will need a high capacity power source, or if used in a car or motorcycle you can use the cigarette lighter or auxiliary connector and you should be okay. For a bicycle a generator may even be possible.
Final Thoughts
The code as included uses all but 6 bytes of the EEPROM space. One of the main reasons is my very verbose DEBUG statements, which are not needed and can be taken or commented out. Many people like to see some feedback when testing things for the first time and I was inclined to provide that although DEBUG statements (or anything with added text) use a lot of program memory.
Note that by default the data logged ignores elevation (altitude) data. If you wish to enable this you can change the mode constant toward the beginning of the program from 0 to 1. Be warned that GPS modules don’t always match the elevation maps used by Google Earth and this can sometimes cause your path to disappear under the terrain, making it invisible. This will cause breaks in the path. I also noted sometimes it looked like I was several meters above the ground (must be my flying car). You can also change the mode in the KML file directly by using notepad. If you change the word ‘clampToGround’ to ‘absolute’ and reload it into Google Earth it will now show altitude data. This data is shown as a line extruded from the virtual ground. Regardless of the mode the altitude data is always written to the data file. The mode just determines if it is displayed within Google Earth.
Two buttons were not required in this project, but I wanted to add some flexibility to the hardware for those I know are going to do more with this. A few possible applications would be tracking a child driver when borrowing the family car. The original design that I created used a BS2p and was installed in a vehicle with a P-Channel MOSFET to control power to the GPS and Datalogger. The BS2p module was powered from the battery power directly. When the ignition was turned on the system would create a new file (sequentially numbered) and start logging data. Once the ignition was turned off the system would write out the footer data, close the file and shut down the GPS and Datalogger. I chose to create a simpler version for this article to make it easier to see how this task could be accomplished and because several people had mentioned that the BASIC Stamp 2 would not have the resources to do this.
Currently time / date stamping is not supported, but in reviewing the KML specifications it seems it is available as an option to use that data and it is readily available from the GPS Module. This project was published in the September 2009 issue of Elektor Magazine.
Updates
At some point a change to Google Earth broke my V1.0 code, so I revised the code to V1.1 to correct the issue. The source code update is attached below.
Since this article was written Parallax has discontinued the GPS Module used as well as the Datalogger module. A standard GPS module will not work with this project. Google has announced deprecation of the Google Earth API. Based on this information I am considering a new more enhanced datalogger using different hardware. When that project is done I will link it from here.
GPS Datalogger by Chris Savage is licensed under a Creative Commons Attribution 3.0 Unported License.
Leave a Reply
You must be logged in to post a comment.