During the 2015 – 2016 school year, I organized and managed my child's school computer club. I trained as a teacher, so I was not intimidated by the kids. On the contrary, I found the experience fun and stimulating, especially considering there was no stress of exams or grades.
I decided we would go beyond learning to code and move onto "making". I had the brainwave that building and programming robots would be more interesting than just coding some lines on a computer screen.
As this was a club and not a class, we decided the children themselves would choose the projects and what they would build. The learning experience would come from researching and figuring out how to make their inventions work.
The kids were aged between 10 and 14 and their suggestions were colourful to say the least. One group wanted to build a satellite. After a while, we agreed this would be, to put it mildly, a little beyond their level of competence. But, hey, we could build the payload for a weather balloon – all we needed was a Pi, a camera and a bunch of sensors… And then try and launch it into the stratosphere.
Another group wanted to build a 3D scanner. After a bit of research, we discovered this is pretty easy. All you need is a rotating platform, a camera and a laser.
Finally there was the group that wanted to build a pair of mechanical walking legs. If you have ever enjoyed the videos of expensive walking robots falling over, you will know that bipedal locomotion is quite hard. We decided we would start by taking baby steps (heh!) and see how it went.
We bought a bunch of cheap Arduino kits (containing lasers, sensors and motors) and a couple of Rasperry Pis to get started. Acquiring stuff on the cheap from China turned out to be a good choice. Not only were we able to kit out each team with their own set of hardware, but if any of the kids burned out a component, as they often did, it wasn't a big deal.
When a component failed, we used it as a good opportunity to learn something too. The first casualty was a digital temperature and humidity sensor, which melted. The team studied the component and, with a little help, discovered they had run 5V through it when it should only have been fed 3.3V. We pinned the component to a cork-board and the kids wrote a short, one paragraph "report" on why the component failed and stuck that on the board too. The report also listed the cost of the component.
Several red LEDs followed the sensor on to the cork board. They also burnt out because the kids had used voltages that were too high. More research and report writing ensued.
Then a whole Arduino board failed and we were unable to figure out why. The kids chalked it up to faulty manufacturing and decided to make a note of whether any other boards broke. If they did, they would know the manufacturer was unreliable and, next time around, they would advise buying from another provider.
We never reprimanded the kids for accidentally destroying components. There is no point in inviting children to experiment if the experiments can't fail. Thanks to the research into why a component failed and writing out a report detailing the cost of the failure, the children were much more conscious of what they could and could not do, so were much more careful. They rarely made the same mistake twice.
The things the kids learned went way beyond coding, even beyond electronics. They learned how to research and autonomous problem solving. They also learned that resources fail and you have to take potential failures into account. In short, they learned how to carry out a project.
Unfortunately, because we started half way through the year and the club met only once a week, we did not have time to finish the projects. The next year, the school's administration changed and the computer club was cancelled.
Be that as it may, I think the children of the computer club at St. George's school went away with some valuable skills that will help them later in life. I also hope they acquired the itch to become makers.
Editor in Chief