Writing our Astro Pi sweaty astronaut code

Since we heard that we'd won the Primary School AstroPi competition, my Codeclubbers have been working on turning the idea - trying to detect the presence of an astronaut by the increase in humidity that they cause - into a working program.

Design 

I was really pleased that of all the ideas that we submitted, this was the one that was chosen because I reckoned it would  be the easiest to split down into individual functions.  It seemed too complicated and time consuming to get every member of the club to write their own version in full, so by allocating individual elements to different children, I was able to try to match difficulty to ability.

To start off with, we generated a flow diagram of the various stages of the program, largely based on the pseudo-code that was submitted as part of our original paper entry to the competition. Pleasingly we found that this was fairly complete and most of the things we added were neat enhancements rather than modifications to the overall logic. Then we tried to identify which of these blocks would constitute a function in the code. 

This was a good opportunity to talk about writing functions, passing input arguments and returning output. The children had encountered these concepts in some of the other projects we'd worked on with the Pis, but  it was clear that not everyone grasped the ideas straight away. In particular, writing code that would would work on input values supplied by another function  was a common cause of confusion:

'Where will |the values come from?'
"They'll be the output from  Harry's code"
"But he hasn't written his code yet..."
"That's OK, just pretend he has and that it provides you with a list of values"
<Pause>
"But where will I get them from?"

Showing how to use fictitious test values when developing helped, but it wasn't until we started putting individual functions together that things started to click.

Teamwork

This approach  is, of course, good experience and representative of 'proper' coding jobs.  It was really good to see them working as a team, particularly when they got together in pairs (without any prompting from me) to solve problems that had an element of commonality. Taking the concept all the way from a design on paper to working code was a great project for a half-term and I could see that some of the children were really engaged with the process, thinking through the various steps and making suggestions as to ways things could be done.

There was a lot of focus on what messages the code would display, Partly I think this was because the children really like programming funky images and scrolling text for the LED matrix, but also because they felt that it was important that program communicated what it was doing. This helped them understand what was going on but also reflects (I think) a sensible and user-centric focus to UI design. Consequently our final code is full of display messages for the LEDs and also logs plenty of data to file too.

We even had a simulated (using an Astro Pi, naturally) Tim Peake to help with our test scenarios.

Testing

The children all excel at coming up with 'What if...?" questions. A lot of these were really great observations (e.g. "what if the humidity doesn't go back down again straight away?") and led to our code being more robust and also incorporating an element of self-tuning.

Throughout the whole thing I have been consistently impressed with the calm and confident way with which the children have approached the task. When we came to testing the first  full working version I was quite nervous but they seemed unsurprised that it pretty much worked first time. It was funny how, at very stages, one or other of the children would ask:

"Is our code really going to be running on the International Space Station?"

as though they thought it was some sort of trick or 'pretend' prize.

Weirdly, none of these positive benefits from working on a team project like this  had occurred to me before we started - I rather blundered into them. But now I'm thinking about how to accommodate something like this in future (including at CoderDojo) rather than stick with the standard single-person project that tends to be the default for this kind of thing.

Testing

I wanted them to think about the environment in which the code would be running - the ISS is obviously very different to the school Computing suite. So we had an idea to build a replica AstroPi flight case from Lego. Apart from being a bit of fun, this did highlight a couple of operational issues, for example the various messages displayed on the LED matrix were not all set at the same rotational angle. Obviously it is easier to spin through 180 degrees in zero-gravity, but it seems sensible to standardise the orientation.

It was also obvious that the flight buttons would be much easier to press in order for the astronauts to confirm their presence. Our original design just had the joystick used for this, but we all agreed that using the buttons would be a good enhancement.

So: Flight Case Mk2, incorporating working buttons connected to the GPIO pins just like the real one.  One of the useful outcomes of having children who have had (pretty much) nothing but Lego for birthday presents for the last 5 years is that we have a wide range of pieces. Combined with the superbly proportioned Pimoroni CakeBoard, and we've been able to add the flight button functionality into our prototype.

Not quite as elegant as the original - its need to be deeper to accommodate the breadboard and buttons. We've also had to make some adjustments to our code and as the end of term was fast approaching, we just adapted the existing functions rather than re-writing that entire 'wait for user input' chunk.

End of term

With only a small amount of after school tinkering (mainly to include the flight buttons)  by my sons, we managed to get the whole program finished by the end of term. The final session of the 2014-15 academic year was spent on some final testing and designing some animations to display when the program starts or when there is nothing else interesting happening (e.g. between measurements).

Of course our code isn't the most elegant or optimal software ever written. Despite my urging, some of the variables are not the most sensibly named (I haven't changed them: this is their code, not mine). But it works and manages to perform the intended task in a concise and efficient way. I think a lot of this is due to the excellent API for the AstroPi HAT, but the children's creativity and user-focused design methodology has also be a big contributory factor.

I'm incredibly proud of what the children have achieved and the positive attitude they've adopted to the whole competition. The best moments for me - apart from the phone call when we found out we'd won - were those light-bulb moments when I saw one of the children work out something they'd been trying to solve for a while.  Or when we'd be discussing the code and they'd tell me that was a better way to achieve something than the one I'd just suggested.

And there were quite a few of those...