From Mini Rover Programs to Algebraic Expressions

From Mini Rover Programs to Algebraic Expressions G. Barbara Demo Dipartimento Informatica University of Torino Torino, Italy barbara@di.unito.it Abstract During their second year of a junior high school, pupils wrote programs for autonomous mini robots using a Logo-like language supplemented by an integrated development environment specifically implemented for them. Then pupils and teachers together performed a static analysis of programs in order to specify the length of the paths each robot covers when programs are run. If a robot mounts sensors and the analyzed program uses them, the path covered during each run generally changes and has a different length. Pupils found that it can be specified with an expression containing variables. This analysis associating algebraic expressions to robot programs provided teachers for a support motivating elementary algebra, a typical subject addressed in junior high schools. Thus it is an example of how robotics can be used as means to introduce and concretely manipulate topics of traditional disciplines. It can be integrated in standard school curricula and become a constructionist learning tool for pupils involved in programming activities. Keywords - programming; inquiry based science education; generalization; learner centered education I. INTRODUCTION Computer Science (CS) or Informatics, as it is more often called in Europe, is present in activities of k-12 schools in mainly three different ways: - for educating pupils in computer science. These are the CS disciplinary activities obviously present in schools that have CS in their educational offer. Very well known robot competitions like RoboCup are in this category, see www.robocup.org; - when using software tools to perform activities concerning non CS disciplines. We call this the instrumental presence of CS in a school activity. Popular examples are GeoGebra, Cabri, MathLab, simulators in general and many other software systems used to visualize and experience the different disciplines; - when using concepts and methods of informatics to teach other disciplines. We call this approach the crossdisciplinary presence of CS in education. In Italy some recent yet already popular CS competitions, like Kangourou for Informatics and Problem Solving Olympic Games, aim at developing this type of CS presence in schools [1,2]. When technology was first introduced in education, the cross-disciplinary approach was considered very interesting but after a while it has been less investigated likely overwhelmed by the instrumental use of CS. Competitions named above, in the third approach to CS, have recently received a large attention in Italian schools and are contributing to renew the interest toward how computer science may influence approaches to learning the other subjects present in standard curricula. Several projects are not classifiable in one only of the above types of CS presence in education because, in the way they are carried out, we can detect aspects belonging to more than one of the above components. In particular, in the crossdisciplinary approach often elements of informatics are taught in order to use them in other disciplines. This is the case of data structures such as trees or graphs introduced to show how modeling a given problem environment in a proper way leads to an easier solution. Here we describe an activity in support of the crossdisciplinary approach carried out in a junior high school second class, i.e. with 11-13 years old pupils, during 2009/2010 school-year. The aim of the study is introducing pupils to algebraic expressions and experimenting when they are needed to specify the length of the paths robots cover when running pupils programs. Pupils write programs for moving different types of autonomous mini robots using a Logo-like language and an integrated development environment (IDE) specifically implemented for young students. In Section 2 examples of programs written in this language are shown and the IDE is shortly described. After some programming activities with very simple rovers, pupils are given sensors that allow a robot to detect when, for example, it is touching an obstacle, hearing a sound or crossing a dark strip on the floor. Pupils design robots behaviors that make use of sensors and write corresponding programs. Then they are required to think whether it is possible to specify the length of the path or of segments of the path covered by a robot during a run of a program. As described in Section 3, through this analysis of their programs, our students were leaded to introduce variables and algebraic expressions typical concepts in their curriculum of junior high school mathematics. By means of this activity, students could experiment and thus motivate elementary algebra. In Section 4 we summarize our current investigations, not yet verified on students, on how pupils can contrast different solutions to the same problem by combining code-reading, paths the robots draw while executing different codes and the shapes of these paths. During these comparisons teachers may drive pupils to discover which solutions solve more

