PRE2024 1 Group1:

Group members

Name	Student Number	Study
Naomi Han	0986672	CS
Gijs Kruize	1656882	CS
Tom de Leeuw	1893904	PT
Morgan van Tilburg	1557947	EE

Problem statement

With the rapid growth in all kinds of technological fields, such as AI and engineering in cars, there is a large shortage of people with a career in technology. A lot of young people do not choose for a career in technology. This is partially because there is no proper introduction to technology in the education of young children.

Users/Stakeholders

There are several stakeholders for the end product of this project. The children that will interact with the simplified programming language are the first major stakeholder. Further, there are the parents of the children, as well as the teachers. Another important stakeholder are technical universities and large tech companies. Lastly there is the education system.  

The children

The primary user of this technology are the children that use the product. They will need a safe and challenging learning environment for them to engage in. The product has to be interesting and fun for them, so they will pay attention to the subjects that are taught. On top of that, the product should be at a level that they can understand. The primary goal of the product is to give the children a gentile introduction to the world of programming and robotics.  

The parents

The most important aspect of the product for the parents is that their children are safe. The children should not be exposed to dangerous elements in the product, such as small parts, lose wires and fast spinning motors they can get stuck in. Further, when there is an online environment in the product, their children's data should be stored in a safe space, so their data is not all over the internet. The second most important thing for the parents is that their children are actually learning something, and they get their money’s worth.

Teachers

The product should be easily integrated into the existing educational program, in order to reduce the amount of work for the teachers. Further, the product should be engaging for the student and have different difficulty levels to fulfill the individual needs of every student. On top of that, the product should be intuitive to understand for the teachers so they can answer possible questions that the students may have. This can be achieved by making a teacher’s guide that explains the program in detail.  

Technical universities and large tech companies

The program is meant to encourage young children to pick a technological career path. This is done by introducing them to technology and its many different aspects at an early age. Technical universities and large tech companies have a major interest in the possible outcome of this project, since they are the ones who benefit the most.  

Educational system

The educational system is the main stakeholder that decides if the product is suited for the current educational program.  Again, the project should be easily integrated into the exiting educational format. Also for this stakeholder, the product has to be properly tested on classes in an ethically correct environment.

Overview of existing resources for early childhood robotics education

Programming languages for kids

There are all different types of programming languages catered to children. In these programming languages we can make the distention between text based programming languages and block based programming languages.

Block based programming languages

A block based programming language is a of visual programming by using blocks. These coding blocks can be dragged and dropped after each other to create a program. The absence of written code eliminates any syntax errors from arising. The visual aspect of this teaching method makes it especially suitable for young children. Scratch and Blockly are some of the most populair programming languages of this type, but there are also other such as Tynker a website that contains games, blockbased programming and text based programming languages all in the same interface, trying to engage children by presenting it as a game.  

Text based programming languages

There are also a lot of text based programming languages for children. There are both text based languages specially made for children as well as normal programming languages with tutorials for children. With the latter, the main issue for educating children is the language barrier. Since nearly all programming languages are in English, there is a language barrier for children who do not master English to a sufficient level. In the Netherlands only in 1.6% of the households English is the primarily spoken language, therefor this is not a viable option for most preschool children. However, the programming languages for children such as Hedy are often translated in many different languages. This in combination with lessons catered specifically aimed at children, leads to a higher popularity amongst the texted based programming languages for children.  

Robots for children

Sequential robots

A type of robots made for children from ages 5-8 years are sequential robot. These robots do not need any code from the children, but make use of buttons. Once these buttons are pressed in a specific order, the robot will move according to the defined sequence. Some examples of these types of robot are BEE-bot and Code & Go Programmable Robot Mouse

Arduino based robots

There are multiple robots such as mBot  which are Arduino based. These are easy to assemble and are often programmed using block based languages like Scratch. The usage of Arduino chips, allows the robots to be relatively cheap. These Arduino’s make them also more fragile for young kids than other alternatives on the market.

