Chain Reactions (with electronics)

Like everyone else delivering ‘maker’ education, we use chain reaction machines in some of our workshops. There’s a lot of fun to be had, and some intriguing mechanisms to be discovered. But there are also some classic problems:

  1. Connecting bits of a chain reaction machine together is fraught with difficulty. It’s typically the links that fail, and that can lead to frustration when it’s not clear who ‘owns’ the connection.
  2. There’s a tendency for everything to start high and finish low, and hence for each stage to run out of energy somewhat.

One of the things we’ve been playing with attempts to solve both problems, by chucking a bit of electronics into the mix. We use Arduinos as control circuits, running some code which is fairly readily tweaked to handle one of a range of inputs, including:

  • Straightforward ‘short to ground’ switches
  • Light-dependent resistors
  • Force- and flex-sensitive resistors
  • IR distance sensors
  • Tilt switches
  • Hall Effect magnetic field switches

The software is configurable into a couple of different modes, but is typically set to trigger on a threshold reading and operate either a servo, or a continuous-rotation servo as a low-speed motor.

The resulting chain reaction machines integrate physical and electronic segments, and splicing them together is hence usually a case of running longer wires from a sensor at the end of one segment into the Arduino which controls the trigger for the next. Last week we ran an end-of-term workshop with 15 year-olds from one of our partner schools, who came up with the machines you see in these two films. We think they did a cracking job.

Now, we don’t use this workshop very often. The challenge, we find, is that there are so many alien pieces of technology that participants tend to freeze rather than try things out and explore. These groups worked particularly well, but more generally we (unexpectedly?) find this to be a better workshop with primary groups than secondary. Younger children tend to be more receptive to (or familiar with?) failure and iterative development.

However, when the workshop comes together it can produce some outstanding results. We think there’s some mileage in the approach, and we’ll continue to refine the idea.

The code we’re using is on Github, I’m afraid with rather minimal documentation at present. I’ll try to include part details for the sensors, but the code comments should walk you through most of it.