Printer Friendly

Designing, developing, and implementing a course on LEGO robotics for technology teacher education.

Within a constructivist philosophy of learning, teachers, as students, are introduced to different perspectives of teaching with robotic technology while immersed in what Papert called a constructionist environment. Robotics allows students to creatively explore computer programming, mechanical design and construction, problem solving, collaboration, physics, motion, music--all within an active, enjoyable, and nonthreatening setting. The theoretical motivation for integrating robotics into the teacher education program comes from Jonassen's (2000) argument that technology tools can be viewed as cognitive tools or "Mindtools" that enhance the learning process. Students are given ownership for their learning within a constructionist environment and allowed to discover and make choices as they explore countless avenues for solving design challenges. Through the use of innovative LEGO[R] RoboLab[TM] technology, students learn various facets of problem solving while simultaneously mastering numerous mathematical and scientific concepts. This article describes a case study of a pilot teacher education course in robotic technology. The goal was to design and develop a course that provides current and prospective teachers with a solid understanding of robot design, construction, and programming--as well as a demonstration and understanding of teaching using constructionist pedagogical strategies.


A revolution is beginning in the field of robotics that sees various aspects of robotics research leaving the laboratory environment and moving out into the world. Recent new programmable robotic "toys" such as SONY's robotic dog or the LEGO MINDSTORMS robot construction kit are typical examples. As Hendler (2000) pointed out, such toys "challenge the very nature of the relationship between children and technologies ... children are no longer anchored to a PC on the desktop, but able to bring the technology into their everyday world" (p. 2). This in turn poses a challenge to the educational community of how best to integrate these new technologies into our school environment.

The evolution of approaches and methods for the application of technology to teaching and learning is inherently linked to the evolution of the technology itself. Witness the impact desktop computers have had on a child's school experience over the last 20 years and the important role they now play in education (Santrock, 2001). The use of robotics in education is a relatively new phenomenon (Miglino, Lund, & Cardaci, 1999). That being said, there appears to be some evidence to indicate that robotics, as a classroom-teaching tool, can help promote student problem solving at many levels of education (Druin & Hendler, 2000; Thangiah & Joshi, 1997; Wagner, 1998). This article will present the theoretical and applied rationale for integrating robotics into a teacher education course in technology, describe a pilot course at the University of Alberta, student reflections on the course, and possible curriculum linkages for robotics.


Essentially one seeks to answer the question; why integrate technology, in the form of robotics, into the teacher education process? From a more general perspective there are many reasons to use technology in teacher education. Underlying almost all of these reasons is the notion that technology, if employed effectively, can positively impact the teaching process and subsequently either change or enhance the learning process (Papert; 1980; Logan, 1995). Jonassen (2000) makes a compelling argument for using computer technologies as "Mindtools" in education in contrast to using computer technologies as a vehicle to deliver instructional material. The theoretical motivation for including robotics in teaching is grounded on Jonassen's notion that Mindtools can indeed change and enhance the learning process in education.

The Mindtools perspective views the individual and computer in a joint-problem-solving-system or intellectual partnership such that the individual's problem solving ability and critical thinking skills are developed or amplified beyond the level that could be achieved without such a partnership (Logan, 1995; Orhun, 1995; Pea, 1985; Penner, 2001; Salomon, Perkins, & Globerson, 1991). In his latest book Jonassen (2000) described the relationship of Mindtools to the educational process,
 Mindtools ... are computer applications that require students to
 think in meaningful ways in order to use the application to
 represent what they know. I argue that students cannot use the
 applications described in this book without thinking critically
 (engaging the mind). So the most effective uses of computers in
 classrooms are for accessing information and interpreting,
 organizing, and representing personal knowledge. Just as carpenters
 cannot build furniture or houses without a proper set of tools,
 students cannot construct meaning without access to a set of
 intellectual tools to help them assemble and construct knowledge.
 (p. 4)

Jonassen (2000) continued by outlining the clear distinction between learning from a computer as opposed to learning with a computer. Learning from a computer often involves transferring instructional material into a computer-based format such as Computer-Assisted Instruction (CAI), or more recently Web-Based Instruction (WBI) (Alessi & Trollip, 1991; Khan, 1997). CAI and WBI generally take the form of direct instruction whereby the student is the receiver of information in its finished form. In contrast, learning with a computer involves the student using computer tools as cognitive tools during problem solving and learning. As Orhun (1995) stated, "computer-based cognitive tools are interactive knowledge construction tools that support human thinking and learning" (p. 317). From a learning theory perspective learning from versus learning with can be generally viewed as the former being instructivist and the latter constructivist.

Robotics as a technological tool can be used to engage students in meaningful learning; students are learning with technology as opposed to learning from technology (Jonassen, Peck, & Wilson, 1999). In doing so they take ownership of their own learning and meaning making. Harel and Papert (1991) also supported teaching with versus from computers. "Children [are] the agents of thinking and learning--not the computer ... Computers cannot produce 'good' learning, but children can do 'good' learning with computers" (p. 41). The theoretical rationale for using computer technologies (e.g., robotics), in the form of Mindtools, is based on a student-centered model of active discovery learning that is embodied in a constructivist approach to technology in teacher education.

The roots of constructivist learning theory are well known and can be found in the work of: (a) Vygotsky's (1962) concepts of the zone of potential development and learner scaffolding, (b) Piaget's (1954) notion of the functional invariants assimilation / accommodation that are postulated to be involved in cognitive restructuring; and (c) Bruner's (1966) argument for discovery learning. Constructivists believe that learners make their own meaning; that knowledge representations are built or constructed. Knowledge construction is a natural process that occurs as learners attempt to make sense of the world around them, constructing their own representations of their experiences (Jonassen et al, 1999). Papert (1990) further extends the theory of constructivism to encompass the more practical idea of constructionism.
 The word with the v expresses the theory that knowledge is built
 by the learner, not supplied by the teacher. The word with the n
 expresses the further idea that this happens especially felicitously
 when the learner is engaged in the construction of something
 external or at least shareable ... a sand castle, a machine, a
 computer program, a book. (p. 3)