Robotic LEGO

The toycompany LEGO has developed 2 different lines of robotic LEGO, LEGO Spike and the Lego Mindstorms. The first one is created for educational use with builds for all different age groups, whereas the second is mainly for personal use. Both series allow you to build your robot and program it using block based programming. LEGO differentiates itself from other robots due to being easily build and reusable multiple times. These products allow the children to learn more about both the coding of the robots, as well as the building.

Our research

A lot of research and products are already available for teaching robotics. There are both a lot of programming languages and robot types for many different age groups. We noticed however that there are no robots for preschoolers that can be programmed using text based programming languages. All programmable robots we have found are programmed using block based code, such as the Robitic Lego, or not programmable by code at al, such as the sequential robots.

Research Question

How does a physical debugging-first approach to coding robots compare to a bottom-up coding approach in terms of students' problem-solving skills and code comprehension?

Test Plan

In this study, students will be divided into two groups, each using a different method to learn how to program robots.

Group 1: Physical Debugging-First Approach

Students in this group will start with incomplete or faulty code. They will:

• Run the robot and observe its behavior to identify what is going wrong.
• Physically debug by adjusting the code based on what they see happening with the robot (e.g., the robot moving in the wrong direction, not picking up objects, etc.).
• Over time, they will progress from fixing small issues to writing more substantial parts of the program themselves. However, they will always start by observing and debugging the robot's physical actions.

This approach emphasizes connecting the robot’s real-world behavior with code changes, helping students develop problem-solving skills by learning how their code affects the robot directly.

Group 2: Bottom-Up Coding Approach

This group will begin by writing code from scratch. Students will:

• Start with simple robot tasks (e.g., making the robot move in a straight line).
• Gradually build up complexity as they master each function, moving from basic actions to more complex behaviors like turning, grabbing objects, and avoiding obstacles.
• Continue building layer by layer until they can write programs to complete complex challenges.

This method focuses on systematically developing coding skills by starting from basic robot control and gradually adding more complexity to their programs.

Comparative Test Process

To compare the effectiveness of these approaches, students will go through several iterations of practice tasks followed by a standardized exam task.

1. Practice Tasks: Each group will work on three tasks using their assigned method—either physical debugging or bottom-up coding. These tasks will vary in difficulty but are designed to reinforce the core learning technique of each group.
2. Exam Tasks: After completing the three practice tasks, both groups will be given the same exam task. This task will be presented without any additional guidance or code aids. The exam task will require both groups to use the robot to complete a challenge, but without the specific support from their previous method (e.g., no pre-written code for the debugging group or no step-by-step build-up for the coding group).

This process will be repeated in several cycles: three practice tasks followed by one exam task. By doing this multiple times, we will collect enough data to compare how both groups perform.

Metrics for Comparison

To evaluate the two approaches, we will focus on the following key metrics:

• Number of attempts per exam task: How many tries does each group need to successfully complete the exam task?
• Time taken: How long does each group take to solve the exam task?
• Quality of the final solution: How accurate and efficient is the program they write for the robot?
• Learning progression: How do both groups improve over time? Are they able to solve exam tasks faster and with fewer attempts as they progress?

Goal of the Study

The comparison will help us determine which method—physical debugging-first or bottom-up coding—leads to better outcomes in terms of problem-solving, code comprehension, and robot control. By tracking how both groups perform on exam tasks, we will see which approach develops stronger programming and debugging skills in students learning to control robots.

Hypothesis

Debugging is a vital part of coding. The traditional approach to learning to code is to learn the syntax and basic programming first and how to debug later. However, by focusing on debugging earlier or even in the beginning of the learning process, coding novices can get a deeper understanding of the coding process and language they are writing in. Furthermore, they can build their coding and problem solving skills more effectively according to Lowe, 2019. On top of that, the robot is a form of visual debugging, which can help promote experimentation and improve debugging in general (Grimm, 2002). The test group that has to debug can practice longer with the visual debugging then the bottom-up group, so all benefits for visual debugging might apply more to them. Since both test groups will have to debug if they make a mistake in the final assignments, it is expected that the group that immediately starts debugging will have an edge both in problem solving skills and in code comprehension.