problems, i.e. to discover more general solutions and introduce students to mathematical generalization. The need for tools motivating elementary algebra and leading to generalization was inspired by the research described in [3], tough, dealing with robot programming, we work in a quite different environment. Rocard s Report has become a mandatory reference for Science pedagogy since its publication in 2007 [4]. In it we read: Mathematics education may easily use a problem based approach while, in many cases, the use of experiments is more difficult. Our aim is to find educational activities for experimenting mathematics, like those described here. They will contribute to settle also for mathematics learning an Inquiry Based Science Education (IBSE) methodology considered as the foundation of the renewed pedagogy for the future of Europe outlined in Rocard s Report. In Section 5 we summarize conclusions on our work. Ending this Introduction, we recall that educational robotics has been and still is addressed in several projects belonging to the first category of CS disciplinary activities. Likely most known of these projects is Roberta, born around 2002 and now developed in several European countries [5]. Another European project called TERECoP (Teacher Education on Robotics-Enhanced Constructionist Pedagogical methods) is nearer to the constructionist perspective for robotics integrated into the school normal curricula that is the aim of our activities [6]. TERECoP complements our activities by adressing high school and university level students. Kurebayashi s group research is also of interest for us because, tough in the first CS approach category, it investigates cognitive influences of the experience of programming on young students, a fourth future way of considering the presence of CS in schools [7]. II. ROVER PROGRAMMING Using programming as a support to other disciplines is one of our aims. Thus it is important we offer a language oriented to users new to programming such as our students and teachers normally are. Also important is to use the same language and IDE for all types of mini robots found in school. In this section both the programming language and the IDE offered to schoolchildren and to teachers are sketched as an introduction to the program analysis described in section III. A. First Programs In our activities pupils use a Logo-like textual language called NQCBaby from the NQC language developed by D. Brawn for the RCX Lego brick [8, 9]. RCX is the brick we found in schools at the beginning of our educational robotics activities in 2006. In the following examples the Italian primitives of the NQCBaby language are translated in English and parameters of moving statements are tenth of seconds. In Progr-1 the first instruction (Hi Mafalda)gives the name Mafalda to the robot, then commands for robot moving follow. Prog-1: Hi Mafalda forward(20) right(10) backward(9) NQCBaby is not a complete programming language because we do not intend to make children become good programmers using it. It is language designed for specific educational achievements. For example, in primary school, a gradual introduction of new hardware components, sensors or actuators, and the related language primitives for using them in robot-programmed behaviors can comply the advances of schoolchildren logical and linguistic abilities, as described in [10]. One of our activities with pupils of the junior high school second year, concerned an exhibition where each robot had to show the geometrical shapes pupils had taught her/him. Most groups came out with programs where several geometrical figures are drawn on the floor one after the other as coded in the program, always the same in the same sequence, as in program Prog-2. Prog-2: Hi Susi forward(12) left(10) repeat(3) forward(9) left(12) A repeat(n) statement makes its body (i.e. the statements from that statement to its corresponding endrepeat) be repeated n times. When we introduce sensors (touch, light or sonar sensors) the NQCBaby language is enriched with statements to deal with them, i.e. for specifying to which port a sensor is connected and for verifying sensor reactions to the environment. In Progr-3 below, a touch sensor is declared on port-1 of the brick. We asked pupils to think of a program that makes the robot move on the floor and turn when touches an obstacle. Progr-3 is the program produced by one group. Before or while the robot is executing Progr-3, pupils decide where to put the obstacles (often these simply are the feet of the pupils). In Prog-3 the statement switches on the engines of both wheels in the forward direction. Thus the robot goes on until something is touched (if-touches becomes true) that makes the robot go right(5) etc. With this program the robot goes on (repeat-always) until it is stopped from the outside. Prog-3: Hi Zoe port-1 is touch repeat-always if-touches right(5) forward(3) left(5) end-if-touches Other examples of robot programs are shown in the next section.