Constructionists approach knowledge formation with an emphasis on the concrete rather than the abstract, believing that manipulation of tangible objects aids in the process of knowledge representation (Carbonaro, 1997). Consequently, robots, as a shareable external construction, fit naturally within a constructionist perspective. Students engaged in the designing and construction of robots are actively engaged in their own learning, developing problem-solving skills, using higher-order thinking skills, working collaboratively and intentionally in an intrinsically meaningful and authentic way. Through the use of robotics as an educational Mindtool, not only are students able to learn in an active constructionist environment, but also do so using technological tools discrete from the computer. Students have the opportunity to manipulate and control computers within their own, real world. Thus, children are not required to interact solely with a two-dimensional screen when working with computers and technology.

In summary, Mindtools, in the form of robotics, represents a constructionist approach for using technology--where such activity is intended to engage the learners in representing knowledge, manipulating virtual and concrete objects, and reflecting on what they have designed and built. Using robotics as Mindtools involves the learner simultaneously building both, a functional physical object, and the problem-solving knowledge it takes to accomplish the task.

LEGO[R] and RoboLab[TM]

Over the last 20 years, a small group of researchers have worked to bring robotics out of the lab environment and into the classroom environment. The research work at MIT and the LEGO Corporation (Papert, 1980; 1990; 1996; Martin, Mikhak, Resnick, Silverman & Berg, 2000; Resnick & Ocko, 1991; Sargent, Resnick, Martin & Silverman, 1996) has recently been combined with research at Tuffs University (Outreach program,; C. Rogers, personal communication, 1999) and National Instruments (T. Petruk, personal communication, 1999; Portsmore, 1999). This work has helped to develop breakthrough micro-technology devices and programming environments that are accessible to children and adults in terms of cost and ease of use.

In the fall of 1998 LEGO released two different "robot construction kits" or packages (Portsmore, 1999). The first one is designed for the retail market and is called MINDSTORMS (after the work of Seymour Papert). It allows both children and adults to build fairly simple robotic devices. Wallich (2001) recently described how adults are using this new LEGO technology to create very sophisticated autonomous robotic gadgets, such as "Rubik's Cube-solving robot" (p. 55). (Also see Knudsen, 1999 for other ways LEGO robotic technology can be extended.)

The second package released by LEGO is directed at the educational or classroom environment and is called RoboLab. It was designed specially to meet the requirements of teachers, structure of school curriculum, and classroom logistics (Portsmore, 1999). An important element of the RoboLab environment is the visual icon-based programming language (also called RoboLab) that was derived from National Instruments very sophisticated programming software LabView[TM](Portsmore, 1999). This impressive programming language enables even first time programmers or young children to develop very complex computer programs to control the robotic structures created out of LEGO (Figure 1).

The designers of RoboLab had a specific goal of creating a programming environment where teachers felt comfortable and confident using the software in their classrooms. During the development of RoboLab, pilot studies with teachers and children indicated that RoboLab designers should be cognizant of the fact that young children often lack the reading level and motor skills required to write and develop complex symbolic programming code (Portsmore, 1999). Given these and other constraints the designers' created a cross-platform (Macintosh and PC), simple to use, programming system for children from grades four to twelve. RoboLab programs are created on a computer and then transferred by way of infrared technology to a LEGO robot, where they can be activated to execute in a fully autonomous mode. Thus abstract robot control instructions, in the form of the icon-based programs, are designed and constructed separate from the robot; however, the actual results from executing these programs can only be realized while observing the behaviors of the robot that has also been designed and constructed to match the program code. Linking a physical robot design with the corresponding abstract icon-based representation of its functionality, demonstrates a complex knowledge-building interrelationship between from and function.


At the core of this LEGO robotic technology is the "programmable brick," developed at MIT (Sargent et al., 1996; Martin et al., 2000). Over the years 1987 to 1998, the programmable brick evolved into its current state--Figure 2 shows the programmable brick in its manufactured form, as the LEGO robotic command explorer or RCX as it is commonly called. The RCX, which is a little larger than two stacked decks of playing cards, was designed explicitly with children and novice learners in mind. "It gives the student the power to control and manipulate a robot of his or her own creation" (Sargent et al., p. 161).


The outer shell of the RCX has a liquid-crystal display (LCD) that shows program and robot control information. There are also control buttons and six input/output wiring connections. Three of these connections are for output to power external motors and lights. The other three connections are inputs for external sensor information such as touch, light, angle, temperature, sound level, and humidity. The shell also houses an infrared transmitter that enables communication with the external computer so that programs can be downloaded to the RCX. Embedded inside the RCX is the Hitachi H8 CPU, 32k of RAM, and room for six AA batteries.

LEGO's effort to reduce sophisticated mechanical engineering principles to a form that is accessible by children has resulted in a powerful teaching and learning environment for technology integration. The RCX is explicitly programmable so that users can continually modify and customize its behavior. In this way, the RCX fits clearly within a constructionist approach to learning (Sargent et al., 1996). The physical robot construction, combined with an easy-to-use yet powerful programming system, creates a rich learning environment that teachers can use without having students anchored to a desktop PC. Support materials in the form of teachers' guides, activity and team challenge student guides, and construction manuals are all available as educational resources (Cyr, 1998; LEGO Group, 1999a; LEGO Group, 1999b; LEGO Group, 1999d). These guides offer collaborative group strategies that promote cooperative learning environments.


Given the underlying theoretical motivation for robotics as a Mindtool and the technological capabilities afforded to us in LEGO RoboLab, a pilot course was designed for current and prospective teachers. Following is a case study description of the course goals, format, and organization; class profile; course proceedings; student results and feedback; and curriculum connections. The course took place during the summer session of 2001 as part of the Career and Technology Studies (CTS) program in the Faculty of Education at the University of Alberta. The course was titled EDCT 400 / 500--Robotics and Learning: Constructionism in Practice.

Course Goals

The goals of this course were twofold; to support curriculum technology integration through introducing students to the designing, building, and programming of LEGO robots with RoboLab software; and to immerse the students in a constructionist, learning environment, thereby "teaching by example" and allowing the students to experience firsthand, learning from a constructionist perspective.

The design, construction, and programming of robots comprise three courses of the Electro-Technology strand in the Alberta CTS curriculum. However, with the inherent problem solving, design, and higher-order thinking skills required in the building and programming of robots, other curriculum connections are myriad and diverse. Cross-curricular links within mathematics, science, social studies, and even music can be made through the designing and building of the programmable LEGO robots. With the advent of the Government of Alberta's technology integration mandate--the Information and Communication Technology (ICT) 2000 Outcomes (Alberta Learning, 2001)--the programmable robots allow for an alternative means for exploring and integrating technology as a tool for learning, within and across the curriculum. Additionally, robots are different; robots offer excitement and fun for children (and adults) and are consequently intrinsically motivating. Students tend to attach personal meaning and feelings to their creations and are better able to use this attachment for personal meaning making. It gives the students an avenue for constructing personal and relevant connections through problem solving and introspective meaning making. Jonassen et al. (1999) stated, "technologies should function as intellectual tool kits that enable learners to build more meaningful personal interpretations and representations of the world" (p. 13). LEGO robotic kits fulfill this requirement, enabling learners to personally, physically, and actively construct knowledge representations about gears, electronics, programming problems and challenges, music, motion, physics--among others. Through the use of the robotic technologies, students will be able to transfer this learning to a number of other areas of learning within the curriculum, school instruction, and the real world.

A second, though perhaps no less important, goal for this course was to demonstrate and model for the students, as prospective or current teachers, teaching and learning from a constructivist/constructionist perspective. The students were immersed in a constructionist learning environment and were able to experience for themselves instruction and meaningful learning within a hands-on, constructive, collaborative and active environment where problem solving was ongoing, authentic and relevant. Students were given the time and space to work collaboratively and to reflect on their learning. The technologies within the lab (LEGO robot construction material Team Challenge kit (LEGO Group, 1999c), RoboLab software, computers outfitted with Microsoft Office/Web software/e-mail) offered the "students the tools to explore, experiment, construct, converse, and reflect on what they [were] doing, so that they learn[ed] from their experiences" (Jonassen et al., 1999, p. 194). It was hoped that by immersing these teachers within an actual and active example of a constructionist learning environment that they would then be better equipped to provide a similar environment for their own students.

Course Format

This pilot course was offered as an intensive full-day CTS course, running over five consecutive days. The course was not divided specifically into lecture and lab time. Rather, the course was devoted primarily to the active learning of the programming language RoboLab and to the designing, building, programming, and testing / debugging of the robots. The first morning was devoted to an overview of the course, a brief discussion of the theoretical underpinnings of constructionism, background information on LEGO RoboLab equipment and software, and an introduction of class members. Thereafter, the course proceeded from a project-based learning approach, with the students working singly and then as teams on their programming projects. Collaboration among students was considered a vital component of the course and was actively encouraged.

The course was held in the CTS lab facility, which, in addition to the Pentium-based computers required for the programming software, provided additional space for the construction and operation of the robots. The lab facility was open for the students from 8:00 a.m. until 11:00 p.m. This was important, as students did not have the means to work on the programming or construction of the robots outside the lab environment.

Twelve of the lab's computers were set up with the RoboLab software and an infrared transmitter (see Appendix A for further information on course preparation and required materials). This allowed each student the freedom to choose to work through the Teachers' Guide for RoboLab software (Cyr, 1998) individually and at their own pace as they learned the programming language basics. However, it was decided that students would be formed into six teams of two when building and programming their Team Challenge robots, fostering a collaborative, constructivist learning environment. Students were given the time and space to move within the classroom and among their peers, seeking others' opinions and advice, and offering their own solutions and discoveries in return. A teaching assistant was available throughout the course to assist the students with any challenges or problems.

Course Organization

The course was not organized along a traditional lecture/lab format but rather was designed to follow a constructionist approach, modeling for the students how they might, as teachers, approach robotics with their students. Over the five days of the course, the students were expected to learn the basics of the Robolab programming language, working through the eight programming levels, from Pilot Level 1 to Inventor Level 4. Students were assigned exercises to complete for assessment as they proceeded through the Teachers' Guide for RoboLab software (Cyr, 1998). They were then expected to apply this knowledge to programming robots of their own design and construction to accomplish a Team Challenge task. The basic Team Challenge consisted of removing weighted soda cans from a prescribed 90 cm diameter circle (Appendix B). Additional challenges were given for those teams accomplishing the basic Team Challenge goal and included extending the Team Challenge by incorporating one or more of the following additional challenges: (a) the robot must start with the light sensor inside the Start Box (see Appendix B for diagram and photo of Team Challenge course with Start Box); (b) robots must be placed facing away from the Boundary Circle in the Start Box. Each robot must find the Boundary Circle before leaving the Start Box and pushing the cans; and (c) only those cans that are pushed through the Start Box are counted (see Appendix C for evaluation rubric for completing the robot Team Challenge).

In addition to programming and robot design and construction, students were expected to keep a daily log of their personal reflections with respect to: (a) discussions with other class members, giving credit to other students who may have come up with a good idea; (b) robotic projects--including examples of the programs and descriptions of why it works and what it does; (c) their debugging processes as they created their program(s); (d) their ideas for how they would use this in a classroom; and (e) reviewing and reflecting on the class readings (Appendix D). Students registered in the undergraduate level were expected to review and reflect on four of the readings, while those students registered in the graduate level were expected to review and reflect on all six of the readings.

For purposes of further research and for inclusion in their logbooks, students were required to videotape and digitally photograph their robots. Robots in various stages of construction as well as initial and subsequent designs were to be photographed in order to record the process the students underwent in the development and design of their robots.

The focus and organization of the course was on a project-based, constructivist approach to learning. It was hoped that by presenting the students with programming challenges and by encouraging the students to work in a collaborative, constructionist environment, they would be able to not only develop skills in programming and designing LEGO robots, but would also develop a keen understanding of project-based, active learning using technology and a problem-solving approach. Further, it was hoped these students would then be able to apply this knowledge as teachers in a school setting, using the technology as a tool for meaningful learning, problem-solving and higher-order thinking among their students.

Class Profile

