This semester I taught four separate sessions on the Arduino and Raspberry Pi platforms — two aimed at developing skills and two aimed at brainstorming project ideas. I’ll touch on the two that were the most challenging to devise: Raspberry Pi Basics | Python and Pi and Arduino Basics | Sensors and Servos. This isn’t new — plenty of fantastic libraries are actively supporting these technologies, but I’m not sure whether we’re clearly documenting how to teach them. I had trouble finding any resources on best practices for teaching these within the constraints of a one-shot method. So I’m sharing my approach, and what I learned from it, in the hopes that it helps others librarians doing similar work.
Developing Learning Outcomes:
Given the time constraints of the one-shot, I knew I had to prioritize — I could either go for a deep dive into the topic or I could keep it purposefully broad for wider exposure. And more importantly, I wanted every student, faculty, and staff member who attended to feel like they belonged — less jargon and specialized knowledge requirements, more getting your hands dirty no matter your background. So I emphasized broad exposure as a primary learning objective. This meant:
- We covered the absolute basics — what a sensor or servo is, what the Ardunio and Raspberry Pi are, and how those add-ons individually connect to them. I like to think of this as the simple exercise model — e.g. lighting up an LED.
- Adapting the simple exercise model above for CU’s science community. I focused on picking a sensor that could be used in advanced projects without diving into advanced specifics. (I chose the Ultrasonic Distance Sensor and Continuous Rotation Servo.)
Pros: By emphasizing exposure, I was able to say — this is a no pressure session. If you don’t leave the room understanding every little thing we talked about, it’s okay. The important thing is: now you know this exists. You’ve gotten experience digging through sample code, of setting up one part of a project. You can build upon that when you leave this room (and you also know who to come to if you feel like you can’t). Quick tips:
- I used pre-written code snippets; this saved time and allowed attendees to focus on comprehending how the sensors were behaving at a basic level. (Again, with the hope that they might build upon this later.)
Cons: Broad is good, but students still had questions about how these sensors could be used in actual projects (despite providing project examples). I think they had trouble seeing the bigger picture with this method.
Structuring the Session:
The nature of these workshops was all about hands on collaboration. I started by providing a brief (10-15 minute) spiel about what the hardware was, how it worked, what it operated on, and what programming languages it paired best with. Then, I asked everyone to introduce themselves to the people around them — aka, their new group members. For the duration of the session, they worked together on a series of open-ended exercises that I’d devised (with the option to veer off course, depending on their skill level). The only rule was: everybody “drives” at least once; meaning, no one person should do all the work. The open-ended lessons were structured as such:
- I got to expose participants to both the hardware and other like-minded individuals; people worked with and learned from one another as the session went on.
- Adding on the “challenge” portion of the lesson allowed me to provide attendees with a flexible low-floor, high ceiling experience; it was VERY cool to see people who ditched the sensors and servos entirely to work on programming an LCD to display data recorded from the Arduino.
Cons: The success of this method largely depends on who shows up. You’re taking a gamble that you’ll get a decent mixture of skill levels, but that may not actually work out.
So even though some things went well, these few really didn’t:
- Including a coding intro. These were 10 minute overviews of various languages (like Python and Wiring); the idea was to give those who’d never programmed before some common knowledge. However, there just isn’t enough time for this to be effective; folks who already knew it were unenthused, and those who didn’t were hard-pressed to understand anything during my flash-coverage of it.
- Showcasing project examples before we got started. Showcasing too many took time away from the hands-on portion. In the future, I’d shorten this to include 2 or 3 really interesting examples, rather than the 10 I used.
- Not using a floater. Let me tell you — these hands on sessions can get out of hand real quick if you don’t have all hands on deck. Consider using other tech-savvy staff to help troubleshoot issues.
- No info is ever “too basic”. I didn’t think to say — “See how the metal rods connecting this sensor to the Arduino are straight? They’re supposed to stay that way.” But 40 minutes in, after noticing that one group actually bent their sensor to fit a part of the board it wasn’t supposed to, I realized — yep. I should’ve included a “no bending” note. This also means I should’ve covered how to properly slot sensors into the board; leaving up a diagram on the screen that showed how to connect it wasn’t enough. Overall, be as thorough as you can with any and all explanations.
I’m not disillusioned into thinking that this is the only way to teach Pis and Arduinos; I’d love to hear about strategies you’ve tried, or even better tips you have, on doing this. And if I missed some ridiculously awesome “How-To-Teach-Raspberry Pis-And-Arduinos-When-You-Have-NO-IDEA-What-You’re-Doing” handbook that you know of, please send it my way!