B. An IDE for unexperienced people Pupils write their programs using the IDE implemented by students of our university whose interface is shown in Figure 1. The NQCBaby code is written in the "white board" central to the window in figure 1. The toolbar shows icons for writing a new code sequence, opening a directory, saving or printing the NQCBaby sequence. The icon gear is used for translating the NQCBaby code. When the Lego RCX robot is used, NQCBaby is translated into NQC [8,10], when an NXT brick is used, NQCBaby is translated into the NXC (Not exactly C) language [8]. As we said, our robot programming language is not a complete language: pupils can see their code translation in the IDE window and thus begin to learn the target language in case they want to achieve advanced programming competencies. Errors are reported at the bottom with code line. Before opening the IDE the user specifies which robot is used and its composition, i.e. which types of sensor or components are present on ports and actuators. Figure 1. IDE window Introduced by levels, the list of commands shown in the left column of figure 1 increases as children school education grows with their knowledge of what they can/want to do with the different types of robots. III. SPECIFYING THE PATH LENGTH After pupils write their programs, they are required to think whether by analyzing the code it is possible to specify the length of the path covered by each one of the robots during a run of these programs. A. Examples We assume that for every run the external (to the brick) environment conditions are the same, in particular we assume that each group always refers to the same robot moving on the same floor with the same battery charge level. Under these conditions when the robot of a single group of pupils executes Prog-1, seen in the previous Section, it covers a path having the same length for every run. Robots of different groups executing Prog-1 may cover a path of a different length, for example because of different wheels (comments on this wheel dependency are among others leading to experience direct and inverse proportions as described in [11]). Yet, each group can precisely say the value of its robot path length for Progr-1. Aiming at having the length expressed in a more general way, independent on the robot, something like the following turned out from our discussions with pupils: α: Length-for-forward(20) + Length-for-right(10) + Length-forbackward(9) where Length-for-forward(20) is the measure of the path covered by one of the robots in 2 seconds, similarly for the rest of α. In Progr-2 we find twice the code pattern: repeat(number)..., first is, second is repeat(3). Thus the length of the path covered by the robot during one execution turns out, expressed in the α-form, like the following: β: 4[Length-for-forward(12)+Length-for-left(10)] + 3[Length-forforward(9) + Length-for-left(12)] The lengths of the paths the same robot covers during a run of programs Prog-1 and Prog-2 are constant for each program. B. Variable paths need variables With Prog-3 pupils expect and verify that the path the same robot covers can be different for every different execution of the program because it depends on how many obstacles the robot finds on its way and on where each obstacle is positioned. We asked pupils to think of how we can specify the length of the path covered by the robot for an execution of this program with three obstacles on its way. The following expression has been formulated: γ: Length-for-forward( x0 ) + [Length-for-rigth(5) + Length-forforward(3) + Length-for-left(5) + Length-for-forward( x1)] + [Length-for-rigth(5) + Length-for-forward(3) + Length-for-left(5) + Length-for-forward( x2)] + [Length-for-rigth(5) + Length-forforward(3) + Length-for-left(5) + Length-for-forward( x3)] In expression γ we have seen for the first time the use of variables x0, x1, x2 and x3: x0, x1 and x2 get a precise value after pupils decide where to put the three obstacles and these values can be different for every execution of Prog-3 if positions of the three obstacles are different Length-for-forward( x3) corresponds to the path the robot covers after the third obstacle, when it executes: right(5)forward(3)left(5) and it is stopped from the outside. For the geometrical shape problem solved with Prog-2 by a group of pupils, another group, toward the end of the school year, wrote Prog-4 that uses the light sensor and the statement repeat-while-bright to verify its status. The

program is shown here in a short version where we do not have a code sequence concerning triangles (it is similar to the one shown here for quadrangles): Prog-4: Hi Mafalda port-2 is light repeat-while-bright left(11) In Prog-4 the robot Mafalda, equipped with a light sensor on port 2, starts moving on the class floor and for four times repeats the going-forward command while the light sensor registers a bright environment. When the bright condition becomes false, for example because a black paper is brought in front of the light sensor, the robot goes left and then again straight until another dark condition is found. For each run of the program, one different pupil of the group is Mafalda's driver thus in charge of deciding her path, i.e. deciding which four sided geometric figure perimeter the robot has to move on by deciding when to use the black paper. This program was run with a robot that by left(11) moved about 90^ so that the robot roughly moved on a rectangle perimeter decided by her current pilot assuming the pilot pays attention at letting Mafalda close her path. The following Prog-5 is equivalent to Prog-4: Prog-5: Hi Mafalda port-2 is light repeat until-dark left(11). Like with previous programs, pupils can verify that the path the robot covers can be different for every different execution of Progr-4 and Prog-5. For an execution of program Prog-4 we have: δ: (Length-for-forward(x4)+Length-for-left(11)) + (Length-for-forward(x5)+Length-for-left(11)) + (Length-for-forward(x6)+Length-for-left(11)) + (Length-for-forward(x7)+Length-for-left(11)) Variables x4, x5, x6 and x7, appearing in expression δ, get values after the pilot of the robot decides when to use the black paper. These values are in general different for every execution of Prog-4. The synthesis of one or more expressions can be done during the translation of the code. An extension of our IDE is under development to provide this functionality. IV. GENERALIZATION Current investigations concern how pupils can compare different solutions to the same (or similar) problem by combining code-reading with both paths the robots draw while executing different codes and the shapes of these paths. During these comparisons teachers may drive pupils to discover which solutions solve more problems, i.e. to discover more general solutions and introduce pupils to mathematical generalization. By looking at the executions of their programs pupils can see if a code makes the robot move on the same path or not. Different paths drawn by different programs possibly mean a different solution has been found to a given problem or different problems have been solved with, obviously, different solutions. Pupil can discover that the robot behavior they have implemented is not a solution for the given problem but for a different one. Questioning the statement of a problem is not something pupils develop an habit for during the primary and junior secondary school as we can read, for example, in the book by Stella Baruk [12]. In robot programming normally pupils are first given the kernel of a problem to solve defining a behavior for their robot, then they have to design a robot behavior, investigate if this is a solution to the given problem, possibly add constraints to the considered scenario and so on. Pupils are involved in activities where they discover that it is normal having to enrich a problem statement though they turn out to be activities strictly connected to mathematics When different paths drawn by the same program it means that a different solution has been found to a given problem or that different problems have been solved. Combining the analysis of programs here described and how the robots actually execute them, we can compare with pupils the different solutions to the same problems and consider how general the given solutions are. Normally pupils first propose solutions very specific to a given problem, in a second step we can drive them to think to more general solutions. In our activities, pupils were first asked to write a program for the robot could go around a box, then modify that program for the robot could go around a chair, then around a table. In the end we had groups finding solutions where the robot can go around any rectangle with a program similar to Prog-4 or Prog-5 above. V. CONCLUSIONS The general thinking of CS in school is changing [1, 13]. As Y. B. Kafai writes about computer games for learning, up to now the use of Informatics in schools for learning normal curricula has been mostly instructionist, i.e. limited to the use of software applications while the direction of our work is toward a constructionist perspective for CS activities in education [14]. As a contribution to this perspective, here we have described an activity integrating mini-robot programming in the standard curriculum of a second grade junior high school in Italy. Integrating technology in school curricula means that technology is used as a tool allowing pupils to build activities exploiting or motivating concepts present in their normal curricula. This integration contributes to a new conception of computing in schools and introduces students to a digital literacy richer than the one they are nowadays usually exposed to.