The course was pilot tested with a small class of 12 students. The number of LEGO Team Challenge kits available predetermined the number of students. The class was a mixture of undergraduate and graduate students and of men and women--seven men and five women. There were five undergraduate students, four of whom were in their final year as CTS Technology Education students. The fifth undergraduate student was a science major in a post-degree education program. Of the remaining seven graduate students, three were working towards their Masters of Education in Instructional Technology; the fourth was an instructor with the Information Technology department at a local community college, hoping to use LEGO robots in a logic course; the fifth was a veteran teacher interested in technology and robotics for her students in upper elementary; the sixth was a computer science major with an interest in education; and the seventh was an elementary education PhD student whose Masters degree was in the Instructional Technology field.

All of the students were familiar with computers to one degree or another, having a minimum of an introductory computer course. Three of the twelve students had some limited programming experience with Visual Basic, while the computer science major had a far more extensive programming background. The four CTS Technology Education students brought mechanical and building experience to the construction of the LEGO robots. Gender and age also played a role in the amount of previous experience the students had building and playing with LEGO, with the women and older students generally having less experience with LEGO than the men and younger students.

The Course

The course began with a brief course overview, a short discussion on the pedagogical theories of constructivism and constructionism, an introduction to the history of RoboLab and the LEGO programmable brick, and student introductions. Students were asked to introduce themselves fully--this was thought to be important as students were required to work collaboratively in teams and, considering the short duration of the course, appeared a viable way to get to know one another in a relatively short time.

Following introductions, the students began five long days of immersion into the RoboLab programming language and the world of LEGO--designing, building, testing, retesting, redesigning, troubleshooting, debugging, and problem solving. The students experienced frustration at times as they struggled to work through a challenging course but they persevered and in the end were very successful.

The first two days of the course were primarily spent working through the Teachers' Guide for RoboLab software (Cyr, 1998) learning the RoboLab programming language. Students were able to successfully work through the eight levels of the programming language (Pilot Levels 1 to 4 and Inventor Levels 1 to 4) without too much difficulty. While students were not specifically paired for this portion of the course, they found it easier and more efficient to team up while working through the Teachers' Guide and in learning the programming language. The pairs formed at this time were the teams that persisted throughout the remainder of the week.

Once the students felt reasonably comfortable with the programming language, they began building their Team Challenge robots. At this point it became readily apparent that those students with experience in building with LEGO or with a construction / mechanical background, were having an easier and more successful time at designing and constructing their Team Challenge robots. This supports Gagne's notion of "learning hierarchies" (Gagne, Briggs, & Wager, 1998); lower-level skills provide the necessary foundation for higher-level skills.

Students with limited construction or design knowledge were encouraged to consult the LEGO Subassembly Constructopedia (LEGO Group, 1999d) manual for sound design ideas. The LEGO Subassembly Constructopedia manual provides step-by-step instructions on how to build various chassis and mechanisms. However, the guide does not illustrate completed chassis or robots, but rather only provides starting ideas and suggestions for students, leaving the completion of the design up to the student (also see Martin, 1995, for explanation of LEGO gears). Given a solid grounding on some basic principles of LEGO construction and design, students should be able to expand their knowledge with further experimentation and discovery and hopefully experience more success in their robot building efforts.

Work on the Team Challenge robots progressed well and the teams worked well together. There was some sharing of ideas and expertise among the teams, but for the most part the teams seemed very focused on their own tasks. Students used a digital camera to visually record their robot creations, including failed designs and recreations. As the robots took on shape and programming "behaviors," the students anthropomorphized their creations, naming their robots and developing personal attachments.

For some teams the very design of their robot limited the ability of the robot to easily return the cans and presented the team with programming challenges. For example, one-motor robot designs cannot reverse in a straight line and can only turn in one direction. The teams that used this design found it to be limiting and a little more difficult and challenging to work with, especially in light of the additional challenges. It was interesting to note the programming challenges and differences that were created due to the different robot designs. How the teams approached the programming challenges was directly influenced by their robot design. For the majority of the students the concrete physical design of the robot dictated the abstract programming control structure. One team, however, thought through the programming challenges that lay ahead and then designed their robot in an effort to meet the requirements prescribed by their programming conceptions and goals. In this case, the abstract programming control structure shaped the concrete physical design of the robot. In either case differences between predictions (expectations of what the robot's performance would be) versus measurements (observations of the actual robot's performance) caused a state of disequilibration in their thinking (Sanders, 1992).


Overall, the pilot course was a great success. There were a few technical glitches and students were at times frustrated and felt pressed for time but every student experienced success in learning the programming language to a reasonably advanced level and were able to effectively program their robots to varying degrees of sophistication and complexity. As well, each student was able to design and construct a LEGO robot, again to varying degrees of sophistication and mechanical complexity and excellence. Perhaps even more significantly, the class throughout the week operated within a total learning, constructionist environment. Students experienced fully the collaborative, problem-based, active, hands-on environment from a constructionist perspective--they lived it as their own students might. It was a fascinating experience--the room was charged with an exciting energy and high level of learning each and every day. What follows is an account of the students' design and programming challenges, solutions, failures, and triumphs.

Each of the students was able to successfully work through the eight levels of the RoboLab programming language without too much difficulty. The final exercises at the highest level (Inventor 4) caused the most difficulty but with the assistance of fellow students, the professor, and the teaching assistant, all were able to complete the exercises and move onto the building and programming of their robots. One team in particular spent a great deal more time working through the exercises and learning the programming language. This was due in part to the students' learning styles, but also in part to the team's belief that a truly solid understanding of the language would benefit them when it came time to complete the Team Challenge. In the end, this team was able to create the most sophisticated and yet efficient code. Both members of this team had prior programming experience with Visual Basic.

The most fascinating and intense learning and problem solving occurred as the teams of students worked through the designing, building, programming, and numerous test trials of their robots. It was in the act of designing, building, and programming their Team Challenge robots that the students experienced the most enjoyment, frustration, feelings of triumph and elation, disappointment and accomplishment. It was very exciting to have such a charged atmosphere in the classroom--one student commented, "I made the car move to the awe of the class. It was quite a rush." Such an experience during the process of robot building is a common occurrence among children (Druin & Hendler, 2000).

The robot designs produced by the six teams were as varied as the team members themselves and reflected the prior knowledge the team members brought to the challenge. For ease of explanation the following sections are organized by the robot names that were assigned by each of the respective teams.


The team with a seasoned and experienced mechanic as a member built an initial robot that was of such sound mechanical design and construction, that only minor modifications were required as they worked through the Team Challenge and additional challenges. This team completed the construction of their robot by Tuesday afternoon, leaving them ample time to develop their programs. "Buttercup" (Figure 3) was an extremely fast, mobile robot that removed the soda cans one-at-a-time.

In the end, this team was able to complete all challenges successfully but while their final program worked, it was very complex and somewhat inefficient. At this stage of knowledge construction they failed to refine and simplify their programming knowledge constructs. This was due in large part to their inexperience with computer programming; neither team member had any prior knowledge of programming previous to the course.



The team comprised of two CTS majors created a robot that reflected their prior experience and knowledge of mechanics and heavy machinery. "Robul" (Figure 4) was bulldozer like in design with a low center of gravity, treads for maximum traction and a large blade for sweeping the soda cans aside and out of the circle. "Robul" changed very little in construction from its initial design--this team maintained their original design and did not alter it in order to better accomplish some of the additional challenges.

This team, while mechanically adept, had more difficulty with programming and was not able to complete all of the challenges. The team stalled in the problem-solving process and was not able to modify their robot's physical design to incorporate the programming knowledge they constructed. This exemplifies a stage of knowledge construction where difficulties occurred; the physical limitations of the robot design constrained their thinking and prevented them from integrating higher-level programming solutions. Their robot was able to sweep the cans from the circle and then to turn about and gather them back up and bring them home to the Start Box (Figure 5). However, due primarily to their robot design but also to their inexperience with programming and the time limitations of the course, they were not able to have their robot start facing away from the challenge circle, turn about within the Start Box and then begin the task of removing the soda cans or to count the soda cans retrieved.



One member of this team in particular provided a prime example of constructionism at work. By actively engaging in the process of programming, testing, debugging and problem solving, he was able to gain confidence in his abilities and was intrinsically motivated to continue to struggle with and improve his skills as the following comment would attest:
 The highlight of the course for me was being able to stay working on
 the programming until I felt more confident with it. This happened
 on Thursday and Friday as I developed programs to enable Robul to do
 additional tasks. I did not need to develop additional programs to
 complete any course requirement but did so to practice programming
 in order that I personally would feel more competent and thus more
 prepared to one day teach the material.


One other team was able to easily produce a mechanically sound robot, in fact their robot evolved through four different versions before its final form. This was partly due to previous mechanical experience but primarily due to their age and gender--they were of the "LEGO generation" and had spent much of their childhood building and playing with LEGO. Unlike the other teams, the members of this team each created several completely different robots. While all of their designs were mechanically viable it was interesting to see this team in action as their robot creations literally evolved as the week progressed.

Early in the knowledge construction process this team lacked social cohesion. In other words, their failure to collaborate/cooperate impacted their ability to construct effective problem-solving solutions. Once they coalesced as a team they were able to generate additional solutions (programming and robot design). This allowed them to move beyond a noncollaborative stage of knowledge construction to a collaborative stage of knowledge construction, thereby overcoming prior conceptual difficulties. They were able to go further together--as a team, than they were as individuals, demonstrating an instance of how social constructionism may effectively promote problem solving (Vygotsky, 1962; Shaw, 1996).

One member of this team equated the creation of their robot to an evolutionary process based on a "survival of the fittest" theory--"based on previous designs, adaptations to design issues were added on to create a robot that is a better fit to the challenge environment." He mentally linked his work with the robots to his prior knowledge and understanding of biology,
 After looking at these initial stages of programming, I quickly
 started to see how I was layering on my experiences with the
 RoboLab environment on top of my biology and education background.
 I have done numerous courses in evolution, and as with my
 experience with vehicle design, I use what I know well to allow
 myself to understand what I am experiencing now.

What this student said convincingly demonstrates the power and authenticity of a constructionist model for learning. On a practical level, looking for knowledge connections can generate a wide range of questions regarding the associations between knowledge constructs. As Papert (1996) suggested, a "deliberate part of the learning consists of making connections between mental entities that already exist; new mental entities seem to come into existence in more subtle ways that escape conscious control" (p. 23).

Though this team moved through several robot creations, from "Tankbot" to "Lobsterbot" to "Dragbot," their final creation, "Thugbot" (Figure 6), was an adept, quick robot that virtually attacked the soda cans it "felt" as it maneuvered about the challenge circle. With the use of dual touch sensors, the robot zeroed in on a soda can as soon as one of the sensors was activated. The robot's program then "instructed" the robot to immediately drive the soda can straight forward until it was pushed beyond the black boundary line.


Though this team was very successful in numerous ways, they were not able to meet the final challenge of counting the soda cans retrieved--they simply ran out of time. This may have been due in some measure to their lack of collaboration as a team for the first few days of the course.

Remaining Three Teams

The remaining three teams all struggled with design and construction issues with LEGO. Two of these teams, however, had team members with prior programming experience. This proved to be valuable for these teams in that they were able to write complex, effective, and efficient program code. The third team however, was hampered by both a lack of experience in LEGO design and construction, and computer programming. Their dual-motor design proved to be somewhat unwieldy and lacked traction and maneuverability. The positioning of the two motors on opposite corners of the chassis created some programming difficulties for this team as well. Unfortunately, the members of this team did not coalesce well as a collaborative group and experienced additional difficulties due to personality conflicts. The difficulties in the group's dynamics hindered their ability to construct higher-level solutions. The end result was that this team was unable to complete any of the additional challenges, though they were successful in completing the basic team challenge of removing the soda cans from within the circle.

Prior experience in programming proved to be a valuable asset for the two remaining teams. Although these teams struggled with the designing and building of their Team Challenge robots, they were successful in completing the basic challenge as well as the additional challenges. Their programming skills were such that these teams were able to create effective and efficient programs, which enabled their robots to maneuver the Team Challenge course despite a few mechanical challenges inherent in their robot designs. Interestingly, both of these teams chose to use one-motor designs to free up the second motor for use in a grabbing mechanism. Consequently, these two teams were faced with sophisticated programming challenges to complete the basic team challenge as well as the additional challenges.


The creators of "Beatrice" used a fairly simple one-motor chassis design from the LEGO Subassembly Constructopedia (LEGO Group, 1999d).

Figure 7 shows their initial design and a close-up view of the differential used in the one-motor design. It did not include a grabbing mechanism as it was designed to complete the basic challenge only and to push the soda cans out of the circle. A grabbing mechanism was added (Figure 8) once this team decided to tackle the additional challenges of returning the soda cans back through the Start Box and of counting the number of soda cans retrieved.


Returning the soda cans back through the Start Box proved to be the most difficult challenge due primarily to the robot's inability to reverse in a straight line or turn in both directions. Timing the turns accurately was crucial for success but due to the issues with the batteries and diminishing power, this was difficult. This team in particular was cognizant of the added benefit and flexibility rotation sensors would provide for robot control and programming ease (these sensors were not available). One member of the Beatrice team was in the process of completing her degree in computer science at the time of the course. She had very little difficulty in learning the ROBOLAB programming language but found the icon-based programming language to be less flexible than written code. She was able to debug her program code through the text mode but felt that students with minimal experience in programming should be introduced at some point in the course to debugging techniques and skills. She believed it important that students learn to create small subroutines for testing sensor reactions, movement etc., and that these subroutines be tested and debugged before moving on to more complicated programming strings. The Beatrice team was successful in meeting the basic Team Challenge as well as the additional challenges.



The final team was comprised of two veteran teachers with prior background knowledge of programming with Microsoft's Visual Basic. This team appeared to struggle somewhat with robot design and construction, due in part to their lack of experience with LEGO as a construction medium, but primarily due to their desire and determination to build a sophisticated robot able to tackle all of the challenges, including retrieving and counting the soda cans using a grabbing mechanism. With only two motors provided in the LEGO kits, this meant they were restricted to a one-motor drive design. Consequently, this team experienced many issues related to turning and reversing, weight and balance, power loss and subsequent inaccuracies as they ran their robot. They were constantly required to redesign in order to address these issues (Figure 9); however, they worked longer hours than most and aided by their programming prowess, were able to complete all of the challenges by the final hours of the last day. A closing comment by one team member attests to the importance their prior programming knowledge and skills played in their success in this course, "We're done! And we accomplished in our code in one day what some of the others have done in three. More proof for that constructionist theory about background knowledge helps to make connections for the learner."


The nature of this course, the speed and tight time-line within which it was delivered and its constructionist format and environment, required the students to work intensely in a collaborative environment. Without proficient collaborative skills and effort, the course would have been just that much more difficult. As Jonassen (1996) suggested,
 Large knowledge bases require a lot of time and effort to research,
 conceive, and construct, and that time and effort will require
 collaborative efforts. An advantage of Mindtools is that they provide
 constrained environments in which learners can more readily identify
 their roles, practice them, and use them consistently while working
 on a knowledge construction project. (p. 37)

Fortunately, the students for the most part rose to the challenge. In particular, the creators of "RoboBot" were amazing examples of the benefits that can be realized from working well as a team. These two veteran teachers were of similar mien and appreciated each other's strengths, bouncing ideas and thoughts off one another. The feelings and thoughts experienced by one member of this team were eloquently expressed in his comment,
 A course such as this is moving very quickly and you are constantly
 learning. I love being in an environment such as this. It is like a
 huge wave that you get on and ride. It is particularly rewarding
 when you have an excellent partner who thinks like you do. It
 creates new learning opportunities and makes available thinking that
 might not otherwise occur.


An underlying goal of this course was to ascertain where LEGO robotics might fit within the Alberta curriculum. Understandably, it was difficult for the undergraduate students in the course to form curriculum connections; the veteran teachers, on the other hand, were readily able to do so. From CTS electro-technologies and robotics, to mathematics, science, and even music, the connections within the curriculum were varied and many. The teachers were able to identify curriculum links from grades four through twelve and across several subjects. Examples included the use of the LEGO robotics kits for exploration in grade 5 sciences--Electricity and Magnetism; grade four sciences--Wheels and Levers; secondary school CTS Electro-Technologies, Mechanics, and Information Processing strands; Grade six music; and Grade nine sciences--Diversity of Living Things; plus numerous curriculum objectives from many areas and levels within mathematics. Within each of these areas, the robotics enable teachers to meet many of the ICT outcomes mandated by the Alberta government and to provide students with an enriching experience using technology as a tool for developing critical and logical thinking, collaboration, and problem-solving skills that will transfer to many other areas of their learning and instruction.


The pilot course was designed to immerse the students within a constructionist environment and to support technology integration within and across the Alberta curriculum. The degree to which this course can be considered a success depends on the technological skills and pedagogical understandings realized by the students enrolled. Based on the student results and feedback, the pilot course appeared to meet its goals, providing the students with a reasonably sound understanding of the design and construction of programmable LEGO robots, and of project-based, constructionist pedagogy. All the students in the course were able to acquire programming skills with the RoboLab software up to and including Inventor Level 4. The degree to which "higher-order" thinking skills can be improved by learning to program is still very much an open question (Ahmed, 1992). That being said, the RoboLab language appears to support a deeper conceptual understanding of the working relationship between the function of the physical objects and how one can logically control these objects; linking the concrete with the abstract. As diSessa (2000) pointed out,
 People learn about many mechanisms purely by the function we
 ordinarily think of them as performing, but no mechanism does only
 and exactly what you want it to do in all circumstances. Usually,
 when a mechanism doesn't match our functional expectations, we
 think of it as a breakdown, but a good learner takes breakdowns as
 opportunities to learn structure, which explains breakdowns and may
 help to avoid them or to "patch" around them. Better, a bit of
 structure may open the possibility for innovative uses not
 orginally considered (p. 129).

The students' robotic machines were successful to varying degrees in accomplishing the programming tasks set before them. Many students commented on the learning environment they were immersed in, appreciating the value of the hands-on, activity-based approach to learning within a constructionist framework.

