A while back I wrote a couple of posts about our experiment with using Raspberry Pis as an introduction to Computer Science at undergraduate level; this last post in the series is a bit of a reflection on how things went, in case anybody is interested in doing something similar, and some thoughts on what to do next.

The Pis themselves have fared remarkably well; they all worked out of the box, and I’ve not heard of any that have failed since, so that’s quite a testament to their build quality (I’m still glad we had several spares though). A handful of students have lost them, and of those several turned up at the Student Support Office. Fortunately we marked each one with a serial number that we registered against the MAC address of the Pi and the name of the student, so they were re-united with them fairly easily.

Power supplies

Three out of around seventy-five-or-so of the 12v to 5v converters that we’d hooked up to the monitors to power the Pis failed within the first few weeks of term (two of them within the first couple of days). At around a 4% failure rate for that particular bit of hardware, this is a bit disappointing; but we knew in advance that this wasn’t top-of-the-range kit and ordered plenty of spares, so this has just been a minor annoyance rather than a showstopper. In any case, having to use these converters rather than more regular mains-to-Micro-USB adaptors is a quirk of our particular room setup; if we expand to support Pis in other labs it’s not going to be an issue.

Using in-line USB connectors, rather than letting  students to plug devices straight into monitor hubs or PCs was definitely a wise move. We’ve found several cables where plugs have been shoved into the in-line socket 180 degrees the wrong way round. I think that doing this the first time takes a fair amount of determination, but once it’s been done once the off-centre lug that would usually discourage you from pushing things in upside down ends up towards the middle, so that tends to mean that subsequent users make the mistake more easily. None of the cables are broken yet, but I wouldn’t be surprised if several are dead before the end of the year. Compared with messing about fixing the on-board connectors in the hardware itself though, swapping out the cables will be cheap and easy, so this was certainly the right move.

The most common ‘problem’ with the Pis has been students forgetting their password. Luckily, resetting a user password on the Pi isn’t too painful if you know what you’re doing, but it does require some fairly esoteric low level Linux magic, and doing a little dance between a desktop machine equipped with an SD card reader and the Pi itself. Explaining what’s going on with kernel boot parameters, runlevel 0 and init scripts is probably too much for a lab that is essentially Unix First Contact, so in these early sessions we set up a password-resetting station in a dark corner of the lab and did it for them. It does take several minutes of manual card-swapping and file-editing and Pi-booting to do the reset though, and around 5% of the students needed this doing, so I’ll definitely try to think of some way of reducing the number of forgotten passwords, and maybe even of automating the reset process (I think it’s just an ext4 partition on the card for the Linux bit).

There were a few instances of students messing the OS up on the Pi badly enough that there was no way to recover other than re-flashing the SD card (one of these was a recursive chmod that made all files executable, and at least one instance of over zealous rm -rf *ing). In these cases, while it was tempting just to hand out a pre-flashed card to avoid any delays, we got the students to find out themselves how to re-install their Pis (which is pretty easy these days using NOOB), and I think in all the instances I know about they found that a really interesting experience. So much that next year it might be worth starting with blank SD cards and getting them to do the install themselves (my only reservation here is that explaining what’s actually going on when you put the OS on a Pi’s SD card is pretty hard; it’s not just a filesystem/boot image being written in raw mode onto a device, but something much more twiddly, clever and Pi specific that allows the Pi to boot of a card that has both a FAT and an ext4 partition on it. Something to ponder about anyway). Worth repeating this quote from the exit-poll I think:

After bricking my Pi, flashing the SD card using the dd command on my laptop was one of the most unintentionally educational things I’ve done.

On the whole the exercises we set worked smoothly. There were a few typos to fix, and a couple of places where in retrospect a bit more guidance or explanation was needed, but things largely went to plan, and we’ve fixed many of the minor issues in the notes already.  After the first four labs, we asked the students to complete a (rather hurriedly designed) questionnaire so that we could get some sense of how they felt things had gone. The responses were overwhelmingly positive, so I think that we can be pretty pleased with how this has gone so far. A few things stood out from the survey though:

The main criticism was that there wasn’t anything in the exercises to stretch those who were already familiar with Linux/Raspberry Pi. We took a gamble this year that there wouldn’t be many people who had used Pis already, and from a question on previous experience only around 5% of the students had had contact with Unix on a Pi. But this is almost certainly expect to increase in future as the new computing curriculum takes effect and more people get to play with Pis at school-level; so we’re definitely going to need to address that for next year’s labs. Interestingly, the numbers for ‘contact with Linux’ and ‘Unix command line usage’ were pretty similar, suggesting that anybody who has played with Linux has had some exposure to the command-line environment (or, alternatively, that no one really uses Linux just as an alternative GUI to other desktops).

The approach we took of ‘learning by doing something interesting’ rather than trying to teach specific principles seems to have gone down well, and using games as the motivator for the early labs was unsurprisingly popular, but was still exposed them to plenty of low-level command line stuff. In particular, setting up network Quake Arena matches acted as a nice ice-breaker for getting students to interact in the real world as well as the virtual (might be worth considering doing something with Minecraft next year I think).

There were several grumbles about the amount of stuff they had to read, and there might be scope for tightening the prose of the scripts  a bit and of making any optional sections clearer; but largely I think this is just something that undergraduates are going to have to get used to.

Perhaps the biggest surprise was realising that many students tend not to read the output of commands they’ve been typing and will often press on regardless even when an unambiguous error or warning message has appeared. And of course the problems that this causes tend to accumulate as subsequent commands assume that previous ones did the right thing. I’m not quite sure how best we address this yet, or why students are in the habit of responding to errors reported in a GUI but happy to ignore them on the command-line (perhaps because you generally have to actively dismiss GUI error dialogs?).  One idea we’ve come up with is to include ‘checkpoint’ sections in the exercises that get them to perform various actions that test whether everything they have tried to do so far has worked, and to make it explicit that they shouldn’t go on any further until everything is set up properly (we’re even considering automating this process somehow, but not thought through the details of that yet).