Last week, I had the privilege of teaching robotics to kids for the entire week. I had two groups: in the mornings I had four kids between 9 and 10 years old (shown in the photo above); in the afternoon I had five kids between 10 and 12 years old. We used Lego Mindstorms NXT 2.0 hardware kits. We programmed the robots using a graphical programming language called Enchanting (which is an extension of MIT’s Scratch and Berkley’s “Build Your Own Blocks (BYOB)”). The course was run by the wonderful Fire Tech Camp, a new UK company which runs “tech camps” for kids during school holidays. FireTechCamp run a number of courses; I only taught on their robotics course.

I was very lucky to have another tutor, Alistair Poat, with me for the morning sessions. Ali is not only a great teacher and a lovely guy, but he also pioneered the FireTechCamp robotics course over summer.

At the end of the week we ran “robot sumo” competitions. It was based on the robot sumo competition described on the “Enchanting Cards”. Two robots compete. The aim is to push the other robot out of the ring. The robots are completely autonomous. They use an ultrasonic sensor to detect their enemy and they use a light sensor to detect if they’re over the line. Here’s a video of the robot sumo competition we ran for the younger kids:

and here’s a video of the competition for the older kids:

Here’s one of the Enchating programs for the sumo competition (this code wasn’t spontaneously generated by the kids; it took quite a lot of hand holding to get this code together. And the code shown below isn’t the final version; the final version put everything into one thread and got rid of the costume changes):

enchanting_sumo1

Which brings me to one of the things which slightly blew my mind…

Kids naturally create multi-threaded code

The code above has two threads of control. On the left, we have a “sensing” loop which continually checks the state of the two sensors and sets two boolean variables. On the right, we have an “action” loop which acts on the state of the boolean variables (now that I think of it, I’m really not sure why we bothered ever using two threads but never mind…).

What really surprised me is that kids just naturally create multiple threads of control in Enchanting. Literally, on day two, some of the kids were writing multi-threaded code. At age 10. Why is this so surprising?

I grew up with single-core computers (specifically the ZX Spectrum +2A and a few IBM PCs). When I finally decided I wanted to study computer science formally at Imperial, we were first taught about procedural aspects of C++, then object orientation, and then we were briefly shown multi-threaded programming. My take-home message from that first exposure to multi-threaded programming was “it’s bloody horrible and you should stay well clear if at all possible”. (I have subsequently written a fair few multi-threaded programs and have learnt that it isn’t that frightening… but… anyway…). The point is that, prior to the FireTechCamp, I thought that multi-threading programming is something that only trained adults were capable of doing; and that it took great care. Yet young kids appear to naturally think that multiple threads are a good way of solving problems which feel “naturally parallel” to them.

During the FireTechCamp tutor’s training day about a month ago; I had a really interesting chat with another tutor about parallel programming. The conclusion of the conversation was something like this: Today’s kids are swimming in cores no matter which hardware platform we consider: mobile phones, games consoles, PC CPUs, GPUs etc. Heck, even the Lego Mindstorms 2.0s have two processors (an ARM and an AVR processor). Parallel programming is going to be a much larger issue for them (if they go into software engineering).

So isn’t it wonderful that kids naturally create multi-threaded programs, almost without knowing it? (Of course, they don’t know about all the problems of multi-threaded programming). I wonder if there’s a way to encourage and guide that drive to write multi-threaded programming?

Testing

Another thing which I found suprising is that some of the kids were somewhat over-confident about their code. If I suggested that they should test a small piece of (untested) functionality on their robots before coding more functions; some kids would reply “but I know it works; why do I need to test it?” by which they meant: it looks fine to me therefor it must be fine. They quickly learnt not to be quite so confident!

Stuff the kids would do when “bunking off”

The attention of some of the older kids would sometimes drift. I was amused to see what they got up to when they were drifting. They particularly liked:

  • changing the colour scheme of the Windows command line. (It’s a shame OSes are so big and complex today. I fondly remember getting kicks out of disassembling MS-DOS’ command.com and changing some of the text. So instead of it saying “Bad command or file name” it might say “Bum command or file name”. God I was witty.)
  • Importing models of sports cars into SketchUp
  • Listening to Skrillex on YouTube.

Levels of abstraction

One thing that I took a while to figure out was what “level of abstraction” to use for each age group. For example, a 10 year old asked me “does the light sensor ever return negative numbers?” to which my knee-jerk reply was “what would a negative quantity of light look like?”. I got a totally blank stare in response! I quickly learnt that not all 10 yearold are ready for a philosophical discussion about representing physical quantities on a computer!

Engduino

On the last day, we gave the older kids a session on the Engduino which is a device designed at UCL. It’s basically an Arduino with a bunch of sensors and LEDs on the PCB so you can start doing interesting stuff with the board without doing any electronics first. It’s a lovely package. The kids were perfectly capable of copying out the C code from the work sheets and making basic little modifications. But it might have been nice to have given them a quick introduction to C first. For example, one kid asked why we have to write void at the very start of each function definition (as in void setup() { /* do something */ }) (he didn’t use the term “function definition”!). I tried to explain functions and return values in 30 seconds and failed misserably.

Summary

I had a really great time and the kids seemed to enjoy themselves too. Fire Tech Camp are a lovely company to work for. I’d highly recommend having a go at teaching kids coding. It was exhausting though! Unfortunately I might not get the time to do another week-long course for a while but I hope to do some more teaching again soon.