CityPeaks is finally live!
The main idea behind the project was to get Digit moving in the new year. By simply taking the stairs up to the office, Digit folk compete in a company wide race to climb the stairs of actual buildings around London. Users can also track their progress on a more personal level, plotting the distance they have climbed against mountains across the world. “Scaled k2 at work today, like a boss”.
The project comprises of 2 custom built check-in stations, an API and a pretty website to display it all on. Each station is built around an ATmega328 (The initial prototypes have been built on Arduino) and uses RFID to read Oyster cards. All communication with the API is done over HTTP and uses an Ethernet module for physical connectivity. Users simply check in and out using the system records their time in and time out and the id of the station, this enables the system to determine a direction of travel. The stations also provide feedback to the user through a 16×2 character LCD screen. Users can earn various badges and trophies i.e. Climbing the stairs more than 3 times in a day, and these results are fed back to the user on completion of a journey. The feedback mechanism also allows for users to play without fully registering themselves on the system. When a new Oyster card ID is read, it creates a new user which is assigned a token. This token is a combination of 2 words that can be entered into the website to fully register, including setting a screen name, password and various other details.
The backend is LAMP and is responsible for handling all of the data processing and communication that happens in the game and also powers the main frontend of the website. The homepage shows each users flag positioned against the current building. The height depicts how far up, in real distances, they have climbed the building. As they check in and check out, climbing the actual stairs to the office, their distance is recorded and added to their in game climbing distance. When a user reaches the top, their flag is positioned at the top of the building to mark that they have conquered it. Each users distance is then reset and the race starts again on the next building. On the users profile page they are able to see the badges and trophies they have earned (badges are collected, however trophies are unique, meaning only one person in the game can have it) as well as view their distance agains some of the tallest mountains in the world!
We did come across a number of problems whilst developing the system. One particular problem was the downstairs check in station. Due to the fact that it wasn’t able to directly connect to our LAN network (as the upstairs station does), we had to route all check-in’s through a 3G router. As you can imagine, this does impede on the latency of requests/responses quite substantially.
There are a number of solutions that we are currently working on implementing, one of which is to change from using HTTP to a custom protocol. The problem with HTTP is that is comes with a lot of overhead. While it provided a quick and established way of communicating, there is a lot of header information that is part of the HTTP standard that we just didn’t need, which not only takes time to transport, but to read and write as well. By using a custom server, possibly built in Node.JS, we can build a ‘proxy’ that can handle communication from the stations, and then forward these requests over HTTP to the API. This final hop from custom protocol to HTTP would be only be across a localhost, meaning that its fast and also means that we dont have to rewrite backend code.
A slightly different solution would be to use a document database with a socket interface that allows for executing custom procedures. One option could be CouchDB(It’s REST, but it could be implemented with the socket-to-http proxy), which provides the ability to read and write data exceptionally fast as well as write custom ‘shows’ to allow it to respond with a custom format, similar to how the API functions already. Another feature of CouchDB is its ‘revision-ing’ functionality, while not practically possible with Arduino, on a higher end processor, such as the Beaglebone, a local DB could be used for making immediate writes, this in turn would make the whole check-in process a lot faster as we no longer need to go through the netwrok to the server. This local DB could be then be synced with the master during quiet periods. It would also assist with problems transmitting over 3G, as we could simply write to our local revision during link downtime, then sync it to the server once its restored. This database would only be responsible for holding journey details, although switching the whole system to a document store could be a interesting experiment in itself.
- SM130 (MiFARE Compatible – 13.56mhz)
- Wiznet based ethernet shield
- Arduino Uno
- 16×2 LCD (drivin by 4-Wire)
- Website/API – PHP (CodeIgniter)
- Spotify App – HTML/JS
Find out more:
Visit the project: