Visualization of Program Behaviors: Physical ... - Semantic Scholar

Visualization of Program Behaviors: Physical Robots Versus Robot Simulators Cheng-Chih Wu1, I-Chih Tseng1, and Shih-Lung Huang2 1

National Taiwan Normal University, Information and Computer Education, 162 Heping East Road, Sec. 1, Taipei, Taiwan {chihwu,samuel}@ice.ntnu.edu.tw 2 Taipei Municipal Dali High School, 2, Changshun St., Taipei, Taiwan [email protected]

Abstract. This study compared the effects of using physical robots (LEGO Mindstorms) and robot simulators (LEGO Mindstorms Simulator, LMS) in teaching novice programming concepts. A quasi-experiment design was implemented in this study. Four classes of high school students, totaling 151 students, participated in the study. Two classes of 76 students used the physical robots to learn programming, whereas the other two classes of 75 students used LMS. The students’ post-experiment achievement tests, replies on questionnaires, and focus group interview data were collected and analyzed. The findings of the study were: (1) no significant difference was found on students’ performance between the physical robot group and the simulator group, (2) the physical robot group demonstrated more positive attitudes toward the learning activities, and (3) the physical robot group indicated that they could better imagine the program behaviors. Keywords: Programming, Robot, Simulator, LEGO Mindstorms.

1 Introduction In recent years, computer science educators have advocated the use of robots in CS1 and CS2 courses, especially in teaching novices programming concepts [1, 2, 3, 4]. Some [5] further proposed that robotics-oriented projects could be used to motivate and enhance the learning of certain knowledge areas recommended in ACM Computing Curriculum 2001 [6]. The use of robots addresses the problems or difficulties that novice programmers face such as weak logical reasoning and coding before designing; and students find working with robots interesting and fun [3]. Early use of the concept of robots in teaching programming originated from the development of the “mini-language” approach. The idea of the mini-language approach is to design a small and simple language to support the beginning of learning programming. Mini-languages provide insight into programming for the general population and to teach algorithmic thinking [7]. The programming environment of mini-languages is often accompanied with a micro-world, where students learn to R.T. Mittermeir and M.M. Sysło (Eds.): ISSEP 2008, LNCS 5090, pp. 53–62, 2008. © Springer-Verlag Berlin Heidelberg 2008

54

C.-C. Wu, I.-C. Tseng, and S.-L. Huang

program by studying how to control a robot, which can be a turtle, a ladybug, or other agents, acting in the micro-world. Students can actually “see” how their programs were executed by observing the behaviors of the programmed robot in the microworld. For example, in Papert’s LOGO [8], students command a turtle robot to draw figures on the screen. In Karel the Robot (http://www.mtsu.edu/~untch/karel/), the robot lives in a micro-world consisting of streets, walls, and beepers. The robot can move along the streets, detect walls, and pick up, move, and put down beepers. Concepts such as procedures and basic control structures can be quickly introduced to students by using the Karel micro-world. The visual representation of the robot’s world offers many benefits, among them are: the animation provides visual feedback on the correctness of an algorithm and students can often see where their program goes wrong simply by watching the animation [2]. Since students may eventually learn to program with general-purpose programming languages, it was proposed to use a subset of a general-purpose language to replace the mini-language approach [7]. In fact, various versions of Karel have been developed based on different programming languages such as C, C++, and Java. A good way to make the virtual robot more attractive for young students is to use a real world robot [7]. The more practical and concrete the learning situations are, the more learning takes place [9]. The game-like feature of the real robots motivates students to invest time and mental efforts on learning [10]. The benefits of using real robots have been supported by the availability of standardized, low-cost robot construction kits during the last decade. For example, the newly released LEGO Mindstorms NXT kit (http://www.lego.com), with a 32-bit microprocessor (NXT brick), 3 interactive servo motors, 4 sensors (sound, ultrasonic, light, and touch sensors), wheels, USB and Bluetooth support, and 519 construction pieces – everything needed for constructing a robot, costs approximately USD 250. It allows the user to build fully autonomous robots with all computing power located within the machine. Many CS educators have used LEGO Mindstorms to teach students programming concepts and the reported effects are mostly positive [9, 11, 12]. Although there are many claimed benefits for using the physical robots to teach novice programming, little empirical evidence has shown that its effects are indeed better than the robot simulators on the screen. If the effects of both teaching tools are the same, it may not be worth spending money on purchasing the physical robots. This study reports our preliminary attempt to compare the effects of using the LEGO Mindstorms (LM) robot and its simulator – LM Simulator in teaching novice programming concepts.

2 Methodology A quasi-experiment design was implemented in this study. Four classes with a total of 151 10th grade high school students who enrolled in an Introduction to Computers course participated in the experiment. Two classes of 76 students used the LM robots (LMR group) to learn programming concepts, whereas the other two classes of 75 students used the LM simulator (LMS group). The experiment was conducted over a seven-week period in which students met two hours per week. All the learning activities were directed by the same teacher who was experienced in using the LM tools.

Visualization of Program Behaviors: Physical Robots Versus Robot Simulators

55

We collected various data sources to analyze the effects between the two groups, including the post-experiment achievement test scores, student questionnaires, and focus group interviews with students. Below, we describe the LM robots, the LM simulator, and the learning activities implemented in the study. 2.1 LEGO Mindstorms Robots The LMR group used the LEGO Mindstorms RCX module which consisted of a 16 bit microprocessor (RCX brick), a light sensor, a touch sensor, and other LEGO components. The robot can use its light sensor to track the path of a street and use its touch sensor to detect the wall so that it can walk in a maze. We decided to provide students with pre-assembled robots (see Fig. 1) instead of having students build their own robot. This allows students to focus their attention on programming the robot. In order to use Java with the Mindstorms robots, the original firmware in the RCX brick was replaced with another firmware – leJOS which is a tiny Java Virtual Machine for the LEGO Mindstorms RCX. LeJOS is an open source project and can be freely downloaded from www.sourceforge.net. Due to the limited number of LM robots we had, students in the LMR group share the robots, that is, two students used one LM robot. However, each student was provided with a PC when writing programs.

Fig. 1. The pre-assembled robot for the LMR group

2.2 LEGO Mindstorms Simulator As to the LM simulator group, we adopted the LEGO Mindstorms Simulator (LMS, http://ddi.uni-paderborn.de/software/lego-mindstorms-simulator.html) as the learning

56


Fig. 2. The LEGO Mindstorms Simulator for the LMS group

Fig. 3. Editing/compiling/downloading a robot program in Eclipse


57

tool. The LMS was developed by a research group at the University of Paderborn. The simulator is written in Java to simulate leJOS programs with simple 3D-Models (see Fig. 2). LMS enables students to write programs in Java that will run in a graphic simulator and in the LM robot. The simulator can simulate a robot and other actors, such as walls and streets. A Java program written for controlling the LM robot in the real world environment can also be used to control the virtual robot running in a similar scene on the simulator screen. Thus, the major difference between the two groups is: the LMR group ran their programs in the real world, and the LMS group ran their programs on LMS on a computer screen. Both groups used Eclipse (http://www.eclipse.org/, see Fig. 3) to edit/compile/ download their programs. We had revised Eclipse source codes and several plug-ins so that students could download their compiled programs to the LM robot and the LMS with simple operations. 2.3 Learning Activities The learning activities were designed to enable students to learn basic programming concepts, that is, variables, expressions, assignment, and control structures. Because our focus was on teaching algorithmic thinking, not the Java language, we limited students’ use of Java components on the following: if-else, if-else-if, while, arithmetic/relational/Boolean operators, integer variables, and assignment. When writing programs for solving a problem, we provided a template for students to use. All the necessary declaration and system settings for the program were given in the template. Students only had to program the codes on the algorithm block (see Fig. 3, “Start your program here”). LeJOS provides basic commands to control the LM robot. For example, for the robot to make a right turn, you need to give a command to stop the right motor (wheel) and a command to start the left motor (wheel), and yet another command to keep the current status for a certain amount of time. We considered these commands too primitive and not intuitive enough for students to manipulate the robot, especially if our focus was on algorithmic thinking. To reduce the learning load and make the control of the robot more intuitive, we provided students with the following seven methods (adapted from [13]): Motor.A.setpower (n): Set the power of left motor to n level. Motor.B.setpower (n): Set the power of right motor to n level. car.travel (±n): The robot move forward (+) or backward (-) n centimeters. car.rotate (±n): The robot turns clockwise (-) or counter-clockwise (+) n degrees. car.stop (): The robot stops. car.touch_sensor (): Return TRUE if the robot touches something, else False. car.light_sensor (): Return the light intensity it detects. The learning activities consist of five units as shown in Table 1. Each unit was conducted with the following steps: First, the teacher demonstrated how to write a program to solve an example problem. The codes of example programs were available for students in the example folder. Next, students were given an assignment, which was similar to the example problem and could be easily solved by revising the example program. Finally, students were given a second assignment to write a whole program. To solve the assignment, students would need to use the concepts/instructions

58


taught in the unit. An optional third assignment was offered for students who had finished the second assignment before the teacher concluded the unit. Fig. 4 is the maze assignment given to the LMR group in Unit 2, whereas Fig. 2 is the same assignment for the LMS group. To solve the problem, students would need to use the conditional structure to determine whether the touch sensor touches a wall and use a simple iterative structure (while(true)) to make the robot continue going. Fig. 5 is the “Tracking the road” assignment given to the LMR group in Unit 4. Students would need to make use of the light sensor to “see” the road to complete the assignment. Table 1. Programming and robot concepts covered in each unit

Unit 1 2 3 4 5

Programming concepts 1. Editing programs (Eclipse) 2. Sequential structure 1. Conditional structure (if-else) 2. Boolean expression 3. Iteration structure (while) 1. Variables 2. Conditional structure (if-else-if) 1. Code reusing 2. Review on control structures A small project

Time Robot concepts 1. LMR/LMS environment 3 hrs 2. Basic control (move, turn, stop) 1. Use of a touch sensor 2. Detecting walls

4 hrs

Walking in a maze

2 hrs

1. Use of a light sensor 3 hrs 2. Tracking the road Combining use of touch sensor 2 hrs and light sensor

Fig. 4. The maze assignment for the LMR group


59

Fig. 5. The “Tracking the road” assignment for the LMR group

3 Results and Discussion 3.1 Achievement Test The post-experiment achievement test consists of two parts. One is for testing students’ comprehension of programs the other is for testing a generation of programs. Since our experiment lasted only 14 hours, we decided to cover only near-transfer tasks in the achievement test, except for one task in the program generation part. The near-transfer tasks were the ones which were similar to the examples or assignments given in the learning activities. A t test was performed to test the differences of the achievement scores between the two groups. Table 2 presents the summary results. The t test results show that there were no significant differences between the LMR group and the LMS group in terms of the program comprehension (t(149) = 0.08, p = .94), program generation (t(149) = 0.56, p = .58), and the total (t(149) = 0.38, p = .71) scores. Obviously, students achieved similar performance levels in learning programming using either the physical robots or the robot simulator. Table 2. The t test results on students’ post-experiment test scores Test (total scores) Program comprehension (7) Program generation (8) Total (15)

Group LMR LMS LMR LMS LMR LMS

Mean 5.37 5.35 5.68 5.49 11.05 10.84

SD 1.74 1.61 2.13 2.08 3.63 3.31

t 0.08 0.56 0.38

60


3.2 Perceptions of Learning Activities In the post-experiment questionnaire, we asked students in both groups about their perceptions of the learning activities and their attitudes toward learning. Students were asked to fill out the questionnaire on a Likert-type scale, which ranged from strongly agree to strongly disagree. Scores were assigned 5 for strongly agree, 4 for agree, etc. Table 3 shows the statistical results of students’ perceptions of the learning activities. Overall, both groups considered themselves to understand the robot methods and the Java statement moderately well in the learning activities (Items 1 and 2) and could reasonably visualize the robot’s behaviors when viewing a program (Items 3 and 4) – the mean score of each item is around 3.5 to 4 (agree). Both groups were neutral on the difficulty of the assignment (Item 5). The t test results reveal that the physical robot group could better imagine the program behaviors (Item 3, t(149) = 1.98, p < .05) and felt that they did not have enough time to finish the assignments (Item 6, t(149) = 3.88, p < .01), as compared to the robot simulator group. It seemed running robots in the real world environment might enhance student construction of the mental model of programming, and thus enable them to imagine program behaviors better. However, downloading programs to the RCX brick via the easy interfered infrared and testing programs with the physical robots required students to take extra time on the tasks. The newly released LEGO Mindstorms NXT brick, which uses USB to download programs, may resolve the problems that resulted from using infrared. Table 3. The t test results on students’ perceptions of the learning activities

Item

Group Mean LMR 4.12 1. I understood the robot methods in the activities. LMS 3.99 LMR 3.71 2. I understood the Java statements in the activities. LMS 3.56 LMR 3.76 3. I could imagine how the robot would move by viewing the program. LMS 3.48 LMR 3.50 4. Viewing the robot running my program helped me find the bugs. LMS 3.39 LMR 3.09 5. In all, the assignments were not difficult. LMS 2.79 LMR 3.70 6. I did not have enough time to finish the assignments. LMS 3.17 *p < .05, **p < .01

t 0.90 0.93 1.98* 0.68 1.90 3.88**

3.3 Attitudes Toward Learning Table 4 presents the summary results of students’ attitudes toward the learning activities. The results show that both groups of students felt a great sense of achievement when seeing the robot running their programs, but no significant difference was found between the two groups (Item 7, t(149) = 1.92, p = .057). The results also indicate that


61

the physical robot group experienced having more fun on the programming tasks (Item 8, t(149) = 3.39, p < .01) and wished to learn more about robot programming (Item 9, t(149) = 3.40, p < .01) as compared to the robot simulator group. No significant difference was found between the two groups when asked if they would like to learn more about other programming (Item 10, t(149) = 1.28, p = .20). Overall, the physical robot groups demonstrated more positive attitudes on learning. Table 4. The t test results on students’ attitudes about the learning activities

Item Group Mean 7. I felt a sense of achievement when seeing the LMR 4.22 robot running my program. LMS 3.91 LMR 3.84 8. Programming with the robot was fun. LMS 3.17 LMR 3.54 9. I wish to learn more about robot programming. LMS 2.89 10. Besides robot programming, I wish to learn more LMR 3.62 about other programming. LMS 3.39 **p < .01

t 1.92 3.39** 3.40** 1.28

4 Conclusions In this study, we compared the effects of using the physical robots and the robot simulators in teaching novice programming. The post-experiment survey questionnaire shows that students in the physical robot group had more fun with the learning activities, wished to learn more about robot programming, and considered themselves imagining the program behaviors better as compared to the simulator group. However, there was no significant difference found between the two groups in terms of the post-experiment achievement. The present study conducted the experiment for a short period of time (14 hours) and only measured students’ near-transfer performance. It is suggested that future studies extend the experiment time so that the learning effects may become more evident and the far-transfer performance can also be measured.

Acknowledgement This study was funded by the National Science Council of Taiwan under the grant number NSC 95-2520-S-003-008-MY3.

References 1. Lawhead, P.B., Duncan, M.E., Bland, C.G., Goldweber, M., Schep, M., Barnes, D.J., et al.: A Road Map for Teaching Introductory Programming Using LEGO© Mindstorms Robots. ACM SIGCSE Bulletin 35(2), 191–201 (2003) 2. Becker, B.W.: Teaching CS1 with Karel the Robot in Java. ACM SIGCSE Bulletin 33(1), 50–54 (2003)

62


3. Schep, M., McMulty, N.: Use of LEGO Mindstorms Kits in Introductory Programming Classes: A tutorial. Journal of Computing Sciences in Colleges 18, 323–327 (2002) 4. Linder, S.P., Nestrick, B.E., Mulders, S., Lavelle, C.L.: Facilitating Active Learning with Inexpensive Mobile Robots. Journal of Computing Sciences in Colleges 16, 21–33 (2001) 5. Klassner, F., Anderson, S.D.: LEGO Mindstorms: Not just for K-12 Anymore. Robotics & Automation Magazine 10, 12–18 (2003) 6. ACM/IEEE Task Force: Computing Curricula 2001. ACM/IEEE (2001) 7. Brusilovsky, P., Calabrese, E., Hvorecky, J., Kouchnirenko, A., Miller, P.: Minilanguages: A Way to Learn Programming Principles. Education and Information Technologies 2, 65–83 (1997) 8. Papert, S.: Mindstorms: Children, Computers, and Powerful Ideas. The Harvester Press Ltd. (1980) 9. Lahtinen, E., Ala-Mutka, K., Jarvinen, H.-M.: A Study of the Difficulties of Novice Programmers. ACM SIGCSE Bulletin 37(3), 14–18 (2005) 10. Dagdilelis, V., Sartatzemi, M., Kagani, K.: Teaching (with) Robots in Secondary Schools: Some New and Not-So-New Pedagogical Problems. In: Fifth IEEE International Conference on Advanced Learning Technologies (ICALT), pp. 757–761 (2005) 11. Flowers, T.R., Gossett, K.A.: Teaching Problem Solving, Computing, and Information Technology with robots. Journal of Computing Sciences in Colleges 17, 45–55 (2002) 12. Fagin, B.S., Merkle, L.: Quantitative Analysis of the Effects of Robots on Introductory Computer Science Education. Journal on Educational Resources in Computing (JERIC) 2, 1–17 (2002) 13. Bagnall, B.: Core LEGO Mindstorms Programming. Prentice-Hall, Englewood Cliffs (2002)