Tag Archives: raspberry pi

Training teachers in coding at Truro School

I’m part of a UK Department of Education funded project to join up 10 primary schools in Cornwall and get them programming. The teachers are very important people in this equation, so our first activity was a training day for them. The idea of this was to get them familiar with using the Raspberry Pi and try out some programming, while at the same time allowing me to gather some research on feasible projects that can result in long term benefits for the schools involved.

We gave Sonic Pi and our Minecraft Python architecture coding a go, and I also briefly demoed the weavecoding project via flotsam – as one of our eventual aims is to produce teaching materials for this too. I’ll start with some of the broader things we discussed, see below for more specific observations for these programming systems.

Unaddressed needs of teachers

Despite a big push in coding in schools, there are still plenty of areas where support is lacking or even misguided. The focus on hardware platforms (Raspberry Pi, BBC’s Micro Bit) is not so relevant as schools have plenty of existing hardware, also the mass of community open source activity needs a lot of work to translate for classroom use. A further problem is that a lot of existing initiatives tend to be high visibility but too short term in their scope. Codeclub is a notable exception in this area. Technology also tends to get considered as a distinct subject – whereas it needs to be linked with other topics (i.e. teaching local history by making computer games about it) in order to make sense.


Long term thinking

Events for teaching a small proportion of children programming has short term benefit unless it is to enable the children to teach each other. This turns out to be successful in after school code clubs, so is it possible to design events and workshops with this aim specifically in mind?

Teachers need access to people who work with technology when they need it, but how can this be done – a local support network perhaps, we also discussed hacklabs for teachers where they can drop in and get advice. Hacklabs could provide teachers with feedback on their ideas, perhaps some small one on one training to help realise them – as well as perhaps building hardware or software specifically according to their needs. The funding for this is an open question at the moment.

One of the issues reported by the teachers is that it takes a lot of effort to get students to a certain tipping point with technical ability, after which they shoot ahead and quickly overtake the teacher. I’m not sure if this is seen as a problem in itself, but it does seem like there needs to be a situation designed where this can easily feed back into the collective knowledge of the group.

Classroom materials are worth their weight in gold, like the ones supplied with Sonic Pi or those provided by Code Club – and they take a long time to check and get right. The problem is that it’s actually hard to get funding to make these, relative to teaching hours. Releasing all teaching materials as creative commons to pool resources nationally (and beyond) is key. One thing that came out clearly with the worksheets we used for both Sonic Pi and the ones we wrote for Minecraft coding was that they are not really very well suited for primary school use. We seem to tend to write documentation that focuses on example recipes to follow rather than encouraging exploration – this was a surprise to me. The teachers were more keen on simple lists of commands (and liked the dropdown menus in Sonic Pi for example) which were then left for the children to discover how they fit together, and less wordy explanations.


Hardware problems

Many schools have already moved away from desktop PCs, whether using laptops or (shudder) tablets exclusively. The Raspberry Pi has considerable extra hardware needs – we discussed whether recycling hardware being thrown out from local businesses was one option to help with this.

We came to the conclusion that one promising area to look at is robotics, making use of the Pi’s easily accessible hardware interface. The problem then is where to get the required motors and other hardware from – one potential resource are the forgotten boxes of lego, electronics and bits and pieces gathering dust in school storage. Again the challenge is how to make effective use of this rather than spending money on new kit.

Systems we tested

We tried following some worksheets for two coding projects on the Raspberry Pi, the aims were twofold – to get some initial experience with them as well as getting feedback for how we can improve them from the teachers point of view.

Sonic Pi

This was the first time I’ve used the new version of Sonic Pi in a class room. We used the version that comes pre-installed on the ‘2015-02-16-raspbian-wheezy’ release. I’m not very familiar with Ruby, the language it uses but I’d had a bit of a play with it in the days prior and had a bit of feedback from Sam Aaron on some specifics too.

One of the big questions I had was whether typing skills would be an issue with the primary age group. They are used to using drag-drop programming languages like Scratch and Espresso but would this translate to using the keyboard? The teachers thought that Sonic Pi’s minimal syntax would be really good with their children – the syntax highlighting (using colour and little lines to denote indentation) would be important to make it easier for them. One problem we noticed is that the syntax colouring might be able to go a little further – it could, for example be more context sensitive – e.g. the difference between a symbol that is user defined and one that is part of the system would be better to differentiate for explanation.