Final Product

Our final product will consist of a teaching package designed as an introductory course consisting of 2 to 3 lessons that integrate an online coding environment, a physical robot, and a comprehensive teacher manual. The curriculum will use a simplified text-based programming language, rather than a block-based one, to offer a more authentic coding experience. To make the learning process approachable for beginners, the language will include predefined functions that will gradually become less predefined in each lesson, encouraging students to take on more coding responsibilities. Each lesson will focus on key skills such as debugging, completing existing code, and writing code independently.

The inclusion of a physical robot is a deliberate choice, as it provides a tangible way to visualize the code's impact, making abstract concepts more accessible. This hands-on approach also serves as an effective method for students to learn debugging by observing the robot’s actions and correcting their code accordingly. Additionally, we will develop a coding manual tailored to the needs of teachers, particularly those who may not be familiar with coding. The manual will include clear, step-by-step instructions and explanations to ensure that teachers can confidently guide their students through the lessons.

Design

The curriculum is designed according to the following MoSCoW criteria:

Must Have  

• A physical robot to keep kid’s attention  

• A Hedy like language as introductory programming language  

• Teacher manual about the languages used, the basics of programming  

• The teaching package must be affordable for schools, since not all schools have large budgets for this  

• Learning steps from Physical debugging, to filling in pre-defined functions, to writing own  

Should Have  

• A classical part to the lessons where the coding and robotics principles are explained, and group-based challenges where the groups work on challenges to make the robot do stuff.  

• Adaptive challenges based on the level of the students, if a group does well it should get harder challenges do not rush through the existing challenges  

• An interactive digital learning environment where the explanations are given, and the programs are written  

• The teaching package should emphasize how the robot running the program is being used in the real world, and thus show the importance of it. So, linking some challenges in the teaching program to a real-world problem that could be solved with the robot.  

Could Have  

• Integration with other subjects (like spelling and math)  

• Translation courses for Dutch programming to English programming as a good transition to real programming languages.  

• Teachers can create their own functions to diversify their class  

• Play/playground functions(?)  

• Wireless communications with the robot  

Wont have  

• Block based  

• Too much preparation time for the teacher  

The robot

Robot used for this project.

For the robots, robots of the old curriculum DBL Venus Exploration course are borrowed. These have some flaws and thus need to be debugged before usage. The robot is equipped with servos for the wheels, encoders on those wheels, a gripper to grab items and an ultrasound sensor to detect obstacles in front of it. It has an Arduino Uno on it. It originally also comes with a ZigBee wireless communication module, but this one will not be used for this project since it only makes communication between robots possible and not with the computer.

Next to this existing robot, we would like to add a Bluetooth module to the robot so it can be wirelessly updated with the code. For this we are looking into the Bluetooth HC-05 module RF transceiver Master en Slave that can be bought for €11,- at TinyTronics, a local electronics store in Eindhoven. With this module it would be possible to upload the code wirelessly. This would decrease the waiting time for the children since they are not allowed to plug in the robot themselves.

With all this equipment the robot can do the following things: Drive forward, make turns (left, right, at certain degrees), stop, detect objects in front of it, grab objects, place objects back.

The web interface

For the web interface we have created for the student is grouped by subject.

We have two different interfaces for each of the testgroups with the same style and lay-out. To appease to the age-group we have tried to make the design suited for children by incorporating vibrant colors, minimizing empty space and making most objects rounded, while still being suitable for educational settings by keeping the collors, although vibrant still in the same collor pallet and making the patterns repatative. The design is kept simple and intuitive, both for students and teachers.

Teaching plan

For the lessons that are given are given by the following lesson plan.

MEER INFO TE KOPIEREN VANUIT HET LESPLAN

