Robot Programming Integrated in a Junior High School Curriculum G. Barbara Demo Dip.Informatica, Università di Torino c.so Svizzera 185 10149 Torino – Italy
[email protected] ABSTRACT Schoolchildren and students have opportunities of actively and concretely manipulate concepts from traditional disciplines when designing, writing and verifying programs for controlling the motion of mini-robots. Thus, educational robotics may naturally allow integrating robot programming activities into traditional subjects of standard curricula instead of adding some form of ICT as a (software) tool for practicing topics from one subject or as one more separate subject. Such an integration, though considered a most fruitful educational usage of computers already in Papert’s researches of the 70’s, is nowadays rarely present in the proposals for introducing computing technologies in schools. Here we present in-progress activities with pupils in the age range 11-14 using RCX and NXT Lego bricks, with a Logo-like programming language supplemented by a development environment specifically implemented for young students. We describe how robot programming has given pupils the chance of manipulating direct and inverse proportions and the concepts of speed and friction in activities coordinated with presentations of these topics in pupils school curriculum. We also comment on the opportunities, while programming mini-robots, of discussing with pupils for comparing solutions to given problems and identifying specific and more general ones. A future direction of our work, toward motivating elementary algebra, arises from these discussions.
Categories and Subject Descriptors K.3.1 [Computing milieu]: Computers and Education - Computer Uses in Education
General Terms
Experimentation, Languages.
Keywords Standard School Curriculum, Autonomous Robots, Learner Centered Education, Cross Disciplinary Activities.
1. INTRODUCTION During the 2008/2009 school-year two national projects have been initiated in Italian primary and junior high schools promoting a new role of computing in education [3, 19]. In Section 4 we come back to these projects and to some others that, though not national, have been repeatedly presented, thus also reaching teachers not directly participating in them, and contributing to draw a large attention toward an original digital literacy. Among other reasons driving us to reconsider ICT in schools, we find urging to investigate on the coexistence of traditional subjects with current technological tools and on how
computing activities shall be integrated in standard curricula of next future schools. This need was one of the main issues discussed in recent meetings [5, 10]. In our activities, we propose robot programming to primary and junior high schools as a direction of work toward developing a new digital literacy where ICT is an educational tool for an active learning of standard subjects. In [4, 7] robot activities are described in connection with geography and counting abilities in primary schools. In [5, 21], the use of robots as a general learning environment is discussed. In [6, 20] 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. Explicit connections with subjects in standard curricula characterize our approach with respect to the many and well known proposals present in the literature on the use of mini robots in education [9, 13, 14, 17, 18, 24, 26, 27, 28]. In this paper we describe our 2008/2009 activities with programmable mini-robots in two junior high schools. One school, located in the Salerno area in the South of Italy, used Lego RCX bricks. The other used Lego NXT bricks and belongs to the Piedmont School-Net for Educational Robotics whose teachers already worked with us in our 2007/2008 robot activities in kindergarten and primary schools [4]. We focus on junior high school level, corresponding to the age 11-14, because generally less considered w.r.t. to the other levels (younger or older students). In both cases only the mathematics teachers decided to propose robot activities to their pupils this first year of the project. As in previous experiences, we did not aim at growing good programmers, rather – as observed above – we intended robot programming as an educational environment for pupils better achievements in standard curricula. Thus, the main interest was not as much in obtaining a desired or predefined robot behavior per se, as in the process of design, trials and errors analysis by which such behavior is being obtained. Indeed particularly during this process pupils have the chance to manipulate concepts that are being introduced in school subjects. All activities are decided with teachers as to involve current topics teachers are working on with each of their classes. In the first chapter of the book Mindstorm. Children, Computers and Powerful Ideas Papert writes: “Learning to communicate with a computer may change the way other learning takes place…My conjecture is that the computer can concretize (and personalize) the formal” (here “communicate” means being able to program the computer) [18]. In a talk at a recent conference, D. Parisi said that “The artifact forces its author at making procedural his ideas” [23]. This sentence adds to Papert’s conjecture the presence of an algorithm and an approach to problem solving by composing solutions of sub-problems. In primary and junior high school
pupils achieve robot programming by first performing themselves, with their own bodies, the desired actions, and then gradually instructing the robots to do the same. We call “concrete programming” this work on solving a robotics problem and formally writing the solution where bodily and programming activities are mixed [7]. In the following, Section 2 contains a concise description of our beginning activities for introducing pupils to the robot kits, the textual programming language and the integrated program development environment specifically developed for school use following the mini-language approach [2]. In our project the use of tools oriented to young people is mandatory to avoid that pupils efforts are mostly centered on programming. The starting phase must allow children to understand the tools they shall use. We often hear that “Teachers teach as they were taught” but it is also true that “Learners learn as they get used to learn”. Our activities are finalized to grow in young pupils the need of understanding concepts and their motivations. Thus we must avoid that pupils approaching robots feel necessary to be quick. Most relevant achievements from this project first year are gathered in Section 3. Pupils found out that a given task can have different, but, under different assumptions, equally valid solutions as we discussed after an activity on a maze problem. Another point is the analysis we have started with our classes to perceive the different degrees of generality the solutions to a given problem may have. This analysis, i.e. relating specific solutions to more general ones, is the beginning of a work concerning how robot programming can help in motivating the traditional study of elementary algebra which is a typical subject for junior high schools. This idea was inspired by the research described in [11], having a similar goal in a different context. Section 3 also contains the skeleton of the methodology for using programmable mini-robots in schools we have followed and refined during this first year experience. In Section 4, some of the recent initiatives about technology, particularly in Italian schools, are sketched to point out their efforts toward defining a new digital literacy for young people. Conclusive comments to our activities are collected in Section 5.
2. BEGINNING OF THE EXPERIENCE Although our activity concerned two junior high school classes, for simplicity, here we only give examples produced by the class using NQCBaby, a Logo like textual language. This class has been working with five RCX Lego bricks that have been assembled in simple shapes, the so-called chariot form. The other class followed the same pedagogical path using the Lego Mindstorms iconic environment that teachers had already been using in the previous school year with six NXT Lego bricks. After the assembly phase, activities focus on verifying the functions of the hardware components used in assembled robots and the semantics of the language primitives in order to ensure that both children and teachers properly understand the robotics world components, hardware and software. The robot language is called NQCBaby because NQC (Not Quite C) is a most used textual language for RCX bricks developed by D. Baum in 2004 [1]. We used NQC as the first programming language in our past years activities. After some time it was judged too difficult for an introduction to robot programming of schoolchildren. Thus an higher level mini-language approach was considered more
suitable and the Logo-like language, called NQCBaby, was developed [6, 20].
2.1 First rule: let pupils have time to verify The first command set introduced to the pupils is called NQCBaby-1 and 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 milliseconds, plus the start and end commands: respectively Hi , 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 start to concretely learn the language semantics. The following Progr-1 is an example (the Italian primitives of the NQCBaby language are translated to English): Progr-1:Hi Zoe forward(200) right(100) backward(90) thanksBye With their first program, pupils observe how the robot executes each single command and the global execution of the sequence of commands. That is, they verify or learn that: - commands of the sequence are executed one after the other. Not all commands introduced later on will have this property; - each command execution takes a different time depending on the parameter specified as its operand. Indeed, according to modern constructivist-constructionist learning approaches, each – even simple – learning task requires an appropriate length of time to be performed. Obviously the most positive projects are the ones that follow the same students for several years, at least during their full cycle in primary or junior high school, so that the achievements of robot activities can be evaluated on long durations. Our approach is typically learner-centered: thus, in general, at the beginning of a new activity the information provided by teachers is the least necessary to get started, but during the next phases there is an intensive student-teacher and inter-students interaction, where new information is continually acquired and verified. Another assumption of a constructionist methodology is that learners work on realistic problems and environments they are interested in. When young people are working with autonomous robots this assumption is easily fulfilled, because the problem consists in moving the robots they have assembled and which, often, they have also dressed in pleasant ways and conceived as characters in short stories. During our first activities, teachers give pupils the time to execute checks for:
verifying directions of robot movements. For some robots, as RCX Lego, forward can easily turn out to be backward and vice-versa, and similarly for right and left, depending on how robots are assembled. This is more likely in junior high schools than in primary ones, because older pupils feel in general more independent from the instructions when assembling their robot. With Lego NXT, for its connection types, forward cannot be exchanged with backward but we can exchange left and right. In order to concretely verify robot actions, it is quite positive for young people to spend some
time in checking movements also with robots that come already assembled such as Scribbler by Parallax.
discovering the effect of different parameter values. In our activities, teachers asked pupils of measuring, in different ways, how far - the robot goes with different parameter, i.e. time values - different robots go with the same command having the same parameter value. It can happen that the robots cover different length paths: a discussion on why this can happen is useful.
Main goal of first experiences is to acquaint schoolchildren with how the robot moves: the actual activity of programming is quite limited. Nevertheless try&Verify activities will not be cut short. They are important for a well-founded acquisition of ICT competencies because: - computing machines we use nowadays are difficult even almost impossible to see in their internal components while with small robots we still have simple ways of touching some components or of simply verifying how it works. An example is reading values detected by the light sensor on the RCX display - pupils do not have a robot at home thus they must get a complete understanding at school. For this reason in our activities we use a robot-exercise-book (which pupils leave in school or bring every day to school) because remarks or questions might be added when dealing with any subject.
2.2 A methodological path for learning what the robot can do and its language The second level of primitives, NQCBaby-2, adds to NQCBaby-1 the command play(note,t) which plays a note for a given time t. Using this command the users can begin to think about an important aspect of what the robot can do: the possibility or impossibility of parallelism between some commands of movement and other actions, for example playing a musical note or tone, or, when sensors will be introduced, checking what a sensor is detecting. The following Progr-2 is Progr-1 enriched with a play(note, t) command. Progr-2: Hi Zoe forward(200) play(A,40) right(100) play(A,40) backward(90) thanksBye After pupils have written and observed the execution of some programs similar to Progr-1 and Progr-2, we discussed with them to find an answer to the question: “our robots can sing while moving?” With NQCBaby2 the answer is negative because only the primitive play(note, time) is added to the primitives of NQCBaby1 for moving a definite time and waiting that time before doing something else. In the next level of the language we introduce commands that will allow a positive answer to this question. With NQCBaby2 children verify that their robot executes the command “play” after the previous command is finished and not in parallel. Among beginning tasks assigned to our schoolchildren we had the following: A-1. find values for operands of movement primitives in order the robot can move around the table on which the group is working, then around a chair, and around a rectangle marked on the floor using four boxes
A-2. change robot wheels and find the operand values of movement primitives such that the robot can cover the same paths as those covered in previous activities A-1 with the previous wheels. Besides consolidating what pupils have learned of robot programming so far, the above activities aim at discussing: -
direct proportion between spokes and length of the path covered with the same value of the parameter time
-
inverse proportion between wheel spoke and the value of the parameter time for covering the same distance.
Direct and inverse proportionality are a specific topic of our second grade pupils (junior high school). Though beginning experiences require little programming, they already allow interacting with the school curriculum in quite rich ways. In our classes first activities -
required working with geometry for both wheels perimeter and paths that the robot of each group had to cover
-
allowed relating robot movements with physics concepts such as the dependencies between engine power and speed, between time and path covered. Also speed and friction dependency has been addressed.
During first activities similar interactions between curriculum and robot activities are possible in both primary and junior high schools, by obviously tailoring discussions to the different education levels. Other try&verify activities are useful whenever a new hardware or software component is introduced. In one school, when the light sensor with the RCX brick has been introduced, all pupils contributed to draw a Colour-RobotNumber Table by reading, on the RCX display, the numbers shown when different colours were brought under the light sensor. This experience immediately made pupils aware of some “weakness” in this sensor because the number returned depends on the brightness of the environment. The dependence on the environment is another important discovery as the influence of the robot power level or the discovery of which effect an asymmetrical robot assembly produces on movements (because the center of gravity is on one side). When we want to introduce a first sensor, usually the touch sensor, NQCBaby-2 must be enriched with commands 1) to specify on which port the sensor is and 2) the first selection-type command for verifying whether the sensor touches an obstacle (iftouches): this is the NQCBaby-3 level. With the if-touches instruction our pupils are introduced to the first instruction having a (perceived as) immediate execution time while previously used commands have a duration time fixed by the user. After the parallelism possibility announced in discussions on NQCBaby-2, the duration time is the second, important property of robots actions we introduce to teachers and pupils with the touch sensor. Since the obstacle can be placed in a different place at every run, in NQCBaby-3 we need two more commands: repeat-always to continuously execute a loop (to verify if the robot has hit a possible obstacle in Progr-3) and forward-always allowing a forward movement going on without duration time specified and parallel with the commands following in the execution sequence. In Progr-3 forward-always is parallel with the if-touches check.
Progr-3: Hi Zoe port-1 is touch forward-always repeat-always if-touches right(50) forward(30) left(50) forward-always end-if-touches end-repeat thanksBye
related language primitives for using them in robot-programmed behaviours comply the advances of schoolchildren logical and linguistic abilities as described in [6]. So doing robot programming fits linguistic learning achievements primary school children accomplish and becomes an original tool contributing to strengthening standard linguistic and logical curricula advances.
Back to the point that activities ask for reasonable time on tasks, it is important to schedule think-about moments. Whenever possible it is advisable the class is let to think “without the robot” about robot experiences. Keeping a copy of the programs that students have written is important for these discussion times in the classroom when solutions to given problems are analyzed without robots. Students should register in their robot exercise book how the robot executes a program to comment this execution during the think-about times together with the class and the teacher and find out new checks to be done in a next robot activity.
2.3 A language and an IDE for robot programming in schools According to the mini-language approach, NQCBaby is not a complete language because we do not intend to make children become good programmers using it but rather to give them the opportunity to use concrete robots for doing concrete programming [2, 6, 20]. Children write their NQCBaby programs using the Integrated Development Environment (IDE) tool, whose interface is shown in Figure 1, developed by students of the University of Turin. Our work has the goal to provide schools with one common childoriented textual language, to be used for programming the different robot types that children use. This language is based on the one presented in [6]. 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 difficult for pupils such as "wood icons" for the iconic programming language proposed in [13]. 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 in fig. 1 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. Before opening the IDE the user specifies the language level (NQCBaby1, NQCBaby2 ... NQCBaby6) to be used and the robot composition, i.e. which types of sensor or components are present on ports and actuators. Each next level of the language 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 ordered introductions of new components, for example sensors, and the
Figure 1. The interface of the development environment Introduced by levels, the language grows with children, with their school education and with what they can/want to do with their different robots. When the RCX robot is used, NQCBaby is translated into NQC [1, 5]. When an NXT brick is used, NQCBaby is translated into the NXC (Not eXactly C) language [1]. Two groups of pupils have each written one of the following Progr-4 and Progr-5. In Progr-4 a robot moves forward and then randomly chooses whether to go right or left. Progr-4: Hi Susi repeat-always speed(7) forward(500) if (flip-coin = heads) right(75) else // it’s cross left(75) end-if end-repeat thanks-bye. In Progr-4 we find the function flip-coin corresponding to a call of the function random in both the NQC and NXC languages. Again, after the NQCBaby English version, here follows Progr-4 translated into the NQC language. task main() { while(true) { OnFwd(OUT_AC, 75); Wait(500); if (Random() >= 0) { OnRev(OUT_C, 75); } else { OnRev(OUT_A, 75); } Wait(360); } }
Progr-5 specifies a robot drawing on the floor a triangular shape and then a squared shape because, for the given robot, statement left(110) corresponds to moving left about 90°, and similarly for right(110). Again, we show first the NQCBaby English version and then the same code translated into the NQC language. Progr-5: Hi Mafalda speed(5) repeat(3) forward(100) left(110) end-repeat repeat(4) forward(150) right(110) end-repeat thanks-bye. task main() { SetPower(OUT_A+OUT_C,5); repeat(3) { OnFwd(OUT_A+OUT_C); Wait(100); OnFwd(OUT_A);OnRev(OUT_C); Wait(110); Off(OUT_A+OUT_C); } repeat(4) { OnFwd(OUT_A+OUT_C); Wait(150); OnFwd(OUT_A);OnRev(OUT_C); Wait(110); Off(OUT_A+OUT_C); } Off(OUT_A+OUT_C); }
3. PUPILS ACHIEVEMENTS In this Section we gather preliminary comments on most interesting pupils achievements during this project first year of robot programming activities.
3.1 Discovering which problem a given code solves During last activities, we compared solutions to A-1 and A-2 problems in paragraph 2.2. Normally pupils first propose solutions specific to a given problem, in a second step we can drive them to think to more general solutions: for exercise A-1 to solutions where the robot circumnavigates any rectangle. We have discussed this possibility after introducing the ligth sensor of the NXT brick and some pupils have used it to specify the length of rectangles sides by changing the sensor result from brigth to dark (simply shading the light sensor by a dark sheet) when they decide to stop the robot going straight and make it turn left (or right) with an about 90° angle. Pupils used this idea when working for a geometrical shapes exhibition where a pen was stuck to each brick and robots had to move drawing on the floor the geometrical figures children had “taught” her/him during the year. Some groups came out with programs similar to Progr-5, 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. One group of pupils, after discussions and trials, came out with Progr-6 using the statement repeat … until-dark and shown here in a short version (we do not show a code sequence concerning triangles, similar to the one shown here for rectangles):
Progr-6: Hi Mafalda port-2 is light repeat(6) repeat(4) repeat forward-always until-dark left(110) end-repeat end-repeat thanksBye In Progr-6 the robot Mafalda, equipped with a light sensor on port 2, starts moving on the class floor. When the light sensor detects a dark condition the robot moves left for about 90°. Then the robot movement is again straight until the light sensor detects another dark condition and so on four times. The repeat(6) statement allows drawing six rectangles. This for example allows different pupils of the group be Mafalda's pilots thus in charge of deciding her path by deciding when to use the black paper. The robot roughly moves on a rectangle perimeter decided by her current pilot assuming this pilot pays attention at letting Mafalda close her path. Like with previous programs, pupils can verify that the path their robot covers can be different for every different execution of programs using sensors. One group proposed Progr-7, again shown here in a short version: Progr-7: Hi Mafalda port-1 is sound port-2 is light repeat-always repeat forward-always until-dark repeat left-always until-dark wait(200) until-sound thanksBye Executing Progr-7 the robot Mafalda, equipped with a sound sensor on port 1 and a light sensor on port 2, starts moving on the class floor. As the light sensor turns to dark the robot ends the repeat … until-dark loop and begins going left until another dark condition is detected which makes the end of the second repeat … until-dark loop. After a stop of two seconds ( wait(200), if no clap (or any other sound) is heard the robot begins another execution of the inner loops. Before starting the run of Progr-7, pupils draw on the floor the geometrical shapes they decide the robot has to cover by moving while executing the program. Then they have to follow their robot and remember that dark means the end of either a side of the geometrical shape or the end of the angle currently drawn. A clap stops the robot. For the geometrical shapes exhibition six schoolchildren groups were given the same task to work on and began planning how their robot will move, writing short code sequences to recall how long are the distances covered by some robot commands, each group drawing several designs for the trip they decided their robot will cover. The most important results concern the experience
each pupil went through while trying to plan her/his robot show. Among these results, particularly relevant for the following education life of each student are: • 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 by reading the program of another group of students in a class and then saying how we think the robot will move • finding to which problem is a solution what they have 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. As we said for the above robot show, one group only has produced a general solution to the given task like the one in Progr-7 but all the other group works have been considered positive solutions to different tasks. Moreover, as a final show, we are thinking to present all solutions in a sort of game where the public has to pair the six code sequences produced by the six pupils groups with six problems. Discussions on robot programs have driven pupils to think over mathematical generalization with direct connections to their current algebra curriculum. Pupils were required to think whether by analyzing the code it is possible to specify the length of the path covered by each robot during one execution of their programs. By assuming stable environment conditions, the same robot covers a path having the same length for every run of Progr1, Progr-2 and Progr-5. For programs using sensors, the path can be different for every run. To describe these possibly different paths lengths we use variables thus we use algebraic expressions. A detailed analysis of the question has been developed in [8].
3.2 A problem has many solutions (or rather we have to better specify the problem) Finding a way out of a maze is a typical problem often addressed as a conclusive experience in robot activities likely because it is considered by students and teachers an interesting and difficult problem to solve thus making them proud of the success. Depending on how long the robot experience has been the considered maze has a more or less difficult shape. To end the experience here described, a maze was proposed to one of the junior high school classes. We considered a very simple maze type without blind corridors, with 90-degree angles and parallel walls having between them a distance sufficient for the robot can move easily without touching the walls. Some pupils claimed that a true maze must have blind corridors where the robot should go backward on the path already covered and try another way to exit, thus ours was not a real maze. Nevertheless, our simple maze is not so simple and gives the opportunity of emphasizing that the robot behavior heavily depends on the environment where it moves: the floor, the battery power, the light. One of the programs made the robot exit when the maze was in the classroom. The same program did not work when the maze was in an exhibition room where the floor caused a bigger friction and the brick battery was very low (another time the light was too bright). In class the robot turned about 90 and
180 degrees when executing respectively turn-left(100) and turnright(200) commands. During the exhibition, the turns resulted quite reduced and the robot went against the walls. Teachers and pupils understood the context influence and modified the turn parameters. Again, an important result is finding out that under a label we do not necessarily have a single problem. In our case we can call maze very different types of mazes, i.e. different problems needing very different solutions. reaching the ones where we have to use sophisticated data structures and algorithms with Artificial Intelligence aspects.
3.3 Skeleton of a methodology In educational robotics activities here described, every new task assigned to pupils has two components: a robot behavior and one or more class curriculum concepts. Pupils are given a short description of the robot behavior goal of the task: they must detail it and implement it in a program. When possible, we filmed videos of the robot executions of programs so that we could use these videos during our thinking-about times. From the experiences here described we derived a number of methodological remarks summarized in the following. Some concern students, some teachers, some both. a. Each robot activity is associated to some concepts from the class curriculum. The teacher acts to direct students projects toward the achievement of these concepts manipulation. b. For most robot activities different solutions are possible depending on the robot asset, on the environment, finally on the robot specific behavior decided by the students. The teacher acts to moderate each group activity ensuring envisaged solutions are doable and consistent with point a. This is a contribution for students getting used to questions against current passive attitude in class activities. c. Solutions reached by chance are not accepted. Competence in proposed programming achievements for both teachers and students is a goal. d. Discussions on robot activities without robots on the table are encouraged in order to gain competences, share problems and solutions and also design possible different solutions. These discussions balance an excessive use of trials that come natural because easy with robots since pupils can immediately check the effect of a command. This is not in contrast with the verifying need in the following point e. Verifying the effect of each command and the behavior of each new hardware component e.g. of sensors as they are introduced and of motors controlling wheels or a palette or lights.
4. PROJECTS FOR ICT IN SCHOOLS Many recent projects have brougth new technology proposals in schools to large numbers of students. Hence we think this is a favorable time for discussing how computing should be present in schools and for possibly structuring new types of activities with computers. In this Section we gather a small number of these projects, first in Italy and then in Europe, mostly to begin illustrating a number of different types of objectives.
In Italy some proposals are explicitly motivated as aiming at developing computing competencies such as problem solving and, in general, logical skills for introducing a conception of computing different from the most current ones normally concerning the use of applications. During school-year 20012002, F. Honsell and C. Mirolo promoted one of the first projects under this approach involving fifteen schools in the Friuli Italian region [12]. But only during the current year we had the first nation wide initiatives aiming at cultivating computing as a science in schools. The Italian Kangaroo Association organised the First Italian Kangarou Informatica contest for the junior high schools, 5-7 May 2009. A. Lissoni with a group of researchers from the Milano University did a big effort in collecting several problems or as they call them “quesisti”, to show in schools what kind of questions computing concerns [19]. 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]. Other large projects aim mostly at asking teachers to exploit new tools such as the interactive blackboards or small autonomous robots as those we use in the activities here described. Interactive blackboards have been promoted by MIUR with a big financial effort. In a short time, many Italian primary schools will have one interactive blackboard each. The First Italian RoboCup Junior competition for k-12 students was organized in Piedmont region in May 2009 [27]. R. Didoni experiences with robots began around 2001 and he is now organising every year a Robotics Festival in Milano area with G. di Benedetto and the FriendRobot School-Net [28]. In our Piedmont region, the JumPC project aims at having one laptop on each schoolchild desk [15]. This experience has been proposed from last autumn to two pilot classes for a total of fifty children, but two other regions announced that other classes are beginning the activities with JumPC. 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. In Roberta project description we read that “Robotics allows for a hands-on introduction to technology. Children can try out things for themselves. With the help of educationally and technically adapted robots, even young children learn that technology is fun and how technical systems are developed. This helps them gain knowledge in IT, electrical engineering, mechanics and robotics” [26]. In particular “Roberta takes girls and young women into the fascinating world of robots, where they can learn science, technology and IT in an exciting and realistic way. Using real robots! Teaching and learning materials tailored for girls have been developed and tested. Roberta instructors are specially trained.” Thus we share several aspects with Roberta project though our efforts concern activities during class hours in parallel with school topics and possibly covering different disciplines. Another European project called “Teacher Education on Robotics-Enhanced Constructivist Pedagogical methods” (TERECoP) involves eight European countries working together for three years on developing robotics competencies in teachers in k-12 schools [29]. A positive aspect to be enphasized is that some proposals have been worked out directly by groups of school-teachers. The
already mentioned JumPC project mainly originated from the convinced work of a group of school teachers haeded by Dario Zucchini and Paola Limone. As another example, teachers of the Piedmont School-Net for Educational Robotics began several years ago activities with programmable mini-robots and they have recently presented part of their work at the TERECOP project workshop, November 2008 [4]. This first international presentation by some of the School-Net teachers concerns kindergarten and primary schoolchildren achievements. Both among this flourishing of more recent initiatives, having different aims and methods, and among older ones, we can find aspects that will likely contribute to a new learning paradigm based on the use of the technology.
5. CONCLUSIONS We have described activities carried out in two second grade classes of two junior high schools during the current 2008/2009 year. Previous years our educational robotics activities concerned mostly primary schoolchildren as described in [4]. In both levels of school, educational robotics makes possible to integrate programming activities in current schools curricula rather than adding to traditional subjects any form of ICT as one more subject. Besides cross-disciplinary activities that schoolchildren experience while robot programming, other important achievements concern new digital literacy competencies since pupils learn how to write in a formal language, what an integrated development environment tool is and how to use the one we implemented specifically for this project. Pupils learn what a translator is, its syntax error finding action. Our conclusive conviction is that small robots programming activities and activities from some of the projects mentioned in the previous section, will contribute to grow in young people the kind of digital literacy Resnick was hoping for when he wrote in his Pianos Not Stereos paper with Bruckman and Martin [25]. “These pupils digital literacy becomes 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”. Motivations why this change is necessary have been discussed here shortly because many relevant contributions are already present since several years in the literature, beginning with [5, 12, 16, 17, 19].
6. REFERENCES [1] Baum, D. 2004 NQC language, http://bricxcc.sourceforge.net/nqc [2] Brusilovsky, P., et all., 1997. Mini-languages: A Way to Learn Programming Principles. Education and Information Technologies, 2(1): 65-83,1997. [3] Casadei, G., Teolis, A. 2009. k-12 Problem Solving Olympic Games. In Proceedings of the Didamatica 2009 Conference (Trento, Italy, April 21-24, 2009) (in Italian). [4] Demichele, M.S., Demo, G.B., Siega, S. 2008. A Piedmont SchoolNet for a K-12 Mini-Robots Programming Project: Experiences in Primary Schools. In Proceedings of the TERECoP Workshop on Teaching with robotics, Conference SIMPAR 2008 (Venice, Italy, 1st November 2008). [5] Demo, G.B. 2008. Programming Robots in Primary Schools Deserves a Renewed Attention. In Proceedings of the First
WSKS (Athens, Greece, September 23-26, 2008). Springer, LNAI 5288, pp 322-331. [6] Demo, G.B., Marcianò, G. 2007. Contributing to the Development of Linguistic and Logical Abilities through Robotics. In Proceedings of the EuroLogo 2007 Conference (Bratislava, Slovakia, August 23-25, 2007). Comenious University Press, Bratislava, 46 (abstracts only, full papers at http://www.eurologo2007.org/proceedings). [7] Demo, G.B., Marcianó, G., Siega, S. 2008 Concrete Programming using Small Robots in Primary Schools, In Proceedings of the IEEE 8th ICALT Conference (Santander, Spain, July 1-5, 2008), pp 300-301. [8] Demo, G.B., 2009 Algebraic Expressions and Robot Programs in Junior High Schools. In Proceedings of the LICE Conference (London,UK, November 9-12, 2009) (to appear). [9] Eronen, PJ, Sutinen, E, Vesisenaho, Virnes, M. 2002. Kids’ Club as an ICT-based learning laboratory, Informatics in Education, 1 (1), 61-72. [10] Fondazione Scuola 2009. International Conference “A School Day in 2020”(Torino, Italy, March 2009). http://www.fondazionescuola.it/magnoliaPublic/ita/homepag e.html [11] 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. [12] Honsell, F., Mirolo, C. (Scientific Coordinators) 2002. SeT Project: the information cycle, http://www5.indire.it:8080/set/informazione/informazione.htm
[16] Kay, A. 2003. Face to Face: Alan Kay Still Waiting for the Revolution. April/May 2003 http://www2.scholastic.com/browse/article.jsp?id=5. [17] Kynigos, C. 2004. Α Black-and-white-box Approach to User Empowerment with Component Computing, Interactive Learning Environments, Carfax Pubs, Taylor and Francis Group, Vol. 12, Nos. 1–2, 27–71. [18] Kurebayashi, A. , Kanemune, S. , Kamada, T. , Kuno, Y. 2007. The Effect of Learning Programming with Autonomous Robots for Elementary School Students, in 11th European Logo Conference, pp. 46, Comenious University Press, Bratislava (abstracts only, full papers at http://www.eurologo2007.org/proceedings. [19] Lissoni, A., Lonati, Monga, Morpurgo, Torelli 2008. Working for a leap in the general perception of computing, In Proceedingsof the Informatics Education Europe III Conference (Venice, Italy, December 4-5, 2008). [20] Marcianò, G. 2006. Robotics languages for schools. In Proceedings of the Didamatica Conference (Cagliari, Italy, 11-13 May 2006), pp. 185-197 (in Italian). [21] Marcianò, G. 2007. Robotics as a learning environment. In Proceedings of the Didamatica Conference ( Cesena, Italy, 10-12 May 2007), pp. 22-30 (in Italian). [22] Papert, S. 1980. Mindstorms: Children, Computers, And Powerful Ideas, Basic Books, New York, 1980 [23] Parisi, D., 2007. A superficial science, “Understanding complexity: a Journey through Science”, CSI Convention, Torino 22-23/11/2007. [24] Resnick, M.,1993. Behavior Construction Kits. Comm. of the ACM, vol. 36, no. 7, pp. 64-71 (July 1993).
[13] Horn, M. S., Jacob, R. J. K. 2007. Tangible programming in the classroom with Tern. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (San Jose, California, USA, April 28 - May 03, 2007). CHI '07. ACM Press, New York, NY, 965-970.
[25] Resnick, M., Bruckman, A., Martin, F. 1996. Pianos Not Stereos: Creating Computational Construction Kits, Interactions, vol. 3, no. 6 (September/October 1996).
[14] Institute for Personal Robots http://www.roboteducation.org/
[27] RoboCUP Junior, Italian organization, 2009. http://www.iislancia.it/robotica-scuola/rcj/
[15] JumPC project: http://share.dschola.it/olpc.
in
Education,
[26] Roberta project: www.roberta-home.eu
[28] Robotics School-Net Friend-Robot http://www.amicorobot.net/index.html [29] TERECoP Project: www.terecop.eu
