Did you know that you can navigate the posts by swiping left and right?
Orienteering is map and compass navigation racing. Here in Puget Sound, the Cascade Orienteering Club hosts meets all year, some attended by more than four hundred competitors. Orienteering is an anti-climactic sport: competitors start individually in 2 minute intervals, race their course (through the woods and out of sight), and return to the finish. Even though this is a race for the fastest time, there is never a head-to-head race to the finish. Also, because every course is different, it can be hard to judge an individual’s performance.
Live results provide coaches and competitors with faster feedback about the race. With this information on-site, individuals and teams can de-brief while still present in the environment, which likely leads to easier recognition of possible corrections and faster improvements.
Because many event sites have limited or no cell phone coverage, the entire system is designed around a web server broadcasting pages over a local WiFi network. As competitors finish the course, event software records information from their e-punch (rfid-like tracking device) and compiles results. The event software is able to export preliminary results at set time intervals, which is the input data for the public live results system. The exported file is routed to a Raspberry Pi which processes it and builds a database each time a new file is received. Some local DNS tricks on a WiFi router and a web server running on the Pi allow anyone on site to connect to a public WiFi network and view the current results. Running this system on the Pi rather than directly on the event laptop helps with modularity and security.
Check out the code (and the readme) on GitHub.
The current server is built on the Flask micro-framework for Python and uses a SQLite database. It all runs on a Raspberry Pi 2. The event software can export the preliminary results file (an .xml file) directly to a folder on the Pi thanks to a samba share. On the Pi, a simple script monitors this directory for changes. When a new file is detected, the script sends the file to the server (another process on the Pi) via HTTP POST request. The server reads the xml and loads the data to the database, recalculating points for individuals and teams. When a user connects to the local WiFi network and requests a page, the Pi dynamically builds and serves the appropriate html.
At three events in February and March 2016, this system was successfully deployed (in areas with cell coverage) such that results were available both via an a internet-facing web server and via the local WiFi. This was trivial: a duplicate web-facing server was running on Heroku, and the script on the Pi was altered to POST each new results xml file to both the localhost and the internet server.
At three events in Winter 2015-2016, this system captured and displayed information from the check or start control in real time, with the help of some additional hardware and integration of the socketIO library.
Previous event software didn’t have periodic export functionality, so a solution was developed to intercept data as it was sent to the results ticket printer. This worked but was undesirable as the system existed within the critical path for the event. This solution was abandoned when the club independently decided to switch to different event software.
Previous iterations of this project used Express on node.js as the backbone. The project switched to python due to more stable support for python on the Pi and other potential hardware targets which were being investigated.