Teaching plan debugging class

Research methods

Finding a place to test:

We sent the following email to elementary schools in Eindhoven, of which we already got multiple enthusiastic replies:

Onderwerp: Samenwerking voor Techniekworkshop op uw Basisschool

Geachte [Naam van school],

Wij zijn vier enthousiaste studenten van de Technische Universiteit Eindhoven en wij willen graag uw basisschool benaderen met een uniek en educatief aanbod. Ons doel is om kinderen te enthousiasmeren voor techniek door middel van een interactieve en leuke workshop.

Wij stellen voor om een middag op uw school te komen en de leerlingen in groepjes te leren programmeren met behulp van een kleine robot. Deze activiteit is ontworpen om de creativiteit en probleemoplossende vaardigheden van de kinderen te stimuleren, terwijl ze op een speelse manier kennismaken met de basisprincipes van programmeren en technologie. De kinderen hebben geen voorkennis nodig over programmeren. We richten ons op kinderen tussen de 9 en 12 jaar.

Wij zorgen voor alle benodigde materialen en begeleiding, zodat de leerkrachten zich geen zorgen hoeven te maken over de organisatie. Het enige wat wij vragen is eenmalig een middag van uw tijd en de enthousiaste deelname van de leerlingen. Zou dit mogelijk zijn in week 41 of 42?

Wij geloven dat deze workshop een waardevolle aanvulling kan zijn op het huidige curriculum en een inspirerende ervaring voor de kinderen zal bieden. Wij hopen dan ook dat u openstaat voor deze samenwerking.

Graag horen wij van u of u geïnteresseerd bent in dit initiatief en of we een afspraak kunnen maken om de details verder te bespreken.

Met vriendelijke groet,

Survey

The survey is designed according to the MCC Survey Guidelines. Further it is adjusted to suit the target group, in this case children between the ages of 9-12. This means that language is simplified and more images are added in order to make the questions clearer to understand. Also the same question is asked multiple times with different phrasings, in order to prevent ambiguous question biases. The questions are in a random order to prevent question order bias.

Project Planning

During the first week the focus has been preliminary research into robotics education on preschools.  

In the second week we delved deeper into similar existing resources for early childhood robotics education and formulated our research question, defined the requirements for the design of our teaching package, and created a schedule for our research and finalized the ERB and consent forms.  

In the third week of our research we are going to decide on our test group, program several predefined functions and start on the frontend the preschool students are going to use. Aside from that we are also going to send out surveils to students of the PABO in Tilburg, such that we can incorporate any feedback they have.

In the fourth week the implementation of the link between the GUI and the robot shall be established.

In the 6^th week of our research we will finalize the teaching environment and finish the questionnaires for the participants of the study and their caregiverst/parents.

In the beginning of the 7^th week we will carry out our lessons for our target group and proccess all the data.

In the last week of our research we will present our findings.

Lessonplan

The lesonplans are created in by the template Lesvoorbereidingsformulier vakdidactiek fysica KU Leuven by Nils van Dessel. This lessonplan is in Dutch, therefor the following paragraph is also in Dutch.

Identificatiegegevens

Naam: Naomi Han, Gijs Kruize, Tom de Leeuw, Morgan van Til- burg	Start op: 10:30	Duur: 1.5 uur	School: Basisschool Rapenland
Schooltype: Basis onderwijs	Lokaal: Klaslokaal met Digibord	Aantal lln.: 24	Graad, jaar en studierichting: Groep 7

Lesgegevens

Schoolvak:	Roboticales()
Lesonderwerp:	Robot programeren met behulp van versimpelde codeertaal
Leerplannummer en onderwijskoepel:	De leerlingen zullen door middel van debuggen leren hoe ze zelf code kunnen schrijven.
Gevolgd leerboek:	n.v.t.
Andere bronnen:	Digitale leeromgeving waar de leeringen in zullen programmeren.
Bijlagen bij de lesvoorbereiding:	Github: , wiki: https://dsdwiki.wtb.tue.nl/wiki/PRE2024 1 Group1:

Verwachte voorkennis bij de leerlingen

 Er is geen voorkennis. De school heeft aangegeven geen robotica te geven in hun techniek curriculum

Situering in lessenreeks

Dit is een individuele gastles.

Andere aspecten van de beginsituatie

(organisatie van het leslokaal, aard van en/of diversiteit in de klasgroep, attitudes, andere aspecten die om aandacht vragen en/of van belang zijn voor het lesverloop)

 De leerlingen hebben eerst pauze. De kinderen zullen van tevoren verteld zijn over deze gastles. Het klaslokaal zal van tevoren opgezet worden, waarna de kinderen daarna pas binnen komen. De leerlingen zullen in groepjes gaan zitten. Elk groepje bestaat uit 4 of 5 kinderen, waarbij gestreefd wordt om zo veel mogelijk groepen van 4 te vormen.

Benodigdheden en materiaal

(Voorbereiding voor aanvang van de les, veiligheidsvoorzieningen, didactisch materiaal...)

Elk groepje zal een laptop nodig hebben die al van tevoren is ingesteld. Daarnaast heeft elk groepje een robot tot zijn beschikking, met een parcours uitgeprint op papier met kartonnen obstakels. Elk groepje heeft ook hulpbladen voor het programeren tot zijn beschikking.

Lesindeling

Onderdeel	Duur	Rol van de leraar	Media	Onderwijsactiviteit leerkracht Werkvormen en didactische principes	Leeractiviteit leerlingen (Bij voorkeur niveau Bloom en aspecten CD aangeven)
Lesopening	10:30- 10:35	Gastheer	geen	De klas tot rust roepen en de aandacht vragen	Plaats nemen en stil zijn.
Introductie	10:35- 10:40	Presentator	Whitebord/ beamer	Toelichten onderwerp, tevens enthousiasmeren	Actief meedoen in conversatie.
Theorie robot	10:40- 10:45	Didacticus	Whitebord/ beamer	Algemene uitleg over de robot geven	Aandachtig luisteren
Theorie fout op- sporingscyclus	10:45- 10:50	Didacticus	Whitebord/ beamer	Uitleg geven over debuggen aan de hand van de foutopsporingscyclus	Aandachtig luisteren, meeschrijven op werkblad foutopsporingscyclus
Debug-opdracht 1	10:50- 11:00	Didacticus/ Pedagoog	Robot, laptop	Rondlopen, vragen beantwoorden, leerlingen helpen bij het doorlopen van de foutopsporings- cyclus.	In groepsverband ”opdracht 1 Bewegen” maken
Eind-opdracht 1	11:00- 11:15	Didacticus/ Pedagoog	Robot, laptop	Rondlopen, vragen beantwoorden, leerlingen ondersteunen bij het leerproces.	In groepsverband ”opdracht 1 Parcours” maken
Omschakelen	11:20- 11:25	Presentator	geen	Klasikaal terug de aandacht pakken. Volgende opdracht introduceren	Aandachtig luisteren
Debug-opdracht 2	11:25- 11:35	Didacticus/ Pedagoog	Robot, laptop	Rondlopen, vragen beantwoorden, leerlingen helpen bij het doorlopen van de foutopsporings- cyclus.	In groepsverband ”opdracht 2 Obstakel ”
Eindopdracht 2	11:35- 11:50	Didacticus/ Pedagoog	Robot, laptop	Rondlopen, vragen beantwoorden, leerlingen helpen bij het doorlopen van de foutopsporings- cyclus.	In groepsverband ”opdracht 3 Wegversperring”
Afsluiting	11:50- 12:00	Afsluiter	geen	De lesstof afsluiten, herhalen wat we vandaag hebben gedaan en enquites uitdelen	Enquites maken

Visualisering van de inhoud en structuur van de les. Voeg een bordschema toe als dat relevant is.

(Indien specifiek van toepassing. Vaak zullen deze elementen opgenomen zijn in de bijgevoegde presentatie.)

Er zal een powerpoint en werkbladen worden gedeeld. Verder is er een parcours voor de robot op A1 formaat voor elk groepje.

Evaluatie

(Hoe wordt de onderzoeksvraag en hypothese beantwoord. Op welke manier worden gegevens voor het onderzoek verzameld?)

Aan het einde van de les zullen enquites worden uitgedeeld over hun ervaringen met de gastles. Er zullen ook observaties worden uitgevoerd, tijdens de les.

Research papers

An Evaluation Framework and Comparative Analysis of the Widely Used First Programming Languages

This paper looks at a framework to assess the suitability of widely used first programming languages (FPLs), where they consider both technical and environmental factors. This study doesn’t find a perfect language that meets all their criteria. Their framework, however, can guide educators in making an informed decision about which FPL to pick.

Non-Native English Speakers Learning Computer Programming: Barriers, Desires, and Design Opportunities

In this paper, the challenges of non-native English speakers in learning computer programming are described. They found that non-native English speakers struggle with reading and writing code, understanding technical materials, and simultaneously learning both English and programming. The paper recommends that a learner-centred approach be taken for these non-native speakers. This should incorporate bilingual programming tools, more visual aids, culturally neutral examples and simplified English.

Teaching Coding to Children: A Methodology for Kids 5+

This paper talks about teaching kids how to code and which parts of coding are essential to learn first. There are already methods for learning kids programming like Scratch and Tynkers but these would lack comprehensive methodologies for effectively teaching fundamental coding concepts. The paper suggest to start the learning process with algorithms, loops and if-conditionals.

Transitioning from Block-Based to Text-Based Programming Languages

This paper looks at what happens at the switch from block-based programming to text-based programming languages. It describes how block-based languages lower the barrier to learning programming since they eliminate syntax complexities. Transitioning from a block-based language to a text-based language comes with challenges like reduced confidence and incorrect programming habits. Which in return might discourage students from using syntax-heavy languages.  They would recommend letting block-based programming languages have a form of automatic syntax placement so it would automatically teach syntax.

Visual programming languages integrated across the curriculum in elementary school: A two year case study using “Scratch” in five schools

This study follows 107 primary school students using a programming language called Scratch for 2 years. This research demonstrates that the implementation of creative computing showed that using a visual programming language (VPL) actively improves a student’s grasp of programming concepts, logic, and computational practices. It highlights that students effectively learned about sequences, loops, parallelism, and events in programming.

Programming experience promotes higher STEM motivation among first-grade girls

In this paper demonstrates that early exposure to programming can significantly boost girls interest in tecnology-related fields like computer science and engineering. The study found that only a brief experience with programming robots reduced the gender gap in technology motivation. It however didn't alter existing gender stereotypes about programming and robotics.  

The Effects of Gender Role Stereotypes in Digital Learning Games on Motivation for STEM Achievement

This study investigated how different gender depictions of a scientist in digital learning games affect STEM-based learning motivations among various age groups. It found that younger children were more affected by the traditional view of scientists, very masculine men and less feminine women. Older children were influenced more by the sex of the scientist. According to the study, personalising characters in these games might help lessen the impact of these stereotypes while also increasing interest in STEM disciplines among kids from diverse backgrounds.

Debugging behaviors of early childhood teacher candidates with or without scaffolding

This study has looked at the how preschool teachers learn how to code with and without the scaffolding method. The scaffolding method is a teaching strategy where support is provide and slowly decreased the further in education goes. In this research the group taught via scaffolding, were using a hypothesis based approach in the debugging, where when stuck, the participants of the study had to form 3 possible hypotheses of why the code was not running. Besides having to try to answer these questions, the instructors were less quick to help out these participants. In the second test group without scaffolding, the participants where not asked to formulate hypotheses for why the code was not running and where given more direct solutions from the instructors while stuck. The research showed that the first group with scaffolding methods, tried for longer to fix their code and gave up less quickly. Even though the research was quite interesting and a good possibility to use going forward, it is important to note that the entire test group was rather small and did also have 2/18 participants with prior knowledge of coding.

Developing preschool children’s computational thinking with educational robotics: the role of cognitive differences and scaffolding   

In this paper, the researchers used aa BEE-Bot to test different teaching strategies in robotic teachings. They looked at the impact of two different scaffolding methods on both field dependent (FD) and field independent (FI) students. The participants where divided amongst 3 groups. Two of the groups where using scaffolding methods and a third control group. Each group had a equal distribution of both FI and FD students. While there was not much difference noted between the two different scaffolding groups, both groups performed better than the control groups while using the scaffolding aids. When these aids where removed, there was not much difference between the FI students of the scaffolding groups or the control group. The FD students of the scaffolding groups did much worse than the FD students after the aid was removed.

“CREA”: An Inquiry-Based Methodology to Teach Robotics to Children

This paper is about the CREA-methodology, an inquiry-based approach to teaching programming and robotics to children. It focusses on hands-on activities with visual programming tools like Visualino and was tested on an international primairy school in Barcelona. CREA consists of six sessions where students observe, analyze, and program robots, promoting problem-solving, teamwork, and creativity. Although some found Arduino’s syntax challenging, most appreciated the discovery-based learning and collaborative nature of the sessions. The paper has shown that this method increases the understanding from the children.

Hours log

Week 1

Who	What	Hours
Gijs	Research (2h), Meetings&Lecture(2+2h)	6
Morgan	Research (9h), Meetings&Lecture(2+2h)	13
Naomi	Research (7h), Meetings&Lecture(2+2h), Administrative(0.5h)	11.5
Tom	Research (7h), Meetings&Lecture(2+2h)	11

Week 2

Who	What	Hours
Gijs	Research (3h), Writing out final product (1h), Testplan (1h) , Research on software systems (2h) Meetings(1+4h)	12
Morgan	Research (4), Meetings(1+4h), talking to teachers(1h), final product(1h), Arranging Robots(1h)	12
Naomi	Research (5.5h), Meetings(0.5+4h), Consent forms + ERB (3h), Wiki (3h), Working out research plan (2h)	18
Tom	Research (4h), Meetings(1+4h), wiki (1.5h), planning (2h)	12.5

Week 3

Who	What	Hours
Gijs	Meetings(1+4h), Setting up backend env local (3h), setting up frontend env local (1.5h), research in systems (3.5h)	13
Morgan	Meetings(1+4h), making and researching pre-defined functions(4h), writing email to elementary schools(0.5h), editing wiki (0.5h)	10
Naomi	Meetings (1+4h), wiki +research (3h) (ill since weekend)	8
Tom	Meetings (1+4h), wiki + research (1h), contact with schools (3h)	9

Week 4

Who	What	Hours
Gijs	Meetings(1+4h), Software research (1.5h), programming (2.5h)	9
Morgan	Meetings(1+4h+0.5), debugging physical robot (3h), writing pre-defined functions (4h), researching wireless transfer of program and the items (1h)	13.5
Naomi	Meetings(1+4+0.5+0.5h) + enquite (1h) (still ill during the week)	6
Tom	Meetings(1+4+0,5h) + contact with schools (2h)	7,5

Week 5

Who	What	Hours
Gijs	Meetings(1+4h), Software research (1.5h), programming (2.5h)	10
Morgan	Meetings(1h+4h+2h)+ writing more pre-define functions (2h) +starting on connecting wireless transfer (1h)	10
Naomi	Meetings(1+4+2h) + Frontend (8h) + enquites(1h) + Wiki (nog te doen voor deadline deze week)	16
Tom	Meetings(1+4+2h) + contact with school (1h) + creating new research questions (1h) + research (1h)	10