Vagaries on the Linux Side

Race Timing Project

As of July 2006, this is very much a work in progress. I welcome feedback.

Interrested? Contact me.

Genesis

On July 1st and 2d 2006 I took part to Thailand's 24 Hrs Go-kart Race. It was a load of fun. To help manage my team during the race, I had spend some of my spare time in the month preceeding the race, to write a Team Management application I had hoped that I could get the decoder timing info, but since that wasn't to be, I had to setup a Targus Wireless Multimedia Presenter so that one could stand on the edge of the track and time each passing of our kart. The software also has a simple pilot scheduler, some timers, et cætera.

It wasn't perfect, but the software performed pretty well given the circumstances. The application is available for download if you want to play with it. It can be found on this page.

During the race, timing was performed by SMS Timing, a company from my native Belgium.

I wasn't impressed.

I realised that the little application I had written in just over a month was not complete, but I had gotten a lot of things right and, I felt, it could be turned into something much better than what I had seen.

So I decided to start this Race Timing Project.

Objectives

The purpose of this project is to create an Open Source system for race timing and management.

By this I mean that the software should be able to monitor a race and produce real-time standing of the competitor as well as the final standing. The race direction should be able to suspend, shorten or lengthen the race as circumstances requires. The system should handle race of various types:

The software shall also handle single and multiple (team) racers situation.

The system should also provide modules to handle common race events and handle various display (e.g. pilot change event, Green/Red light, Public display,...)

While the base building block of the system should be as generic as possible, there are still significant differences between various types of races. This difference may require the GUI to be adapted to different race types to keep the user interface simple.

Practical Objectives

I do realise that the objectives presented in the previous paragraph are quite ambitious. In order to get things going, one should set shorter term less ambitious objectives. In this case I plan to initially aim for a software that could handle all sorts of races on a circuit. This software could be used for Go-kart races, model car races, ...

The Tools

Programming Language

Since this is a software, one has to select a programming language. The application I wrote for my team was written in Python and used the Qt toolkit thanks to the Python binding. This was only my second application written in Python and the first time I used the Qt toolkit.

I like Python. It is quite elegant and flexible. Since race events are relatively slow, the software execution speed is not all that critical. Python will be used for this project. If parts of this project require it, Python can be extended with pieces written in C or other compiled languages.

For parts of the software, I may temporarily use PHP to create web-based tools. I wrote a library in PHP that makes it easy to create and process database forms. It offers a rich set of types (e.g. Email address, Country, ...) and allows you to link various aspects of the form. E.g. the State entry will only show the US states if the United State is selected in the Country entry, and the label of the Telephone entry will show the country code and the long distance prefix accordingly.

Development Platform

Linux, is there anything else?

Development Tool

I have used Emacs for a very long time. I still like it, but I feel it starts showing its age. There are more modern tools to develop Python application. I am currently using Eric. It's great, I shall continue. If only I could get some Emacs-style key binding....

Database

Information about races, racers, vehicles, tracks and so on shall be recorded in a database. With Python, it does not really matter which database you use since there are some nice database abstraction modules. For practical reason I shall be using MySQL. I shall try to avoid using features that are specific to MySQL.

A flexible database schema has to be developed. I think it is reasonable to assume that a given database will contain racing information for only one sport. Hence the database schema can be slightly different depending on the targeted sport. Even if some aspects of the database may differ with the type of race targeted, a great many things will be similar.

Design

When writting my application I modeled the race as a series of race entities exchanging race events. At the centre of this model is a multiplexer ( a mediator in Design Patterns lingo, but the term is a bit too anthropomorphic for my taste). I feel this model is the right one and I shall revisit it.

Database

The database should be able to store polymorphic data. In that I mean that each race may have a variable set of data stored, and the database should be able to handle that. This probably means that it should associate each race with metadata and store the actual data in some generic form. This reeks of XML.

Practical Design

I usually design things by imagining various scenari and seeing how things would work. In this case, I have been thinking about Go-kart races, F1 races and bicycle races. This has led me to see the project as a series of collaborating tools. All would be based on a common foundation. I see the system comprising the following operational units.

Race Tool
The race software is the main part of this project. This is the one that will run the multiplexer. It will receive and manage all the race events. It will keep track of the standings, It will also verify that the rules are followed, inasmuch as that is possible. It will also issue penalties when rules are broken. The race software should also allow the race management to: The race software will mostly write to the database. It will read from it at start up to configure itself.
Design Tool
This module is used to describe the race, the timing/detection devices (button, decoder,...), the constraints ( all members of the team must race, time limits on racing sessions,...). It should also describe the penalties that can be imposed.
Registration Tool
The module will manage the various racing entities and store the information in the database. It should also issue the various id's needed for the race. For example, if the race includes pilot changes, the change could be managed using barcodes, in this case this module should issue the id's with the barcode identifying the pilots.
Event Stations
Event's station are remote entities issuing specialised events to the multiplexer (i.e. the race module). For example, in a race using 1 transponder per team, pilot changes could be managed using barcode or magstripe cards, a station could be setup to verify the pit lane speed, a blackbox on a boat could verify its position using a GPS to verify that it did pass the required buoy.
Display Stations
Stations displaying information pertinent to the race. You may have combined Event/Display stations.