They considered the documentation, both ‘online’ as part of the interface and the wording of the tutorials was probably too prescriptive and in-depth (which to be fair is written for older children). More importantly the teachers loved the musical aspect, and immediately got into creating their own tunes (all mixing with the amen break :) Initially the concept of MIDI notes was a confusion – “why is 60 middle C?”. A popular request was for some pre-written examples of familiar tunes to fiddle with.

The interface including visible debugging/errors was very popular, as it seems a lot of existing commercial software they use in classrooms does not to this well. Being able to ‘hear’ bugs was also important. It was also good to explain Sonic Pi in terms of musical livecoding and Supercollider, as this culture gives it a kind of extra spice which is exactly what we need when ‘coding’ can so easily slip into being about boring product-centric thinking.



To contast Sonic Pi, in the afternoon we switched to the Minecraft world and the system we developed for teaching teenagers programming with Python. I’ve recently been using this for one-on-one teaching with an 8 year old, so I wanted to find out if they thought it would be useful in the classroom for this age group.

This setup relies on an IDE (we use Geany) which communicates with Minecraft via network messages running in a different window. The multiple windows and strange ‘always on top’ OpenGL rendering of the Raspberry Pi GPU makes this a fiddly business until you get the hang of it, but the upside is that this is the same approach as programming in the games industry – and kids like it when you tell them this. However it would be wonderful to be able to ‘dock’ minecraft in a Python IDE in a friendly way and have some of the features of Sonic Pi.

The projects we made with this system are again pre-created recipes without much information on things like how to get the coordinates right rather than just following the instructions. One of the teachers found out that you can use the player’s position to figure out what the coordinates should be, we need to include these kinds of hints and think a bit more broadly how to describe the creative process.

On thing I picked up from the teachers was that they had high expectations of the scale of what would be needed to capture interest for the children – for example that we’d need to write programs to create entire cities and a worry that the amount of code needed for a simple house seemed so much. However, what I’ve noticed when using this for teaching younger children – is that we’ve sometimes spent an entire hour on a single line of code. For example creating a block, changing it’s position and size in 3 dimensions and then trying changing the block type – seeing how water or lava acts in different circumstances. The strength of Minecraft is that it contains a lot of complexity which is already understood by children who play it, so they don’t really need to be convinced so much as given space to explore possibilities.

Screenless music livecoding

Programming music with flotsam – for the first time, it’s truly screen-less livecoding. All the synthesis is done on the Raspberry Pi too (raspbian release in the works). One of the surprising things I find with tangible programming is the enforced scarcity of tokens, having to move them around provides a situation that is good to play around with, in contrast to being able to simply type more stuff into a text document.

The programming language is pretty simple and similar to the yarn sequence language from the weavecoding project. The board layout consist of 4 rows of 8 possible tokens. Each row represents a single l-system rule:

Rule A: o o o o o o o o
Rule B: o o o o o o o o
Rule C: o o o o o o o o
Rule D: o o o o o o o o

The tokens themselves consist of 13 possible values:

a,b,c,d : The 'note on' triggers for 4 synth patches
. : Rest one beat
+,- : Change current pitch
<,> : Change current synth patch set
A,B,C,D : 'Jump to' rule (can be self-referential)
No-token: Ends the current rule

The setup currently runs to a maximum depth of 8 generations – so a rule referring to itself expands 8 times. A single rule ‘A’ such as ‘+ b A - c A ‘ expands to this sequence (the first 100 symbols of it anyway):


I’m still working on how best to encode musical structures this way, as it needs a bit more expression – something to try is running them in parallel so you can have different sequences at the same time. With a bit more tweaking (and with upcoming hardware improvements) the eventual plan is to use this on some kid’s programming teaching projects.

Adventures with i2c

In order to design the next version of the flotsam hardware I need to make it cheaper and easier to build. The existing hardware was very cheap in terms of components but expensive in terms of time it took to construct! With this lesson learned and with a commission on the horizon I need to find a simpler and more flexible approach to communication between custom hardware and the Raspberry Pi – mainly one that doesn’t require so many wires.

i2c is a serial communication standard used by all kinds of components from sensors to LCD displays. The Raspberry Pi comes with it built in, as the Linux kernel supports it along with various tools for debugging. I also have some Atmel processors from a previous project and there is quite a bit of example code for them. I thought I would post a little account of my troubleshooting on this for others that follow the same path, as I feel there is a lot of undocumented knowledge surrounding these slightly esoteric electronics.

