Introducing hands-on computing in secondary education

No readers like this yet.
Several crayons

Opensource.com

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!

User profile image.
Matt is passionate about the design and development of usable languages for embedded control. You can some of his work at concurrency.cc, a rallying point for parallel programming on the popular Arduino platform. However, most of the time Matt keeps himself busy as a member of the faculty at Berea College.

9 Comments

I know there's a ton of noise around Mindstorms and open source -- how much value do the various open source projects add to the Mindstorms experience? Have you played with that at all?

Hi Greg,

I didn't want to get bogged down in this article on any one of the platforms; the Mindstorms has an interesting history w.r.t. open source.

The RCX was closed, but LEGO (wisely) did not pursue litigation when the RCX was completely reverse engineered. pbForth was one of my favorite projects for the RCX: <a href="http://www.hempeldesigngroup.com/lego/pbForth/homePage.html">a complete Forth interpreter running on the LEGO brick</a>. You sent it text, and it compiled it and ran it right in the 32KB. (I love Forth. I mean, just as a matter of principle... a language-extending language you can bootstrap with little more than 1KB of flash. Awesome... but I digress.) There was also <a href="http://bricxcc.sourceforge.net/nqc/">NQC</a> (Not Quite C) and a number of other efforts that gained a fair amount of traction. (Porting software to the RCX was a pain, though... everything you did was over an IR link, so if you crashed your firmware, you lost the ability to debug...)

When the NXT came out, LEGO acknowledged its community rather intelligently. It brought critical members of the hacking community together, and they listened to their input. The firmware was open (but I think there's a copyrighted phrase in there or somesuch), and from the get-go people were hacking new runtimes and languages for the NXT, a 60MHz, ARM7-powered device. It was possible to get a JTAG port on the device, but most everything you might want to do as a hacker was possible over the USB connection.

<a href="http://www.botmag.com/articles/10-31-07_NXT.shtml">Many languages and tools for programming the NXT</a> have been developed. NXC (not eXactly C), pbLua (also by Ralph Hempel, developer of pbForth), and NXJ (a Java environment for the LEGO NXT) are all open solutions. I have not touched any of these in several years, so I cannot speak to their maturity with any authority. <a href="http://bricxcc.sourceforge.net/nbc">NXC is a port of NQC from the RCX</a>, so is mature toolchain, and <a href="http://lejos.sourceforge.net/">NXJ is a revision on leJOS</a>, the Java runtime for the RCX. Ralph Hempel is a great developer, and is an example of what one person can do when they're passionate about something---I think the vast, overwhelming majority of the work on both pbForth and <a href="http://www.hempeldesigngroup.com/lego/pbLua/">pbLua</a> was all him.

(Shameless note: our environment for parallel programming was recently ported to the NXT; it's <a href="http://projects.cs.kent.ac.uk/projects/kroc/trac/browser/kroc/trunk/tvm/nxt/">now in our tree</a>, but needs some love before we integrate it into our development environment and can support it with documentation.)

So the NXT paved the way for people to do cool, open stuff with their LEGO robots. I probably should have highlighted that better in the article, but I felt it might get a bit long in the tooth. That's why we have comments, though. :)

Mindstorms look like a load of fun right out of the box. When you use Mindstorms, are you stuck learning the RCX code or can you use other software and languages with the LEGO hardware?

Hi James,

See my previous reply. You aren't stuck with the tools LEGO gives you, by any stretch.

This is a great focus on the issues at hand. To not push personal open-source-friendly devices just because it is open source, but to use what will be the most beneficial!

There's a reason why BASIC was taught for so many years, and I don't think it was because of Microsoft!

Matt,

We build our own PC's, and program routers, switches, Lego Mindstorms (Robofest), C++ (GCC), Assembly (Droidbattles), shell scripts, etc. This is all done with high school juniors and seniors.

We also do one more thing that is not mentioned here. We build our operating systems from scratch using Gentoo (or LFS), and stick with Linux all year.

Our class is a blast. My students love learning all of this stuff and I love to teach them. Do not underestimate the potential of teenagers.

Sincerely,

Paul

Hi Paul,

I believe our students are capable of great things. I don't mean to suggest you shouldn't expose them to everything and anything... I only suggest that when working with teachers or recommending tools that one is prepared to support the teacher and students fully.

It sounds like you're in a position to support your students well. In which case, you're able to provide positive educational experiences. When the technology gets in the way, that isn't a good thing.

Keep up the awesome work.

I highly recommend online education but make sure its a good program. My suggestion is to stay away from generic schools and try to find a program that will add credit to your resume.

I have been using Alice in my 8th grade classroom for the past couple years. What a wonderful application to teach programming principles. It is free at http://alice.org . There are also several tutorals that were created by teachers.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.