Tag Archives: sonic pi

Training teachers in coding, and thinking about e-waste/recycled robots

We recently had the second inset training day in programming related activities at Truro school. Following on from the previous session I didn’t want to introduce too much new stuff, so we concentrated on going back over Sonic Pi and Minecraft/Python programming in the morning, then discussed a lot more about our future workshops in the afternoon. These will include children from most of the primary schools in the Truro area and take place during the next term. I also wanted to use the day to work on some specific ideas the teachers wanted to get going. One of these involved running a Kinect camera with the Pi, which we managed to get more or less working – reading depth data in Python for potentially plugging into Minecraft at a later date.

IMG_20150617_143455

The big idea I wanted to get feedback about was the use of robotics and electronics in conjunction with code (the photo above is my desk while preparing the day before). I didn’t have any lesson plans for this, but based on some comments from the first workshop and from playing a bit with this during CodeClub teaching I felt it might be good with this age group, who already know quite a bit about screen based activities. To keep costs down (as well as building in issues like e-waste) we’re planning to make use of recycled junk to extract motors from toys and hack them to do different things. It seems this doesn’t cause too many issues from safety POV (everything will be low-voltage and we can check everything beforehand), even the use of soldering irons seems to be acceptable as they have supervision.

The advantage of using code to move real things (as shown by a long history) is that it directly connects programming with the world outside of the screen (where it most certainly now has great importance in our lives), and at the same time results in teamwork – as it’s not easy for a single person to make a robot while programming it. When we tried this at Troon Primary they self organised into a group with one person programming while another was building stuff in lego and a third provided excited communication between them and more or less managed the task. Other programming activities tend to be more individualistic – with the possible exception of networked Minecraft, which is important but a very different form of collaboration.

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.

IMG_3478s

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.

IMG_3479s

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.

IMG_3480s

Minecraft/Python

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.