Cowterpillar robot

This is a bit of a retrospective of teaching Robotics as a subject to Year 8 students this year. A bit of a theme for my newish subjects tends to be a reduction in expectations as I filter out what I would have liked to have worked into what actually worked and variations on a theme.

The three themes I’ve really thought about since I started teaching this subject are:

  1. Programming environment
  2. Inputs and outputs
  3. Project freedom and complexity

My typical course runs something like this:

  • Spend some time looking at what robots are and their variations (inputs and some form of output affecting their environment) like robotic systems (~2 lessons).
  • Programming crash course using different sensors and outputs as a theme (single sensor or output at a time) (~half a term).
  • Electronics crash course in building simple circuits, and understanding digital and analog systems (~half a aterm).
  • Personal or group project (~6 weeks with some post project evaluation).
I currently get 2 lessons (of 45-50 minutes each) per week over around 20 weeks (1 semester). Assuming I lose students for around 6 lessons due to absences, public holidays, excursions etc, this means I have about 22 hours with them in total.

Programming Environment

There are two options which students have (with easy access anyway): MicroPython and Microsoft MakeCode. Being a fan of Python on the desktop/server I have always leaned towards MicroPython as my language of choice when programming Micro:bits, since you’re using the fundamentals of a general purpose programming language and complex programs are much easier to manage than block-based programming. However there are a couple of significant downsides: there is very little memory available for your program, and events and signals aren’t a thing, meaning you need to poll for events, making interactive programs quite tricky in some cases, and any work with SPI or I2C modules mean you’re trawling Github for libraries or learning about their arcane implementation rites.

MakeCode on the other hand benefits from a decent library management system that’s easy to search through for kids, a lack of syntax errors (although occasionally my students get burnt by trying to compare integers to strings), being able to fit quite complex programs onto the Micro:bit, and most importantly events, although these can be a double edged sword. One of the issues some of my students run into is multiple Forever loops or button inputs with pauses accessing and causing race conditions with variables.

The downside is that complex programs end in you panning around the program canvas continuously at tiny zoom levels, and rearranging your code chunks all the time so they don’t overlap (or taking your life into your own hands and asking the browser to format your code and then spending the next few minutes finding all your chunks again).

Electronics

When I started out with the Robotics subject in 2018 there were a pretty large array of sensors and outputs that I wanted to use so that students could really build a range of diverse projects. Unfortunately, even though these all worked in very similar ways (analog, digital, or through a protocol like SPI/I2C) lots of students struggled because they either didn’t have the time to practice and get comfortable, or had trouble deciding on a direction because of an All The Things problem.

This year I cut down my set of explicit instruction and practice to a few different components:

  • Servos (continuous and standard)
  • WS2812B LEDs (“Neopixels”)
  • Speakers
  • Passive InfraRed sensors
  • InfraRed line followers
    (These were without fail used as proximity switches rather than their intended purpose)
  • Potentiometers
  • Light Dependent Resistors

This gives students a few options for different methods of input in addition to the accelerometer, buttons, etc built into the Micro:bit, and a range of outputs that can exhibit different behaviours (stationary, moving, visual, audible).

Most students this year created projects involving servos, RGB LEDs, and PIR sensors, and they ended up with some fairly diverse sets of features, so I’m pretty happy to work with that set of tools going forward.

I soldered up a whole bunch (~50) of RGB LEDs to 3 port plugs to make them easier to use and practice with. This worked really well, except next time I’ll cross over the voltage and data pins so the plugs can go straight onto the pins on the Micro:mate boards in the standard Ground-Volage-Data order. Normally I just pull the male ends off some of my male-female dupont jumper leads and solder the ends which were crimped into the plug onto whatever I’m working with. Saves me doing up dupont plugs myself and doesn’t cost a lot.

Projects

My biggest lesson from eight groups of student projects, is that a reduction in the freedom to choose is a Good Thing. Extension kids will roam free without my encouragement (or in most cases event explicit permission), and the reduced scope tends to make it easier for the students who struggle.

My first set of projects focused on the UN Global Goals, and although these gave some good real world focus areas, there is still an intimidating array of different paths which could be pursued. There’s good scope for building interesting (yet fairly simple) environmental monitoring tools such as water quality, data logging of temperature, soil moisture monitoring and so on, but reading through each of the goals and their associated targets is quite time consuming.

This year I have predominately focused on animatronics. Whilst it’s a bit light and fluffy compared with getting students to think Deep Thoughts (in a Douglas Adams sense) about solving global problems with robotics, it’s also much more achievable in the timeframe that I have available to me. In the future I intend to build some learning resources around environmental monitoring as an aid for students in understanding how different types of sensors operate.

Here are a couple of short Twitter threads with some of the projects my students have built in the latter half of this year:

I really like Robotics as a teaching area; it incorporates a lot of the Digital Technologies curriculum in an effortless manner (such as evaluating designs, designing for user interaction, the role of hardware and constraints of speed and memory and so on) which can be difficult in other settings where these ideas sometimes need be put into a quite contrived context. This isn’t without drawbacks however, since to run an effective Robotics class I am constantly trying to balance teaching the three main topics of algorithms, electronics, and design (since many final projects are 3D objects laser cut to fit components), which is a real challenge given the limited timeframe.

Just to finish things off, here are a couple of short videos from a pair of my favourite projects from the first half of the year, a cow being abducted by a UFO (the pulley system just never really worked out sadly) and a papercraft corgi that shakes its head and woofs (and by ‘woof’ I mean uses the speech module in MicroPython to say ‘woof woof’ :).