In previous ressearch, we have proposed activities with different types of autonomous mini robots to children of different ages: in kindergarten, primary and junior high schools [15, 16]. Pupils in pre-writing age program by pushing buttons, then use different iconic languages or the textual Logo like language mini robots is that pupils face problems, to be solved and programmed, they understand and are interested in solving. Moreover, here we have described an activity showing how educational robotics is a learning environment where robot programming activities can be integrated into a standard subject rather than being a form of ICT use added to school curricula as one more, separate, subject or as a number of (software) tools for practicing topics from standard subjects. Until nowadays, such an integration has rarely been present in the proposals for introducing computing technologies in schools, though considered a most fruitful educational usage of computers already in Papert s researches of the 70 s. ACKNOWLEDGMENT Thanks to the pupils who were engaged in the activities here described and to their teacher Annamaria Paolillo. Thanks for our email-discussions to R. Didoni of the Regional Institute for Educational Research-Lombardia and to Eleonora Pantó. I am grateful to the referee who suggested reading Y. B. Kafai s papers. REFERENCES [1] Lissoni, A., Lonati, Monga, Morpurgo, Torelli, Working for a leap in the general perception of computing, Proc. Informatics Education Europe III Conf., Venice, December 4-5, 2008. [2] G. Casadei, A. Teolis, k-12 Problem Solving Olympic Games, Proc. Didamatica 2009, Trento (in Italian). [3] Gutierrez, S., Mavrikis, M., Pearce, D., A Learning Environment for Promoting Structured Algebraic Thinking in Children, Proc.. IEEE 8th ICALT Conf., Santander, July 2008, pp 74-76. [4] Michel Rocard et al., Science Education now: a renewed pedagogy for the future of Europe, EUR22845, ISBN 978-92-79-05659-8, European Communities, 2007. [5] Roberta project: www.roberta-home.eu, Access date: August, 25th 2009 [6] TERECoP Project: www.terecop.eu, Access date: January, 25th 2010. [7] Kurebayashi, S., Kanemune, S., Kamada, T., Kuno, Y.,The Effect of Learning Programming with Autonomous Robots for Elementary School Students, Proc. EuroLogo 2007 Conf., August 2007, p.32. [8] D. Baum (2004) NQC language, http://bricxcc.sourceforge.net/nqc, Access date: January 2010. [9] RCX and NXT Lego robots, Access date: April, 15 th, 2010, http://www.lego.com/education/activities/default.asp [10] G.B. Demo and G. Marcianò (2007) Contributing to the Development of Linguistic and Logical Abilities through Robotics, Proc. EuroLogo 2007 Conf., August 2007, p.46. [11] G.B. Demo, Robot Programming Integrated in a Junior High School Curriculum, Proc. Informatics Education Europe IV Conf., Freiburg, Nov.5-6, pp 56-63, 2009. [12] Baruk, S. (1985), L âge du capitain, Seuil, Paris. [13] Robotics School-Net Friend-Robot http://www.amicorobot.net/index.html, Access date: January, 25th 2010 [14] Y. B. Kafai, Playing and Making Games for Learning. Instructionist and Constructionist Perspectives for Games Studies, in Games and Culture, Vol. 1 N. 1 January 2006, 36-40. [15] G. Marcianó, S. Siega, G. B. Demo (2008) Concrete Programming using Small Robots in Primary Schools, Proc. IEEE 8th ICALT Conf., Santander, July 2008, pp 300-301. [16] M.S. Demichele, G.B. Demo, S. Siega (2008) A Piedmont SchoolNet for a K-12 Mini-Robots Programming Project: Experiences in Primary Schools, Proc. TERECoP Workshop Teaching with robotics, Conference SIMPAR 2008, Venice, November 2008.