Algebraic Expressions and Robot Programs in Junior High Schools

G. Barbara Demo Dip. Informatica, University of Torino, Italy

barbara@di.unito.it

Abstract

In our ICT activities in junior high schools pupils program the RCX and NXT Lego bricks using a Logo-like language supplemented by a program development environment specifically implemented for young students. In their first programs, pupils mainly aim at moving their autonomous robots. We describe how teachers and pupils have analyzed with us a number of robot programs, performing a static analysis of the code, for specifying the length of the path a robot covers when a program is executed. When sensors are used this length is specified as an expression containing variables. The analysis associating algebraic expressions to robot programs can be used as a teachers support in motivating elementary algebra, a typical subject addressed in junior high schools. In this activity robotics is used as means to concretely manipulate topics of traditional disciplines. It is integrated in standard school curricula and becomes an active learning environment. 1. Introduction

Programming autonomous mini robots is a helpful educational tool when it is used to implement an active learning approach to concepts from standard disciplines in schools. Examples in [4, 7] describe robot activities related to geography and counting abilities in primary schools while the use of robots as a general learning environment is discussed in [5,13]. In [6,12] a step-by-step methodology is suggested where learning a textual Logo-like language for robot programming is coordinated with the parallel acquisition of logical and linguistic abilities in schoolchildren native language. In earlier papers we described the NQCBaby language for educational robotics and the program development environment we offer to teachers and pupils to write NQCBaby programs and translate them into the NQC language by D. Baum for the Lego RCX brick [1]. More recently we described activities introducing to educational robotics pupils of the age range 11-14 using the Lego NXT brick where robot programming is integrated in a junior h igh school standard curriculu m. In that project we began an analysis to

perceive and evaluate with pupils the different degrees of generality of solutions to a given robotics problem [18].

This paper concerns activities carried out during the school year 2008-2009, again with pupils in junior high school, new to robot programming. In this project we aimed at verifying whether robot programming, through relating specific solutions to more general ones, can help in motivating the traditional study of elementary algebra introduced in junior high schools. To recognize different degrees of generality of programs we have statically analyzed, with teachers and pupils, their movement statements. By this analysis , expressions are synthesized specifying the length of the paths that the robot can perform during one execution of the analyzed code. Roughly, an expression containing variables is synthesized if in different runs of the analyzed program a robot covers paths with different lengths. Pupils are aware or can easily verify whether paths produced by different runs of a program have the same length or not. Observing that expressions without variables are coupled with programs producing the same length paths while linear algebraic expressions, with variables, correspond to programs producing different length paths can become an introduction to linear algebra. The analysis process produces a motivation for linear algebra, often considered as a syntactical game by pupils.

The idea is inspired by the researches of Gutierrez, Mavrikis and Pearce on a “learning environment for promoting structured algebraic thinking in children” [8]. Distinctive aspects of our work are the different context, as we refer to robot programs, and the possibility of working on more general algebraic expressions, having nested levels. Nevertheless, we do not recommend pupils write programs with several nested loops that produce algebraic expressions with correspondently several nested levels of parenthesis.

In Section 2 the NQCBaby language is introduced and some examples are shown of programs used in Section 3 to illustrate the technique for rewriting segments of programs into algebraic expressions. As a conclusion some of the recent initiatives for a renovated conception of computing

in Italian schools, are sketched in Section 4. Educational robotics contributes to defining this new conception that will result in a deeper digital literacy for our young students . Their digital literacy will be “to the one of pupils only using any Office suite or similar, as the musical technique of piano players is to the one of stereo players”: from the Pianos Not Stereos paper by M. Resnick, Bruckman and Martin [14].

2. Basic Tools

Our educational robotics activities have so far

particularly concerned primary and junior secondary schools. In primary schools we propose a textual programming language because the parallel learning of two languages having the same format, the native and the formal language, can help pupils develop better general linguistic abilities. The language is called NQCBaby from NQC (Not Quite C) a most used textual language for RCX bricks developed by D. Baum in 2004 [1]. NQC was used as the first textual programming language in schools. Judged too difficult for an introduction to robot programming, after some activities, a mini-language approach was considered more suitable and the Logo-like language NQCBaby was developed [4, 6, 12]. According to the mini-language approach, NQCBaby is not a complete language because we do not intend to make children become good programmers but rather to give them the opportunity to use concrete robots for doing concrete programming [2, 7].