The basic idea of i2c is that you can pass data between a large number of independent components using only two wires to connect them all. One is for data, the other is for a clock signal used for synchronisation.

Debugging LEDs
Debugging LEDs

I started off with the attiny85 processor, mainly as it was the first one I found, along with this very nice and clear library. I immediately ran into a couple of problems, one was that while it has support for serial communication built in (USI) you have to implement i2c on top of this so your code needs to do a lot more. The second was with only 8 pins the attiny85 is not great for debugging. I enabled i2c on the Raspberry Pi and hooked it up, ran i2cdetect – no joy. After a lot of fiddling around with pull up resistors and changing voltages between 3 and 5v either no devices were detected, or all of them were, all reads returning 0 (presumably logic pulled high for everything) or noise – nothing seemed to make any difference.

After a while (and trying other i2c slave libraries to no avail) I switched to an atmega328 processor using this library which includes a Makefile! One thing that I’ve noticed that would make things much easier for learning this stuff is more complete toolchains in example code including the right #defines and fuse settings for the processor. However this code didn’t work either at first, and my attempts at using debugging LEDs on PORTB didn’t work until I figured out it was conflicting with the UART i/o used in the example code – after figuring out that this wasn’t part of the i2c code I removed it and the Raspberry Pi could at last see the device with i2cdetect. With the addition of some LEDS I could check that bytes being sent were correctly being written to the internal buffer at the correct addresses.

It finally works!
It finally works!

Reading was another matter however. Most of the time i2cget on the Pi failed, and when it did work it only returned 0x65 no matter what the parameters. I’d already read extensively about the Raspberry Pi’s i2c clock stretching bug and applied various fixes which didn’t seem to make any difference. What did the trick was to remove the clock divide on the atmega’s fuses – by default it runs at 8Mhz but slows the instruction cycles to 1Mhz – without that it could keep up with the Pi’s implementation and all reads were successful. I still had to solve the ‘0x65 problem’, and went into the i2c code to try and figure out what was going on (using 8 LEDs to display the i2c status register). It seems like reading single bytes one at a time is done by issuing a TW_ST_DATA_NACK as opposed to TW_ST_DATA_ACK, as it sends a not-acknowledged for the last byte read. This state is not supported by the library, after fiddling around with it a bit I switched over on the Pi’s side to using the python smbus library, and tried using read_i2c_block_data – which reads 32 bytes at a time. The first byte is still 0x65 (101 in decimal, in the photo above) – but the rest are correct, I’ll need to read a bit more on the i2c protocol to figure that one out (and get the attiny working eventually), but at least it’s enough for what I need now.

Handy collection of pinouts
Handy collection of pinouts

Tangible livecoding tests in the wild, and material as type in programming

Last week I took the flotsam tangible livecoding system to my programming tutoring lesson for some first tests with the real experts. To provide some background, we started a while back with Raspberry Pi, messing around with the Minecraft API and python and we’ve recently moved on to laptops and pygame. I arrived with the system set up for the Minecraft building language, and we gave it 10 minutes or so before resuming normal activities – although it did get a bit more use during natural breaks in the lesson. Here’s a recent pic of the weaving l-system setup:


First impressions were that it was immediately playful, most of the blocks were eagerly removed and examined before we’d turned the thing on. One problem with this was that the chalk symbols rubbed off very quickly! A similarity with the Scratch programming language was also picked up on fairly soon.

A big issue was getting the connectors the right way round – this is not easy as the blocks are circular with little indication of which way is ‘up’. This could be fixed by altering the shape or cutting a little notch – learning how to manipulate them is part of the point, but right now it’s too difficult. This will also be a big problem in livecoding performance situations.

Using Minecraft, the screen was still a distraction. The connection between what’s happening in the 3D world and with the physical blocks is not obvious enough – even with the LED indicators. Also the mouse and keyboard need to be plugged in so we can move the camera around and see stuff, leading to a few too many things going on. I’m not sure how this can be solved regarding Minecraft, but indicates that a musical approach (with no screen or any other peripherals needed other than speakers) is the way to go.

Overall there is huge potential to think much more about the touch/feel of the blocks. Lots of these problems can be solved by using different shapes for different symbols (removing the need for chalk) with a clear orientation. Using different materials to provide textures and ‘feel’ in order to represent different sounds, or in terms of weaving, using the actual yarn material to represent itself is a huge area to explore.


