We’ve been running our own summer school for many years now, and over the course of these years we’ve learned a lot of details about running them. Robotics summer schools present their own unique challenges which might not be obvious from the start. Our hopes are this post will help those who haven’t had any experience running a summer school, and want to follow in our footsteps and run their own robotics summer school.
Student knowledge
At the start of the event, you can’t assume much prior knowledge of the students. If you’re running a school as short as our one (1 week), the strongest constraint by far is time. Students (or their parents) sign up with ambitions that roughly fit into 2 categories: “I love technology, I want to do more as a summer school” or “I haven’t done any tech but I’m interested in looking into it”.
Students never tell you about how well they’re doing. This is a general rule anyway, but especially so for tech challenges, there’s this underlying assumption that other students know more about electronics, or programming than they do, so they keep quiet more so than in a normal school setting with students who all know each other. To that effect, it’s super important to humanise everyone who’s taking part, so icebreakers are important.
What hardware to use
Our summer school uses our own custom-designed kits. The designs are completely open-sourced. We use raspberry pi's and arduinos for IO and our custom boards for motor and power controls. We decided to create these kits because we wanted to allow the students to learn woodworking, metalworking, and quickly produce a robot. The current consumer kits typically focus on smaller robots, and kits which support larger robots are more expensive than manufacturing our own kits. Smaller robots need to be precision-made, whilst bigger robots can be planks of wood with 2 motors attached. Drill the wrong holes? It’s fine, just drill some more in the right place. Our kits are all put in laser cut plastic cases, which protects them from students fingers. Students usually ignore any warnings about touching metal. It's not a health and safety issue, it's more likely that they do damage to the boards than themselves. I've once spent ages trying to debug a magnetometer which was randomly resetting, only to find out that the student was was holding it by the IO pins.
Prototyping robots is essential
One common mistake we see by our students is they never prototype their robots, If time is tight, it’s one of the first things they decide to skip. Prototyping is extremely important for spotting the smaller mistakes, common questions you should ask students are: Have they left enough space for the wires around their board? Have they even thought about where all the boards go? Have they thought about how they’re going to mount their sensors?
Students resist making prototypes, they're usually aware of the time and want to get straight into making them. The only way to make sure the students make prototypes for their robots is to force them; Hide the real tools, give them cardboard, scissors, and tape. Let them use real electronics and sensors, so they know where to fit them. Ask them where the wires will go, ask them what materials they will make things out of. Once they’ve prototyped it, they can then start on the real robot.
Keep a schedule for them
We give students milestones to achieve each day, it’s important to get them to having a working robot by the end of it, we typically give them the second half of the Monday to prototype their robots, then the Tuesday morning to draw out designs on wood to be cut out over lunchtime. We then introduce them to coding their robots in the afternoon. By Wednesday they should have a robot that moves, and by Thursday it should be scoring points. Then, they compete on the Friday. Try to keep them on schedule, ask them how they're doing and regularly update them with how far they should be.
The problems we need to solve
One of the biggest issues we have with our summer school is we need to put students in teams, the individual students specialise. In teams of 5, we usually have 1 or 2 be the ‘programmers’ and the rest be the mechanical engineers. The mechanical engineers start off with the bulk of the work, but the issue is their work tails off in the last day. We end with 2 students working intensely on the code, and the rest getting bored. It works against what we aim to do, which is give everyone an experience of all methods of engineering. We aren’t sure how to solve this whilst still allowing the students to build their robots in time. We could make the teams smaller, but even with 2 students they will still split themselves into a programmer and a designer.