Our current work has the goal to provide schools with one common child-oriented textual language, to be used for programming the different robot types children use most suitable to the different ages. It is a textual language with primitives taken from children natural language following the Logo philosophy. Indeed our approach is to make children use easier languages rather than building tools to make easier the existing languages too difficult for pupils. An approach in this direction uses the “wooden icons" for helping schoolchildren to compose syntactically correct programs in the iconic programming language proposed in [10].

Pupils write their NQCBaby programs using the Integrated Development Environment (IDE) whose interface is shown in Figure 1, developed by students of the University of Turin. The pedagogical methodology integrated in the IDE already available to schools, provides a gradual introduction of pupils to NQCBaby with language enrichments from children at beginning-to-write level that use NQCBaby0 to NQCBaby6 level, usually for junior high schools. NQCBaby0 is the kernel of the language: it is the textual form of the button commands on the Bee-Bot back, a small robot children can use when not yet able to write as described in [4]. The "white board" central to the

window of our IDE is where children write their NQCBaby code. 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. Errors are reported at the bottom with code line.

Figure 1. The interface of the program

development environment Before opening the IDE the user specifies the

language level (NQCBaby1, NQCBaby2 ... NQCBaby6) to be used and the robot comp osition, i.e. which types of sensor or components are present on ports and actuators.

The NQCBaby-1 level only contains: forward(t), backward(t), right(t), left(t) primitives, for making the robot move forward or backward and turn right or left for t seconds (or different parts of seconds as specified on opening the system), plus the start and end commands: respectively Hi <robotName>, to give a different name to the robot of each group of pupils, and thanksBye. It is convenient that children write their very first programs as simple (even random) sequences of move commands, with the only goal of checking the motion produced by such command sequence, thus verifying the assembly of hardware components and starting to concretely learn the language semantics. The following Prog-1 is an example: Prog-1: Hi Mafalda forward(20) right(10) backward(9) thanksBye

In Prog-1 Italian primitives are translated to English and parameters of moving statements are tenth of seconds as in the other examples following. Each next level of the NQCBaby encapsulates the previous one and deals with either a different robot needing/allowing new primitives or new hardware components, sensors or actuators. In primary school, the gradual introductions of new components, for example sensors , and the related language primitives for using them in robot-programmed behaviours comply the advances of schoolchildren logical and linguistic abilities as described in [6].

One of our activities concerned an exhibition where each robot had to show the geometrical shapes children had “taught” her/him during the year. 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 the following program. Prog-2: Hi Susi

repeat(4) forward(12) left(10) end-repeat repeat(3) forward(9) left(12) end-repeat thanksBye

A repeat(n) statement makes its body (i.e. the statements from that statement to its corresponding end-repeat) be repeated n times.

When we introduce sensors (touch, light and sonar sensor) 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). Prog-3: Hi Zoe

port-1 is touch forward-always repeat-always if-touches right(5) forward(3) left(5) forward-always end-if-touches end-repeat

thanksBye In Prog-3 the forward-always 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.

In the next section other examples of NQCBaby programs are given.

3. Expressing the length of robot paths

If we stick a pen to each brick, so that the pen marks the floor while the robot is moving, we can measure the pen mark on the floor at the end of the program execution. In this Section we discuss how we can also give an answer before a robot executes a program by analyzing the movement statements in the given program.

3.1 Examples

After pupils write their first 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 one execution of these programs. We assume that for every run the external (to the brick) environment conditions are the same, in particular we assume that each group always refer 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, because of different wheels for example. Each group can precisely say the value of its robot path length. 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: a : Length-for-forward(20) + Length-for-right(10) +

Length-for-backward(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 a.

In Progr-2 we find twice the code pattern: repeat(number) ... end-repeat. Thus the length of the path covered by the robot during one execution turned out, expressed in the a-form, like the following:

ß: 4[Length-for-forward(12)+Length-for-left(10)] + 3[Length-for-forward(9) + Length-for-left(12)]

The lengths of the paths a given robot covers during a run of programs Prog-1 and Prog-2 are constant for each program. With Prog-3 pupils expect and can verify that the path the same robot covers can be different for every different execution of the program because it depends on where the obstacle are 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-for-forward(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-for-forward(3) + Length-for-left(5) + Length-for-forward( x3)] In this 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) forward-always and it is stopped from the outside.

