Introduction

In the modern classroom where IT usage is taken for granted, what can I possibly say that will interest my readers? Worse, what innovative use of IT in pedagogy can possibly excite students like those in the School of Computing who are already avid users of computer technology?

All freshmen at the School of Computing are required to take CS1101 "Programming Methodology". This module is to computer science what arithmetic is to mathematics. The module and its variants have been with us since the age of 8-bit microprocessor (the early 1980s). Unfortunately, over the past two decades, many freshmen, who already knew how to do programming, viewed the module as a bore and a chore. However, weaker students liken programming to lion-hunting in the Sahara desert. Even if one survives the tedium, he/she might still end up getting mauled by the lion. Thus, when I was offered to teach the class in Semester 2, Academic Year 2003/04, I resolved to change this stigma.

Background

From mostly a pen-and-paper affair at the dawn of the computer era, computer programming and how it is taught, have changed over the years. The main vehicle through which students learn the nitty-gritty has evolved from text-based exercises to involve Windows, Icons, Mouse and Pointers (WIMPs), and more recently, sound as well as animated images. It seems therefore logical to make the next evolutionary leap to incorporate robotics in programming. After all, toy robots, such as the Lego MindstormsT, are readily available. Moreover, robots are perceived to be the epitome of machine intelligence.

However, computers do not understand English. Programming language consists of cryptic symbols like: while(*ptr++!=0){*ptr%=*ptr+2;}. To the untrained eye, this is no different from expletives found in comic strips. In addition, we have a myriad of programming languages to choose from, some popular, some so arcane as to border on the insane. No wonder our staff struggle to teach CS1101 and students perceive it as a torture.

Robot Pedagogy

Pedagogically speaking, using a robot to teach programming accomplishes several goals. First, the concept of abstraction is made explicit- coordinating the various sensors, motors and decision-making components of the robot is best done by designing software layers with clear interfaces (i.e. abstractions) between them. There is also the abstraction between the robot's hardware configuration and the controlling software to consider. Second, students get a handson introduction to embedded systems (where the computer is part of a larger system) and the engineering issues arising therein. Programs that run on a desktop PC do so in a 'perfect' environment; adding one and two always produces three. If the result is wrong, it is due to a program bug. But this does not always happen in the real world where sensors and motors are imperfect. Instructing a robot to move in a straight line may produce a curved path instead because of tiny imperfections in the wheelsize, in the speed of motor rotation and so on. In an imperfect environment, a wrong result is not necessarily caused by a 'buggy' program. Students thus begin to appreciate the complexity of building real systems and the need for reliability engineering. Furthermore, as the robot is a resource-scarce platform with limited battery power and memory space, its CPU runs considerably slower than on a full-fledged desktop PC. These allow students to get a taste of how such constraints affect their program design. And finally, controlling a robot is inherently fun. The satisfaction of seeing one's creation come alive and the robot obeying every command cannot be gained from traditional desk-bound programming exercises.

The assignment that I give students is a simple one: program the robot to draw patterns on a piece of mahjong paper on the floor. Attached to the robot is a marker pen which can be raised or lowered to make contact with the mahjong paper. The robot draws by moving forward or backward while the pen is down. Disjointed lines may be drawn by raising the pen, moving the robot to the new position, and lowering the pen. Turning the robot is achieved by driving the left motor forward and the right motorbackward. The assignment builds up incrementally: first, students program the robot to execute the basic movements for moving forward/backward, turning, and raising and lowering the pen. Then students choreograph these basic movements to produce more complicated drawings, such as writing letters of the alphabet, words, or even fractal pictures.

In a variant of the assignment, I ask students to select a mystery symbol from a box, and then reprogram the robot to draw the symbol within five minutes. This challenges students to prepare useful program abstractions beforehand in order to meet the time constraint. If students have attempted to ‘code from scratch’ they would not be able to accomplish the task in the allotted time. Throughout the whole assignment, there is a lot of trial and error in getting the robot to ‘behave’ correctly. Robotics is not an exact science! Students learnt to be patient, to anticipate the outcome of their programs and to troubleshoot when things go awry.

To add a competitive element, I also conduct an optional drawing contest. Students are free to get their robots to draw anything within six minutes, and their drawings are judged for aesthetics. The winning team is rewarded with chocolates and candies. Some of the pictures are remarkable for their novelty and creativity. I have seen drawings of a Christmas tree (crooked because of the imperfect lines), the Greek symbol λ drawn to perfection, a penguin wearing a bow tie and a beach scene complete with sun, sand and umbrella. There was even an attempt to draw the NUS Centennial logo! While most of the drawings honestly resembled chicken scratching, I am delighted to see the sheer creativity students displayed.

Conclusion

How do students find this robot assignment? Here are some comments:

• “This lab, while extremely interesting and entertaining, certainly had its challenges. It’s like a simple issue of mind over matter, where in the mind (our program) is theoretically accurate, but the matter (our robot) decides to have a fi nicky mind of its own; hence we chose its name to be FussBot. … Writing letters are [sic] something that a small toddler can even complete with more accuracy than our robot, and at some points, we felt as though we were the robot’s parents, trying to coax it to work and constantly gauging its progress.”
  
  
• “Once we have our robot fixed, we then tried to make the robot travel in a straight line. Apparently, we did not know that the motors of the robot had to be calibrated, and thus, our robot went in circles instead of going in a straight line. … Apart from that, it really was an enriching and interesting way of ending the semester.”
  
  
• “I did enjoy this assignment … I found that this robot is so cute...thanks for providing us with such a wonderful lab!!!”
  
  
• “Lab 8 is time-consuming.”

I believe these comments speak for the value of such an assignment. A survey conducted at the end of the semester revealed that almost everyone agreed that the robot assignment was fun and instructive. Fewer students, however, agreed that this should be a required assignment in every introductory programming module. Personally, I find it gratifying to go beyond the traditional mode of desk-bound computer programming. It is doubly satisfying to get students to work hard and have fun at the same time.