« first  « prev 

Jump to:


Klog Software and User Interface

1. Software in a Klog



Figure 1 shows how the various software components interact within the Klog. Each component is explained in more detail below.

Software interaction within the Klog
Figure 1: Software interaction within the Klog


1.1. gpsd



gpsd is a third party application which reads NMEA data from a GPS unit, via a serial port, and makes that data available to any number of client applications via TCP/IP connections. This means that more than one application can monitor GPS information without any contention over serial port access. gpsd has been integrated into the Gumstix buildroot, so it's very easy to install.

1.2. gpslogger



The GPS logging application is one of two main applications written as part of this project. The logger connects to gpsd, using the handy gpsd C libraries, and stores position data to an SQLite database. The logger is also responsible for updating the system clock using time information from the GPS module.

1.3. SQLite 3 Database



SQLite is a very nice relational database engine for embedded platforms which provides many of the most important features of a fully fledged database management system with only a fraction of the overhead. Connections to an SQLite database can only be made from the local machine (i.e. no network protocol exists). This is fine for the Klog project, where the key features I'm looking for are safe concurrent access and simple sorting and searching of data.

The gpslogger application connects to the database file and stores data on position, heading, speed and satellite usage. This data is then read by various output applications for translation to KML and suchlike. SQLite provides a mechanism for safe concurrent access for these programs.

1.4. CGI Applications



Data is output from the Klog via a USB network and embedded boa webserver. A simple CGI program have been developed to translate database data to KML. The CGI also partitions the data into ten minute long "chunks" to make it easier to browse in Google Earth (see below).

1.5. Watchdog



The PXA255 processor used in the Gumstix has a built in watchdog timer which forces a hard reset should the operating system crash. A simple linux driver exists which exposes the watchdog functionality to userspace programs. Once the module is installed the /dev/watchdog file must be written to at least once a minute. If nothing is written to /dev/watchdog then the Gumstix will reset.

I wrote a very simple shell script to "tickle" the watchdog every 30 seconds, provided the gpslogger application is still running. So if the gpslogger crashes the Klog will reset and hopefully everything will run OK after it boots up again.

#!/bin/sh

while [ 1 ]
do
  if [ -d /proc/`cat /var/run/gpslogger.pid` ]
  then
    echo
  else
    exit
  fi

  sleep 30
done


1.6. LED Driver



Since the Klog is a passive logging device in a black box, I thought it'd be handy to have some indication that everything is working, that nothing's crashed and that the batteries don't need changing.

To provide a limited amount of feedback I attached a three colour LED to three of the Gumstix's GPIO lines and wrote a very simple device driver. The LED flashes in various colours every second or so.

In future I'd like to extend the device driver to encode system information, so a green flash implies power is present, a red flash implies that the GPS unit has a fix, a blue flash implies that the USB cable is connected and so on.

2. Google Earth and KML



KML is an XML format which is used for presenting data in Google Earth. GE supports two types of KML, standard KML which is text based and KMZ which is simply zipped KML. The following code snippet shows a very simple KML file with one folder named "Chequers Walk", containing two placemarks. The first placemark is a simple "pin in the map" and the second contains route data recorded using the Klog. Click here to view this KML file in Google Earth.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.0">
<Folder>
  <name>Chequers Walk</name>

  <Placemark>
    <name>Chequers</name>
    <description>The PM&apos;s House</description>
    <LookAt>
      <longitude>-0.7816837753264748</longitude>
      <latitude>51.74451081245437</latitude>
      <range>1300</range>
      <tilt>45</tilt>
      <heading>0</heading>
    </LookAt>
    <Point>
      <coordinates>-0.782170516814631,51.74329567582883,0</coordinates>
    </Point>
  </Placemark>

  <Placemark>
    <name>Route</name>
    <description>Our route</description>
    <LookAt>
      <longitude>-0.7821428775787354</longitude>
      <latitude>51.74325364082546</latitude>
      <range>3000</range>
      <tilt>45</tilt>
      <heading>0</heading>
    </LookAt>
    <Style>
      <LineStyle>
        <color>ff00ffff</color>
        <width>2</width>
      </LineStyle>
      <PolyStyle>
        <color>7f00ff00</color>
      </PolyStyle>
    </Style>
    <LineString>
      <altitudeMode>clampedToGround</altitudeMode>
      <coordinates>
