GPS, Palm Pilot, OpenGL ... Let's Go!
Pages: 1, 2
Building your own cables
For those who still love the sight of solder melting, the smell of flux in the (well-circulated) air, and the creative freedom of a roll of shielded twisted two-pair and the right ends, this section's for you. Dig out your soldering iron!
When soldering, why limit yourself to opposing thumbs? Steady hands are required to avoid cold-solder joins.
If you prefer your cables prebuilt, and pronounce solder the way it's spelled, I refer you to your GPS manufacturer. However, please be prepared for sticker-shock -- a GPS-to-PC cable can cost as much as 40% of the price of an inexpensive GPS receiver.
Besides cost, in many cases it may be desirable to have many different cables for one or more GPS units, each appropriate depending on location or use. GPS-to-PC adapter cables also do not "expose" the power supply pins on the DB9 connectors, so to supply power to the receiver for long-term use, a power and data adapter cable must be acquired. These are almost universally designed to plug into a cigarette lighter in a vehicle, however, so they aren't optimal for building installations.
Thus, simply for flexibility reasons, building a custom cable is often desirable if you have the skills to do so. Unfortunately, once you try to acquire the proper ends, or connectors, to mate with the GPS units, you quickly find that most GPS manufacturers use proprietary connectors.
Arg! Foiled by a little bit of plastic and metal!
Fortunately, in the case of the Garmin units, there's an answer! It turns out that one person who encountered this very problem also happened to have access to a plastic injection mold machine. Full details, including information on how to have a couple shipped out to you upon pledge of payment, are available at Larry's PPlug page
Long story short: There's a world-wide network of "Pfranc"s, who have implemented a "share-hardware" distribution network for these little connectors. Find your nearest Pfranc, fill out an order form including agreement to send some amount of money (or something in kind), and the connectors are on their way.
Once you receive them and agree they're to spec, you submit your pledge. Fill out the check while your iron comes up to temperature. Connectors for older (e.g., GPS 12) series have been available since 1996. The new interface type used for the eMap and eTrex series has just become available as well.
A compact adapter for a Palm mobile cable.
Beyond the difficulties of acquiring the correct connectors and getting documentation on which pins are what, the actual wiring is quite trivial. To connect to a computer's serial port, the GPS Data-Out (T) pin connects to a DB9 female connector's pin 2. The Data-In (R) goes to pin 3, and GPS Ground connects to pin 5. These pins correspond to RxD, TxD and GND, respectively, on the computer's serial port.
When wiring a cable to interface directly with a Palm Pilot's cradle or mobile PC connector cable, a DB9 male connector is used instead, and pins 2 and 3 are reversed. Another option is to place a null-modem adapter between the above wired PC GPS and the Pilot cables, but it obviously won't be as compact.
When building a cable to provide power to the GPS unit, extreme care must be taken to provide only the voltage level the GPS can handle. Different GPSs have very different requirements, ranging from +24 to +3.3 volts DC. Supplying the wrong voltage, or the correct voltage to the wrong pin, can result in a very fast and very expensive lesson.
Even when only building a data cable, serious damage can still result from incorrect wiring. If you're not comfortable performing this kind of work, ask a friend who is to help, or perhaps invest in a professionally built cable. Letting out the Magic Blue Smoke is bad karma.
Humm ... 3D data ... OpenGL!
When you start to think about data returned by a GPS receiver, you immediately realize that it's three dimensional. Thus, the display of GPS data will often be very well suited for implementation in OpenGL, letting the standard do most of the heavy lifting. It's not being lazy, it's being efficient!
GPS fixes include three values: longitude, latitude, and altitude. For simple cases covering relatively small areas (a few hundred kilometers), these can be mapped to X, Y, and Z and displayed. However, for more advanced cases where high precision is required, the lat, long, and altitude must be mapped onto a spheroid as defined by the map datum.
In order to keep our demonstration program as simple as possible, we're going to take the easy route and do the simple linear transform. This will be adequate for our purposes, but those who require greater precision are encouraged to investigate the WGS83 specification.
The program presented here builds upon previous examples in past articles. A familiarity with these, or OpenGL in general, is presumed.
GPS data plotter
It takes surprisingly little effort to get a meaningful plot of GPS data using OpenGL. Once an NMEA parser has been written, the rest of the work is primarily just record-keeping for all the data. OpenGL has an antialiased lines mode which results in nicely blended images.
First person point of view of a local road trip.
In our sample implementation,
main() does the usual call to
glutInit() and then calls a new function,
ourLoadFiles(). This is passed the
argv variables, which include the command-line arguments passed to our program.
ourLoadFiles() will attempt to load up to 10 files passed to it on the command line. Data is stored in instances of the Point structure, with bookkeeping information for each file in instances of the Points header structure.
After all the files have been loaded, a second pass is made through the data converting latitude, longitude and altitude into Y, X, and Z, while at the same time normalizing the points to be within +/- 1.0 horizontally and 0.0 to 0.5 vertically.
ourLoadNMEA() parser is a fairly simple affair, and is only interested in GPGGA messages. It itself leverages on
ourChecksumValid() to confirm the checksum of each message before attempting to parse, although, as it's a simple XOR checksum, errors can still slip by. The function keeps an eye out for messages with a datestamp of 999999, which is a non-standard flag we use to allow for
One thing to take note of is the extra effort made to extract the latitude and longitude values from each line. Standard versions of
sscanf() can't scan for doubles, floats being the best available. Unfortunately, float values introduce rounding errors when representing the numerical resolution provided in the NMEA format. This extraction is encoded in the
The other new feature of this program is the inclusion of some additional GLUT callbacks,
glutMotionFunc(). These are used to implement a more natural way of moving around in 3D space using the mouse. A quick call to
ourOGLInit() for some of our last-minute housekeeping (including generation of Display Lists for ground tracks for each file), and then we're into
What are we drawing?
On the path of a local road trip.
cbRenderScene() is where we draw our pretty pictures, based on any data we've already loaded plus any inputs acted upon by the other callback functions. The first thing this function does is enable or display line smoothing, depending on the current flag. Controlled with the 'A' key, antialiased lines result in beautiful images. This is off by default, but should be enabled if hardware support (or a fast CPU) is available.
The next thing is to act upon the "On Path" flag, toggled with the 'O' key. Using
gluLookAt() places the viewpoint either on the first file's path, looking at the current position, or at some independent "First Person" location. The path positions increment by some value each frame, which can be controlled with the "<" and ">" arrow keys. Thus, when on the path, it's as if you're replaying the trip.
In first person mode, on the other hand, your position remains the same during the playback of the first file's data. Pressing the left mouse button and dragging around the screen results in the view rotating around, but the position remaining the same. Dragging the middle mouse button changes the observational point's height, while dragging with the right button adjusts the position of the observer. The Page Up/Down buttons, and arrow keys, offer the same functionality.
Note that in first person mode, the motion commands are relative to the current orientation. Thus, simply adding some value to the observer's position when forward motion is requested doesn't work. Instead, a point-of-interest vector is maintained, which is both the direction we are looking as well as where we should move to in case of forward motion.
The OpenGL feature GL_LINE_STRIPS comes in handy. Used to draw successive, attached line segments, it allows us to send half as much data to OpenGL to draw our paths as we might otherwise have to. The GLUT library's stroked characters are also used to incorporate text directly into the 3D scene.
A plot of a stationary GPS receiver over several hours.
The GPS Plotter program accepts multiple files in order to allow past trips to be compared to the most recent, for example, or to include sets of tracks for reference. The first ground-track is color-coded based on the time stamp for each fix, varying from red to blue for the earliest to oldest fix. The green value is set based on the time stamp's seconds, so gives a clear indication of time frame and thus speed. Any other groundtracks are assigned a solid, preset color.
In addition to the usual applications of plotting positions during over-ground travel, plotting a stationary receiver's data stream over several hours or days can be informative, too, if a little discouraging. In fact, anyone who uses their GPS for anything serious would be well advised to collect several days worth of data, and to take the observed random wander into consideration.
If you have more than two GPS units, try collecting data from both of them at the same time, and feed them to this program. As we'll examine much more deeply in our next installment, two GPSs don't help improve things much.
This program is intended for developer experimentation and adoption. Because of the overly simple Lat/Long/Altitude to X/Y/Z transformation, it should not be used for serious navigation or distance calculation. For such work, commercial off-the-shelf (COTS) software is probably best.
On the other hand, for those wishing to experiment with GPS programming, it should be good enough to start. True WGS84 support could be added without too much effort, as could texture mapping of imported maps for current position on a chart type display where outline vectors are not adequate.
As GPS receivers start finding their way into PDAs, 3D plotting applications such as is demonstrated here will soon be possible in self-contained hand-helds. In fact, if you were to combine a GPS module and a Handspring or a clip-on GPS for a Palm, such functionality is technically possible now; there is a sub-set port of OpenGL available for the Palm OS.
Although, in reality, it's going to take something more powerful than a Palm to do meaningful OpenGL displays. Palms are OK for logging or simple processing, but 3D is really a bit beyond them. On the other hand, something like the iPAQ or Yopy would likely have little trouble generating a very interesting real-time display from a GPS stream.
On the bleeding edge, strange looks just mean you might be doing something right.
Real-time plotting is only one possible solution space when GPSs are considered, however. As receivers continue to shrink in size and cost, current position data will become available to a greater number of devices, and thus to their programmers. With background logging of data, or combining position data with other events, exciting possibilities arise.
PDAs will be able to report where, physically, each and every note, address or e-mail message was entered, and where they themselves have been for the last month. They may be programmed to demand a password if they ever find themselves outside of a pre-set geographical area, and to "phone home" if the challenge fails. And, of course, when you're hungry for sushi, they'll know where to go for the best tekka maki and ika.
Download Files for OpenGL GPS Datastream Plotter
airport.gps - GPS Track - Road trip to the airport.
It is already possible for vehicles to know where they are, and to give directions to particular destinations. Currently still quite expensive, mass production will result in such ability to be standard options on most cars by the middle, or, at the very latest, the end of the decade. For teen-agers, borrowing the family car will be far less like getting true freedom for a few hours than it current does -- wireless networking will allow constant monitoring of location and speed.
All this leads to the holy grail, of course: pervasive computing. At about the same time as everything is tiny, running code and chatting on wireless networks, everything should also know (approximately) where it is physically. The possibilities that result from this are only beginning to be explored and exploited.
So, as you get strange looks from people as you wander around with a GPS cabled to your PDA, both balanced in one hand, just remember the chant: "I'm living the future... I'm living the future..." Strange looks are nothing, especially if you come up with the next killer app.
Discuss this article in the O'Reilly Network Wireless Forum.
Return to the Wireless DevCenter.