In the photo above, I’m using thick and thin blue yarn wrapped around the blocks that represent them, and tinfoil for l-system rule symbols (X, Y and Z) – this is a kind of material based type indication. Interestingly the yarn feels very different even though it looks the same in the photo. In use this results in much less checking of the block when you pick them up, as your fingers tell you what they are.


Flotsam: A prototype screenless livecoding language

Two languages are working with Flotsam, the new name for the prototype screenless tangible programming language I’ve been building (which comes from the fact it’s largely made from driftwood). It’s somehow already been featured on the Adafruit blog!

The circuit seems to be fully debugged now, with short circuits fixed – which took a little while and more than a little frustration :) The Raspberry Pi python code is currently on the weavingcodes repository (more on this project on the kairotic site), and the first language is a declarative style L system for describing weave structure and pattern with yarn width and colour. The LEDs indicate that the evaluation happens simultaneously, as this is a functional language. The blocks represent blue and pink yarn in two widths, with rules to produce the warp/weft sequence based on the rows the blocks are positioned on:

The weaving simulation is written in pygame (which I’ve been using lately for teaching), and is deliberately designed to make alternative weave structures than those possible with Jacquard looms by including yarn properties. The version in the video is plain weave, but more complex structures can be defined as below – in the same way as Alex’s gibber software:


This is a completely different language for building shapes in Minecraft, and is an imperative, stack based language for driving a turtle in 3D space. Eventually (when I’ve manufactured a few more programming blocks) it will be possible to change Minecraft block materials and react to player actions. The LEDs indicate here the more sequential evaluation of this Forth like language:

All that’s needed to switch languages is to redraw the symbols with chalk and run a different script. It won’t be truly screenless until I write a musical language for it, which is obviously coming soon…


Screenless programming language: assembling the plug panel

Never seen so many VGA ports, ironic perhaps. It’s great that it’s transparent, but I’m regretting the material choice for the panel – acrylic is horrible to work with and leaves behind lots of microplastics pollution I have to carefully collect up. Lesson learnt for next time, lots more soldering to do now – then more testing with the Raspberry Pi. Following on from the previous post, the instruction blocks will plug in to these 9 pin plugs.



Symbai field site testing

Some photos from Shakti Lamba who is currently testing Symbai in the Chhattisgarh state in north eastern India.


The whole system is solar powered, and provides it’s own networking via the Raspberry Pi synchronisation node shown here. The android tablets also recharge from the same power source. The Raspberry Pi networking is a direct descendant of the experiments we carried out in London during the Sonic Bike workshop.


Here are three of the tablets syncing their data – photographs for people to identify each other (names are used differently to western culture), audio recordings of verbal agreements (a requirement in preliterate societies), and information of who knows who.


More on this free software project, links to source etc over at foam kernow.


Building a screenless programming language for the Raspberry Pi #6

Following on from the last in this mini series, the giant 16 byte multiplexer is finished and tested – lots of head scratching due to shorts and wonky solder joints (it’s amazing how sensitive CMOS logic is, interference on accidental free pins causes strange effects) and I’ve replaced the breadboard with a new interface board between the Pi and the multiplexer.


Now it’s time to think more about the ‘front end’ – here are some prototype programming blocks made from the ‘holes’ from a hole saw (I’m chopping up bits of driftwood). These include a central drill hole, which we can use for an indicator LED.


This is the minimal circuitry needed for each programming block – it’s just a 4 bit identification code (reconfigurable via jumpers) and the LED, mounted around the 7 pin VGA style plug.


Here it’s mounted in the block after a bit of hollowing out. To be fully kid-proof I’ll probably eventually set the internals in epoxy glue.


Testing the plug/socket wiring on the breadboard. The plan is to paint the top surface of the programming block in blackboard paint so different instructions and languages can be tested and built with the same blocks. It also intriguingly makes abstraction possible, which is usually a problem with non-text based approaches, but this needs more thinking about.


Here it is with another unenclosed block attached to the main board, and via the new interface to the Raspberry Pi. The interface will need a bit more circuitry to drive the LEDs – which will be able to be lit in different ways depending on the needs of the language, perhaps sequential in some cases, more dependant on logic in others. Also, different shaped blocks or different coloured LEDs may have different meanings in a language too.

Hindi translations in Symbai

A couple of screenshots of the hindi version of Symbai – our solar powered Raspberry Pi/Android anthropological research tool. As is usual we’re still having a few issues with the unicode but it’s nearly there. We’ve been working on this software for the last few months, making sure the data (including photos and audio recordings of verbal agreements) synchronise properly across multiple devices.