For the geometrical shape problem solved with

Prog-3 by a group of pupils, another group, after discussions and trials, 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, similar to the one shown here for quadrangles: Prog-4: Hi Mafalda port-2 is light forward-always repeat(4) repeat-while-bright forward-always end-repeat left(11) end-repeat thanksBye

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 bought 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(4) repeat forward-always until-dark left(11) end-repeat thanksBye

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 this program 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)) In this expression we have the variables x4, x5, x6

and x7. Again, first three variables get each a precise value after the robot pilot decides when to use the black paper and these values can be different for every execution of the program.

Combining the analysis of the programs here described and how the robots actually execute them, we can compare with pupils the different solutions to the same problems for considering how general they are. Normally pupils first propose solutions 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 circumnavigates any rectangle with programs similar to Prog-4 above. 3.2 Other achievements and future work

Given the same problems to work on, schoolchildren groups begin planning how their robot will move, write short code sequences to recall how long are the distances covered by their robot for a statement. Each group draws several designs for deciding the trip their robot will cover. From the experience each pupil goes through while trying to plan and implement the robot show, results particularly relevant for her/his following education life are: § working together to understand the given

problem and usually realizing that his/her other group members can differently understand a given non-standard problem. Non standard problems are an experience that young people have very little chance of getting in touch with because they are usually given problems with unique solutions,

§ understanding these possibly different interpretations of a problem and making them explicit,

§ comparing and exchanging competencies also by reading the program of another group of students in a class and then saying how they think the robot will move

§ finding to which problem is a solution what is coded in a program when they find out that it is not a solution to the case meant by other children in their group or in the class.

Discussing different interpretations of a given task is the beginning of learning that having questions on a subject is the true starting step of the learning process. For the robot show mentioned above, one group only has produced a more general solution to the given task but programs of all the

other groups are correct solutions to different tasks. For a future show, we are planning to present all programs in a sort of game where the public has to pair the six code sequences with six different tasks.

The above analysis of robot programs has driven pupils to think about mathematical generalization with direct connections to their current algebra curriculum. We are now working on the automatic synthesis of algebraic expressions that specify the length of (part of) the robot path when a program is executed as discussed in this paper. Our next goal is to develop a software tool to be integrated in our IDE that will support teachers and pupils during the analysis described in this paper for motivating algebraic expressions.

4. Conclusions

Up to now technology in schools has been most normally limited to the use of software applications or during laboratory activities having little connection with what pupils learn in regular class hours. 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 pupils use it as a tool for building activities exploiting or motivating concepts present in traditional 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. Solving problems and explicitely specifying their solutions as combined solutions of sub-problems, with a language pupil oriented but formal, as to be understood by a mini-robot, is a peculiarity of this future digital literacy. In this respect, educational robotics shares the aim of several new ICT projects initiated in Italian primary and junior high schools during 2008/2009 school year. Explicit aim of some proposals is developing computing competencies such as problem solving and, in general, logical skills for improving pupils achievements particularly in scientific subjects.. Actually, already in school-year 2001-2002, F. Honsell and C. Mirolo promoted one of the first projects aiming at cultivating in schools computing as a science that involved fifteen primary schools in the Friuli Italian region [9]. Yet, during the school-year 2008/2009 we had the first nation wide initiatives in schools under this approach. The Italian Kangaroo Association organised the First Italian Kangarou Informatica contest for junior high schools, 5-7 May 2009. A. Lissoni with a group of researchers from the Milano University collected several problems, or as they call them “quesisti”, to show in junior high schools what kind of questions computing concerns [11]. Also Problem Solving Olympic Games have been supported for the first time during the current school-

year by the Italian Ministry of Instruction, University and Research (MIUR) for the fifth degree of the Italian primary school and the third degree of the junior high school after the initiative of G. Casadei [3]. These projects share the idea that pupils must get used to a structured i.e. algorithmic way of dealing with problems and of solving them. Some projects also introduce young students to data structures typical of computing thus showing how properly structuring the data of a problem influences finding a solution. According to the title “Data+Algorithms=Programs” of one of Wirth’s books, in these projects pupils acquire programming competencies.

