Ready, steady, program! How children can learn coding (and teach numeracy to a robot) during STEM school visit events

Abstract

STEM topics are often perceived by secondary school students as boring, difficult and uninteresting. Therefore, the authors designed an event to challenge these perceptions. The opportunity was given during STEM School visits to Brunel University where the authors use a 55 minute event to attempt to convince pupils that STEM and in particular computing is fun. During an interactive sessions where students were encouraged to play with robots, they were gently introduced to the art of coding. The results were an increased confidence in their programming abilities and a better perception of STEM. This paper discusses this event in more detail.

Introduction

Many Western countries face shortages of STEM graduates. This shortage can partially be explained by a lack of engagement by students with STEM topics. These topics could be perceived as difficult and not very interesting and these are often among the reasons often given to explain this general reluctance (see for example (Robins et al. 2003) and (Major et al. 2012)).

One way to reverse this trend is to introduce STEM topics in a friendly way and at an early stage of the education. Several initiatives have been promoted to support this idea (see for example (STEM 2014a), (Major et al. 2012) and (Pierre and Christian 2002)). As discussed in (Šorgo and Kocijančič 2004), computer driven activities are also considered part of a successful strategy for connecting pupils with STEM related topics.

According to The National Science Learning Centre White Paper about the future of science (STEM 2014b), there is a need to accelerate the improvements in science, technology, engineering and mathematics education. To sustain and further develop STEM education there is the need for the increased involvement in all schools or colleges by scientists, engineers and others with STEM experience from universities or industry needs to become the norm.

One such example is a scheme at Brunel University where local schools have been encouraged to meet within the University environment for several years. At Brunel University the STEM team brings together school pupils, undergraduate students and academics to develop a pupil understanding of STEM and explore their future potential opportunities. The hope is that children will develop some interest on STEM topics and realise the potential STEM can offer. For this purpose, regular one day STEM events have been organised at the University with the aim of increasing the student’s familiarity with STEM topics. During these events secondary school pupils participated in various STEM related activities. In particular, one of these activities focuses on computing and this paper is an account of an initial exploration of this pilot activity.

This paper captures and discusses the ordinary activities of the participants in naturally occurring settings. Since the main goal of the event was to increase the participants confidence in their programming abilities and a better perception of STEM, then it was not designed as an experiment to collect data. Hence, the paper is based on the author observations and some qualitative data obtained from questionnaire collected by the University as a result of event management. Despite the limitations of this approach, it is hoped that the outcome of this paper can contribute in revealing common denominators connected to the STEM Education topic.

In the next section, the design of the robot event is presented. Then, in the following section, there is a discussion on the how actual experience from the events can be connected and used as part of the evidence of increasing the student’s familiarity with STEM topics. The final section includes an evaluation of the event.

The robot event structure

The robot event can be broken down into six steps. Since school pupils are expected to have little or no programming experience then, the various steps discussed below are designed to gradually take them from no knowledge to the final stage of being able to write simple programs.

Step 1. Introduction

Students are divided into groups and small robots such as the hexbug (Hex 2014) are given to each group. These robots have very limited sensing with a single response and without closed feedback control. For example, they can detect when their antennas run into something or alternatively they can sense loud noises. Thus, when they run into something or hear a loud noise, they make a quarter-turn clockwise. Otherwise, they walk forward in an approximately straight line. Students, by initially playing with these robots, will start to familiarise themselves with basic concepts of robotics, such as sensors detection and control, and they begin to explore the robot functionality. A simple task, such as making the robot move around an obstacle, is defined so that, students will understand concepts such as goal, planning, errors in a very practical way. After a few minutes, the activities will switch into the next phase.

Step 2. Scribbler.

A more complex robot is used during this phase (Scribbler 2014). This robot has several sensors and it is controlled via a laptop connected to Scribbler via a wireless connection. An basic user interface running in the laptop is then used to control the robot. The interface has been designed so that the robot can draw segments on a horizontal whiteboard, placed under the robot. A standard whiteboard marker is vertically attached to the robot shell so that the tip of the pen is in direct contact with the whiteboard. Therefore, when the robot moves, it draws lines on the whiteboard underneath. The user interface allows a student to select a number using the laptop keyboard. Once a number has been selected, the robot will execute a predefined sequence of moves in order to write the chosen number on the whiteboard. The aim of this activity is both to introduce students to the general concept of programming and to test the students ability to identify problems. Indeed, due to some (ad-hoc) program bugs and natural occurring robot real time inaccuracies (slippery wheels, uneven surface, etc.) the sequence of segments drawn on the whiteboard by the robot are likely to be only a resemblance of the number selected by the student. During the discussions following the outcome of this task, the student’s conclusion is that a better program is required and in the next step students are challenged to do so.

Step 3. Coding.

The challenge during this stage is to enhance the pupils confidence on their coding abilities. This is done by gradually introducing them to the art of programming. To write a better program than the one they just tested, students will initially use Guido Van Robot (GVR) (GVR 2014), a virtual robot running on a computer. GVR uses minimalistic programming language providing just enough syntax to help students learn the fundamental concepts of programming (see Figure 1). GVR is a robot represented in a window by a triangle on the computer screen that moves around in a virtual world very similar to the whiteboard used in the previous step. GVR can also set dots (very much like drawing dots/lines on the real whiteboard).

GVR robot

 

Figure 1: The GVR robot. Commands are typed on the right. The robot (represented as a triangle) is displayed on the left. In the example here, the full list of commands has been executed (by either clicking “Step” or “Execute”) and the robot is in its final position after having drawn circles (putbeeper) and moved (move, turnleft).

The robot actions are completely guided by a program written by the user on a separate window. The interactive environment allows instant visual feedback since every time the student type a command it is possible to observe the robot reactions (i.e. the triangle movements). There are only three basic instructions: move, turnleft, putbeeper. The virtual robot (i.e. the triangle on the screen) will respectively move one step forward if the move command is typed, turn left 90 degrees if the turnleft command is used and put a circle when putbeeper is used. In other words, the GVR language is very intuitive and with a syntax very similar to natural language.

The simple graphic and reduced cognitive load make very easy and straightforward for children to familiarise with the environment and they can confidently control the robot within minutes of being introduced to this application. At any given time, the list of created instructions can either be executed step by step (by clicking on the “Step” button, see Figure 1) or in block (by clicking on the “Execute” button, see Figure 1).

As a consequence, pupils naturally start using block of commands to implement sequence of actions. During this stage, a student is invited to the front stage to control the robot by typing commands on the keyboard with the computer monitor being connected to a projector. In this way, everybody can follow and contribute to the task and therefore interaction among all the students is natural and everybody is encouraged to participate and contribute to this activity. Indeed, with the help of the whole class pupils will then be able to define the correct sequence of GVR instructions to draw a number on the screen. For example, to draw the number I, a possible sequence (or a program as they will then realise) would be the following: move; putbeeper; move; putbeeper; move; putbeeper; move; putbeeper. As a consequence of this sequence, then the triangle (facing upward) on the screen will move and put circles in the desired shape (in this case, a straight sequence of circles that can be seen as the number I). Once they are happy with the program they have produced, then the program (i.e. the sequence of actions they have created) will be saved into a file.

During this stage, students familiarised with the task of writing a program by trial and errors. They quickly realise, for example, the need to alternate moving actions and drawing circles by observing that if a robot movement action is not followed by a putbeeper action, then the robot will move around but there will be no writing on the whiteboard.

The immediacy of the visual feedback on the screen therefore help them to gain confidence in coding and to increase their perception of being able to program and control the robot. The fact that they are using a simulated environment will give them the confidence they can try different options with no physical repercussions on the robot, while the use of the screen being projected on the wall will encourage co-operation.

Step 4. Translating

At this point, the code written into the GVR minimalistic programming language will be translated into a (Python (Python 2014)) program that can be executed by the Scribbler robot. This is done by an ad-hoc program without pupils intervention. However, the produced (Python) program will be shown (using a standard text editor application) to the students. By comparing the Python program displayed on the monitor with the GVR program they have previously implemented, they can see the outcome of their activities and have a basic insight of computer program structures. During this phase pupils could also modify their initial plans (for example they can modify the speed of the robot, the sequence of actions, by modifying the Python program).

Step 5. Execution

Finally, students will be invited to volunteer to launch the (Python) program. This program will be executed by the Scribbler robot. They will be able to monitor that the same sequential order as defined in the GVR program during Step3 is now executed by the real robot (the Scribbler). That is, pupils have been able to control the real robot by executing the GVR program they have produced and tested (and being translated into a Python one). During this stage, pupils assess the real effects of their actions by observing the robot action.

Step 6. Debriefing

During this phase of the event pupils discuss and identify challenges, to reflect on how to optimise their work and discuss further problems. They are encouraged to evaluate the outcome of their implementation. This is achieved by comparing the number written by the robot on the whiteboard when executing their program with the number written by the robot when using the original program. They are able to identify the different sequential action used in each program and therefore they understand the importance of the order in sequential instructions. Often, during this stage they can identify or attempt to introduce complex programming structures (such as loops) to optimise the program structure. Moreover, they are encouraged to discuss the differences between the simulated and real world (for example friction affecting robot moves) by comparing the physical robot with the software simulator. This helps them to understand how their selected strategies should take into account of unforeseen situations and the challenges that STEM faces. Discussion focussed also on examples of programs being used in everyday devices.

Discussion

The duration of the robot event and the fact that each class will attend one event only, are some of the key restrictions to consider when designing this type of activities. Indeed, the challenge is to use a short amount of time to introduce various complex concepts at once. Nevertheless, the duration of the event is such that pupils generally stay focus and concentrated for the full session.

The (almost) lack of prior programming knowledge is another aspect to be taken into account. Therefore, while designing the event, it was decided to focus on two key aspects of programming: the fact that, at its core, computer programming can be considered as a form of problem solving and that coding is the process of formulating a description of a method (or a set of instructions) to achieve a goal. In this way, the bite-size approach adopted here can successfully aim at increasing the student’s perception of being able to program rather than aiming at teaching core programming concepts. Step5 should provide a useful insight on whether they feel they have been successful. Step5 should provide a better understanding of the complexities behind coding.

In turn, an event based around robot activities should reinforces their idea that programming is the convergence of three factors: problem solving awareness, the ability to develop suitable strategies to tackle the identified problem and the acquisition of the technical knowledge necessary for the task. Indeed, the immediacy of their actions should stimulate their reaction, while the relative simplicity of the specific task should ensure a successful end to their attempts. The hope, then, is that, once their coding confidence has been raised in this way, they would be more inclined to engage with more formal aspects of programming (i.e. core programming aspects) in future. In other words, by hinting that programming can be seen as the ability to build and implement a plan, then it is possible to convince them that the art of coding can be reduced into breaking down programming into something that can be managed by simply following the three factors mentioned above. This is done during Step1 and Step2 in an abstract way. Indeed during these initial steps they can observe different robot activities and then discuss their behaviour. However, taking the students through this process in a very practical and realistic way is crucial. Step3 and Step5 aims at this. Indeed, Step3 will test their ability to both formulate and decompose the problem, while the final demonstration in Step5 of the robot moving on the whiteboard (as they had originally planned during Step3) is the concrete evidence of their success that should encourage them to increase their perception that they possess these qualities. Their confidence would also being reinforced by the fact that, even with very little or no prior preparation and knowledge of the topic treated, they have still been able to manipulate and handle code successfully. Therefore, their ability during Step1 and Step2 to both explore the functionality and the limitations of the robots could be used to evaluate their ability to formulate the problems whereas the outcomes from Step3 and Step6 could be used to evaluate their basic insight to computer program structures. The outcomes from Step5 could be used to evaluate their perception of their coding skills.

Evaluation

About 30 robot events have been run so far with about 15-20 school pupils attending each session. Pupils were aged between 14 and 18 of mixed gender and ethnic background. School did not use any particular criteria to select the participants to the STEM day. Sometime it was the whole class, sometime it was the ones interested to at least one of the several events organised during that STEM visit to Brunel University.

Overall, almost every time pupils have managed to finish the assigned task successfully. An event has been considered a success when Step5 was successfully completed while actively contributing to Step6, for example expressing great satisfaction in being able to both improve (compared to the original implementation) and control the robot behaviour or discussing alternative strategies to achieve the same task. In general, their participation and engagement during the event has been very enthusiastic. A qualitative analysis of the questionnaire feedback obtained from the students after their visit has also been showing positive responses. The questionnaire was managed and collected by the University management staff as a result of the management of the school visit to the University. One of the questions asked to the participants was to indicate their preferred event. Moreover, they were asked to asses their preferred event. The robot event described in this paper was among the highest rated ones. Also they found the event easy to follow and entraining. The participants were also asked to comment on the overall visit and several of them commented positively on the robot event. These outcomes have also been supported by the feedback from accompanying teachers, suggesting that more involvement of the teachers during the event could be beneficial for both the event and the teachers.

The task of identify the correct sequence of robot moves (putbeeper, move, putbeeper, move,etc was one of the initial challenge pupils faced. Often their initial attempt was incorrect (for example no use putbeeper between one move and another resulted in the robot moving without wrtiting). However, both the immediacy of the simulated environment (they could test the sequence produced so far by pressing the Execute or Step button) and the highly collaborative, interactive nature of the event helped them to independently (i.e. without any the intervention of the teachers) identify and tackle the issue in a successful way. Indeed, after few initial incorrect attempts they successfully mastered the sequential aspect of the task.

Towards the end of Step4, participants often inquired about how to make the program more efficient. For example, they started thinking of strategies to avoid or minimise repetitions. That is, once they felt confident with the basic task of defining sequential actions, they spontaneously started thinking of core programming strategies, such as looping, to optimise their implementation. During Step6 the use of basic program structures such as sequences and loops was therefore discussed.

In the overwhelming majority of the cases the participants have demonstrated that they have been able to successfully take a problem description and decompose it into subtasks and implement them. During Step6 their ability to engage with discussions such as the introduction of more efficient coding strategies (such as loops, etc) or expanding the same approach to a different domain (letters, punctuation, etc rather than just digits) could be interpreted as an increase in their confidence of coding proficiency.

Indeed, the participants perception about their coding ability was another challenge faced. Beginners confidence about their programming abilities is very low. One of the main issue, with beginners attempting to write computer programs, is associated with the complexity of the syntax of the programming language used. The overhead of learning the syntax and semantics of a language at the same time contributes to the complexity of learning how to program (Linn and Dalbey 1989). The perception about their inability to write the correct code can overwhelm children and affect their engagement with computer science. In (Koulouri et  al. 2014) it has been shown that a programming language with a simple syntax contributes to increase the participant perception of their coding ability. For this reason, during Step3, the GVR virtual robot was used. In most of events participants were able to learn the basic syntax very quickly and successfully produce the correct sequence during Step3. In other words, they quickly felt they could easily control and program the virtual robot.

It must highlighted that this was a pilot event and therefore both qualitative and quantitative data are incomplete, therefore more systematic quantitative evaluations are needed to confirm these initial evaluation. Nevertheless, from both the completition success rate mentioned above and the feedback obtained it is reasonable to assume that this approach could contribute to increase pupils interest and familiarity with some STEM aspects.

The issue of whether any new activity with children could be seen as enthusiastic and positive and therefore likely to introduce some bias in the evaluations discussed so far is an unsolved question. A possible answer could be obtained in future by carefully designing the event. For example, events with similar tasks but without the use of robots could be considered. In this way it would be possible to assess the influence of the robot component by comparing the two events. However, as discussed in (Major et al. 2012), there is some evidence that robots are an effective teaching tool and can help novice programmers in their studies. The event presented in our paper has focussed on the combined use of physical and simulated robots. A further development planned for the event described in our paper is to design an event based around introducing several physical robots at once with increased sensing capabilities and with reduced use of simulated steps. The hope is to increase the immediacy and the physicality of the situation should enhance the children experience.

Future plans also include collecting data about their future academic choices to establish any possible correlation.

Finally, an expanded version of this event based on involving more than one school at once and adding a competitive element is currently being developed at Brunel University by the authors (AdoptaBot 2014).

Acknowledgments

The study was carried out in accordance with Brunel University’s research ethic’s guidelines and approval procedures. The author would like to thank Dr. A. Payne, Dr. Y. Li, Lesley Warren and Dr. N. Patel for their support and constructive comments.

References

AdoptaBot (2014), <http://www.adoptabot.org.uk/> (Jul, 2014).

GVR (2014), <http://gvr.sourceforge.net> (Jul. 5, 2014).

Hex (2014), <http://www.hexbug.com> (Jul. 5, 2014).

Koulouri, T., Lauria, S., and Macredie, R. D. (2014). “Teaching introductory programming a quantitative evaluation of different approaches.” ACM Transactions on Computing Education, In Press.

Linn, M. C. and Dalbey, J. (1989). “Cognitive consequences of programming instruction.” Studying the novice programmer, 57–81.

Major, L., Kyriacou, T., and Brereton, O. (2012). “Systematic literature review: teaching novices programming using robots.” Software, IET, 6(6), 502–513.

Major, L., Kyriacou, T., and Brereton, P. (2014). “The effectiveness of simulated robots for supporting the learning of introductory programming: a multi-case case study.” Computer Science Education, 24(2-3), 193-228.

Pierre, J. S. and Christian, J. (2002). “K-12 initiatives: increasing the pool.” Frontiers in Education, 2002. FIE 2002. 32nd Annual, Vol. 1, IEEE, T4C–21.

Python (2014), <http://www.python.org> (Jul. 5, 2014).

Robins, A., Rountree, J., and Rountree, N. (2003). “Learning and teaching programming: A review and discussion.” Computer Science Education, 13(2), 137–172.

Scribbler (2014), <http://en.wikipedia.org/wiki/Scribbler_(robot)> (Jul, 2014).

Šorgo, A. and Kocijančič, S. (2004). “Teaching basic engineering and technology principles to pre-university students through a computerised laboratory.” World Trans. Eng. Tech. Educ, 3, 239–242.

STEM (2014a), <http://www.nationalstemcentre.org.uk/elibrary/resource/9171/stem-knowledge-networks> (Jul. 5, 2014).

STEM (2014b), <https://www.sciencelearningcentres.org.uk/impact-and-research/research/future-of-stem/> (Dec. 1, 2014).

 

Stanislao Lauria

Stanislao Lauria (stasha.lauria@brunel.ac.uk) is a computer scientist with an interest in robotics, human-computer interaction, natural language interfaces and education. He is a Lecturer in the Department of Computer Science of Brunel University.

Creative Commons License
This paper is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Double Blind Review
This paper has been subject to a double blind peer review by at least two reviewers. For more information about our double blind review process please visit: http://bejlt.brookes.ac.uk/about/double-blind-review/

How to cite this paper.
Posted in Research Paper

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Subscribe to BeJLT

Get email alerts when there is a new issue.
* = required field

Send this page to Kindle

your kindle user name:
(you@kindle.com, without @kindle.com)
Approved E-mail:
(Approved E-mail that kindle will accept)
Kindle base email kindle.com | free.kindle.com
(Use kindle.com to download on wispernet or wifi, use free.kindle.com for wifi only.)
using kindle.com may incur charges)