FM.24.07 Lap Tracking System

Faster Mustache and FM.24.07

Faster Mustache is a progressive organization made up of a diverse group of Atlanta residents with one thing in common: riding bicycles. We believe in the power of cyclists to change our communities and our world through ongoing discussion, entertaining events, and positive action. Online and on the road, at work or at play, we challenge everyone to use a bike. It doesn't matter what type: fixed, free, geared, single, cruiser, chopper, racer, or clunker. No two bikes are the same and certainly no two riders are the same, but in the auto-centric city of Atlanta, we have fun sticking together. Simply put, we invite everyone to bike everywhere with us.

FM.24.07 is a 24 hour relay through the streets of Atlanta. Teams of 4-6 riders passed the baton through grueling traffic, up insane hills, and through dark alleys to complete laps for prizes. Faster Mustache, in conjunction with Johnny's Pizza and a host of sponsors, offered the most exciting weekend of urban cycling of the year and the chance to be crowned the king or queen of the streets! This was the third year that Faster Mustache has organized a 24 hour race and certainly won't be the last.

Why build a tracking system?

A 24 hour urban race is something out of the ordinary: 200+ people competing, a 14+ mile course through city streets, and 24 hours of racing!  This meant that some rider would pass any spot on the course once every few minutes for an entire day. Staffing checkpoints requires getting people to and from them and hopefully placing them where the volunteer has access to a bathroom and won't likely be bothered or distracted in any way. In the woods this isn't much of a problem (the woods is a bathroom, there are no people in the woods), but in the city it is a different beast.  Additionally, in a mountain bike race, there is typically one trail and no easy way to take shortcuts so simply checking riders at one or two places on the course works to make sure everyone is doing a full lap, but in the city it can be a bit more difficult.  We chose to go with 4 checkpoints and a suggested route between them. Knowing that some people would try to make a faster route given the number of options, we tried to make the suggested route the best that we could and simply required that people visit the checkpoints in order. The in order criteria was to keep things in the spirit of the race with the first part being fairly easy and the last part being the hardest part, with the middle segment requiring dealing with crowded and busy parts of Atlanta.  Because we required the checkpoints to be in order, we somehow needed to track this.

2005

In 2005,  the first year of FM.24,  we discussed many options but settled on a fairly unique tracking scheme. Around the course, unmarked newspaper boxes were distributed and locked. Each team was given a key that unlocked the boxes, and inside the boxes there were different colored spools of carnival tickets.  To complete a lap, a team had to visit each box and get one ticket.  At the end of their lap, the team name, rider name, and the unique number on each ticket was entered into a spreadsheet. In theory, we could make sure that tickets were retrieved in order and only once per lap, and that any inconsistencies could be worked out by hand after the race, but this had a few major problems:

2006

We learned a lot about tracking a race for our second try and took things into consideration.  In 2006, we again discussed many options and again settled on something pretty unique.  Each checkpoint was a very unique hole puncher permanently attached to a telephone pole at a major intersection.  Teams were given numbered cards for each lap that we recorded the number and color of, and they had to visit each checkpoint and punch a hole in their card. (We gave up on the in order requirement this year due to late planning of the tracking system.) At the end of a lap, a rider one again turned in their card for manual entry into a spreadsheet.  This worked a lot better than last year, but had it's own, smaller, set of issues:

We wanted to do 2007 right!

2005 and 2006 worked out fine, but there were a few trends of problems that we wanted to work around for the system for 2007:

These gave us a few possible ideas:

The 2007 Solution

So for 2007, we decided to go with a home grown RFID based solution. Each team would be given an RFID card which they would need to swipe/tap at each checkpoint.  The registration table would have a "start" and "finish" reader so that exact lap times could be appropriately recorded. This would require a network uplink from each checkpoint, as well as software for turning all these swipes into laps (after a lap, telling a race official your team name and name so that the lap could be associated with you, and a verify button), and the details of this follow. This method has a few extra benefits:


But comes with some very real things that could fail:

Lap Tracking System Design

Several components were required for this tracking system work work and each of them needed to be easy to use and reliable:

RFID and Swipe Reporting

None of the race organizers had any experience with RFID so we had to do a bit of research on this.  After considering varying active and passive solutions, as well as different types of cards, we chose a cost effective solution.

An open source, off the shelf hardware solution was chosen for two simple reasons: cost and ease of programming of the software interface.  The system chosen was the Phidgets USB RFID kit.  The system uses an industry standard EM4102 format.   The tags themselves are cheap (less than one US dollar each) and are read only (useful to prevent counterfeiting of tags).  Each tag has a unique 40 bit ID (64bit total EEPROM capacity).  No external power or signal conversion was needed for the readers as well due to the USB interface.  The only drawback to the hardware is the limitation of USB 2.0 cable length (currently 5 meters).