The majority of the students enrolled in the course were able to make connections and link robotic technology with a variety of curriculum objectives across several subject areas. In particular the area of science education offers an environment where activity, in the form of constructing knowledge through model building, can be used to understand the scientific thinking process. Penner (2001) pointed out that programmable LEGO technology embodies three characteristics of science education. "First, it puts students in control of expressing their ideas. Second, it allows students to design and build their personal representations of phenomena. Finally, the concrete artifacts can help focus discussion and reflection within a community of learners" (p. 27).

Students were also cognizant of the realities of a robotics program, that is, the costs and requirements involved in equipment, space, and time. Several students commented that while they believed robotics to be highly valuable as a tool for learning, they could not foresee using it in a regular class setting. Rather, students viewed robotics as better suited for use in a school science, computer and/or enrichment club. Such comments are reminiscent of those made over 20 years ago with respect to computers. That being said, as technology evolves it provides the potential for various forms of integration into the teacher education process--to this end, the students appear to be truly excited by the possibilities.


Course preparation:

Preparation and set-up: The preparation and set-up immediately prior to the commencement of the course included sorting the twelve LEGO Team Challenge kits (LEGO Group, 1999c), requiring approximately 20 to 30 minutes per kit--a time-consuming task; installing the RoboLab software and infrared transmitters on the PCs in the lab; preparing the course materials for the students, including a course outline; and gathering and preparing the materials needed for the Team Challenge.

Materials: Student course materials included copies of Introductory Activities for LEGO DACTA Set # 9790 and LEGO DACTA[TM] Robotics System Teacher Notes (LEGO Group, 1999a), LEGO DACTA[TM] Robotic System Teacher Notes and Copymasters for LEGO DACTA Set # 9790 (LEGO Group, 1999b), and the Teachers' Guide for RoboLab Software (Cyr, 1998). The LEGO DACTA kits were supplied for the students' use, however, the batteries for the RCXs were purchased by the students. Each team had two sets of 6 AA batteries. The materials needed for the Team Challenge included four sheets of white Bristol board per team, black and green felt markers, masking tape, and five weighted soda cans partially filled with clean cat litter.





Evaluation Rubric for Completing the Robot Team Challenge


1. Robot built

2. Robot moves

3. Robot completes basic navigation (can the robot maneuver throughout its environment?)

4. Does the robot use sensors (touch and lights sensors)?

5. What level of the robot team challenge did your robot complete?

(a) Remove one can

(b) Remove more than one can

(c) Remove all cans

i. One at a time

ii. More than one at a time

(d) Starting position of robot

i. Inside circle

ii. In Start Box facing entrance

iii. In Start Box facing away from the boundary circle

(e) Only the cans returned to the Start Box are counted

i. Each can is counted

ii. An exhaustive search area ensures all cans have been removed

6. Programming: justify programming based on

(a) Level of complexity

(b) Efficiency of the design

Note: Include a printout of your program(s)

7. Design: justify design based on

(a) Level of complexity

(b) Efficiency of the design

Note: Include digital still photos of your design (Please submit a disk copy, NOT printout)


Course readings reference list:

Brandes, A. (1996). Elementary school children's' images of science. In Y. Kafai & M. Resnick (Eds.), Constructionism in practice: Designing, thinking and learning in a digital world, (pp. 37-69). Mahwah, NJ: Lawrence Erlbaum.

Martin, F.G. (1995). The art of LEGO design. The Robotics Practitioner: The Journal for Robot Builders, 1(2), 1-19.

Papert, S. (1991). Situating constructionism. In I. Harel & S. Papert (Eds.), Constructionism. (pp. 1-11). Norwood, NJ: Ablex.

Papert, S. (1996). A word for learning. In Y. Kafai & M. Resnick (Eds.), Constructionism in practice: Designing, thinking and learning in a digital world. (pp. 9-24). Mahwah, NJ: Lawrence Erlbaum.

Resnick, M. (1996). New paradigms for computing, new paradigms for thinking. In Y. Kafai & M. Resnick (Eds.), Constructionism in practice: Designing, thinking and learning in a digital world. (pp. 255-268). Mahwah, NJ: Lawrence Erlbaum.

Sargent, R., Resnick, M., Martin, F., & Silverman, B. (1996). Building and learning with programmable bricks. In Y. Kafai & M. Resnick (Eds.), Constructionism in practice: Designing, thinking and learning in a digital world. (pp. 161-173). Mahwah, NJ: Lawrence Erlbaum.


Ahmed, A. M. (1992). Learning to program and its transference to student's cognition. (Eric Document Reproductive Service No. ED 352 261)

Alberta Learning. (2001). Information and Communication Technology Program of Study. Retrieved August 25, 2001, from:

Alessi, S. M., & Trollip, S. T. (1991). Computer-based instruction (2nd ed.). Englewood Cliffs, NJ: Prentice Hall.

Bruner, J. S. (1966) Toward a theory of instruction. Cambridge, MA: Harvard University Press.

Carbonaro, M. (1997). Making technology an integral part of teaching: The development of a constructionist multimedia course for teacher education. Journal of Technology and Teacher Education, 5, 255-280.

Cyr, M. N. (1998). Teachers' guide for RoboLab software. Billund, Denmark: The LEGO Group.

diSessa, A. A. (2000) Changing minds: Computers, learning, and literacy. Cambridge, MA: MIT Press.

Druin, A., & Hendler, J. (2000). Robots for kids: Exploring new technologies for learning. San Diego, CA: Academic Press.

Gagne, R., Briggs, L., & Wager, W. (1988). Principals of instructional design. New York: Holt, Rinehart & Winston.

Harel, I., & Papert, S. (1991). Software design as a learning environment. In I. Harel & S. Papert (Eds.), Constructionism. (pp. 41-84). Norwood, NJ: Ablex.

Hendler, J. (2000). New robot technologies for kids. In A. Druin & J. Hendler, (Eds.), Robots for kids: Exploring new technologies for learning. (pp. 1-8). San Diego, CA: Academic Press.

Jonassen, D. H. (1996). Computers in the classroom: Mindtools for critical thinking. Upper Saddle River, NJ: Prentice Hall.

