Teaching Robotics to High School Girls at GetSET (Shallow Thoughts)

Teaching Robotics to High School Girls at GetSET

Wednesday I taught my "Robotics and Sensors" workshop at the SWE GetSET summer camp.

It was lots of fun, and definitely better than last year. It helped that I had a wonderful set of volunteers helping out -- five women from CodeChix (besides myself), so we had lots of programming expertise, plus a hardware engineer who was wonderfully helpful with debugging circuits. Thanks so much to all the volunteers! You really made the workshop!

We also had a great group of girls -- 14 high school seniors, all smart and motivated, working in teams of two.

How much detail?

One big issue when designing a one-day programming workshop is how much detail to provide in each example, and how much to leave to the students to work out. Different people learn differently. I'm the sort who learns from struggling through a problem, not from simply copying an example, and last year I think I erred too much in that direction, giving minimal information and encouraging the girls to work out the rest. Some of them did fine, but others found it frustrating. In a one-day workshop, if you have to spend too much time working everything out, you might never get to the fun stuff.

So this year I took a different approach. For each new piece of hardware, I gave them one small, but complete, working example, then suggested ways they could develop that. So for the first example (File->Examples->Basic->Blink is everyone's first Arduino exercise), I gave everyone two LEDs and two resistors, and as soon as they got their first LED blinking, I encouraged them to try adding another.

It developed that about half the teams wired their second LED right next to the first one, still on pin 13. Clever! but not what I'd had in mind. So I encouraged them to try moving the second LED to a different pin, like pin 12, and see if they could make one LED turn on while the other one turned off.

Another challenge with workshops is that people work at very different speeds. You have to have projects the fast students can work on to keep them from getting bored while the rest are catching up. So for LEDs, having a box full of extra LEDs helped, and by the time we were ready to move on, they had some great light shows going -- tri-colored blinkers, fast flashers, slow double-blinks.

I had pushbuttons on the tentative agenda but I was pretty sure that we'd skip that part. Pushbuttons are useful but they aren't really all that much fun. You have to worry about details like pull-down resistors and debouncing, too much detail when you have only six hours total. Potentiometers are more rewarding. We went through File->Examples->03.Analog->AnalogInput, and a few teams also tried LED fading with File->Examples->03.Analog->AnalogInOutSerial.

Music

But then we moved on to what was really the highlight of the day, piezo speakers. Again, I provided a small working example program to create a rising tone. The Arduino IDE has no good speaker examples built in, so I'd made a short url for my Robots and Sensors workshop page, is.gd/getset, to make it easyto copy/paste code. It took no time at all before their speakers were making noise.

I was afraid they'd just stop there ... but as it turned out, everybody was energized (including me and the other volunteers) by all the funny noises, and without any prompting the girls immediately got to work changing their tones, making them rise faster or slower, or (with some help from volunteers) making them fall instead of rise. Every team had different sounds, and everybody was laughing and having fun as they tweaked their code.

In fact, that happened so fast that we ended up with plenty of time left before lunch. My plan was to do speakers right before lunch because noise is distracting, and after you've done that you can't to concentrate on anything else for a while. So I let them continue to play with the speakers.

I was glad I did. At least three different teams took the initiative to search the web and find sample code for playing music. There were some hitches -- a lot of the code samples needed to be tweaked a bit, from changing the pin where the speaker was plugged in, to downloading an include file of musical notes. One page gave code that didn't compile at all. But it was exciting to watch -- after all, this sort of experimentation and trial-and-error is a big part of what programmers do, and they all eventually got their music projects working.

One thing I learned was that providing a complete working .ino file makes a big difference. Some of the "music on Arduino" pages the girls found provided C functions but no hints as to how to call those functions. (It wasn't obvious to me, either.) Some of my own examples for the afternoon projects were like that, providing code snippets without setup() and loop(), and some teams were at sea, unsure how to create setup() and loop(). Of course I'd explained about setup() and loop() during the initial blink exercise. But considering how much material we covered in such a short time, it's not reasonable to expect everybody to remember details like that. And the Arduino IDE error messages aren't terribly easy to read, especially showing up orange on black in a tiny 3-line space at the bottom of the window.

So, for future workshops, I'll provide complete .ino files for all my own examples, plus a skeleton file with an empty setup() and loop() already there. It's okay to spoon feed basic details like the structure of an .ino file if it gives the students more time to think about the really interesting parts of their project.

Afternoon projects

After lunch, the afternoon was devoted to projects. Teams could pick anything we had hardware for, work on it throughout the afternoon and present it at the end of the workshop. There were two teams working on robotic cars (sadly, as with so many motor projects, the hardware ended up being too flaky and the cars didn't do much). Other teams worked with sonar rangefinders, light sensors or tilt switches, while some continued to work on their lights and music.

Everybody seemed like they were having a good time, and I'd seen a lot of working (or at least partly working) projects as I walked around during the afternoon, but when it came to present what they'd done, I was a little sad. There was a lot of "Well, I tried this, but I couldn't get it to work, so then I switched to doing this." Of course, trying things and changing course are also part of engineering ... that sentence describes a lot of my own playing with hardware, now that I think of it. But still ... I was sad hearing it.

Notes for next time

So, overall, I was happy with the workshop. I haven't seen the evaluation forms yet, but it sure seemed like everybody was having fun, and I know we volunteers did. What are the points I want to remember for next time?

• Start with small but complete working examples to introduce each new hardware component.
• Provide complete .ino files, not just code snippets.
• Skip pushbuttons, but do try to cover AnalogInOutSerial and PWM output. Or at least have printed handouts explaining the PWM outputs and LED fading.
• Turnkey kits are good: the less "connect the blue wire to pin 7, the green one to pin 8" the better. For things like cars, I'd like something already wired up with battery and shield, "Just add Arduino".
• Keep a closer eye on the afternoon projects -- try to make sure each team has something they're proud to show off.

Thanks again to the great volunteers! I'm looking forward to giving this workshop again.