facilitating children to learn coding outside of school with the assistance of parents. ... children from engaging with coding outside of school in Rwanda have been identified ...... Figure 11:L293D top side view (a ) pin names (b), and its functional diagram ...... With agile methodology I gain an occasion to test the product under ...
Teaching coding to children in Rwanda using robotics: an innovative approach Gabriel Baziramwabo
A thesis submitted in fulfillment of the requirements for the degree of Master of Science in Information Systems
Graduate School of Information Technology Kobe Institute of Computing
Japan 2018 September, 15th
Teaching coding to children in Rwanda using robotics: an innovative approach Gabriel Baziramwabo
Abstract This research introduces the innovative approach to improve the way children in Rwanda learn coding. The current national curriculum does not allot enough time for children to engage with coding and I wish it would be reviewed. However, proposing the review of the national curriculum is beyond the scope of this research. Instead, the problem is tackled with a new approach aiming at facilitating children to learn coding outside of school with the assistance of parents. Two major challenges preventing children from engaging with coding outside of school in Rwanda have been identified. 1) Some parents are hindered by having no background in coding and they don’t know how to help their children learn coding. 2) Other parents are trying to help their children learn coding but they cannot find suitable tools on market. To address those challenges the research seek to provide suitable tools for teaching coding to children, to guide parents on how to assist children in using those tools, and to find out whether using those tools improves coding skills of children. The research starts with four hypotheses: 1) Using a physically interactive robotic tool to teach coding to children is more motivating than just using on-screen animated graphics. 2) Assembling the robotic tool using local materials that children can obtain for free or at very low cost like pieces of wood and cardboard will reduce the cost of the robot. 3) If children along with parents are able to assemble the robotic tool under the guidance of a provided video or a written manual and if the robotic tool is programmable in their local language then there will be no need to hire experts for facilitation and that will cut off inconveniencing overheads. 4) As long as the robotic tool is easy to assemble, to program and to troubleshoot, parents will not feel daunted to assist children. For the robotic tool to operate three materials were developed. 1) A programming language in Kinyarwanda, the Rwanda's native language, 2) a text-based programming environment where users input codes for controlling the robotic tool, 3) and the physical robotic tool to respond to the instructions it receives from users. The first prototype of the robotic tool was tested with 9 Rwandan children aged between five and twelve. During a one-hour session, children were assisted to self-teach how to give instructions to a robotic tool. Their confidence was measured and the average success for all 9 children was 86.11%. Observations and comments acquired from that testing are leading to improve subsequent prototypes. i
List of Abbreviations
CSS: Cascaded Style Sheet
DC: Direct Current
DIY: Do It Yourself
EDPRS: Economic Development and Poverty Reduction Strategy
EN: Enable
GND: Ground
GPIO: General Purpose Input Output
GSMA: Global System for Mobile Association
HTML: Hyper Text Markup Language
IC: Integrated Circuit
ICT: Information and Communication Technology
IP: Internet Protocol
KIC: Kobe Institute of Computing
LEGO: Leg Godt (Danish words meaning "play well" )
MINT: Mathematics, Informatics, Natural sciences, Technics
MIT: Massachusetts Institute of Technology
NPO: Non-Profit Organization
OLPC: One Laptop Per Child
PCB: Printed Circuit Board
PWM: Pulse Width Modulation
SWOC: Strengths, Weaknesses, Opportunities, Challenges
SWOT: Strengths, Weaknesses, Opportunities, Threats
XML: Extensible Markup Language
ii
Table of Contents Introduction .......................................................................................................................................... 1 1.1
Background ........................................................................................................................... 1
1.2
Problem analysis ................................................................................................................... 2
1.3
Objectives of study ................................................................................................................ 5
1.4
Research questions ................................................................................................................ 5
1.5
Research approach ............................................................................................................... 6
1.6
Contribution .......................................................................................................................... 6
1.7
Thesis Structure .................................................................................................................... 8
Literature Review.................................................................................................................................. 9 2.1
Scratch’s efforts to lower the floor for children in coding..................................................... 9
2.2
Scratch challenged .............................................................................................................. 11
2.2.1 Less powerful ...................................................................................................................... 11 2.2.2 Slower authoring and more verbose ................................................................................... 11 2.2.3 Inauthentic .......................................................................................................................... 12 2.3
Utility of manipulative materials to children’s learning ..................................................... 12
2.4
LEGO Mindstorm ................................................................................................................ 12
2.5
“Children’s care-giving robot” versus “children’s peer robot” ......................................... 13
2.6
Animated toys ...................................................................................................................... 14
2.7
Applying the takeaway from related works to Rwanda’s context ........................................ 14
System Development ........................................................................................................................... 16 3.1 Methodology: Agile ................................................................................................................... 16 3.2
Design ................................................................................................................................. 18
3.3
Building............................................................................................................................... 21
3.3.1
Hardware building .......................................................................................................... 21
3.3.2
Software building ............................................................................................................ 37
3.4
Testing................................................................................................................................. 45
3.4.1 Testing questions ................................................................................................................ 45 3.5
Configuration ...................................................................................................................... 48
3.5.1 Apache must be installed on the Raspberry Pi .................................................................... 48 3.5.2 PHP must be installed......................................................................................................... 49 3.5.3 Apache must be added to sudoers ....................................................................................... 49 3.5.4 User pi needs ownership on the project folder .................................................................... 49 3.5.5 The project folder needs to be readable and writable ......................................................... 49 3.5.6 Device to Device (D2D) connection through Wi-Fi must be well set .................................. 49 iii
3.5.6 Pairing the Raspberry Pi and the Smartphone.................................................................... 51 3.6 Product Releasing: next work.................................................................................................... 53 Validation and implementation ........................................................................................................... 54 4.1 Tankyu Practice......................................................................................................................... 54 4.2 Analysis method: Questionnaire ................................................................................................ 55 4.2.1 Survey 1: Kids vis-à-vis car toys ......................................................................................... 55 4.2.2 Survey 2: Interest in robotics .............................................................................................. 55 4.2.3 Survey 3: Preferable coding style ....................................................................................... 55 4.3
SWOC Analysis ................................................................................................................... 56
4.3.1 Strength............................................................................................................................... 56 4.3.2 Weaknesses ......................................................................................................................... 57 4.3.3 Opportunities ...................................................................................................................... 58 4.3.4 Challenges .......................................................................................................................... 59 4.3
Benax vs. RC Toy ................................................................................................................ 59
Conclusion and Acknowledgement ..................................................................................................... 60 5.1 Conclusion ................................................................................................................................ 60 5.1.1 Answers to research questions ............................................................................................ 60 5.1.2 Recommendation................................................................................................................. 62 5.1.3
Where to go from here?....................................................................................................... 63
5.2 Acknowledgement ...................................................................................................................... 64 Bibliography ....................................................................................................................................... 65 Appendices .......................................................................................................................................... 68 Appendix A: input.js ........................................................................................................................ 68 Appendix B: interpreter.php ............................................................................................................ 71 Appendix C: functions.py ................................................................................................................ 80 Appendix D: IPSpreading.py ........................................................................................................... 85 Appendix E: catch-device-ip.php..................................................................................................... 86 Appendix F: queryRobotIP.php ....................................................................................................... 87 Appendix G: checkRobotIP.js .......................................................................................................... 88 Appendix H: Hardware components with brief specifications ......................................................... 89 Appendix I: Survey 1 Questions....................................................................................................... 97 Appendix J: Survey 1 Answers (Summary) ...................................................................................... 99 Appendix K: Survey 2 Questions ................................................................................................... 100 Appendix L: Survey 2 Answers ...................................................................................................... 101 Appendix M: Survey 3 Questions................................................................................................... 102 Appendix N: Survey 3 Answers ...................................................................................................... 103
iv
List of figures Figure 1: The curve for learning to code in Rwanda today .................................................................. 3 Figure 2: Problem analysis................................................................................................................... 4 Figure 3: Coding skills gained with current method vs. coding skills gained with proposed solution .. 7 Figure 4: Increase in coding skills contributed by current research solution ....................................... 8 Figure 5: Label 1 shows Kinyarwanda as a supported language while label 2 shows some blocks who failed to be translated into Kinyarwanda, rather in Russian............................................................... 15 Figure 6: Agile methodology .............................................................................................................. 17 Figure 7: Hardware design................................................................................................................. 19 Figure 8: Software design ................................................................................................................... 20 Figure 9: Raspberry Pi 3 Model B ...................................................................................................... 22 Figure 10: Raspberry Pi 3 GPIO Pin Chart [25] ............................................................................... 22 Figure 11:L293D top side view (a ) pin names (b), and its functional diagram (c)[25][26][27] ....... 24 Figure 12: Diagram for wheel driving ................................................................................................ 25 Figure 13: SG90 Servo Motor ............................................................................................................ 26 Figure 14: SG90 Servo Motor dimensions .......................................................................................... 27 Figure 15: Torque —Position from the center of rotation versus the allowed load ............................ 29 Figure 16: Illustration of SG90 Servo Motor's torque ........................................................................ 29 Figure 17: Illustration of PWM .......................................................................................................... 30 Figure 18: How the front wheel is controlled ..................................................................................... 31 Figure 19: Ultrasonic Ranging Module HC - SR04 ............................................................................ 32 Figure 20: Working principle of the ultrasonic distance sensor [36] ................................................. 33 Figure 21: Timing diagram [33]......................................................................................................... 33 Figure 22: Conceptual voltage divider ............................................................................................... 34 Figure 23: Actual voltage divider as used in robot building ............................................................... 34 Figure 24: How Ultrasonic Distance Sensor is connected to the Raspberry Pi .................................. 35 Figure 25: Pi Camera ......................................................................................................................... 35 Figure 26: Front-Right view of the produced robot ............................................................................ 37 Figure 27: Top View of the produced robot ........................................................................................ 37 Figure 28: Diagram showing the languages and tools to be used in the software building ................ 37 Figure 29: Command Input in a browser ............................................................................................ 38 Figure 30: Command Input in a mobile application ........................................................................... 39 Figure 31: Interpreting person ........................................................................................................... 40 Figure 32: Sample of command flow implementation ......................................................................... 41 Figure 33: Interpreter zoomed in ........................................................................................................ 42 Figure 34: Module “functions” zoomed in ......................................................................................... 43 Figure 35: Executor zoomed in ........................................................................................................... 43 Figure 36: Picture taking is an example of a feedback flow ............................................................... 44 Figure 37: Prototype testing ............................................................................................................... 48 Figure 38: D2D Connection through Wi-Fi ........................................................................................ 50 Figure 39: IP Address spreading is the way the Raspberry Pi communicates its IP Address ............. 51 Figure 40: Checking the current IP Address of the robot ................................................................... 52 Figure 41: For every new Smartphone being paired to the Raspberry Pi is necessary ....................... 53 Figure 42: Sprint illustrated ............................................................................................................... 53 Figure 43: Tankyu Chart of the project .............................................................................................. 54 Figure 44: Code Typing vs. Visual Based Coding .............................................................................. 57 Figure 45: Solution verification .......................................................................................................... 58 Figure 46: Adhesive tapes .................................................................................................................. 89 v
Figure 47: Battery .............................................................................................................................. 89 Figure 48: Blank circuit boards .......................................................................................................... 89 Figure 49: Bolts and nuts ................................................................................................................... 89 Figure 50: Cable ties .......................................................................................................................... 90 Figure 51: Capacitors ........................................................................................................................ 90 Figure 52: Card board ....................................................................................................................... 90 Figure 53: Corner brace..................................................................................................................... 90 Figure 54: Fixed Castor Wheel........................................................................................................... 91 Figure 55: Gear motors ...................................................................................................................... 91 Figure 56: Gripper ............................................................................................................................. 91 Figure 57: Jumper cables ................................................................................................................... 91 Figure 58: Light.................................................................................................................................. 92 Figure 59: Microphone ....................................................................................................................... 92 Figure 60: Piezo Buzzer...................................................................................................................... 92 Figure 61: Plastic Tire Wheels ........................................................................................................... 93 Figure 62: Plug-in Terminal ............................................................................................................... 93 Figure 63: Power Bank....................................................................................................................... 93 Figure 64: Push pins........................................................................................................................... 93 Figure 65: Relay ................................................................................................................................. 94 Figure 66: Resistors............................................................................................................................ 94 Figure 67: Rubber dampers ................................................................................................................ 94 Figure 68: Screws ............................................................................................................................... 94 Figure 69: Sound Card Adapter ......................................................................................................... 95 Figure 70: Speaker ............................................................................................................................. 95 Figure 71: Strong magnets ................................................................................................................. 95 Figure 72: Wood board ...................................................................................................................... 96 Figure 73: Threaded spacer hex ......................................................................................................... 96
List of tables Table 1: Components to be used during hardware development......................................................... 18 Table 2: L293D Pin characteristics [25] ............................................................................................ 23 Table 3: Adding explanations to the diagram in Figure 12 ................................................................ 25 Table 4: SG90 Servo Motor wire configuration .................................................................................. 27 Table 5: Significance of SG90 Servo Motor's torque .......................................................................... 28 Table 6: ON-Time versus Motor position............................................................................................ 30 Table 7: Pi Camera specifications ...................................................................................................... 36 Table 8: The meaning of some functions ............................................................................................. 39 Table 9: Testing Questions ................................................................................................................. 45 Table 10: Answers to research questions ............................................................................................ 60 Table 11: Hardware components with brief specifications ................................................................. 89 Table 12: Summary of interview 1: Kids-vis- à -vis car toys ............................................................... 99
List of formulae Equation 1: Equation of torque [32]................................................................................................... 28 Equation 2: Voltage divider ................................................................................................................ 34 vi
Chapter I Introduction This chapter focuses on research area and describes the purpose of this Master’s thesis project.
1.1 Background Rwanda is a small, landlocked country in Central-East Africa. The nation is making efforts to transform itself from a subsistence agrarian society into a knowledge-based economy, striving to overcome the devastation caused by the genocide of 1994 during which an estimated 1 million people lost their lives.
In 2000, Rwanda established a set of objectives to transform the country into an industrial based economy in 20 years. The Vision 2020 [1] plan specifies short-, medium- and long term goals with measurable indicators of progress. In order to achieve the goals defined by Vision 2020, the Rwandan government established an Economic Development and Poverty Reduction Strategy (EDPRS) [2]. The EDPRS recognizes the key role that education can play in improving social and economic wellbeing and in reducing poverty. These governmental plans recognize that the children of Rwanda are the nation’s most precious natural resource.
In 2007 Rwanda Government adopted OLPC program aiming at remaking its education system to develop 21st century skills [3] known as 4C' i.e. communication, collaboration, creativity, and critical thinking. OLPC laptops came installed with Scratch, a visual programming environment that lets users create interactive, media-rich projects [4].
One of the challenges Rwandan community faces is being unable to make use of some tools just because their operation is documented in foreign languages. ICT Sector Strategic Plan 2018-2024 [5] 1
admits that there is a limited production of local content and that it limits citizens from some services. The content available is not translated into local language that can be understood by wider citizen. As a remedy, a focus has been undertaken to encourage more investment to increase local contents creation by providing various incentives.
Alongside the increase of portable devices for children, came the ubiquity of Smartphones. Whenever a good use is made out of that opportunity to equip learners with computational skills positive changes will be seen in education. According to GSMA report on Sub-Saharan Africa in 2017, Smartphone penetration in East-Africa where Rwanda is located is increasing from 21% in 2016 to the prediction of 55% in 2020 [6].
1.2 Problem analysis Rwanda Education operates on a 6-3-3-4 system. That is, 6 years for Primary School, Junior 3 years for Secondary School (Ordinary level) , 3 years for Senior Secondary School (Advanced level) , and 4 years for University Bachelor’s degree. 6 years of Primary School are summed up from 3 years of Lower Primary and 3 years of Upper Primary.
With the current national curriculum, computer programming is taught in Computer Science subject at the level of Senior Secondary School and in Universities having Engineering as a faculty. The introductory Programming which serves to teach the logic of programming in order to prepare learners for the programming in coming years is currently too brief, not well distributed over the learning trajectory, and using less engaging methods.
As illustrated on Figure 1, the current curriculum does not offer learners in Lower Primary (Primary 1, Primary 2, and Primary 3) the occasion to learn coding. The introductory coding is placed in Upper Primary (Primary 4, Primary 5, and Primary 6) where learners animate graphics using Turtle and Scratch Programs that come installed with OLPC laptops. Given that students are not allowed to take OLPC laptops at home, their engagement with coding remains little. In Junior Secondary School (Secondary 1, Secondary 2, Secondary 3) there are no courses for coding and learners will be subjected to Ebbinghaus Forgetting Curve [7].
2
Figure 1: The curve for learning to code in Rwanda today
Figure 2 depicts the analysis of the current problem. There is a shortage of human resources in fields that require computational skills. It results from the shortage of people who graduate from computer science schools equipped with required skills. Learners cannot get enough skills as long as their engagement with computer programming is limited.
3
Figure 2: Problem analysis
4
1.3 Objectives of study After analyzing the factors that cause young learners to be unprepared for computer programming in computer sciences, the primary objective of this study is to develop a low-cost and easy-to-use tool that will help young learners from Lower Primary to Lower Secondary to get more engaged with coding.
In order to accomplish the above primary objective, four secondary objectives are to be accomplished:
To develop education tools capable of equipping children with computational thinking.
To develop a manual to guide parents on assisting their kids in learning how to code.
To minimize the cost of developed tools making them affordable to any parents regardless of their social classes.
To make the usage of developed tools as simplified as possible in order to avoid frequent intervention of experts.
1.4 Research questions In order to reach the above research objectives, this study addresses the following research questions:
Why are current coding tools not effective?
How to get parents involved in the code learning of their children?
When exactly children can start learning to code?
How can coding which is normally inflexible be made easy for children?
How to make children motivated to learn coding?
How to produce a tool affordable to every child?
5
1.5 Research approach The research was conducted by interviewing parents, teachers, seasoned computer programmers, and researchers. All of them are Rwandans. From their views, adding to my personal experience as a parent, IT engineer, and a former teacher, I developed a tool which is an educational robot. I then tested the first prototype of the tool with a sample of Rwandan children. Observations and opinions collected from both children and parents who tested the tool led to improving the tool.
1.6 Contribution This research seeks to equip children with computational thinking from early age. I believe that computational thinking is nowadays essential and that children should learn it for life. I therefore promote the idea that coding should be a skill every child should have at every school stage, including the primary school. I do not follow the ambition to make a computer scientist or a software engineer out of each child, but I presume that introducing programming at a very early school stage might increase the interest of a child in computer science and MINT subjects. I hope that therefore, on a long-term perspective, the number of students will consider to choose computer engineering while enrolling in a university or to start a career in a MINT field. Figure 3 roughly compares coding skills gained under current learning method against coding skills expected to be gained when a solution proposed by current research is applied.
Economical contribution of this research is regarded in a big picture that there will be more people to fill jobs requiring computational skills if there are more computer-science graduates, and there will be more graduates if more people could start that subject in high school, and students will not be motivated to start the subject in high school if they don’t feel confident about coding; hence the need to start preparing them from primary school.
6
Figure 3: Coding skills gained with current method vs. coding skills gained with proposed solution
7
Figure 4: Increase in coding skills contributed by current research solution
1.7 Thesis Structure This thesis is comprised with 6 chapters:
Chapter 1 (current): General introduction
Chapter 2 describes the literature review, related work and the overseas research
Chapter 3 describes design and development, used components both hardware and software
Chapter 4 describes implementation and validation, the web interface, and the prototype
Chapter 5 concludes with suggestions for future work and some reflections on issues that are relevant to this thesis project
Chapter 6 has appendices
8
Chapter II Literature Review In this chapter I reviewed the similar works done regarding effective tools created to help teach programming to children. The design of playful learning experiences for children is a complex challenge. Designers are asked to not only define which artifact to use, but to also investigate how that artifact may enable children to construct new knowledge based on their experience of the world. Some efforts are put in developing languages like Scratch [8] while other efforts are put in the physical facets. And driven by the passion of lowering more the floor for children in code learning new ideas keep on emerging to challenge and improve previous works. Similarly the idea in this research is built on previous ideas while engaging in something contextual for children in Rwanda.
2.1 Scratch’s efforts to lower the floor for children in coding Resnick et al. in the paper Scratch: Programming for Everyone [8] presented Scratch as an effort to lowering more the floor for children in learning coding. When personal computers were first introduced in the late 1970s and 1980s, there was initial enthusiasm for teaching all children how to program. Thousands of schools taught millions of students to write simple programs in Logo or Basic. Seymour Papert’s book Mindstorms: Children, Computers, and Powerful Ideas [9] presented Logo as a cornerstone for rethinking approaches to education and learning. Although some children and teachers were energized and transformed by these new possibilities, most schools soon shifted to other uses of computers. In the past 20 years, computers have become a pervasive presence in children’s lives, but few children learn to program. Today, most people view computer programming as a narrow, technical activity, appropriate only for a small segment of the population.
9
Resnick et al. [8] discussed the factors that choked the initial enthusiasm for introducing programming to children.
Early programming languages were too difficult to use. Many children had difficulty mastering the syntax of programming.
Programming was often introduced with activities that were not connected to young people’s interests or experiences.
Programming was often introduced in contexts where no one had the expertise needed to provide guidance when things went wrong – or encourage deeper explorations when things went right.
Papert [9] argued that programming languages should have a low floor (easy to get started with) and a high ceiling (opportunities for increasingly complex projects over time). In addition, we believe that languages need wide walls (supporting many different types of projects, so that people with different interests and learning styles can all become engaged). Guzdial in the paper Programming environments for novices [10] argues that satisfying the triplet of low-floor/high-ceiling/wide-walls hasn’t been easy. Kelleher et al. in Lowering the barriers to programming: A taxonomy of programming environments and languages for novice programmers [11], argued that by the time of writing in 2005, new attempts to introduce programming to children and teens were emerging, some using professional programming languages like Flash/ActionScript, others using new languages developed specifically for younger programmers, such as Alice [12] and Squeak Etoys [13].
Resnick et al. [8] admitted that though previous efforts inspired and informed their work on Scratch they weren’t fully satisfied with the existing options. In particular, they felt that it was important to make the floor even lower and the walls even wider – but still supporting the development of computational thinking. To achieve these goals, Resnick and his team established three core design principles for Scratch: 1) more tinkerable, 2) more meaningful, and 3) more social than preceding programming environments.
10
2.2 Scratch challenged Explaining the core features of Scratch in their paper Scratch: A Sneak Preview [29] John M. et al. defined Scratch as based on a building-block metaphor, in which learners build scripts by snapping together graphical blocks much like pieces in a jigsaw puzzle. Commands and data types are represented by blocks of different shapes, with pieces fitting together in only syntactically-correct ways. This approach eliminates syntax errors (which have proven to be a major obstacle for learning text-based programming languages), allowing youth to focus on the problems they want to solve, not the mechanics of programming. However, David and Uri presented in their paper To Block or not to Block, That is the Question: Students’ Perceptions of Blocks-based Programming [28] three drawbacks to blocks-based programming.
2.2.1 Less powerful The first drawback to blocks-based programming students cited was that block-based programming was viewed as a less powerful programming technique compared to the text-based alternative. By power, David and Uri were referring to the set of things that are possible with the language. Interviewed students flagged blocks-based programming as limiting due to the fact that there is not a block for everything and they expressed that with text-based programming a lot more can be done.
2.2.2 Slower authoring and more verbose The second drawback brought up by a number of students with whom David and Uri [28] conducted the study, was the time and number of blocks it takes to compose a program in the blocks-based interface compared to the text-based alternative. Those students said that though it is possible in a blocks-based program to achieve something similar to what is achieved with text-based programming, it requires a lot of time of editing and messing around with variables thus sometimes taking a lot of time, while it is just a matter of typing something in text-based environment to do something different. A student exhibited that if a specific block is missing a lot of blocks must be put together to make it do what you want it to do while that is easily done with a single line of text or so. Text being more concise was identified as not only useful for composing programs, but students also thought that the resulting shorter text-based programs could be easier to understand while many blocks lead to confusion.
11
2.2.3 Inauthentic The third and final drawback identified in the paper To Block or not to Block, That is the Question: Students’ Perceptions of Blocks-based Programming [28] about the use of blocks-based tools is potentially the most damaging. Some of the students David and Uri interviewed expressed concerns over the authenticity of blocks-based programming. They labeled blocks-based programming as ineffective to develop skills that can be used beyond the classroom, be it for a job or further computer science coursework.
2.3 Utility of manipulative materials to children’s learning In this regard, a decisive contribution was given by the research, and the activities carried out at the Lifelong Kindergarten of MIT, over the last twenty-five years. Here, researchers investigated ways to expand the range of concepts that children can learn through the direct manipulation of physical objects [14]. To do so, they developed a series of what they call “manipulative materials” which embed computational capabilities inside traditional toys, such as blocks, beads and balls. As reported by Resnick [15], their work was guided by three underlying principles: encourage design projects, leverage new media, and facilitate personal connections. Resnick, however, points out the fact that the introduction of new media is aimed at fostering creative thinking, not at developing creative technologies, and that the media per se cannot ensure a playful-learning experience [15]. Decisive aspects appeared to be the capacity of meeting children’s interests, the ability to support different play styles, and the use of familiar objects in unfamiliar ways [15].
2.4 LEGO Mindstorm The most popular example of robotics applied for playful learning, developed at MIT, is LEGO Mindstorm [16]. Launched by LEGO in 1998 [16], the Mindstorm Robotic Invention System is a product line that combines programmable bricks with sensors, actuators and LEGO technics elements, for engaging children in playful learning activities. This product resulted from a series of initiatives and research that were carried out at MIT Media Lab in the nineties, such as an annual challenge called LEGO Robot Design Competition, and, especially, the Programmable Brick project [17].
12
LEGO Mindstorm is nowadays quite diffused and used in several contexts, and its use for playful learning activities is getting popular. Furthermore, several robots for teaching computational thinking are nowadays spreading, such as Thymio [18] and Cubetto [19].
2.5 “Children’s care-giving robot” versus “children’s peer robot” Less systematic and long term studies, instead, were focused on the investigation of playful learning with robotic characters designed to show social behaviors, rather than construction kits. Most of the projects that employ social robots in educational contexts tend to develop them to play the role of a teacher or a caregiver [20]. However, some studies demonstrated how a playful interaction with a robot as children’s peers could be beneficial regarding both engagement and learning. Tanaka and Matsuzoe [20], for instance, by introducing the concept of the care-receiving robot, showed how children increase their performances in terms of learning by teaching to the robot. The idea of children as teachers is also presented by Gordon et al. [21]. The authors present a tangible toolkit for programming social robots, a DragonBot in their case, through a playful and fun interaction. In other studies, instead, the robot assumed different role: a mediator. Marti and Iacono [22] designed a robot companion for children with disabilities, for empowering them to explore different play modalities. Kronreif et al. [23], instead, designed a Cartesian coordinate robot that enables children with severe physical disabilities to play with existing toys, such as bricks.
Although both aspects of play and learning are addressed in the mentioned examples, these do not converge fully in playful learning experiences. Nevertheless, these kinds of examples provide useful methodological references for design processes that often address particular user requirements and take into account context specificities. These methods for designing social robots for play or education, in fact, often present some common traits. They usually include explorative stages in which both existing knowledge as well as specific findings, emerging from user studies, are used to define the requirements that subsequently guide the design and development of the robot and the interactions. In addition, the testing phases are peculiar: these are usually carried out in real contexts, with representative samples of participants, and there is keen interest in qualitative data, rather than quantitative.
13
2.6 Animated toys Regarding the actual design of robots for children’s playful learning, Edith K. Ackermann [24] provides handy hints. In particular, in her work about AniMates, she points out some crucial aspects of animated toys. AniMates are animated in the sense that they exhibit specific behavioral attributes, attitudes, or social skills [24]. She does not refer to robots or educational content explicitly. However, she explains how animated toys represent self-reflective tools that can help children in their process of identity formation and social-emotional development. According to the author, these animated toys can also be described as toys that feel or sense. These, in fact, are sensitive to particular features of their environment and children can affect their behavior by manipulating these features.
This idea of animated toys that feel may be combined with the idea of manipulative materials that can support children’s self-exploration and knowledge building, with the intent of developing not only an empowering artifact but also an intrinsically motivating experience around it.
2.7 Applying the takeaway from related works to Rwanda’s context Efforts to lower more the floor for children in learning coding presented by Resnick et al. in their paper Scratch: Programming for Everyone [8] are enormous and worth admiration. However the drawbacks of blocks-based programming prevented by David and Uri [28] can’t be minimized. It can be put that with more floor lowering can result side effects which tend to make coding sessions more playful than educational. Rwanda adopted Scratch in education system and Scratch comes installed in OLPC laptops. Children learn coding with Scratch from Primary 4 up to Primary 6 as specified by the national curriculum [30]. At Primary 4, children are aged 10. It can be well stated that in Rwanda children start learning coding with Scratch at 10 years. That is because learning in English language starts with Primary 4. Prior to Primary 4, leaning is in Kinyarwanda, the mother tongue. As it can be seen on figure 5, Scratch supports Kinyarwanda with a translation that needs to be improved.
14
Figure 5: Label 1 shows Kinyarwanda as a supported language while label 2 shows some blocks who failed to be translated into Kinyarwanda, rather in Russian
Two things should be done in order to give to children an opportunity to learn Scratch before Primary 4: First, the national curriculum must be reviewed. Second, the translation of Scratch in Kinyarwanda must be optimized. This research does not aim to propose a review of the national curriculum. This research will not try either to optimize the translation of Scratch in Kinyarwanda. Rather, this research brings forth a different approach which consists of creating a new programming environment in our mother tongue based on code typing rather than code blocks after considering the drawbacks of blocksbased programming unveiled by recent publications. This research will also consider promoting coding out of school.
15
Chapter III
System Development In this chapter, the methodology and the path of the development are described. The developed system is an educational robot expected to help children up to 15 years of age learn coding.
3.1 Methodology: Agile The website linchpinseo.com [34] describes the Agile Methodology as a particular approach to project management that is utilized in software development. It is accredited to assists teams in responding to the unpredictability of constructing software. Agile Methodology uses incremental and iterative work sequences commonly known as sprints. Though the description only mentions software development while robotics, our field, requires both hardware and software development, I still adopted Agile as my methodology of choice because I was developing hardware and software inseparably.
Figure 6 illustrates five steps covered in each sprint: design, build, test, configure, and release.
The following reasons pushed me to select agile methodology:
Engaging targeted clients and investors through providing multiple occasions for engaging targeted clients and investors before, during, and after each sprint.
Being transparent through showing to clients and investors a work in progress and how their feedback contributes to new releases.
Rooms for change in a way that if something went wrong in the previous release, it becomes a concern in the next sprint. 16
Focusing on business value: From allowing the clients to determine the priority of features comes delivering the product they really want to have.
Focusing on users: In the case of this project clients are parents while users are children. With agile methodology I gain an occasion to test the product under development, in the middle of a sprint.
Exercise of quality improvement: By breaking down the project into manageable parts, I can focus on high-quality development, testing, and collaboration one at a time. Later when the business grows these tasks will be assigned to teams. Therefore it is preferable to start early exercising work breakdown and quality improvement. Also, by producing frequent builds and conducting testing and reviews during each sprint, quality is improved by finding and fixing defects quickly and identifying expectation mismatches early.
Figure 6: Agile methodology
17
3.2 Design While designing the robot, the main objective was to build it in a way that children will interact with it in a playful way while unconsciously learning to code. In this section both hardware and software designs are described.
3.2.1 Hardware design Something educational, cheap, easy to carry, easy to assemble, easy to mend, and DIY-inspiring for any Rwandan child aged up to 15 no matter her/his social-economic class — that is what I bore in mind while deciding on materials to use. At the center of my robot I decide to use Raspberry Pi. I had been tinkering with Raspberry Pi in a couple of months when I got the idea of using it to build something useful for children. I had checked other important boards namely Arduino and Microbit and still wanted to use Raspberry Pi especially for its support for Linux and Python. Later in this thesis you might guess why I prefer Linux and Python. After choosing Raspberry Pi other hardware components were chosen according to the feature I intended to provide to beneficiaries as shown in table 1.
Table 1: Components to be used during hardware development
Shown on Features
Components
the design diagram
Control
Raspberry Pi
Yes
Free Moving
Motor driver, wheel drive gear motors, wheels
Yes
Sensing
Sensors
Yes
Taking pictures
Camera
Yes
Holding objects
Gripper
Yes
Rotating some parts
Servo motors
Yes
Signaling
light, buzzer
Yes
Audio Input and Output
Microphone, Sound Card Adapter, Speaker
Yes
Power source
Batteries
Yes
Casing
Cardboard
No
Chassis
Wood board
No
Fastening
Bolts & nuts, screws, magnets, pins, cable ties
No
Circuitry
PCB, jumper cables, resistors, relays, capacitors
No
18
Figure 7 shows some of the materials used for the hardware part and how they are logically connected.
Figure 7: Hardware design
3.2.2 Software design It is with software that robot’s hardware comes to life. The software concept is based on trying to make something that is easy and that works flawlessly. As illustrated on Figure 8, the software design is based on three major components: Connectivity, Command Flow, and Feedback Flow.
Connectivity: Before making the software design I had already decided to use Wi-Fi connectivity. On one hand the Raspberry Pi that I had already decided to use (see section 3.2.1) can be connected to Wi-Fi. On the other hand users will be using mobile devices supporting WiFi. Having user device and robot connected on the same hotspot eases the flow of both command and feedback.
19
Command Flow is made up of three parts as illustrated on Figure 8: Command Input, Command Interpreter, and Command Executer. A user at client side will type a text in local language and submit it to the robot (on server side). Then because the machine (Raspberry Pi in our context) cannot understand directly a local language, interpreter comes in need. Finally the interpreted command is executed.
Feedback Flow comes to help the user understand the results of the submitted command. For example if there is a typing error the user has to be communicated in order to know what to change. A feedback is generated at command runtime and it is of course something hard for a user to understand given that the user is supposed to not knowing a professional programming language like Python. That necessitates a feedback interpreter. Then the interpreted command is displayed on the user’s screen.
Figure 8: Software design
20
3.3 Building In this section both hardware and software building is described. It is time to implement the designs made in section 3.2.
3.3.1 Hardware building Referring to the hardware design made in section 3.2.1, I started looking for the components to fit in that design. I divided hardware components into two major categories according to the amount of specifications those components carry with them. Those categories were hence simply named “Hardware with large specifications” and “Hardware with brief specifications”. After putting together all those hardware components a robot was brought into being but still lifeless. The section 3.3.2 “Software building” will describe how software vitalized the hardware production.
3.3.1.1 Hardware with large specifications 3.3.1.1.1 Raspberry Pi By the time of building the robot, Raspberry Pi 3 Model B was the latest. The headlining feature of the Pi 3 is the built-in WiFi and Bluetooth. More specifications are illustrated on Figure 9.
1. 40 Pin Extended GPIO 2. 4 USB2 Ports 3. 10/100 LAN Port 4. 3.5mm 4-pole Composite Video and Audio Jack 5. CSI Camera Port 6. Full size HDMI Video Output 7. Micro USB Power Input 8. DSI Display Import 9. Broadcom BCM2837, 64-bit Quad Core CPU, ARMv8, at 21
1.2 GHz, 1GB RAM 10. System memory 11. Micro SD Card Slot
12. Onboard Bluetooth 4.1 and WiFi
Figure 9: Raspberry Pi 3 Model B
Figure 10: Raspberry Pi 3 GPIO Pin Chart [25]
22
3.3.1.1.2 Motor Driver During the building of the robot, L293D was used and any motor driver with the same specifications can be used. L293D was used as an interface between Raspberry Pi and the motors. L293D is capable of controlling two DC motors simultaneously. The L293D is a 16 pin IC, with eight pins, on each side, dedicated to the controlling of a motor. There are 2 INPUT pins, 2 OUTPUT pins and 1 ENABLE pin for each motor. L293D consist of two H-bridge. H-bridge is the simplest circuit for controlling a low current rated motor [26]. The L293D is designed to provide bidirectional drive currents of up to 600mA at voltages from 4.5 V to 36 V. L293D is designed to drive inductive loads such as relays, solenoids, DC and bipolar stepping motors, as well as other high-current/high-voltage loads in positive-supply applications.
Each output is a complete totem-pole drive circuit, with a Darlington transistor sink and a pseudoDarlington source. Drivers are enabled in pairs, with drivers 1 and 2 enabled by 1,2EN and drivers 3 and 4 enabled by 3,4EN. The L293 and L293D are characterized for operation from 0°C to 70°C [26].
Table 2: L293D Pin characteristics [25] Pin No.
Pin Name
Pin characteristics When this is HIGH the left part of the IC will work and when it is low
1
Enable 1-2
the left part won’t work.
2
INPUT 1
When this pin is HIGH the current will flow though output 1
3
OUTPUT 1
This pin is connected to one of the terminals of motor
4
GND
Ground
5
GND
Ground
6
OUTPUT 2
This pin is connected to one of the terminals of motor
7
INPUT 2
When this pin is HIGH the current will flow though output 2
8
VCC2
This is the voltage which will be supplied to the motor
9
Enable 3-4
When this is HIGH the right part of the IC will work and when it is low the right part won’t work
10
INPUT 3
When this pin is HIGH the current will flow though output 3
11
OUTPUT 3
This pin is connected to one of the terminals of motor
12
GND
Ground
23
Pin No.
Pin Name
Pin characteristics
13
GND
Ground
14
OUTPUT 4
This pin is connected to one of the terminals of motor
15
INPUT 4
When this pin is HIGH the current will flow though output 4
16
VCC1
This is the power source to the IC. So, this pin should be supplied with 5V
a)
b)
c)
Figure 11:L293D top side view (a ) pin names (b), and its functional diagram (c)[25][26][27]
24
The full illustration of how L293D drives wheels is shown by Figure 12 along with Table 3.
Figure 12: Diagram for wheel driving
Table 3: Adding explanations to the diagram in Figure 12
To L293D
From/To
Wiring purpose
Pin 1
Raspberry Pi, Pin 7
Enabling Left Motor Drive
Pin 2
Raspberry Pi, Pin 11
Driving Left Motor Clockwise
Pin 3
Left Motor, terminal 1
Driving Left Motor Clockwise
Pin 4
Raspberry Pi, Pin 6
Ground
Pin 5
Raspberry Pi, Pin 6, Negative terminal from 4 AA Batteries
Ground
Pin 6
Left Motor, terminal 2
Driving Left Motor Counter Clockwise
Pin 7
Raspberry Pi, Pin 12
Driving Left Motor Counter Clockwise
Pin 8
Positive terminal from 4 AA Batteries
VDD for Motors 25
Color
To L293D
From/To
Wiring purpose
Pin 9
Raspberry Pi, Pin 13
Enabling Right Motor Drive
Pin 10
Raspberry Pi, Pin 15
Driving Right Motor Clockwise
Pin 10
Right Motor, terminal 1
Driving Right Motor Clockwise
Pin 12
Raspberry Pi, Pin 6
Ground
Pin 13
Raspberry Pi, Pin 6
Ground
Pin 14
Right Motor, terminal 2
Driving Right Motor Counter Clockwise
Pin 15
Raspberry Pi, Pin 16
Driving Right Motor Counter Clockwise
Pin 16
Raspberry Pi, Pin 2
VDD for L293D
Color
3.3.1.1.3 Servo Motor In the present hardware building SG90 was used and any servo motor with the same specifications can be used. The role of a servo motor in my design is to allow the programmer of the robot to controllably rotate front wheel, distance sensor and camera. SG90 Servo Motor [31] is tiny and lightweight with high output power. It can rotate approximately 180 degrees (90 in each direction), and works just like the standard kinds but smaller. You can use any servo code, hardware or library to control these servos. Good for beginners who want to make stuff move without building a motor controller with feedback & gear box, especially since it will fit in small places. Torque and PWM are the most notable parameters that I had to pay attention to.
Figure 13: SG90 Servo Motor
26
Table 4: SG90 Servo Motor wire configuration
Wire
Wire
Number
Color
1
Brown
Ground wire connected to the ground of system
2
Red
This wire powers the servo motor with approximately +5Vdc
3
Orange
PWM signal is sent through this wire to drive the servo motor
Description
Dimensions and Specifications
A (mm): 32
B (mm): 23
C (mm): 28.5
D (mm): 12
E (mm): 32
F (mm): 19.5
Speed: (s/60°): 0.1
Torque (kg-cm): 2.5
Weight(g): 14.7
Voltage: 4.8-6
Figure 14: SG90 Servo Motor dimensions
Torque at which the motor operates is the most important parameter. Torque is the tendency of a force to rotate an object about an axis. Torque is made up of two components; a load (constant) component and an acceleration component. The load torque component is usually due to friction and/or gravity and is always acting on the motor. This component can usually be determined by calculation or by putting a torque wrench on the system and reading the torque value. When the torque wrench is not able to measure, then some equations are used to calculate the approximate value. The acceleration torque however, is only acting on the motor when it is accelerating or decelerating. Once the motor is running at a constant speed as in the case of a servo motor, this component goes away.
27
As seen on equation 1, torque T is the product of the force and the distance between the force and the center of rotation. For example, to hold the force acting on the end of pulley, T = F x r. So calculating load torque is to determine the force in the system and the logical distance between the motor shaft and where the force is acting.
Equation 1: Equation of torque [32]
The torque of SG90 Servo Motor is 2.5kg/cm. This means that the motor can pull a weight of 2.5kg when it is suspended at a distance of 1cm. If the load is suspended at 0.5cm then the motor can pull a load of 5kg, and similarly the load is suspended at 2cm then the motor can pull a load of 1.25kg. In my hardware design I made sure not to act beyond the specified torque 2.5kg/cm. Table 5, Figure 15, and Figure 16 give details of SG90 Servo Motor.
Table 5: Significance of SG90 Servo Motor's torque
Position from the center of rotation
Allowed load
0.5cm
5.0kg
1.0cm
2.5kg
2.0cm
1.25kg
28
Figure 15: Torque —Position from the center of rotation versus the allowed load
Figure 16: Illustration of SG90 Servo Motor's torque
29
PWM is generated by the Raspberry Pi. Its understanding is vital in order to determine which direction to rotate the motor to.
Figure 17: Illustration of PWM
Figure 17 depicts how the PWM signal produced has a frequency of 50Hz. That means that the PWM period should is 20ms. Out of that period the ON-Time can vary from 1ms to 2ms. Table 6 shows how the servo motor position varies depending on the applied pulse signal. When the on-time is 1ms the motor will be in 0° and when 1.5ms the motor will be 90°, similarly when it is 2ms it will be 180°. So, by varying the on-time from 1ms to 2ms the motor can be controlled from 0° to 180°.
Table 6: ON-Time versus Motor position
ON-time
Motor position
1.0ms
0°
1.5ms
90°
2.0ms
180°
30
One of the applications of the servo motor in this project is controlling the front wheel. Figure 18 illustrates how the servo motor in charge of controlling the front wheel is connected to the Raspberry Pi. That servo motor has been connected to pin 29 of the Raspberry Pi.
Figure 18: How the front wheel is controlled
Similarly the PWM cable of the gripper controlling servo motor, the PWM cable of the servo motor to control the vertical rotation of the Pi Camera, and the PWM cable of the servo motor to control the horizontal rotation of the Pi Camera are connected to pin 33, pin 38, and pin 40 respectively.
3.3.1.1.4 Ultrasonic Ranging Sensor In the robot building, HC-SR04 was used and any Ultrasonic Ranging Sensor with the same specifications can be used. This is an ultrasonic ranging module that provides 2cm to 400cm noncontact measurement function. The ranging accuracy can reach to 3mm and effectual angle is < 15°. It can be powered from a 5V power supply [33]. 31
Figure 19: Ultrasonic Ranging Module HC - SR04
HC-SR04 Specifications
Working Voltage: DC 5V
Working Current: 15mA
Working Frequency: 40Hz
Max Range: 4m
Min Range: 2cm
Measuring Angle: 15 degree
Trigger Input Signal: 10µS TTL pulse
Echo Output Signal Input TTL lever signal and the range in proportion
Dimension 45 * 20 * 15mm
Figure 20 illustrates how the ultrasonic distance sensor works. The sensor’s transmitter transmits the pattern and it hits the object and reflects. The reflected source is detected and received by the sensor’s receiver. Now the time taken for the source to make a round trip is measured and by using the speed of the medium it is derived.
32
Figure 20: Working principle of the ultrasonic distance sensor [36]
The Timing diagram of HC-SR04 is shown on the figure 21. A short 10uS pulse is only needed to be supplied to the trigger input in order to start the ranging, and then the module will send out an 8 cycle burst of ultrasound at 40 kHz and then receive its echo. The Echo is a distance object that is pulse width and the range in proportion. The range is calculated through the time interval between sending trigger signal and receiving echo signal. Formula: The range = (high level time * velocity (340m/s)) ÷ 2.
Figure 21: Timing diagram [33]
Dividing the voltage of the signal reflected to the sensor’s receiver pin known as Echo is a necessary process because failing to do it can result into damaging the GPIO pins of the raspberry Pi. The operating voltage of the module is 5V while the input pin on the Raspberry Pi GPIO is only 3.3V 33
tolerant. Sending a 5V signal into 3.3V input port could damage the GPIO pins. So it is needed to solve this problem through using a voltage divider to bring the voltage from 5V down to 3.3V.
Equation 2: Voltage divider
Where Vout is 5V measured at Echo pin and Vin, 3.3V desired to input to GPIO Pin of the Raspberry Pi
Fixing R2 to 1KΩ, R1 can be Figure 22: Conceptual voltage divider
calculated.
)-1
R1 is approximted to 500 Ω 500 Ω is obtained by connecting two 1k Ω resistors in parallel because if the two resistances in parallel are of the same value, then the equivalent resistance is equal to half the value of one resistor. Figure 23: Actual voltage divider as used in robot building
Equation 2, Figure 22, and Figure 23 show how to determine which resistance to use. While building I had only 1Kilo ohms resistors. So, by fixing R2 to 1 Kilo ohms resistor the value of R1 could be obtained. It showed that it was approximately 515 ohms which is close to 500 ohms. By connecting two 1 Kilo ohms resistors in parallel, I obtained 500 ohms.
34
Figure 24: How Ultrasonic Distance Sensor is connected to the Raspberry Pi
3.3.1.1.5 Pi Camera The Raspberry Pi Camera Module is an official product from the Raspberry Pi Foundation. The original 5-megapixel model was released in 2013, and an 8-megapixel Camera Module v2 was released in 2016. For both iterations, there are visible light and infrared versions [34].
Figure 25: Pi Camera
35
Table 7: Pi Camera specifications
Specifications Still resolution Video modes
Camera Module v1 5 Megapixels 1080p30, 720p60 and 640 × 480p60/90
Linux integration C programming API Sensor Sensor resolution Sensor image area Pixel size Optical size
V4L2 driver available OpenMAX IL and others available OmniVision OV5647 2592 × 1944 pixels 3.76 × 2.74 mm 1.4 µm × 1.4 µm 1/4"
Camera Module v2 8 Megapixels 1080p30, 720p60 and 640 × 480p60/90 V4L2 driver available OpenMAX IL and others available Sony IMX219 3280 × 2464 pixels 3.68 x 2.76 mm (4.6 mm diagonal) 1.12 µm x 1.12 µm 1/4"
3.3.1.2 Hardware components with brief specifications Unlike the hardware components with large specifications that have require a profound knowledge about them in order to make the best use of them, hardware components with fewer specifications are purchased and connected immediately without necessarily being too cautious. Appendix H contains in details all the hardware components with brief specifications.
3.3.1.3 Entire Hardware Product: Benax Components described above were joined together make an entire hardware product. The shape of the production depended on both the possible arrangements of used components (taking into consideration their shapes and sizes) and my personal concept of what I think can look good to users. After the visible product was assembled, it was a big time to give it a name. I named it “Benax” after my daughter “Bena” and “x” for experience. By the time of writing this thesis my daughter Bena is 5 years old, the minimum targeted age for users of this robot. That means she will be the first young child to experience this robot, hence the name “Benax”.
36
Figure 26: Front-Right view of the produced robot
Figure 27: Top View of the produced robot
3.3.2 Software building Referring to the software design made in section 3.2.2, I started looking for the development tools to use in order to have an application working as per my design. Figure 28 illustrates the selection I made regarding the tools to use for developing the software application for the robot as shown in six connected parts. In this section I will describe the decisions and the coding involved in each of those six parts.
Figure 28: Diagram showing the languages and tools to be used in the software building
37
3.3.2.1 Command Input This is the user interface where commands can be typed and submitted. So far I have designated two media for users to type commands: Browser and Android Application. This command input is dubbed “Benax Terminal”.
Browser: Basically the interface is made up of multiline input and a submit button implemented in HTML as and respectively. The role of CSS was to improve the style of the interface and JavaScript was used to apply asynchronous connection to the robot side.
Figure 29: Command Input in a browser
Android Application: Android programming offers various methods to connect to backend. I considered the following three of them: Volley, WebView and Cordova for Android. For the best user experience I decided to use Volley and WebView altogether in the application. Both Volley and WebView can be implemented using XML and Java. Volley serves to fetch the IP Address broadcasted by the robot and passes it to WebView which is nothing more than the browser (described in the previous paragraph) embedded Android Application.
38
Figure 30: Command Input in a mobile application
The meaning of some functions met in screenshots is found in table 8. Table 8: The meaning of some functions
Function name in Kinyarwanda imbere ruhuka bisubiremo ibumoso inyuma fotora
Function mane in English
What the argument expresses
forward pause, sleep loop left reverse take picture
time in seconds time in seconds number of loops to do time in seconds time is seconds
39
3.3.2.2 Command Interpretation and Execution The part “Command Interpreter” is coded making the analogy with the usual interpreting person as in Figure 31. The person X wants to communicate to the person Z. Since they speak different languages they need a facilitator Y specifically known as interpreter. Y has knowledge on the languages of both X and Z. Y processes a limited amount of information in order to avoid dropping out some important information. Let us say X is telling Z to do something visible. What Z does will ensure X that Y got the message clearly. However, if the message from X is not clear to Z, the latter will tell what is not clear, Y will interpret it to X and the latter will make it clear.
Figure 31: Interpreting person
Similar logic of interpretation is imitated in the software design as shown on figure 32. For the sake of quick understanding a single task execution is demonstrated. “imbere” word means “forward” in Kinyarwanda. If the user wants to tell the robot to move forward for one second, s/he will access its IP address from the browser and in the given interface s/he will type “imbere(1)” then push the run button represented by a walking fingers icon. HTML, CSS, and JavaScript produces the interface
40
given to the user as previously described in the section 3.3.2.1. What happens next is illustrated in Figure 32, Figure 33, Figure 34, and Figure 35.
Figure 32: Sample of command flow implementation
According to the current development version the command interpreter is written in PHP. In next versions other languages might be used when they will be proved to offer the highest efficiency. My choice to use PHP in command interpretation originates from my background in computer programming. I have been programming in PHP since 2011.
41
Figure 33: Interpreter zoomed in
The interpreter “interpreter.php” is designed to do the following tasks:
To receive the command submitted by the user via POST method
To parse the received command.
To refer to the module “functions.py” that is a collection of functions that the robot can understand, and then select to corresponding function.
To create a file “executor.py” designed to drive the robot forward in this sample case.
To append in the created file “executor.py” the corresponding function (according to what the user submitted).
To append necessary addition functions the file “executor.py”.
To finally launch the file “executor.py”.
42
Figure 34: Module “functions” zoomed in
Figure 35: Executor zoomed in
43
3.3.2.3 Feedback handling As previously illustrated on Figure 28, the feedback flow can be thought as a reverse flow of command flow. Command flow goes from user to the robot while the feedback flow goes from robot to the user in response to the command sent by the user.
Figure 36: Picture taking is an example of a feedback flow
Figure 36 shows the example of a feedback flow. The user runs a command “fotora”. That is Kinyarwanda word meaning “Take a picture”. The command requesting the robot to take a picture is processed in a similar way as already described in section 3.3.2.2 with the only difference that one command is for moving the robot forward while another command is for taking a picture. The user needs to get a feedback as a picture. The user makes further decisions according to the picture s/he gets.
To conclude the Software Building part, it is important to notice that in the appendices are all the codes used in software building. Another point is, the way it goes with this software product it is a new programming language and has its conventional signs which are in Kinyarwanda or Kinyarwanda-like. I dubbed that new language “BenaXcript” as a portmanteau of “Benax” and “Script”.
44
3.4 Testing The next step in Agile Methodology after designing and building is testing. Throughout the development process every component added was immediately tested. That applies to both hardware and software development. And after finishing the prototype I conducted a thorough testing. But that is not the kind of testing described in this section. The ultimate testing was the testing done with targeted users that are children up to 15 years of age.
From 2018-01-27 to 2018-02-06, I conducted a test of the first prototype [37] with nine Rwandan children aged between 5 and 12 and through my observation I found answers to testing questions I had set as described in Table 9. All of the children had no prior experience with programming.
I wanted them to test hardware, software. Moreover, because this robot is being developed for personal development, I wanted to see how much confidence users would have developed at the end of one hour session. I defined the confidence in that context as “Capability to write any program to the robot without instructor’s intervention”.
3.4.1 Testing questions Table 9 describes thirteen points observed as the children tested the prototype. Table 9: Testing Questions
No
Questions
Answers
Observations and further plans Children were careful with the
Was the hardware
prototype. They didn’t have enough
fastened enough to resist 1
time to play with it. This implicates YES
rough handling of
the necessity of carrying out further
children?
tests. I just assumed it was fastened enough. The first prototype was not easy to
Is hardware assembling assemble. In the beginning I was not easy enough to be done by 2
NO
planning to allow users to assemble
children and parents on the robot. I had thought software their own? programming was enough for them. 45
No
Questions
Answers
Observations and further plans But when I started testing with children, they showed very high interests in knowing the components inside the robot, how they are connected, and their roles. In the next prototypes, easing the assembly is in priorities.
Which features do 3
Picture taking
Moving the
children use most? robot Which features do 4
Switching ON the light children use least? Which features children
5
Object gripping never attempted to use? Which features do
6
Music playing children suggest to add?
7 out of 9 children scored 100% in confidence
1 out of 9 children
How confident were
scored 75% in
children after the testing?
confidence
7
1 out of 9 children scored 0% in confidence
That brings the total confidence to 86.11% 8
How did children behave
Friendly and
46
I thought it is because they are not
No
Questions while learning
Answers enthusiastic
Observations and further plans worried of grades
programming at an open place? A group of 3 children that I gathered in a class room at certain school exhibited great How do children behave 9
while learning
competitiveness. I had not told them Competing
programming at school?
that the school was not going to consider that session. I think they were worried about grading. In my future test that behavior carefully with a larger sample.
How did children behave
I only tested that with 3 children. I Enthusiastic, Creative,
10
while learning
will need to test with a larger Open minded
programming at home?
sample.
How did children Remembered 11
I only tested that with 1 child. I will
remember what they everything learnt
need to test with a larger sample.
learned after 10 days? Parents were excited, How do parents value contributed to the 12
their children’s testing planning and programming learning? cost. Some commands to type required children to have attained a certain level of reading and writing. However, 2 of the children who What else did children
13
Reading and writing
tested the prototype had not yet
learn with this prototype? learned some required reading and writing. Because they were highly motivated to tell the robot what to do they hastily learnt it.
47
Figure 37: Prototype testing
3.5 Configuration This section describes the necessary configuration for the user to interact with the robot.
3.5.1 Apache must be installed on the Raspberry Pi In the section 3.3.2 describing the software building, PHP is used to build the interpreter. PHP runs on the top of Apache. Therefore Apache must be installed. To do so I opened the terminal and simply typed sudo apt install apache2.
48
3.5.2 PHP must be installed After installing Apache, PHP must be installed by simply typing sudo apt install php phpmbstring.
3.5.3 Apache must be added to sudoers In order to be authorized to take control of the Raspberry Pi, Apache needs to be added to sudoers. The command sudo nano /etc/sudoers opens the file of sudoers. At the end of that file, we just add www-data ALL=(ALL) NOPASSWD: ALL.
3.5.4 User pi needs ownership on the project folder Now I have a project folder “benax” but the user “pi” needs to own it. The command below will do it. sudo chown pi:pi /var/www/html/benax.
3.5.5 The project folder needs to be readable and writable Because the program will need to manipulate files inside the project folder “benax”,
user (u),
group(g) and others(o) need read and write permission. The command below will do it. sudo chmod -R ugo+rw /var/www/html/benax.
3.5.6 Device to Device (D2D) connection through Wi-Fi must be well set This is a crucial step for the sake of keeping the cost of usage as low as we can. Recent Smartphones are equipped with the technology of wireless tethering. Therefore, instead of using a router between a Smartphone and Raspberry Pi (inside the robot), the Smartphone uses its internal routing capability. This is how it happens. When wireless tethering function is enabled, the phone itself is connected to 49
its own hotspot and gets an IP Address. When any other device is connected to that Smartphone’s hotspot, let’s say the Raspberry Pi, both the Smartphone and the Raspberry Pi are in the same LAN. Now that the Smartphone and the Raspberry Pi are in the same LAN the Apache Web Server running on the Raspberry pi can be accessed via a web browser in the Smartphone as illustrated on Figure 38.
Figure 38: D2D Connection through Wi-Fi
Now comes a question: In the absence of monitor, keyboard and mouse for the Raspberry Pi, how can the user know the IP Address assigned to the raspberry pi at that moment? We are talking about a child who comes, grabs Benax robot, checks its IP Address, and opens a browser on the Smartphone to type in that IP Address. That process is a routine to start programming and it applies “where to check for the current IP Address of the robot”. Figure 39 illustrates how the Raspberry Pi communicates its IP Address. It keeps sending updates online about its IP Address as long it is connected to the internet. This implies briefly connecting the Smartphone to the Internet in order to get the current IP of the Raspberry Pi. In order to achieve that I did the following steps: 1) I created a python program “IPSpreading.py” (refer to Appendix D) to recursively read the current IP Address of the Raspberry Pi and send it on the online Web Server. 50
2) I told Raspberry Pi to run that program “IPSpreading.py” whenever it boots. I did so by opening the terminal and typing sudo nano /etc/rc.local. Then in the end of file rc.local just before exit 0 I added python3 /var/www/html/benax/ipBroadcast.py &
3) On the Online Web Server, I created a PHP program (refer to Appendix E) to receive the IP sent by the program on the Raspberry Pi and store it in the database.
4) I create a program to interface the fetching of the IP address as shown by the screenshots on the Figure 40. For the web application I used a blend of HTML, JavaScript, and PHP (refer to Appendices F and G) while for the Android App I used XML and Java as described in section 3.3.2.1.
Figure 39: IP Address spreading is the way the Raspberry Pi communicates its IP Address
3.5.6 Pairing the Raspberry Pi and the Smartphone From the previous section the required activities in order to achieve a D2D connection between the Smartphone and the Raspberry Pi were described. Did you notice a missing point? I showed you a Raspberry Pi without a mouse, without a keyboard, without a monitor. I however showed the 51
Raspberry already connected to the Wi-Fi. How did it happen? There is no magic about it. For the first time, we need to connect a monitor, a mouse, and a keyboard to the Raspberry Pi and manually connect to an available hotspot broadcast from a Smartphone (See the illustration on Figure 41). That process is called Pairing. From then onwards, if the Smartphone’s credentials remains unchanged and the settings wireless card of the Raspberry Pi remain unchanged, whenever that hotspot is enabled and visible in the proximity of that Raspberry, the connection will be automatic. What we cannot be sure of is the IP Address. It is not static so thought it might remain the same for some time, I cannot guarantee that. There is time when I tried to set that IP Address but it affected the way the Raspberry was getting updates. I decided not to keep it dynamic and resolved to the work-around described in the previous section.
a) Web Interface
b) Android Application
Figure 40: Checking the current IP Address of the robot
52
Figure 41: For every new Smartphone being paired to the Raspberry Pi is necessary
3.6 Product Releasing: next work This is the last phase in agile methodology of development. By the time of writing this thesis this phase is listed under “next work”. With agile methodology, it is possible to go through multiple sprints before releasing. Sprint is illustrated on Figure 42. In my case, I am planning to make a release after testing the second prototype. This is because, the first testing was made with a small sample and I want to be decisive based on more down-to-earth testing.
Figure 42: Sprint illustrated
53
Chapter IV Validation and implementation 4.1 Tankyu Practice One of the important things to notice in this thesis is ‘Tankyu Practice’, a method developed by Prof. Toshiki Sumitani (Professor and President at Kobe Institute of Computing, KIC, by the time of writing this thesis) for social innovation. Tankyu Practice is handy when it comes to solving social issues by utilizing ICT and human resources. Tankyu chart (Figure 43) is a well-defined method to identify issues or problems in current situation, and to propose the most possible solutions to fix those issues effectively. By the help of Tankyu Practice, whenever I had to think of my solution I had to consider its enablers in order to be realistic and to ensure the solution will be sustainable. Tankyu Chart is an at-glance summary of whatever I need to be successful.
Figure 43: Tankyu Chart of the project
54
4.2 Analysis method: Questionnaire I conducted three surveys in order to know which paths to take during this research.
4.2.1 Survey 1: Kids vis-à-vis car toys This is the first survey I conducted in this research. I sent an online questionnaire to 13 persons. They were either teachers or parents or both at the same time. Appendix I and Appendix J contain respectively questions and answers to that survey. From the responses I got from this survey I decided to build a robot similar to car toy. In nutshell, a good number of parents in Rwanda buy toys and they are happy to see their children playing with them. Children can make toys too and that is what most parents want. They prefer to see their children developing engineering skills.
4.2.2 Survey 2: Interest in robotics Appendix K and Appendix L contain respectively questions and answers to survey 2. This survey was direct and used closed-ended questioning. I target people whom I presumed they at least know what robotics is. 123 people responded. From the percentage as high as 92.7% of people who agreed they would pay to obtain skills regarding robotics I gained the confidence that it [robotics] has potential clientele in Rwanda.
4.2.3 Survey 3: Preferable coding style Appendix M and Appendix N contain respectively questions and answers to survey 3. I conducted this survey because I wanted to know which style of coding to provide to children. I had to ask 9 seasoned programmers that I know. 8 of them are Rwandan and another is Vietnamese. I asked them to compare Text-based coding to Visual-based coding and then to briefly explain about their choice. Though 66.7% is not really a distinguishable percentage I based on it to take the decision to adopt Text-Based coding style at the moment while keeping in mind that Visual-Based coding has also to be revisited. The decision I made was somehow supported by the paper To Block or not to Block, That is the Question: Students’ Perceptions of Blocks-based Programming [28] which describes three drawbacks to blocks-based programming (also known as visual-based programming). 55
4.3 SWOC Analysis 4.3.1 Strength The strengths of the robotic tool produced throughout this research project lie in its uniqueness. In Rwanda there has never been an educational robotic tool like Benax that is programmable in Kinyarwanda, assembled using improvised materials; suitable both at home and at school, requires no expertise to start using, and accessed via web browsers.
The fact that Benax is programmable in the local language takes away the difficulties related to using a foreign language and lets learners focus only on creativity.
Benax is assembled using improvised materials that children can obtain for free or at very low cost like pieces of wood and cardboard. This will have three advantages. 1) The cost of the robot will be based on core materials only, namely Raspberry Pi, sensors and actuators. 2) While playing with the robot, children will not feel limited by the panic of damaging external parts thus focusing only on creativity. 3) When some parts are damaged, loosened, or fall apart, children will be able to try mending and that is a new skill they will gain.
Benax can be used both at school and outside of school. Private schools can easily start using them in programming courses. And hopefully, Benax will be adopted to be used in public schools in the future.
Exempt of both language barrier and too much technicalities, Benax can be assembled by children along with parents under the guidance of provided videos and written manuals. It has double advantage. First, there is no need to hire experts for facilitation and that will cut off inconveniencing overheads. Second, because parents can easily assist their children to assemble, program, and to troubleshoot, parents will not freak out when children needs them on the matter.
Benax is accessed via any web browser that supports JavaScript. That takes advantage on the ubiquity of web browsers.
Text-based coding style used to program Benax was chosen by a majority of seasoned programmers who responded to my survey (Section 4.2.3) as shown on Figure 44, in addition
56
to the research of David and Uri [28] that text-based programming is more powerful, faster, lass wordy, authentic compared to blocks-based programming.
Figure 44: Code Typing vs. Visual Based Coding
4.3.2 Weaknesses Operating power is the weakness Benax is suffering. It has two sources of power. One source is rechargeable power bank that operates the Raspberry Pi while another power source is made up of 4 AA non-rechargeable batteries dedicated to only driving the wheels. Functions like taking pictures, playing audio, blinking lights, and gripping rely on the Raspberry Pi power that is from a rechargeable source. Those functions are however not the mostly liked ones. During the testing of the first prototype, it has been found out that the function mostly liked by children was driving the robot and that function will drain the non rechargeable batteries fast. If parents have to buy batteries very often they will see the robot as sucking. Two alternatives are currently possible with some side effects. 1) Using rechargeable battery to drive the wheels with the side effect that it will make the cost of the robot look enormous. 2) Connecting the robot to power supply during operation using long cables is an alternative which has side effects of making the robot unable to move free everywhere. 57
4.3.3 Opportunities Opportunities open for this research projects are the following:
Penetration of mobile devices in Rwanda [6].
Wireless tethering available in recent Smartphones opens an opportunity to bypass the need of a router and do a device-to-device (D2D) connection thus enabling cheaper yet powerful solutions.
According to Rwanda ICT Sector Strategic Plan 2018-2024, there is a limited production of local content and various incentives to increase local content creation have been promised [5].
OLPC devices are everywhere in Rwanda and both support Wi-Fi and web browsers; the only two requirements to access Benax. Though today OLPC usage is limited at school only, later it will be easy to discuss with the Ministry of Education on how to adopt Benax in public schools.
There is a support from citizens. As shown on Figure 45, 114 persons out of 123 who responded to the survey I conducted (Section 4.2.2), 92.7% admitted they are ready to pay for the solution.
Figure 45: Solution verification
58
4.3.4 Challenges SWOC and SWOT analysis differ because SWOT analysis focuses on threats. Challenges are similar to threats but have the chance of being overcome. While threats have the potential to hamper the project, challenges often already exist and need to be handled properly. The big challenge is that Benax will be judged as an ordinary toy. This project was born from a strong belief that a Rwandan child aged between 5 and 15 can start self-teaching coding through robotics after only one hour or so of introduction given that a programming language used is constructed in Kinyarwanda and the programming syntaxes are made very simple. That is what I have in mind and have demonstrated with the first prototype and with just 9 children living in the city. But it is totally different from what people will see on the market. In the shop, the robot “Benax” will be looking like any other toy or rather looking far less than other toys from advanced industries. A description of what it really is and what it can do is what will make it different and worth money. It will take months of advertising.
4.3 Benax vs. RC Toy A robot is a mechanical device that can be programmed to follow a set of instructions. A robot has a processing unit, sensors to perceive its environment, and motors to move its limbs or wheels. It may speak, make other sounds, or flash lights in response to the environment as per instructions. Many children are familiar with toys that can be remotely controlled by sending them a single command to do a single task like to move straight ahead, to turn right or left, to switch on sound or lights, and so on. A robot differs from a just remotely controlled device in that it can be sent a single command to do many tasks one after another following certain logic as per instructions. For example, a robot can be programmed to move straight and to turn left whenever it detects an obstacle with its right sensor.
59
Chapter V
Conclusion and Acknowledgement 5.1 Conclusion In a developing country like Rwanda, taking coding down to kids and into a local language while keeping the cost of it all affordable to all families regardless of their social classes is challenging but proven possible by this work though it is just the beginning. In order to reach that objective I decided to collaborate with parents first rather than the Ministry of Education.
5.1.1 Answers to research questions Throughout this study I looked for answers to six research questions raised in the beginning (refer to section 1.4). Table 10 recites the questions and answers found throughout the research.
Table 10: Answers to research questions
No
Research Questions
Answers Coding tools currently existing in Rwanda for children are OLPC laptops. I found 2 major causes of their ineffectiveness.
Curriculum: Though children start using those laptops from Why are current Primary 1, the National Curriculum places coding only from Primary 1
coding tools not 4 to Primary 6. From Primary 1 to Primary 3 and from Secondary 1 effective? to Secondary 3 children don’t learn to code. School policies: School policies forbid OLPC laptops to be taken home except for special homework. This means that children have limited time to engage with coding.
60
No
Research Questions
Answers Parents are mainly divided into 4 categories: 1) Parents who are unaware of what coding is and why children need to learn it. These parents require awareness rising first, and then the coding tools for their children. 2) Parents who are aware of what coding is but who think it is too early for children to learn coding. Like the first category, these parents require awareness rising first, and then the coding tools for
How to get parents their children. involved in the code 2
3) Parents who are aware of what coding is and who know it is learning of their children?
important for their children to learn it but who think it is the duty of schools. Like the first and the second categories, these parents require awareness rising first, and then the coding tools for their children. 4) Parents who are aware of what coding is, know it is important for their children to learn it, who think it is their duty to assist their children in code learning how to code. These parents require only coding tools for their children. So far I have not yet found out the precise answer to this question. The coding approach introduced by my research is text-based that require children to type words as instruction to the robotic tool. Children who finished Primary 1 (age 7) were able to easily code
When exactly children with text-based approach because they had learnt basic reading and 3
can start learning to writing. During prototype testing one child who had completed 3 code? years in kindergarten (age 6), just before he started Primary 1 required some coaching for prematurely teaching him basic writing and reading only targeting the characters used in the program language BenaXcript (designed during this research). How can coding which
Based on my own experience as a parent and the interviews I
is normally inflexible
conducted with 13 parents and teachers, I found out that when
be made easy for
children are playing with a toy, they want to make it autonomous.
children?
That implies that children have already a problem they want to
4
61
No
Research Questions
Answers solve. This research provides a robotic tool that is programmed to do tasks autonomously. I tested it with 9 children and they were motivated to face coding challenged as shown on the video link https://youtu.be/xdEeQtQlMHA
How to make children The answer to this question is the same as the answer given to 5
motivated to learn question 4. coding? To answer this question I investigated what makes expensive an educational robotic tool and found the possible reasons and then applied methods that lead to cost reduction: 1) The hardware materials making up the tool are expensive. Solution: Using cheap or free materials
6
How to produce a tool
2) The software that run it was developed at high cost
affordable to every
Solution: Developed the software oneself.
child?
3) To start using the tool requires a training that has to be paid for. Solution: Development of comprehensive user guide that parents can easily use to assist children. 4) To maintain the tool requires paying for mending time after time. Solution: Making the mending easily doable for parents along with children.
5.1.2 Recommendation I have two recommendations to make for this research project. One recommendation goes directly to the Ministry of Education. Though the objective of this research has nothing to do with proposing the Ministry of Education to adjust the national curriculum regarding computer programming for children, revising the curriculum to provide coding lessons from Primary 1 up to Secondary 3 is the recommendation to be considered as soon as it is possible. I understand the current national curriculum was launched in 2015. That is very recent and therefore, proposing another curriculum review this soon might not sound agreeable to the Ministry of Education. Meanwhile I resolved to think and act as an Engineer and not a policy maker, turning to parents. 62
Another recommendation goes generally to NPO’s, Government and business partners who have education in their attributions. In the table 10, the sixth research question seeks to explore all the means to reduce the cost of the robotic tool down to the capability of any parent in Rwanda. It is however important to notice that despite all the efforts made to make the robotic tool developed by this research available for every child in Rwanda, that it is a huge task requiring joined efforts.
5.1.3 Where to go from here? So far, there is no much to brag about. Benax needs some time to be tested by more children living in both cities and countryside and assess what it can really do. After that if Benax still outstands in the eyes of investors as a potential business, and in the eyes of the community as a promising solution to education; then Benax will start soaring.
Now, I created a simplistic language “BenaXcript”, given it a text-based environment “Benax Terminal” to program an educational robot “Benax” and the portal for support is open at http://yellowpages.rw/projects/benax/.
It is the first of this kind to be used in
Rwanda. I really expect that approach will shape future computer programmers but it is too soon to predict exactly how this will be done. I so far worked with 9 children that I will follow up, and I am planning to continue the study with many more children. I will need to compare it with other approaches like Scratch’s popular approach and if it succeeds many developing countries will benefit.
This project will of course be open to partnership with any individuals or organizations which wants to promote computer programming for children in their local languages and in the cheapest way as suitable to developing countries.
63
5.2 Acknowledgement It is with heartfelt gratitude that I first thank God, I believe that He has always been with me, led my path and helped me to achieve my goals.
I would also like to thank Japan Government for ABE scholarship I obtained through JICA and Rwanda Government. I am grateful for this opportunity to study at Kobe Institute of Computing.
I would like to thank many people who helped me to make this thesis a success. First, I would like to gratefully acknowledge the enthusiastic supervision of Prof. Sandor Markon, PhD, for his diligent guidance through this work.
I am grateful to all the people in different institutions who have generously spent their precious time by answering my questionnaires and offering guidance and suggestions that advanced my work.
Many thanks to KIC staff, Sakura-sha Company, friends and classmates who helped me in different ways, during internship, data collection and prototyping.
Finally, I am forever indebted to my wife Nyirahabimana Francoise, my two sons Dushime Godwill, Dushime Bright, my daughter Dushime Bena, my mother Kakuze Marie, Mr. Rugira Bernard who always taught me to go hard, and all family for love, care, understanding, endless patience and constant encouragement when it was most required. To all of you, thank you so much.
64
Bibliography
1. The Government of Rwanda (2012). Vision 2020, Revised 2012. [ONLINE] Available at: http://www.minecofin.gov.rw/fileadmin/templates/documents/NDPR/Vision_2020_.pdf. [Last Accessed 2018-06-3]. 2. The Government of Rwanda (2013). Economic Development and Poverty Reduction Strategy. [ONLINE] Available at: http://www.minecofin.gov.rw/fileadmin/templates/documents/NDPR/EDPRS_2.pdf [Last Accessed 2018-06-3]. 3. OLPC Wiki (2011). OLPC Rwanda. [ONLINE] Available at: http://wiki.laptop.org/go/Rwanda [Last Accessed 2018-06-3]. 4. John Maloney, M. Resnick (2010). The Scratch Programming Language and Environment. ACM. 5. ICT Sector Strategic Plan (2018-2024) “Towards digital enabled economy” November 2017, [ONLINE] Available at http://www.mitec.gov.rw/fileadmin/Documents/Strategy/ICT_SECTOR_STRATEGIC_PLAN_ _2018-2024_.pdf [Last Accessed 2018-06-3]. 6. https://www.gsma.com/mobileeconomy/sub-saharan-africa-2017 7. Ping Zhan, Jeffrey Hanks (2014). Forgetting Curve: Experiments on Intervals and Total Time in Recall 8. Mitchel Resnick, J.M. (2009). Scratch: Programming for Everyone. ACM. 9. Papert, S. Mindstorms: Children, Computers, and Powerful Ideas. Basic Books, 1980 10. Guzdial, M. Programming environments for novices. In S. Fincher and M. Petre (Eds.), Computer Science Education Research, 127-154. Taylor & Francis, 2004. 11. Kelleher, C., and Pausch, R. Lowering the barriers to programming: A taxonomy of programming environments and languages for novice programmers. ACM Computing Surveys, 37, 2, 83-137, 2005 12. Kelleher, C., and Pausch, R. Using Storytelling to Motivate Programming. Communications of the ACM, 50, 7, 58-64 (July 2007). 13. Kay, A. Squeak Etoys, Children, and Learning. http://www.squeakland.org/resources/articles 65
14. Resnick, M. Technologies for lifelong kindergarten. In Educational Technology Research and Development; Springer: New York, NY, USA, 1998; Volume 46, pp. 43–55. 15. Resnick, M. Computer as paint brush: Technology, play, and the creative society. In Play = Learning: How Play Motivates and Enhances Children’s Cognitive and Social-Emotional Growth; Oxford University Press: Oxford, London, UK, 2006; pp. 192–208. 16. Martin, F.G. A toolkit for learning: Technology of the MIT LEGO Robot Design Competition. In Proceedings of the Workshop on Mechatronics Education, Stanford University, Stanford, CA, USA, 21–22 July 1994; pp. 57–67. 17. Resnick, M.; Martin, F.; Sargent, R.; Silverman, B. Programmable bricks: Toys to think with. IBM Syst. J. 1996, 35, 443–452. [CrossRef] 18. Riedo, F.; Chevalier, M.; Magnenat, S.; Mondada, F. Thymio II, a robot that grows wiser with children. In Proceedings of the 2013 IEEE Workshop on Advanced Robotics and its Social Impacts (ARSO), Tokyo, Japan, 7–9 November 2013; pp. 187–193. 19. Firth, N. Code generation. New Sci. 2014, 223, 38–41. [CrossRef] 20. Tanaka, F.; Matsuzoe, S. Children teach a care-receiving robot to promote their learning: Field experiments in a classroom for vocabulary learning. J. Hum.-Robot Interact. 2012, 1. [CrossRef] 21. Gordon, M.; Rivera, E.; Ackermann, E.; Breazeal, C. Designing a relational social robot toolkit for preschool children to explore computational concepts. In Proceedings of the 14th International Conference on Interaction Design and Children, Medford, MA, USA, 21–25 June 2015; pp. 355–358. 22. Marti, P.; Iacono, I. Learning through play with a robot companion. In Proceedings of the 11th European Conference for the Advancement of Assistive Technology (AAATE), Maastricht, The Netherlands, 31 August–2 September 2011. 23. Kronreif, G.; Prazak, B.; Mina, S.; Kornfeld, M.; Meindl, M.; Furst, M. Playrob-robot-assisted playing for children with severe physical disabilities. In Proceedings of the 9th International Conference on Rehabilitation Robotics (ICORR 2005), Chicago, IL, USA, 28 June–1 July 2005; pp. 193–196. 24. Ackermann, E.K. Playthings that do things: A young kid’s incredibles! In Proceedings of the 2005 Conference on Interaction Design and Children, Boulder, CO, USA, 8–10 June 2005; pp. 1–8.
66
25. https://www.iconspng.com/image/97539/raspberry-pi-3-gpio-pin-chart-with-pi
26. http://www.instructables.com/id/L293D-Motor-Driver/
27. http://www.ti.com/product/L293D/description
28. David, W., and Uri, W. To Block or not to Block, That is the Question: Students ‘Perceptions of Blocks-based Programming. ACM, June 21 - 25, 2015, Medford, MA, USA
29. John, M., Leo, B., and Yasmin, K. Scratch: A Sneak Preview.
30. Rwanda National Curriculum, Science and Elementary Technology – Upper Primary, 2015 31. SG90
Motor
Datasheet.
[ONLINE]
available
at
http://www.ee.ic.ac.uk/pcheung/teaching/DE1_EE/stores/sg90_datasheet.pdf. [Last Accessed 2018-06-29]. 32. Oriental
Motor,
Motor
Sizing
Calculations.
[ONLINE]
http://www.orientalmotor.com/technology/motor-sizing-calculations.html.
available [Last
at
Accessed
2018-06-29]. 33. Ultrasonic
Ranging
Module
HC-SR04.
[ONLINE]
available
at
https://www.electroschematics.com/wp-content/uploads/2013/07/HCSR04-datasheet-version1.pdf. [Last Accessed 2018-06-30].
34. Pi
Camera.
[ONLINE]
available
at
https://www.raspberrypi.org/documentation/hardware/camera. [Last Accessed 2018-06-30]. 35. Linchpinseo.com/Agile Method. [ONLINE] available at https://linchpinseo.com/the-agilemethod. [Last Accessed 2018-06-30]. 36. Code Electron/HC-SR04. [ONLINE] available at http://codelectron.com/measure-distanceultrasonic-sensor-pi-hc-sr04. [Last Accessed 2018-06-30]. 37. Gabriel Baziramwabo. Video “What about programming robots in our native languages?” [ONLINE] available at https://youtu.be/xdEeQtQlMHA. [Last Accessed 2018-07-30].
67
Appendices
Appendix A: input.js $(document).ready(function(){ $('#benax-terminal-run-button').on('click', function(event){ event.preventDefault(); var codes = $('#benax-terminal-textarea').val(); if(codes == ''){ alert(":) Mbega wowe!"); $('#benax-terminal-textarea').focus(); } else if(codes == '?'){ $('#codes_form')[0].reset(); $('#benax-terminal-textarea').html("#01: imbere(how long in seconds): go straight forward.\n\n"+ "#02: inyuma(how long in seconds): go straight backward\n\n"+ "#03: iburyo(how long in seconds): turn right\n\n"+ "#04: ibumoso(how long in seconds): turn left\n\n"+ "#05: ruhuka(how long in seconds): turn left\n\n"+ "#06: bisubiremo(how many times): turn left\n\n"+ "#07: ikaramu-hasi: pencil ready to write\n\n"+ "#08: ikaramu-hejuru: release the pencil\n\n"+ "#09: kamera-ubuhagarike(position from 3 to 7): rotate camera vertically\n\n"+ "#10: kamera-ubutambike(position from 3 to 8): rotate camera horizontally\n\n"+ "#11: fotora: take picture\n\n"); } else if (codes.includes('fotora')){ $('#loadPic').show(); $('#loadPicHeader').show(); $('#closeButton').show(); $.ajax({ url:"interpreter.php", method:"POST", data:{'codes':codes},
68
beforeSend: function(){ $('#load_pic').html('Loading...'); }, success:function(data) { $('#codes_form')[0].reset(); $('#benax-terminal-run-button').show(); $('#benax-terminal-textarea').focus(); $('#last_codes').html("Last scripts, "+new Date().toLocaleString()+"
"+codes); $('#load_pic').load('loadPic.php').fadeIn("fast"); } }); }
else{ $.ajax({ url:"interpreter.php", method:"POST", data:{'codes':codes}, beforeSend: function(){ /* Do something here! */ }, success:function(data) { $('#codes_form')[0].reset(); $('#benax-terminal-run-button').show(); $('#benax-terminal-textarea').focus(); $('#last_codes').html("Last scripts, "+new Date().toLocaleString()+"
"+codes); } }); } }); dragElement(document.getElementById(("loadPic"))); function dragElement(elmnt) { var pos1 = 0, pos2 = 0, pos3 = 0, pos4 = 0; if (document.getElementById(elmnt.id + "Header")) { /* if present, the header is where you move the DIV from:*/
69
document.getElementById(elmnt.id + "Header").onmousedown = dragMouseDown; } else { /* otherwise, move the DIV from anywhere inside the DIV:*/ elmnt.onmousedown = dragMouseDown; } function dragMouseDown(e) { e = e || window.event; // get the mouse cursor position at startup: pos3 = e.clientX; pos4 = e.clientY; document.onmouseup = closeDragElement; // call a function whenever the cursor moves: document.onmousemove = elementDrag; } function elementDrag(e) { e = e || window.event; // calculate the new cursor position: pos1 = pos3 - e.clientX; pos2 = pos4 - e.clientY; pos3 = e.clientX; pos4 = e.clientY; // set the element's new position: elmnt.style.top = (elmnt.offsetTop - pos2) + "px"; elmnt.style.left = (elmnt.offsetLeft - pos1) + "px"; } function closeDragElement() { /* stop moving when mouse button is released:*/ document.onmouseup = null; document.onmousemove = null; } } }); function hideAllThis(){ $('#load_pic').html(''); $('#loadPicHeader').hide(); location.reload(); }
70
Appendix B: interpreter.php