Other approaches explicitely address programming in primary and secondary high schools. Educational robotics is one of these. R. Didoni experiences with robots began around 2001 and he is now organising with G. Di Benedetto a yearly Robotics Festival in Milano area with the Friend-Robot School-Net [16]. In Europe different projects concern robots beginning with the well known Roberta project born in Germany around 2002 and now developed in several European countries [15]. Another European project called “Teacher Education on Robotics-Enhanced Constructivist Pedagogical methods” (TERECoP) involves eight European countries, Italy is one of them, working together for three years for developing educational robotics competencies in teachers in k-12 schools [17].

We have proposed activities with different types of autonomous mini robots to children of different ages: in kindergarten, primary and junior high schools [4]. Pupils in pre-writing age program by pushing buttons, then use different iconic languages or the NQCBaby textual Logo like language sketched above. An advantage of programming autonomous mini robots is that pupils face problems , to be solved and programmed, they understand and are interested in solving. Beginning problems with robots are based on making them move in different environments: avoiding obstacles or doing different actions depending on where obstacles are positioned or depending on when a noise is made or similar. These moving-activities are something that young people know quite well by themselves. Teachers do not have to find problems. Robots have wheels and, consequently, pupils first of all want to write programs that make them move. While designing, writing and verifying programs for controlling the motion of mini-robots, schoolchildren and students both acquire programming competences in a young people oriented context and have the chance of concretely manipulating concepts present in their school curriculum with a conctructivistic learning approach. Educational robotics is a learning environment where robot programming activities are integrated into standard subjects rather than being a form of ICT 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. The activity described in this paper, is an example of how robot programs written by pupils can provide an active learning context of a traditional curriculum subject in junior secondary schools. 5. References [1] D. Baum (2004) NQC language, http://bricxcc.sourceforge.net/nqc, Access date: August, 25th 2009 [2] P. Brusilovsky et all., "Mini-languages: A Way to Learn Programming Principles", Education and Information Technologies, 2(1): 65-83,1997. [3] G. Casadei, A. Teolis, “k-12 Problem Solving Olympic Games”, Proc. Didamatica 2009, Trento (in Italian). [4] 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. [5] G.B. Demo, “Programming Robots in Primary Schools Deserves a Renewed Attention”, First WSWS 2008, LNAI 5288, pp 322-331. [6] 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. [7] G.B. Demo, G. Marcianó, S. Siega (2008) “Concrete Programming using Small Robots in Primary Schools”, Proc. IEEE 8th ICALT Conf., Santander, July 2008, pp 300-301.

[8] 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. [9] F. Honsell, C. Mirolo, Scientific Coordinators, “SeT Project: the information cycle”, 2002, http://www5.indire.it:8080/set/informazione/informazione.htm, Access date: August, 25th 2009. [10] M. S. Horn and R. J. K. Jacob (2007), Tangible programming in the classroom with Tern, Proc. CHI '07 Conference On Human factors in computing systems, San Jose, pp 965-1970, 2007. [11] 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. [12] G. Marcianò (2006) Robotics languages for schools, Proc. Didamatica 2006 Conference, Cagliari, 11-13 May 2006, pp. 185-197 (in Italian). [13] G. Marcianò (2007) Robotics as a learning enivronment, Proc. Didamatica Conference 2007, Cesena, 10-12 May 2007, pp. 22-30 (in Italian). [14] M. Resnick, A. Bruckman, and F. Martin (1996), Pianos Not Stereos: Creating Computational Construction Kits, Interactions, vol. 3, no. 6 (September/October 1996). [15] Roberta project: www.roberta-home.eu, Access date: August, 25th 2009 [16] Robotics School-Net Friend-Robot http://www.amicorobot.net/index.html, Access date: August, 25th 2009 [17] TERECoP Project: www.terecop.eu, Access date: August, 25th 2009. [18] G.B. Demo, “Robot Programming Integrated in a Junior High School Curriculum”, Proc. Informatics Education Europe IV Conf., Freiburg, Nov.3-4, 2009.