Legos in the Classroom?: Teaching Computer Programming
to Advanced High School Students
William Greenley
Andrews University
Nova Southeastern University
Charles H. Tidwell, Jr.
Andrews University
A Paper Presented at the Hawaiian International Business Conference,
June 18 – 22, 2002
Abstract
This paper focuses on pedagogy issues in teaching information systems. As the teacher for the past several years of an introductory information systems class for high school students, the challenge has been to develop a method of introducing computer programming in an academically responsible way while at the same time making it interesting.
The curriculum that has been developed involves teaching problem solving and programming skills through the use of Lego MindStorm Robotics Invention Systems™. These Lego sets allow students to learn a subset of the C++ language while at the same time doing problem analysis to accomplish a set of challenges staged as classroom competitions. This methodology has been very successful. While many students build on a childhood love of playing with Lego’s and are intrigued by using class time to “play”, the activity has not only led to a strong and at times passionate involvement in using computer programming and problem solving, it has also stirred in many students an interest for further study in information systems.
The presentation will not only address specific pedagogy issues and outline the curriculum that has been developed, but will also include a brief demonstration of the Lego MindStorm robots as used in one of the typical class competitions.
Topic Area and Keywords
Teaching Information Systems, Secondary School, Computer Programming, Problem Analysis, Lego MindStorms, C++, NQC, Constructivism, Instructional Pedagogy
Legos in the Classroom?: Teaching Computer Programming
to Advanced High School Students
As the teacher for the past several years of an introductory information
systems course to a non-traditional class, the challenge has been to develop
a method of introducing computer programming in an academically responsible
way while at the same time making it interesting. This
study will focus on pedagogy issues and the use of Legos as basic course
material arising from the experience with a group of freshman and sophomore
high school students, most of whom are unlikely to enter the computer science
or information systems professions.
A Non-Traditional Course
Andrews University hosts the Math Science Center, an advanced program of the Berrien County Intermediate School District. This program offers the top 30 high school students in Michigan’s Berrien and Cass Counties the opportunity to spend half of every school day for their four years of high school in classes taught by university professors on the university campus instead of the traditional classes in their home school. They take all of their sciences, mathematics, and computer / information system (IS) classes through this advanced program. In addition, they have the opportunity of taking regular college classes as advanced placement electives at Andrews University. While the information systems classes are taught specifically to high school students, they are taught at a college level. The first author has been the subject coordinator and primary instructor for the IS portion of this program for the past seven years. These IS classes include a year of applications and a year of programming taught in the first and second years.
The standard
teaching approach to programming uses a character-based environment for one
year. This approach has been used by the university
in its college level C++ programming course. Initially,
it was simply converted to the Math Science Center (MSC) program. The MSC
course covered essentially the same material as the two-semester C++ programming/data
structures course for the university. This was split
up with an early introduction to the concepts of programming for one term
during the students’ freshman year with the second year being spent almost
entirely on programming. This first term introduction
is the focus of this study.
A traditional teaching approach was used in
the early years of this course. This consisted of
using the beginning chapters of the same college text that the university
was using in its course. With this approach, students
begin learning about computer memory, binary notation, and the use of variables. A series of problems of increasing complexity are illustrated
and explained. These problems often include simple
math computations such as computing sales tax or, in advanced examples, the
quadratic formula. These examples build from variables
through operators, logic statements, loops, and arrays. All
of the assignments are typically done in a character-based environment, which
means no graphics, no color, and the use of simple text.
The advantages of using the traditional format
include: wide acceptance, the use of existing compilers,
and the ability for students for remote access. The
disadvantages include the ease of copying assignments, the difficulty of
generating a positive response to computer programming in students who are
initially non IS enthusiasts, and the inability to write productive programs.
This traditional programming approach has been used for years. Because of its heritage, it is easy to defend as an appropriate way to introduce programming. In addition this broad-based acceptance means that there are a wide variety of resource materials available to support this method.
In the labs and on the campus network several different C++ compilers are available. Through these compilers the students can work on their programs from almost anywhere, even from home through use of the Internet. These compilers are already installed and as such incur no additional costs in their use. If a student wishes, there are freeware compilers that can be installed on a home computer thus allowing work offline.
One of the major disadvantages of the traditional approach is the ease with which one student can copy another student’s work. Since assignments are usually identical and since the programming concepts are fairly simple and short, it is easy to copy, change a few minor stylistic details, and turn it in as one’s own work.
Another disadvantage comes from the structure of the program. All of the students in the MSC program are required to take both years of the IS classes. As high school students in an increasingly computer literate society, most students in the class enjoy playing computer-based games or surfing on the computer net. However, the majority has no knowledge of or interest in computer programming. Only a few students have some knowledge of programming and are interested in continued learning in the discipline. Since the disinterested group is usually the majority, it becomes a challenge to keep the class as a whole involved and motivated while introducing computer programming. Motivation is especially critical when dealing with top-level freshmen high school students who often lack the patience to deal with mundane or apparently unrewarding educational tasks.
With the traditional C++ approach, students typically start programming at a fairly low level. The following example of an early programming exercise comes from Friedmann & Koffman (2000):
// miles.cpp
// Converts distance in miles
to kilometers
#include <iostream>
using namespace std;
int main()
// start of main function
{
const
float KM_PER_MILE = 1.609; // 1.609 km in a miles
float miles, // input: distance in miles
kms;
//output: distance in kilometers
//
Get the distance in miles
cout
<< “Enter the distance in miles: “;
cin
>> miles;
//
Convert the distance to kilometers
kms
= KM_PER_MILE * miles;
//
Display the distance in kilometers
cout
<< “The distance in kilometers is “ << kms << endl;
return
0;
}
There is a lot of conceptual learning involved in writing even this simple code. But note the output:
Enter the distance in miles: xx
The distance in kilometers is yy
Even though a short programming exercise, this outcome of converting miles into kilometers is not very exciting to today’s video game generation. In fact, to put it bluntly, it is perceived as tedious, essentially a basic mathematics exercise that most of them already know even as high school freshmen.
Even as the course progress to a higher level of mathematical skill, the potential for tedium remains. For example, by the end of the introductory term, program complexity increases as seen in this example project from Litvin & Litvin (1998).
// MEANS.CPP
//
// This program calculates
the arithmetic, geometric and harmonic
// means of two positive integers.
#include <iostream.h>
#include <math.h>
double ArithmeticMean (short
a, short b)
{
return
double(a+b)/2.0;
}
double GeometricMean (short
a, short b)
{
return
sqrt(double(a*b));
}
double HarmonicMean(short
a, short b)
{
return
2.0/(1.0/a + 1.0/b);
}
int main()
{
short
a, b;
char
again = ‘Y’;
do
{
cout
<< “Enter two positive integers a and b ==> “;
cin >>
a >> b;
cout << “Arithmetic
mean of “ << a << “ and “ << b
<< “ = “ << ArithmeticMean(a,b) <<
endl;
cout
<< “Geometric mean of “ << a << “ and “ << b
<< “ = “ << GeometricMean(a,b) << endl;
cout
<< “Harmonic mean of “ << a << “ and “ << b
<<
“ = “ << HarmonicMean(a,b) << endl;
cout << “Do you want to go again(Y/N)? “;
cin >> again;
}while
(again == ‘Y’ || again == ‘y’);
return 0;
}
While this has considerably more complexity, it still does not generate a lot of excitement to disinterested students. In addition, as mentioned earlier, a significant problem is that assignments are essentially the same. One student can simply do the assignment and email it to the rest of the class.
As these two brief examples illustrate, the critical concerns for this program have been: how to stimulate interest among a non-traditional group, how to have an academically defensible program, and how to create problem variability to minimize academic dishonesty with a reasonable level of grading effort. Before addressing these concerns, however, it may also be relevant to address the teaching and learning concepts that impact computer programming instruction.
Several recent studies have focused on the pedagogy involved in teaching computer programming to high school students. Earlier studies examined the use of Logo programming as an aid to teaching programming (Keller 1990). More recently, Thomas and Upah (1996) addressed the issue of metacognitive development using the LOOPS simulation. They also addressed an underlying issue of whether or not to teach programming to high school students. The validity of teaching a programming language to high school students still needs to be resolved, particularly when the preferred programming language within the industry changes fairly rapidly making the current language obsolete for any non-traditional students entering the workforce six to eight years after taking this high-school level programming course. A recent study notes the on-going shift in programming languages and comments that the current popularity of C++ may soon be overtaken by Java (Stephenson and West, 1998). As a result, most studies of computer programming instruction for high school students have focused on skill building rather than post-school practical application. Ennis (2001) along with many others notes the need for problem solving and reasoning as critical skills, skills developed through computer programming instruction (see also Rucinski, 1991; Norris and Jackson 1992).
Another critical issue in the teaching of computer programming has been transference, notably the tendency for a skill in one area to transfer and support another more desired outcome such as the enhancement of cognitive skills. Keller (1990) supports such enhancement whereas van Merrienboer (1990) suggests no cognitive correlation (see also Beard, 1993; Shih and Alessi, 1993).
A more pertinent issue is the learning theory itself. It is a truism that students need to be actively involved in their learning rather than being passive recipients of instruction from the teacher. In computer science in particular the focus has been on constructivism. Constructivism theory, which promotes a student-centered, active learning approach, is becoming the preferred methodology in many classrooms both at the secondary as well as the tertiary level. A current overview, which noted that more than 200 articles had been published on the topic, suggests the pervasiveness if not the faddishness of the theory (Vermette, Foote, Bird, Mesibov, Harris-Ewing, and Battaglia, 2001; see also Colburn, 2000).
Constructivism, as one recent study points out, represents a paradigm shift in the theory undergirding contemporary pedagogy. It should also be noted that constructivism has especially been embraced by the sciences and the language arts. In contrast to the more traditional approach, typically referred to as objectivist or behavioralist (an approach that typically isolates basic skills and builds on them in order to deal with more complex tasks), the constructivist approach focuses on students developing their own learning through building on existing knowledge, a critical use of social interaction, and a focus on reality based tasks which are perceived as meaningful (Applefield, Huber, and Moallem, 2001). While the computer programming techniques described in this study do not strictly follow a constructivistic framework, the underlying concept still applies. It should also be noted that while there are few empirical studies, the work of Van Grop and Grissom (2001) does illustrate its applicability to computer programming education.
Thus, a central concern of the instructor has been to find a means to engage high school students in computer programming while avoiding the pitfalls of rote memorization of a programming language and syntax that will likely be outdated by the time the student finishes his or her college studies.
The first alternative to traditional approaches that was used in this MSC course was multimedia programming using Lingo, the Macromedia Director scripting language. Using this environment, students created numerous animated screens that together produced a multimedia yearbook on CD-ROM with individualized pages for each student. The immediate advantages were obvious. It was extremely visual, students perceived it as fun (a significant entertainment enhancement to what otherwise would have been perceived as a rote chore), and it created a permanent product. The disadvantages included expense, lack of resource material, difficulty in equitable grading, and the practical impossibility of maintaining adequate control over content.
The Lingo approach had the distinct advantage of being highly visual. The students could write the code for a specific movement, and immediately see it represented in action on the screen. A complex code for loop seemed a lot more interesting when, instead of generating a string of numbers, it caused a ball to bounce around the screen.
This ability to create animation and even to write games was enjoyed by many in the class. Students often came early to class and then had to be chased out when class time was over. More significantly, all of the programming taught in Lingo was tied together at the end of the term through the production of a multimedia yearbook. This was designed to be created on CD-ROM, and gave vast amounts of space for the students to fill with their work. So, instead of a yearbook entry simply being a small black and white photo, they could have many pages of photos, information, artwork, animation, etc.
Initially academic pricing on the Macromedia Director was approximately $45 per license. While this was a significant discount from the regular price of $400, it was still possible although somewhat expensive to license 30 computers. However, when upgrades were necessary due to changes in Windows, Macromedia had raised the academic pricing to $200 per license, which simply was beyond budget allocations.
Another disadvantage was the lack of resource materials. Since no one else was using Lingo in the fashion, it was necessary to prepare all specific lesson materials. It was a challenge to produce quality materials in a timely manner in order to keep up with class learning. Seminars on Lingo were extremely expensive and therefore essentially unavailable because of budget limitations. In addition, they were designed primarily for the professional animation community.
In giving the students latitude to explore their own interests, the problems of grading became apparent. It was difficult to specify grading criteria that could be applied equitably across the wide variety of work that students were doing. After teaching new programming techniques, such as “if statements” or “for loops,” students would be assigned to create an animation that demonstrated the new concept. The problem in grading was that the code was in many pieces, attached to many different sprites throughout the project. It was difficult to get a simple program listing that could be evaluated objectively. The instructor had to meet individually with each student, asking for a demonstration of where and how code was implemented. This meant that much of the grading ended up being done in the lab, and thus took valuable time away from teaching.
A final disadvantage was related to how the code was spread out. It was virtually impossible, in a large project, to examine every piece of code. This meant that some enterprising students decided it would be fun to see how much they could hide in their yearbook pages. This took the form of everything from copyrighted songs to “inappropriate” material. It was time consuming to carefully analyze every screen to find and remove these “Easter Eggs.”
There was success in overcoming many of these difficulties. However, when the price became prohibitive, it became imperative to find another alternative. A goal was to find a product that preserved as much as possible the strong positives of Director, but at the same time eliminated as many of the disadvantages as possible. This search ended with the discovery of the new Lego product, the MindStorms Robotic Invention System. Its advantages were: like Lingo, it has immediate feedback and was entertaining. It also has the strong advantage of no code sharing, thus removing the potential for copying other student’s work. Like Lingo it also was fairly expensive and took significant preparation time. Finally, because of its association with a common childhood toy, the initial parental and administrative response was negative.
The Lego
MindStorm Robotics Invention Systems™ was introduced several years ago, and
immediately became very popular. Although an evaluation
set was ordered as soon as it came on the market, it still took five months
before it was shipped, largely due to its immediate popularity. As Wasserman (2002) notes, it was designed for the twelve-year-old
market but developed a cult following among adults leading to a major shortage
in the first year. There are a number of general guides
to using Lego MindStorm kits such as Knudsen (1999), Baum & Zurcher (2000),
Buam, Gasperi, Hempel, & Villa (2000). In addition, the following Lego Robots web site has a
number of links to enthusiasts: http://www.idi.ntnu.no/grupper/ai/research/eval/lego_links.html.
The heart of a Lego MindStorm kit is a programmable brick (RCX) containing a CPU, 32k RAM, three connections for sensors, three connections for motors, control buttons, and a small LCD display screen. This onboard computer supports multitasking event-driven programming. To program the brick, students create a program on a PC and then compile and download the program into the RCX. The program is downloaded via an infrared communications device that is connected to the computer using either the PC’s serial or USB port. Once downloaded, the program is initiated by pushing the run button on the RCX. At this point the program is running independently on the RCX and students see it perform strictly as the downloaded program directs. The RCX is not normally controlled by a remote control device, but by running the installed programs.
The RCX comes with a graphical programming language developed by the Lego corporation. It is simple and intuitive to use but somewhat simplistic in structure. Its limited abilities make it a poor choice for teaching programming. For example, it lacks any form of variable. This makes it impossible to create programs of more then rudimentary functionality. The supplied language also uses significant memory resources, making it impossible to create anything other then very small programs. Fortunately there is a alternative, NQC.
NQC, which stands for ‘Not Quite C,’ is a language similar to C++, but designed for programming the Lego RCX. Unlike the Lego language, it contains variables and most of the control structures used in the C++ programming language. This makes it an ideal candidate for teaching an introduction to programming as preparation to a year-long series on C++. It also has the attractive attribute of being freeware. It has been developed by some robotic enthusiasts and presented as free software to anyone using it in a non-commercial venue. In addition, because of the popularity of the Lego MindStorm sets, brief introductions to NQC are readily available (see McComb, 2000).
The full package also includes an IDE (integrated development environment) that provides a GUI front-end for the language and a number of useful utilities. These utilities include a joystick control emulator, a piano keyboard to assist in programming songs, and a number of diagnostic tools and language templates.
An example of an early program in NQC used in the course is:
task main() // drive a square
{
repeat(4) // repeat 4 times
{
OnFwd(OUT_A+OUT_B);
// turn motors A & B on forward
Wait(100);
// wait 1 second
OnRev(OUT_B);
// reverse motor B – this turns the robot
Wait(85);
// wait .85 seconds
}
Off(OUT_A+OUT_B);
// turn off both motors
}
This program, while roughly equivalent in complexity to the early C++ program described above, gives a very different feedback. This program will cause the robot to drive in a square. This highlights one of the main advantages of using the MindStorm robots. Students are immediately able to see their program run. One of the more frustrating areas for students starting to learn programming is that the computers do exactly and only what they are told to do. Many times students don’t understand the true meaning of each line they have written. They only see that the final output is wrong. With the robots, students see each piece of code executed through the movements of the robot. When a student makes a change, he or she gets immediate feedback demonstrated in the visible change of the robot’s behavior.
This program will only work for a specific robot. If it is downloaded and run on a second robot, it will not run in the same square as the first robot unless that second robot is absolutely identical with the first. The values must be adjusted to make allowances for differences in design and varying performances of the motors. This means that with a quick glance at individual robot design, the instructor can know whether or not a student has simply copied another’s code.
Another major advantage is the obvious entertainment value. It is clearly more interesting for a student to see a robot he or she has designed, built, and programmed in the process of dodging obstacles than to discover, as noted in the earliest traditional programming assignments how many kilometers equals 8 miles. In addition, through the use of robotics, the course includes a competitive element that created intense interest in the assignments. This competition takes the form of three challenges that are held during the term: two forms of two speed tests (one through a maze) and a demolition derby meets Sumo wrestling for a final contest.
These
advantages mean that the students come to class excited about learning. With the robotic competitions, the students are seeking
ways of making their robots more sophisticated. Because of this they come
asking about additional programming structures. This
has turned lessons into an active learning environment where most of the
class is searching for new commands and techniques instead of having this
information forced on them. By the end of the term
the students are writing programs of equivalent or greater complexity then
when C++ was taught directly in the character-based programming environment. At the same time they have also explored the fields of
robotics, artificial intelligence, and physics. The
following is an example taken from a final class project.
int state;
#define LEFT 0
#define RIGHT 1
#define DARK2 35
#define LIGHT2 40
#define POWER 7
#define TIMEOUT 50
task main() {
state
= LEFT;
SetSensor(SENSOR_2,
SENSOR_LIGHT);
SetPower(OUT_A
+ OUT_C, POWER);
Start
lightWatcher;
while
(true) {
if
(SENSOR_2 < DARK2)
OnFwd(OUT_A
+ OUT_C);
}
}
task lightWatcher() {
while
(true) {
if
(SENSOR_2 > LIGHT2) {
toggle();
Wait(TIMEOUT);
if
(SENSOR_2 > LIGHT) {
toggle();
Wait(TIMEOUT
* 2);
}
}
}
}
sub toggle() {
if
(state == LEFT) {
OnRev(OUT_A);
OnFwd(OUT_C);
state
= RIGHT;
}
else
{
OnFwd(OUT_A);
OnRev(OUT_C);
state
= LEFT;
}
}
This code directs a robot to follow a line. If the robot leaves the line, it turns back and tries to find it again. If it doesn’t find the line within a set distance, it turns the opposite direction and searches. If still fails to find the line, it searches further to the opposite side. It continues in this fashion with ever-enlarging search patterns until the line is found and then it resumes following the line.
Being able to follow the line is part of one of the class competitions. This contest presents the robot with a maze. It can be traversed either by finding a path through the maze by dodging the walls, or by following a black line that weaves a very indirect path through the maze. There is also a third option which is a straight path to the finish line, but the robot is faced with obstacles that must be climbed over to reach the end. The fastest time wins.
The use of the Lego MindStorm/NQC sets has
not been without its disadvantages. The first was
simply the response that the idea of Legos generated with administration and
parents. “You want to buy what?” It was not easy to
get approval to purchase $3,000 worth of Legos. While that was a onetime
battle, every year there are some parents who question whether “playing with
Legos” is a legitimate academic exercise. This requires
explaining what the MindStorms are and how they are used in the classroom. While the resistance has not been long-lasting, it still
takes time to explain.
Expense continues to be a major disadvantage. At $200 per set, plus further cost for additional motors and sensors, these sets can be quite expensive. Fortunately they are also quite durable. In the past four years five motors that quit working had to be replaced, at $16.50 each. The bigger ongoing expense comes from misplaced parts and batteries. There are many small parts in the set that often disappear. It costs around $150 a year to replace missing and broken pieces in addition to the replacement of motors. Each RCX unit uses 6 AA alkaline batteries, and each infrared transmitter uses one 9v battery. It usually requires two to three sets of AA batteries, and one 9v battery each term.
The biggest disadvantage of using the MindStorm sets is the preparation and cleanup time. With each set containing over 800 parts, parts inevitably get lost or damaged. At the same time, for each group to be able to accomplish their projects, the sets need to be complete. This means a significant amount of time has to be spent at the end of each term sorting through the sets and resupplying them with any missing parts. Some of the parts are difficult to find. One source that has proven very helpful in finding parts is www.bricklink.com, an online market of thousands of different Lego parts. In addition, the small pieces tend to disperse during class as students test their robots, and it is necessary to carefully patrol for parts after each class session.
Lego MindStorm Demonstration
As a demonstration we will observe a Lego MindStorm robot similar to those designed by students in the program. The robot is set to wander randomly. If the robot runs into an obstacle on its right hand side, it will backup, turn left and continue exploring. If the robot runs into an obstacle on its left hand side, it will backup, turn right and continue exploring. If both bumpers are hit at the same time, it will back up and randomly turn left or right. The robot for this program will have two motors, each driving a single wheel on opposite sides. In order to turn, either the wheels need to turn in opposite directions or at different speeds. Two touch sensors are connected to the robot, each going to an arm surrounding the respective side and half of the front of the robot. The code for this is as follows, with generous comments throughout the code describing how it works.
task main(){ // This task required and runs when robot starts
SetSensor(SENSOR_1,SENSOR_TOUCH); // touch sensor connected port
1
SetSensor(SENSOR_3,SENSOR_TOUCH); // touch sensor connected port
3
start check_sensors;
// starts task that monitors sensors
start wander; // start task that make robot wander
}
task wander (){ // task to make robot wander
while (true){ // loop runs as long as true
is true (forever)
OnFwd(OUT_A+OUT_C); // turns on in a forward direction
the motors
// connected to ports A &
C
Wait(Random(50)+25);// Waits .00 - .50 seconds
plus .25 seconds
// motors are running
while it waits
random_turn(); // calls
random_turn subroutine
Wait(Random(40)+10); // Waits .00 - .40 seconds
plus .10 seconds
} // goes back to beginning
of while loop and starts loop again
}
task check_sensors(){ // task to monitor sensors
while (true){ // again infinite loop to continually
check sensors
if (SENSOR_1 == 1 && SENSOR_3 == 1){
// if both touched turn random
stop wander;
// before turning need to stop wandering
OnRev(OUT_A+OUT_C); Wait(50);
// back away from obstacle
random_turn(); // call random_turn
start wander;
// restart wandering
}
else if (SENSOR_1 == 1){
// if only left sensor touched
stop wander;
OnRev(OUT_A+OUT_C); Wait(50);
OnFwd(OUT_A);
Wait(85); // turn right
start wander;
}
else if (SENSOR_3 == 1){ // if only right sensor touched
stop wander;
OnRev(OUT_A+OUT_C); Wait(50);
OnFwd(OUT_C);
Wait(85); // turn left
start wander;
}
}
}
sub random_turn(){ //
random turn subroutine
if (Random(1) == 0){ // generate random 0 or 1
OnRev(OUT_C); // if one turn right
}
else{
OnRev(OUT_A); // else, i.e.
was 0, turn left
}
}
The students are always excited to be able to watch their robot wander around the floor as this done in this simple demonstration. This physical feedback to programming gives the student a real feel for what the program does. If there is an error, they see it because the robot doesn’t run correctly.
Conclusions and Further Directions
The use the Lego MindStorm sets with NQC has proven to be the most popular of the three methods explored for teaching an introduction to computer programming. It is apparent that it is rapidly gaining support at the university levels as an important tool in teaching introductory computer skills (Schumacher, Welch, and Raymond, 2001; Kolberg and Orlev, 2001), although the cost factor may account for its relatively low use at the secondary and elementary levels. Particularly noteworthy is the constructivist rationale for its use at the university level (Matt Jadud 1999). Its classroom effectiveness is reinforced in the experience of Eric Wang (2001) who, after using Legos with university freshmen mechanical engineering students, comments: “The use of LEGOs was found appealing to the student while providing an excellent medium for teaching design, programming, and creativity.” In particular, Wang notes that it has been an “an excellent recruiting tool. The enrollment has more than doubled in three years, despite the national trend of decreasing enrollment in engineering programs” (p. 15). Elizabeth Mauch (2001) also reports the experience of middle school teachers who remarked that “Students remained highly engaged throughout the process” (p 212).
The experience of the high school students described in this paper is equally supportive. Initially, many students build on a childhood love of playing with Legos and are intrigued by using class time to “play.” More importantly, however, the activity has not only led to a strong and at times passionate involvement in using computer programming and problem solving, but it has also stirred in many students an interest for further study in information systems. Granted, the use of Legos has not been without its problems. But when balanced against the learning that has occurred with the use of Legos and the popularity they have help to generate for this course, it has been an excellent choice.
Future directions. Given that the College Board has decided to move to Java for its AP curriculum, the possibility of using Java with the Lego MindStorms is being actively explored. Other ideas being considered to enhance the effectiveness of the program include a robot road show to be used as a community awareness / recruiting activity and a weeklong robotics camp during the summer.
References
Applefield, J. M., Huber, R., & Moallem, M. (2001). “Constructivism in theory and practice: Toward a better understanding” [Electronic version]. High School Journal, 84, 35-53.
Baum, D., Gasperi, M., Hempel, R., & Villa, L. (2000). Extreme MindStorms: An advanced guide to Lego MindStorms. Berkeley, CA: Apress.
Baum, D., & Zurcher, R. (2000). Dave Baum’s definitive guide to LEGO MindStorms (Technology in Action). Berkeley, CA: Apress.
Beard, C. H. (1993). “Transfer of computer skills from introductory computer
courses” [Electronic version]. Journal of Research
on Computing in Education. 25, 413-430.
Colburn, A. (2000). “Constructivism: Science education’s
‘grand unifying theory’” [Electronic Version]. The
Clearing House, 74, 9-12.
Ennis, D. L. (2001). “Combining problem-solving instruction and programming instruction to increase the problem-solving ability of high school students” [Electronic version]. Journal of Research on Computing in Education, 26, 488-496.
Ferrai, M., & Ferrari, G. (2001). Building and programming Lego MindStorms. Rockland, MA: Syngress Publishing.
Ford, W., & Topp, W. (1996). Data structures with C++. Englewood Cliffs, NJ: Prentice Hall.
Friedman, F. L. & Koffman, E. B. (2000). Problem solving, abstraction, and design Using C++ (3rd ed.). Reading, MA: Addison-Wesley Publishing Company.
Horton, I. (1998). Beginning visual C++ 6. Birmingham, UK: Wrox Press Ltd.
Jadud, M. (1999). TeamStorms as a theory of instruction. Retrieved March 14, 2002 from Indiana University Faculty
Web site: http://www.cs.indiana.edu/~mjadud/
papers/tsaatoi.html
Keller, J. K. (1990). “Characteristics of Logo instruction promoting transfer of learning: A research review” [Electronic version]. Journal of Research on Computing in Education, 23, 55-71.
Knudsen, J. B. (1999). The unofficial guide to LEGO MINDSTORMS robots. London: O’Reilly.
Kolberg, E. & Orlev, H. “Robotics learning as a tool for integrating science-technology curriculum in K-12 schools.” Proceedings of the 31st ASEE/IEEE Frontiers in Education Conference. Reno, NV, October 10-13, 2001.
Laverde, D. (2001). Programming Lego MindStorms With Java. Rockland, MA: Syngress Publishing.
LEGO
Robot links. (n.d.)
Retreived March 14, 2002, from
http://www.idi.ntnu.no/grupper/ai/research/eval/lego_links.html
Litvin, M., & Litvin, G. (1998). C++ for you++ An introduction to programming and computer science. Andover, MA: Skylight Publishing.
Mauch, E. (2001). “Using technological innovation to improve the problem-solving skills of middle school students: Educators’ experiences with the LEGO MindStorms Robotic Invention System” [Electronic version]. The Clearing House, 744, 211-214.
McComb, G. (2000, April). “Using “Not quite C” to program Lego MindStorms” [Electronic version]. Poptronics, 1, 52-56.
Norris, C. & Jackson, L. (1992). The effect of computer science instruction on critical
thinking skills and mental alertness. [Electronic version]. Journal of Research on Computing in Education, 24,
329-336.
Rucinski, T. T. (1991). Effects of computer programming on problem solving
strategies” [Electronic version].
International Journal of Instruction Media, 19, 341-351.
Sahni, S. (1998). Data structures, algorithms, and applications in C++. Boston, MA: WCB/McGraw-Hill.
Schumacher,
J., Welch, D., & Raymond, D. “Teaching introductory
programming, problem solving, and information technology with robots at West
Point.” Proceedings of the 31st ASEE/IEEE
Frontiers in Education Conference. Reno, NV, October
10-13, 2001.
Shih, Y. F., & Alessi, S. M. (1994). “Mental models and transfer of learning in computer programming” [Electronic version]. Journal
of Research on Computing in Education. 26, 154-175.
Stephenson, C. & West, T. (1998). Language choice and key concepts in introductory computer
science courses” [Electronic version]. Journal of
Research on Computing in Education. 31, 89-95.
Thomas, R. A. & Upah, S. C. (1996). “Give programming instruction a chance” [Electronic Version]. Journal of Research on Computing in Education, 29, 96-108.
Van Gorp, M. J. & Grissom, S. (2001). “An empirical evaluation of using constructive classroom activities to teach introductory programming” [Electronic version]. Computer Science Education, 11, 247-260.
van Merrienboer, J. J. G. (1990). “Instructional strategies for teaching computer programming: Interactions with the cognitive style” [Electronic version]. Journal of Research on Computing in Education, 23, 45-53.
Vermette, P., Foote, C, Bird, C., Mesibov, D., Harris-Ewing, S., & Battaglia, C. (2001). “Understanding constructivism(s): A primer For parents and school board members” [Electronic version]. Education, 122, 87-93.
Wang, E. (2001). “Teaching freshmen design, creativity and programming with LEGOs.” Proceedings of the 31st ASEE/IEEE Frontiers in Education Conference. Reno, NV, October 10-13, 2001. Retrieved March 14, 2002, from http://fie.engrng.pitt.edu/fie2001/papers/1291.pdf
Wasserman, E. (2002, Winter). “Why industry giants are playing with Legos” [Electronic version]. Fortune [2002 Winter Tech Review], 144, 101-106.