As part of Vísar’s ability to deploy a survey system we’ve tried to keep it with fairly low dependancies. The system is built with Django in python and requires some database access for survey response persistence and user data. Beyond that, it is pretty standard. This means we have the ability to run it on a variety of hosting providers, including places like AWS and Heroku. This makes deployments easy and highly portable. So portable infact that we decided to see if we could run the entire stack offline on a Raspberry Pi.

The great think about this solution is literally a survey system in a box. We could pre-program the survey and populate the possible respondents or create an anonymous survey. Then stick the box in the post and when you receive it, all you need to do is give it power and plug it into a monitor. The system would boot to the browser and be ready for any respondents. Or atleast that was the plan.

We used a Raspberry Pi B, which has a few more features than the A series. After installing the OS onto an SD card, booting-up and prepping the system, we pulled all the code for the collection server from the git repo. Then installed all the dependancies. The first huddle was Gunicorn, which is used as the production server. We decided to simply skip this since we were certain only one user would be accessing the survey at a time, therefore we could us the built-in Django runserver command. With that out of the way, we hit our next roadblock with PostgreSQL. It required some jiggling and finagling, but in the end it worked. As a fallback we decided to just use SQLite, but with Django’s migration tool South, we ran into problems with some aspects of the models working. That forced us back to PostgreSQL.

After getting everything working and running, we did successfully manage to connect to the localhost webserver and browse the survey. The downside was that page loads were taking a long time, too long for our needs. We suspect that the memory, processor speed, SD card writes all contributed to the slowness.

This leaves us with several options:

1. Rewrite the Database ORM layer to work with flat files. Then we could remove the whole database from memory. This would be a lot of effort and not work on services like Heroku where the file system is not persistent.
2. Ditch Django and use Flask, or something even lighter. For an open anonymous survey, we don’t need all the user settings we have now, nor the admin tools. We can always move the data into other tools to manipulate it later, but we’d need to actually write this new software.
3. Skip the offline aspect. If we can get online, we push the heavy lifting back to the server and just focus on the dumb client. All we need is a web browser and internet access. Internet connections are a problem in highly secure areas such as banks or government institutions, but could be solved with private 3G access.
4. Try other hardware. Instead of using an inexpensive Raspberry Pi, we could switch to an Android Tablet or other device that we can install arbitrary software and run our stack using this hardware instead.

Getting this working on the Raspberry Pi was a good experiment, with less than a stelar outcome. Admitably we were pushing the limits of what we could do, so we’re not disappointed. The one good aspect of the Pi is that the built-in web browser, Midori does a great job of rendering web fonts and is fast and feature-rich enough to be used as the browser in a Raspberry Pi powered kiosk with an internet connection.

This mean the Pi project isn’t completely shelved yet and it might make an appearance in the future.