-0.7898370000000001,51.75267300000001,0

...snip...

-0.8204900000000001,51.44644200000001,0
      </coordinates>
    </LineString>
  </Placemark>

</Folder>
</kml>


KML is an open standard, details of which can be found here. So it's very simple to create applications which output KML which can be displayed in Google Earth.

A CGI application on the Klog reads route data from the sqlite database and outputs it as KML, chopping the route into ten minute sections which are organised into daily and hourly folders. A network link to the CGI can be set up in Google Earth, so each time the Klog is plugged into a computer the route data is automatically updated.

It's possible to do all kinds of interesting things with KML. One that I like quite a lot is to plot the route as a wall, using speed to determine the height of the wall. Figure 2 shows the results (a full size screenshot can be seen here).

Route data plotted as a wall, where height is proportional to speed
Figure 2: Route data plotted as a wall, where height is proportional to speed


On the walk we won't have access to a fast internet connection so it's lucky that Google Earth is able to function without access to the net. By setting the maximum size of GE's cache to 2Gb it's possible to save a heck of a lot of data for use offline. The only annoying thing is that you need to know where you're going, so you can scroll round the area at various zoom levels before you set off.

3. Google Maps and Javascript



Google Maps is another mapping application from Google. The API for Google maps is free, so it's another handy tool for displaying route information, especially on a webpage.

Google Earth and KML were not developed from scratch by Google, it was first developed by another company who were bought by Google. The upshot of this is that Google Maps does not support KML. This is incredibly annoying and lead to many hard days of Javascript work to read KML files and display them on Google Maps. I managed it in the end though; figure 3 (a full size version of which can be found here) shows my route to Green Park on my bike.

Klog route data displayed using Google Maps
Figure 3: Klog route data displayed using Google Maps


Output in Google Maps isn't as impressive looking as output in Google earth, but it does allow better integration into websites, so I'll be extending my Google Maps code to link pictures, sound recordings and video from the walk to a map on this website. Of course, I can't do that until the walk's over, so I can't say much more about it in this article.

4. GPSD Client



Since GPSD allows multiple connections via TCP/IP I thought it'd be fun to write a windows application to display live GPS data via the USB network. While we drive to Cornwall in the minibus it might be fun to watch the movements of the satellites overhead and our changes in heading, speed and altitude as they happen.

The application is written in Delphi. I've used Delphi professionally for many years, so I'm able use it to create Windows applications very quickly, especially where there's lots of graphical output to do. At the moment I'm trying to get a grip of C# and Visual Studio, so were I to start the project again today I might not have used Delphi.

Anyway, figure 4 (click here for full size version) shows the GPSD Client GUI. Note the cool heading and satellite display components (written as part of this project) which spin as heading changes and the speedometer and altitude graph. There's also a simple map of the UK, which uses the Proj library and vmap0 data.

Windows GPSD Client shows heading, speed, position and active satellites
Figure 4: Windows GPSD Client shows heading, speed, position and active satellites


There are a few more bugs to fix and features to add to the GPSD client. When those are done I'll hopefully be able to release it here for others to have a play with.

5. The End?



Less than two weeks to go before the walk now. Hopefully the Klog will cope with eight days of field testing. Once the walk is over I'm sure there'll be loads of features I'll want to add to the Klog. Hopefully I'll also have time to finish my work with the jogwheel and LCD screen.

One things for sure, I'll be putting all the data I record on the website and writing about the experiences I have on the forums.

More details of my adventures with the Gumstix can be found in the Gumstix Snippets section of the forums.

« first  « prev 

Jump to: