Teaching Programming With Scribblers

Parallax has been making a tank robot called the Scribbler for a while now and in fact will be selling a second version starting August 2010.  It’s a cute little blue ‘bot that I’ve been using to pretty good effect in my Creative Computing class using an add-on board by the Institute for Personal Robotics in Education, a Bryn Mawr, Georgia Tech and MSR endeavor.

The Scribbler itself comes with a visual programming interface I haven’t explored much at all but the add-on board (Fluke) allows for over-the-air programming in Python.  I teach Creative Computing in Python so I saw these ‘bots as a nice opportunity to expose students to an interesting problem space using programming tools they would already be familiar with.

At Bryn Mawr and Georgia Tech, the robots are used as the primary context for learning about programming but I’ve got some reservations about that approach.  I find the robots are fun for about two weeks and then their limitations really come through.  I would worry about irritating students by spending too much time with them so I introduce them late in the semester as sort of a ‘hey, look what you can do with what you know!’  I think it’s pretty satisfying for students to realize that all the concepts they’ve learned — iteration, conditionals, user input, variables, etc — can produce intelligent-seeming behavior in physical objects.  I also really like introducing students to the idea that information can be translated between forms to produce interesting effects.  For example, one exercise  I have students do makes their robot into something like a theremin by using light sensor values as beep frequencies.  Yesterday some students who had finished required activities were expanding on the idea of taking information in one form and using it in another to have their robot ‘sing’ an image by changing the beep frequency based on the amount of red in each pixel.  It was surprisingly nifty.

Issues I’ve run into:

• Bluetooth is unbearably flaky — there are range issues, interference issues and so on.  Also, on Windows XP, the COM ports change constantly which is irritating beyond belief.  Every time the robot needs to be reset, students have to pair with their robot again and reload the libraries.  Pretty much unacceptable.
• The myro library will inexplicably crash fairly frequently.  For example, it’s not uncommon for robots to stop being able to take pictures for a while.  The joyStick() command freezes all the time.  Again, very frustrating for students.
• Everything is slow.  Moving is slow, taking pictures is slow, reading sensor values is slow.  It makes for a good lesson on embedded systems and their limitations, but again I think that’s only tolerable for about two weeks.
• The sensors suck.  Sorry, but there’s no other way to put it.  The only two that work somewhat reliably are the light and obstacle sensors.  The others are worse than useless: they suck your time away and irritate you to no end.  Luckily I’d done enough playing around on my own to realize this before letting students loose on them.  The stall sensor, brightness sensor, line sensor, IR sensors are are mythical if you ask me.  It may be a myro issue, but I’ve never seen them give any sort of reasonable output.  Super frustrating, and again reduces the robot’s usefulness significantly.

People always ask me why I wouldn’t choose Mindstorms, especially given the limitations listed.  I’ve done enough outreach work with Mindstorms to have concluded that they’re great for mechanical engineering instruction but not so hot for learning to program.  It’s cool to be able to build custom robots but parts get lost, fall off and generally just take away time from programming so that was not an option I was willing to consider.

I do think the Scribblers were the right choice for what I’m doing.  At $200 each including the Fluke, they won’t break the bank and they’ve been very little maintenance.  I have 15 of them and they’re all doing fine even after a couple hundred students have used them over a year.  I know the Fluke looks fragile, but they’ve taken several face plants and been just fine.

I tried using them as an introduction to Python programming with students who had only used Scratch and I’ve decided not to do that again.  All the limitations are too frustrating in addition to trying to learn Python syntax and I’m afraid too many students walked away from the experience thinking programming was a huge time-sink with little reward!

I think these are the right robots to bring some excitement to a Python-based programming class for about 2 weeks and look forward to seeing the newer, beefier Scribbler 2.

(I recently gave a little training on using Python and Scribblers to the Puget Sound chapter of the CSTA.  My slides.)