Galileo Wrap-up

Last spring, I received a grant of five Galileo development boards from Intel and intended to use them with my class this semester to study balanced aquaria. It hasn't gone as well as I had hoped.

I set one up last spring and my initial testing was encouraging. I wrote a script that could collect the data, display it on an LCD screen, and output it to the serial port.

My goal was to extend the script so that we could use MQTT to upload the data to a server to aggregate it. But over the summer, I spent several weeks in St. Croix and then, when I returned, I was totally absorbed in getting the new BCRC renovated and set up for the fall. I never had time to finished my preparations for working with the boards.

I thought about having the students work with the boards, but I ran into enough weird problems that I decided that was a bad idea. For example, I had found that the liquid crystal libraries provided with the Arduino application didn't compile cleanly for x86. Someone had posted an updated version of the library, but it was non-trivial to replace them in the MacOS X application bundle -- or, at least, I surmised it would have been non-trivial for the students.

I ultimately found several similar problems: some c++ headers weren't correctly linked and required creating a symlink in a magical place. The MQTT PubSubClient for Arduino wouldn't compile for Galileo. Much of the Arduino code for x86 was buggy: the SD library could write to an existing file, but couldn't create a file. In all of these cases, I could find a discussion online where someone had figured out how to fix the problem, but the fix was often complicated and required being adapted for the local circumstances.

Some problems were simply architectural: Galileo, unlike an Arduino, doesn't save a script you upload to it. So if it loses power, when it restarts, it's simply dead. You can fix this by creating a micro-SD card with a distribution of linux on it, but creating the cards is non-trivial and getting the boards to boot from the cards seemed tricky -- it took me a couple of hours to make it work reliably. Also, the Galileo has a real-time clock chip, but no simple way to include a battery to keep the clock running across reboots (ie, there are headers where you could attach wires connected to a battery, but there's no battery holder).

If I could have simply worked with a linux shell, it would have been a lot easier: but it wasn't trivial to get a terminal connection to the Galileo. Working through the Arduino interface made everything cumbersome, especially as it was buggy and unreliable.

In the end, the students proposed using an incubator in the ISB which created another level of difficulty, because the University never turned on most of the network in that building. Given time, I could have figured out which was the closest network jack, requested it be turned on, and found a switch to connect the boards to the network but, in the interest of time, decided to write to the SD card instead.

Eventually, I got a script that would manually set the time, minimally collect data, and log it to the SD Card. But the boards seem to only run for a day or so before they quit logging. And if the boards have a power failure or reboot, they reset the time to what the script originally set it to. I'm not sure if it's memory leaks or some other hardware problem, but the net result is that the data are very, very messy.

In any event, I'm glad I didn't try to have students work directly with the Galileos -- I think it would have been very frustrating for them and to little purpose. I think, in the long run, it would have been a lot easier to use Raspberry Pis for this project. And I think, if I can find the money, that's what I'll try for next time around, if I decide to do this again. Next semester, I'm thinking I may try agent-based modelling with Netlogo.