Jonassen, D. H. (2000). Computers as mindtools for schools: Engaging critical thinking (2nd ed). Upper Saddle River, NJ: Prentice Hall.

Jonassen, D. H., Peck, K. L., & Wilson, B. G. (1999). Learning with technology: A constructivist perspective. Upper Saddle River, NJ: Prentice-Hall Inc.

Khan, B. H. (1997). Web-based instruction (WBI): What is it and why is it? In B. H. Khan (Ed.) Web-based instruction. (pp. 5-18). Englewood, NJ: Educational Technology.

Knudsen, J. B. (1999). The unofficial guide to LEGO[R] MINDSTORMS[TM] robots. Sebastopol, CA: O'Reilly & Associates.

LEGO Group (1999a). Introductory activities for LEGO DACTA set # 9790 and LEGO DACTA[TM] robotics system teacher notes. Billund, Denmark: The LEGO Group.

LEGO Group (1999b). LEGO DACTA[TM] robotic system teacher notes and copymasters for LEGO DACTA set # 9790. Billund, Denmark: The LEGO Group.

LEGO Group (1999c). LEGO MINDSTORMS[TM] set for schools # 9790. Billund, Denmark: The LEGO Group.

LEGO Group (1999d). Subassembly constructopedia. In LEGO Group (1999), LEGO MINDSTORMS[TM] set for schools # 9790. Billund, Denmark: The LEGO Group.

Logan, R. (1995). The fifth language: Learning a living in the computer age. Toronto, CA: Stoddart.

Martin, F.G. (1995). The art of LEGO design. The robotics practitioner: The Journal for Robot Builders 1(2), 1-19.

Martin, F., Mikhak, B., Resnick, M., Silverman, B., & Berg, R. (2000). To Mindstorms and beyond: Evolution of a construction kit for magical machines. In A. Druin & J. Hendler (Eds.), Robots for kids: Exploring new technologies for learning. (pp. 11-33). San Diego, CA: Morgan Kaufmann.

Miglino, O., Lund, H.H., & Cardaci, M. (1999). Robotics as an educational tool. Journal of Interactive Learning Research, 10, 25-47.

Orhun, E. (1995). Design of computer-based cognitive tools. In A.A. diSessa, C. Hoyles, R. Noss, & L. D. Edwards (Eds.), Computers and exploratory learning, (pp. 305-319). Berlin: Springer-Verlag.

Papert, S. (1980). Mindstorms: Children, computers and powerful ideas. New York: Basic Books.

Papert, S. (1990). Introduction. In I. Harel (Ed.), Constructionist learning, (pp. 1-8). Boston: MIT Laboratory.

Papert, S. (1996). A word for learning. In Y. Kafai & M. Resnick (Eds.), Constructionism in practice: Designing, thinking and learning in a digital world. (pp. 9-24). Mahwah, NJ: Lawrence Erlbaum.

Pea, R.D. (1985). Beyond amplification: Using the computer to reorganize mental functioning. Educational Psychologist, 20(4), 167-182.

Penner, D.E. (2001). Cognition, computers, and synthetic science: Building knowledge and meaning through modeling. In W. G. Secada, (Ed.) Review of research in education, (pp. 1-35). Washington, DC: American Educational Research Association.

Piaget, J. (1954). The construction of reality in the child. New York: Basic Books.

Portsmore, M. (1999). RoboLab: Intuitive robotic programming software to support lifelong learning, Learning Technology Review, Spring/Summer, 26-39.

Resnick, M., & Ocko, S. (1991). LEGO[R] /Lego: Learning through and about design. In I. Harel & S. Papert (Eds.), Constructionism. (pp. 141-150). Norwood, NJ: Ablex.

Salomon, G., Perkins, D.N., & Globerson, T. (1991). Partners in cognition: Extending human intelligence with intelligent technologies. Educational Researcher, 20(3), 2-9.

Sanders, W.L. (1992, March). Constructivist perspective: Implications and teaching strategies for science. School Science and Mathematics, 92(3), 136-141.

Santrock, J.W. (2001). Educational psychology. New York: McGraw-Hill.

Sargent, R., Resnick, M., Martin, F., & Silverman, B. (1996). Building and learning with programmable bricks. In Y. Kafai & M. Resnick (Eds.), Constructionism in practice: Designing, thinking and learning in a digital world. (pp. 161-174). Mahwah, NJ: Lawrence Erlbaum.

Shaw, A. (1996) Social Constructionism and the inner city: Designing environments for social development and urban renewal. In Y. Kafai & M. Resnick (Eds.), Constructionism in practice: Designing, thinking and learning in a digital world. (pp. 175-206). Mahwah, NJ: Lawrence Erlbaum.

Thangiah, S.R., & Joshi, S. W. (1997). Introducing robotics at the undergraduate level. Journal of Computers in Mathematics and Science Teaching, 16, 223-237.

Wagner, S.P. (1998). Robotics and children: Science achievement and problem solving. Journal of Computing in Childhood Education, 9(2), 149-192.

Wallich, P. (2001). Mindstorms: Not just a kid's toy. IEEE Spectrum, 38, 52-57.

Vygotsky, L. S. (1962). Thought and language. Cambridge, MA: MIT Press.


University of Alberta

COPYRIGHT 2003 Association for the Advancement of Computing in Education (AACE)
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2003, Gale Group. All rights reserved. Gale Group is a Thomson Corporation Company.

Article Details
Printer friendly Cite/link Email Feedback
Author:Carbonaro, Mike
Publication:Journal of Technology and Teacher Education
Date:Jun 22, 2003
Previous Article:Video technology as a support for teacher education reform.
Next Article:PBL + IMM = PB[L.sup.2]: problem based learning and interactive multimedia development.

Related Articles
Lessons click with young engineers.
Preparing practicing teachers to teach in inclusive schools.
Missions to Mars.
Aberdeen chapter sponsors Robotics Competition.
Robotics: the 4th R?
Robotic technologies: when parents put their learning ahead of their child's.

Terms of use | Privacy policy | Copyright © 2018 Farlex, Inc. | Feedback | For webmasters