The RFID tag ID capturing software was written using C++ and the hardware driver provided by Phidgets.  Each tag is read singularly, multiple tag reads are not supported.  The SW interfaces the hardware.  When the tag comes with in reading distance the ID is read and written to a data file along with a UNIX timestamp, the checkpoint ID, and a status marker to be used by the batch upload script.  The data is written to the file in a colon delineated format to allow for easier processing.  The rider receives confirmation of the tag read via an LED lighting up.

The tag reads are then uploaded a batch uploading script written using the Bash scripting language and common UNIX command line tools (sed, base64, and wget).  This method was chosen in case of uplink failure.  In the event of uplink failure, the script would mark each recorded swipe as still pending and then upon return of a good uplink, the swipes would be uploaded to the back end in turn.  The script parses the data files and parses out the swipes with a status of either 'PENDING' or 'BAD' and encodes them to a hash using base64 (used merely for abstraction) and then appends the hash to a URL and then feeds the URL to wget.  The backend server then returns a status which is then appended to the swipe in the data file.  The script is called from a cron tab that is run every minute and the output of the upload script is outputted to a log file.

The uplink technology chosen was standard ethernet to a some manner of broadband technology (either DSL, Cable, or WiFi).  One checkpoint was chosen to have a cellular uplink as a backup measure (the only checkpoint that used WiFi).  This proved troublesome due to the requirement of having to run MS Windows.  The checkpoint was switched over to Linux shortly after the beginning of the race.

Swipe Processing and Lap Creation-Server listener for reports (URL GET)

All team, rider, swipe, and lap data were stored in a MySQL database.  To prevent any irregularities in the data, the administrative interface had no write access to the swipes and the only write access to the lap table was through the administrative page.  The process works as follows:
  1. Swipe data is recorded at each checkpoint as a rider visits a checkpoint and waves their card in front of the RFID reader (attacked to the inside of a window at each location inside of a tupperware container) This blinks a bright red LED to confirm the read to the rider.
  2. When a rider finishes a lap, they swipe out at the final checkpoint.
  3. In the next hour, they must stop by the registration table and mention that they completed a lap.
  4. The volunteer working at the table clicks a "rider in" button which scans the swipe and lap tables to see if a new lap has been completed (all checkpoints in order) that isn't in the lap table yet (the 1st swipe is after the completion time of the last completed lap).
  5. An entry shows up in the completed lap table for the riders team.
  6. The volunteer selects the riders name from a drop-down box, and click validate.
  7. After an hour, a completed lap is removed from this table so that it can no longer be changed.

This worked out very well and enabled quick training of new volunteers.  We planned for tracking system failure two ways.  Firstly, if a reader failed, the tracking system admin could edit a file that would allow the "rider in" algorithm to skip over a certain checkpoint. If this happened, we would not inform the racers so they would be less likely to purposely skip that checkpoint. Secondly, a manual "add lap" button was in the interface.  When clicked, the volunteer would select a persons name and a lap would be added to the system with the start time being that rider's team's last completed lap end time, and the end time being the time the add lap button was pressed. If all of the readers were to fail, this would allow us to still track the race, but we did not end up needing to do this. Once the race was live, the interface disabled the ability to delete teams, cards, or people, but a volunteer could still do things like add a replacement card if a team lost their original one.  (The "rider in" only checks for laps using the teams most recent card.)

All client side components of the administrative interface were built using the YUI toolkit, mostly for asynchronous requests for data (adding/modifying teams/riders/cards, rider in and setting rider names and validating). YUI was also used for all of the dialog boxes and the tab view of the administrative page. PHP was used for the entire backend including the page that received swipe reports from the readers.  Total lines of code for the entire server component was less than 1000.

Race Tracking

The most exciting part of the tracking system for the riders was being able to track the race in real time. For this, several options were created and made available:

How it worked in the race

The tracking system worked surprisingly well. We tried to test most things beforehand but a few gotchas did come up at the last minute:

Overall, we were very happy with the tracking system and received a lot of positive feedback about it during and after the race. Many people were checking the stats on the web and on their cellphones, and 100k/s of bandwidth and 20 database queries a second was used by the server on the race tracker for the duration of the race.  This was definitely orders of magnitude better than the previous two years, and we were told by people that often participate in slightly more official races that this was the best tracking system that they had ever seen in a race.  It worked smoothly and flawlessy, and we look forward to improving it for next year.

Plans for FM.24.08 and beyond

We have several ideas for next years race, many of which likely will be implemented:

Credits

Seth Kingry was responsible for all "client" aspects of the system including the OS load, acquiring the RFID hardware, and network connectivity of the readers. Chris Kelly was responsible for the "server" aspects of the system including swipe report recording, lap generation, and administrative and tracking tools.  GT Mobilesphere provided us with 6 AT&T SIM cards and 6 PCMCIA 3G cellular uplink cards.  Georgia Tech's Office of Information Technology provided us with 6 computers to use at each tracking station. Faster Mustache purchased the RFID readers, cards, and other small things required for the system to function.