On the teaching open source mailing list, the following question was recently posted:
I'm advising a high school teacher who is putting together a computer programming course. We are thinking along the lines of:
- Basic electronics with PIC processors
- Assembly
- C
- Robot programming with VEX
The underlying idea is to make sure that students have ample opportunities to tinker and to see how things work (instead of just using black boxes).
Philosophy
Before I comment on this, I should be clear where I'm coming from. I have taught with small robots in tertiary settings regularly since the release of the LEGO Mindstorms RCX in 1998. I have served as a judge at both the UK regional and national level for the FIRST LEGO League, and I continue to contribute to the development of runtimes for these small systems.
My philosophy regarding teaching is that it should be authentic, constructive, and fun. The shortest reasonable summary I can provide is as follows:
I believe good learning experiences should be authentic, constructive, and fun. Learning experiences are authentic when they reflect the needs of the learner both now and in the future. They are constructive when the student has the opportunity not just to create an artifact, but also to build their own understanding of that creative process. This process is fun when the learning is both engaging and challenging.
The Educator's and Students' Needs
Teachers work long hours and are underpaid for the work they do. Between 7AM and 3PM they're responsible for their students, with (possibly) an hour of time during the day where they might be free to "prep". The truth is that "preparation time" for many educators comes either early in the morning or after work. Many teachers spend one, two, or more hours after work (either at school or at home) preparing their lessons for the next day. Weekends, likewise, are often time spent catching up, grading, or doing other work that (in theory) should be doable during their "preparation time." Put simply, educators work hard.
If a teacher wants to engage their students with extracurricular activities, or opportunities that do not casually slot into the standardized curriculum, they are talking about committing their own time to their students. In the world of open source, this should be familiar... the donation of time to a cause that matters to the individual. If that donation of time and effort isn't successful, it will still impact them negatively when it comes time for professional evaluation—even if it was a "donation." If the students or parents complain about the teacher's efforts, no one will care if they went "above and beyond," they will only care that things may have gone wrong.
For these reasons it is absolutely critical that if you are going to offer to help a teacher with some educational activity that you are fully committed to supporting them throughout the exercise. This is not a patch that you fire off to a mailing list and hope someone picks up. It is not a ticket you leave languishing in a tracking system, wondering if someone might do something about it. You must be 110% along side the teacher from start to finish. And the reason for being there isn't because it makes things better for the teacher: you're there because it means a better educational experience for the students. Never, ever forget that.
Principles for Choosing Technology
If you're trying to bring technology into a classroom or learning experience, there is a critical rule that you must adhere to at all times: the technology must JUST WORK. If they already have Windows machines in place, and they work (and are supported by an admin), DO NOT suggest that everyone boot Sugar on a Stick to carry out your exploration of robotics in the classroom. Neither the teacher, students, or admin will be familiar with the tools, and if anything goes wrong, you will have done nothing more than applied open source technologies to detract from a student's learning experience. If the point of the exercise is to learn about open source tools, then great—do this! If the exercise is about success in being exposed to programming, don't confuse the matter. Use what is there and is institutionally supported.
Second, choose technologies that will yield success early and success often. This is a mantra I try and apply to my own teaching. My commitment to this ideal is why I have little respect for people who say students should start by learning assembly, or insist that "C is where I started, so should they" or that "Perl is a great scripting language to teach with." Assembly should be generated by compilers. C is a horrific language that does nothing to protect the developer from themselves—especially novices. A bowl of alphabet soup is probably syntactically valid Perl. None of these technologies yield success from the start, and none support a novice in learning big ideas and concepts quickly... they just teach students about the worst of the tools we use as software developers, and require them to try (and fail) to think like experts on day one.
Pick technologies the students can learn and be successful with, not tools that experts continue to struggle with in their daily practice. Scratch. Alice. Greenfoot. NetLogo and StarLogo. These are just a few tools that were designed for beginners, and they are where you should look to if you want to introduce students (successfully) to programming.
If your goal is to do something in the physical realm (small robots or similar), then I have a few more thoughts I'd like to share. All of the above still applies, of course.
Technologies to Avoid
I would rule out PICs and assembly. In no small part this is because Microchip insists on keeping parts of their toolchain proprietary, which means you would be introducing your students to tools that they will never fully own. Atmel makes perfectly good processors, and with the Arduino you can do some really awesome things (plus, it has a massive user community). That said, I would tread carefully in this space. Having recently introduced soldering to 12 college students, I learned many things. Despite creating a complete set of videos to support their build process, I still had the opportunity to learn about:
- Cold solder joints...
- Bad oscillators...
- Burning in missing bootloaders...
... and many other problems. The bad oscillator (a bad component in one of the kits) took 4 hours to diagnose. While this was rewarding in the end, it would have been disastrous in a 1-hour after-school computer club (or 50-minute, 3x a week classroom setting). Or, perhaps that is exactly what you want your students to experience... you have to weigh the possible problems and the possible learning outcomes against the particular needs of the teacher and students.
If the purpose of the educational experience is to learn about soldering, electronics, and their relationship to computing, then go for it! If the purpose of the experience is to engage students quickly and empower them to do cool stuff from the start, an Arduino kit may or may not appeal to your target audience. This would absolutely be the platform I'd introduce students to, though, if my goal was to explore embedded electronics.
Technologies to Try
Having expressed my concerns regarding technologies I would not start with, let me talk briefly about some technologies that should serve well in K-12 classrooms.
The IPRE Scribbler/Fluke
The Institute for Personal Robotics in Education is a joint venture between several academic institutions and Microsoft Research. The Scribbler platform provides a vehicle for exploring robotics through the Python programming language. The text and curricular materials supporting this exploration is open, as are all of the tools involved in the project.
The IPRE has a lot of years of effort in it, and represents an excellent open resource for learning about robotics and AI. The IEEE Robotics and Automation society provides a number of (mostly open) robotics education links; the IPRE's work features heavily in this list.
The LEGO Mindstorms
The LEGO Mindstorms is over a decade old. It has a massive community of users, and has serious industrial and user-centered design behind it. The technology is robust, and there is a great deal you can do with it quickly. I am a fan of the RCX and NXT.
Both require infrastructure: you must have software installed on your PCs (either what ships with the kits or Robolab, a visual language based on LabView). You need a way to recharge the kits between uses—this is easier with the NXT, and harder with the RCX, as the latter requires 6 AA batteries. (This also implies that, for 10 kits, you need at least 60 rechargeable AA batteries.) You need space for the students to work, and ideally space to store models that are in progress between sessions.
The reason community matters (do I need to say that here?) is because the teacher can grow their exploration into larger opportunities for their students. Both Botball and the FIRST LEGO League are excellent competition frameworks that teachers can plug their students into. These kinds of competitions provide a way for something that begins as an exploration to grow into a high-profile (and educational, and excellent) opportunity for the students and teacher(s) at the school to engage in. Lastly, there are excellent curricula available from the CEEO at Tufts as well as through LEGO Dacta.
VEX Robotics
I don't know as much about VEX, but there are many similarities (conceptually) with the LEGO RCX/NXT platform. There are several curricular resources available to teachers, and the kits are designed with student learners in mind. Like FIRST LEGO, there are competitions teachers and students can get involved with, and there is a community of practitioners surrounding the tools who can act as resources to you and the teacher you are working with.
In Conclusion
I may have ranted a bit, but I'm passionate about students having excellent learning experiences with technology.
Tools like the IPRE Scribbler/Fluke, the LEGO Mindstorms, and the VEX kits provide a great jumping-off point into tools like the Arduino. Once students have a taste for success and what is possible, I think you should absolutely get a soldering iron into their hands and turn them loose. Or, you can start there... but you need to be prepared, from the beginning, to support their activities thoroughly. Whatever you do, remember: focus on learner needs, and strive to encourage success early, success often!
9 Comments