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

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.

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.

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?

Hypothesis

Debugging is a crucial aspect of coding. Traditionally, coding education begins with learning syntax and basic programming concepts, with debugging introduced later. However, emphasizing debugging from the outset can provide coding novices with a deeper understanding of the coding process and the language they are using. This approach can also enhance their coding and problem-solving skills more effectively (Lowe, 2019). Additionally, using a robot for visual debugging can encourage experimentation and improve overall debugging skills (Grimm, 2002).

Our hypothesis is that the debug group will, on average, complete one more exercise than the bottom-up approach group, as we expect them to be faster. The test group focusing on debugging will have more practice with visual debugging compared to the bottom-up group, potentially reaping greater benefits. Since both groups will need to debug errors in the final assignments, we anticipate that the group starting with debugging will have an advantage in problem-solving skills and code comprehension.

This hypothesis will be tested through surveys and classroom observations. The results will undergo statistical analysis to determine their significance, complemented by qualitative research analysis of the observations to form a comprehensive conclusion.

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?

Getting 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,

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.

Final Product / Research

Our final product is a comprehensive teaching package designed to introduce students to coding. It includes a 20-minute presentation on the fascinating aspects of coding and a brief introduction to debugging. The package features a robot programmed using Arduino © and an online coding environment where students can practice their coding skills and track their progress.

The code written in the online environment closely mirrors what is implemented in Arduino, providing a seamless learning experience. To aid in the learning process, we included predefined functions that students could use. These functions were particularly useful for teaching coding in Dutch, making the material more accessible.

Although we did not create a formal lesson plan, the project effectively integrates hands-on learning with theoretical knowledge. The robot provides a tangible way for students to see the impact of their code, making abstract concepts more accessible. This approach also helps students learn debugging by observing the robot’s actions and making necessary corrections to their code.

The online coding environment was crucial for researchers to track the students’ progress, although this aspect was not of great importance to the children themselves.

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.

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  

Enquête: Lespakketten voor Robotica in het Basisonderwijs

To design the curriculum, we have also sent out a questionnaire to obtain insights from the future teachers, as they can give is unique insights from an educational point of view. Since these participants were al members of the PABO study, the questionnaire was conducted in Dutch. The questionnaire was made in MS Forms and the responses are anonymous. Only the first question has been made manditory, in which the students agrees to have read and accepted the terms in the consentform. The suggestions and feedback from the enquête has been incorporated in the design of the lessonplan.

Enquête: Lespakketten voor Robotica in het Basisonderwijs

Beste student, In het kader van ons onderzoek zijn wij benieuwd naar jouw mening over het ontwerp: lespakketen voor robotica in het basisonderwijs. Jouw feedback draagt bij aan ons onderzoek en helpt bij het ontwikkelen van een educatief, inspirerend en effectief lespakket.

Vul de enquête in en deel jouw ideeën en inzichten met ons. Alvast hartelijk dank voor je deelname aan dit onderzoek

1. Door deel te nemen aan deze enquete verklaar ik het Consent form te hebben gelezen en hiermee akkoord te gaan.

Deze is te vinden op:https://tuenl-my.sharepoint.com/personal/n_s_han_tue_nl1/_layouts/15/onedrive.aspx?id=%2Fpersonal%2Fn%5Fs%5Fhan%5Ftue%5Fnl1%2FDocuments%2F0LAUK0%20%2D%20USE%20%2D%20Robots%20everywhere%20project%2FFormulieren%20en%20communicatie%2FConsentFormPabo%2Epdf&parent=%2Fpersonal%2Fn%5Fs%5Fhan%5Ftue%5Fnl1%2FDocuments%2F0LAUK0%20%2D%20USE%20%2D%20Robots%20everywhere%20project%2FFormulieren%20en%20communicatie&ga=1

Verplichte bevestigingInformatie over de Lespakketten

In dit onderzoek willen we jouw mening vragen over twee verschillende lespakketten voor robotica-onderwijs in het basisonderwijs. In beide lespakketten zullen de leerlingen samenwerken in groepjes en zullen ze code schrijven in een versimpelde programmeertaal. Deze code zullen ze vervolgens naar de robots kunnen uploaden.

Lespakket A: In dit lespakket leren leerlingen de basis van programmeren op een gestructureerde manier, met duidelijke instructies voorafgaand aan het zelfstandig schrijven van code. Dit pakket biedt een traditionele leerbenadering waarbij leerlingen eerst grondig worden begeleid door uitleg en voorbeelden, voordat ze zelf aan de slag gaan met het programmeren van hun eigen oplossingen.

Lespakket B: In dit lespakket zullen leerlingen op een unieke manier om te leren programmeren door zich te richten op één van de belangrijkste vaardigheden in softwareontwikkeling: debuggen. In plaats van alleen maar code te schrijven, leren leerlingen hoe ze bestaande, foutieve code kunnen analyseren, fouten kunnen vinden en deze effectief kunnen oplossen.Vragen over lespakket A

An enquête to require other insights from an educational point of view about our curriculum.

2. Wat vind je van het idee van dit lespakket in het algemeen? Denk je dat een traditionele manier van uitleg en opgaves maken goed aansluit bij de behoeften van leerlingen in het basisonderwijs?

1 (helemaal niet geschikt) tot 5 (Zeergeschikt)3. Wat vind je van het idee van dit lespakket voor Robotica lessen specifiek? Denk je dat het goed aansluit bij de behoeften van leerlingen in het basisonderwijs?

1 (helemaal niet geschikt) tot 5 (Zeergeschikt)4. Hoe lang zouden de theorie uitleg voor elk onderwerp moeten zijn in pakket A. (Traditioneel lesplan)

Meerkeuze: 5 min, 10 min, 15 min, anders namelijk ....5. Wat verwacht je dat de grootste voordelen zijn van dit lespakket?

Open vraag6. Wat verwacht je dat de grootste nadelen zijn van dit lespakket?

Open vraag7. Heb je nog adviezen voor het opstellen van dit lessenplan?

Open vraag

Vragen over lespakket B

De volgende vragen zullen gericht zijn op het lespakket waarbij de leerlingen leren programeren door middel van debuggen.

8. Wat vind je van het idee om leerlingen te laten leren door het verbeteren van vooraf gegeven foutieve antwoorden in het algemeen? Denk je dat deze aanpak goed aansluit bij de behoeften van leerlingen in het basisonderwijs?

1 (helemaal niet geschikt) tot 5 (Zeergeschikt)

9. Wat vind je van het idee om leerlingen dit lessenplan toe te passen voor Robotica lessen specifiek? Denk je dat deze aanpak goed aansluit bij de behoeften van leerlingen in het basisonderwijs?

1 (helemaal niet geschikt) tot 5 (Zeergeschikt)

10. Hoe lang zouden de theorie uitleg voor elk onderwerp moeten zijn in pakket B. (Debug lesplan)

Meerkeuze: 5 min, 10 min, 15 min, anders namelijk ....

11. Wat verwacht je dat de grootste voordelen zijn van dit lespakket?

Open vraag

12. Wat verwacht je dat de grootste nadelen zijn van dit lespakket?

Open vraag

13. Heb je nog adviezen voor het opstellen van dit lessenplan?

Open vraag

Vergelijkingen tussen de twee lessenpakketten.

De volgende vragen zullen zich richten op het verschil tussen Lespakket A (Traditioneel lesplan) en Lespakket B (Debug lesplan)

14. Welk lespakket denk je dat leerlingen het meest enthousiast worden? Geef toelichting waarom je dit denkt.

Open vraag

15. Van welk lessenpakket denk je dat de leerlingen het meeste leren? Geef toelichting waarom je dit denkt.

Open vraag

16. Zijn er nog onderwerpen die we niet hebben besproken, maar waarover je graag iets zou willen delen?  

Open vraag

Bedankt voor je hulp!

Robot used for this project.

The robot

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. We were 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. After thoroughly trying to make this method work, we sadly had to conclude that for this project we were unable to do this. Thus the robot was wired while uploading with a USB-B to USB-A cable to the laptop.

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, and place objects back.

The web interface

The web interface we have created for the students is grouped by subject.

We have two different interfaces for each of the test groups with the same style and layout. To appease the age group, we have tried to make the design suited for children by incorporating vibrant colours, minimizing empty space, and making most objects rounded, while still being suitable for educational settings by keeping the colours, although vibrant, in the same colour palette and making the patterns repetitive.[1] The design is kept simple and intuitive, both for students and teachers.

For recreating the web interface, see the following GitHub Repository, https://github.com/GijsKruize/0LAUK0. The readme file will guide you through the steps needed to get the same setup.

Exercises

For both groups, the goals of the exercises will be similar. The debug group will, however, get faulty code while the other group will start writing from scratch.

These exercises are the following:

Exercise	Explanation of the exercises	What is wrong in the faulty code
practise exercise 1, driving forward	Drive the robot forward by 25 cm	The robot only moves forward by 10 cm
practise exercise 2, driving forward	Make the robot drive forward, turn left, drive forward, turn clockwise until you get back to the route you were on and drive it back to the first spot	The robot makes the first turn to the right, when moving clockwise it has one turning left in there.
practice exercise 3, turning	Make the robot go forward, turn left, drive forward, turn left and then make the robot go backwards over this same route	The robot does the backward route (turning right twice) without going backwards (forgot the minus in the forward)
Exam exercise driving	Follow the route on the A0 sheet	(No code is given)
practice exercise 5, obstacle detection	There is an obstacle(their own hand) in 20 cm, the robot stops 10 cm before the hand	The robot is programmed to stop 20 cm before the obstacle
practice exercise 6, obstacle detection	There is an obstacle(their own hand) in 20 cm, the robot stops 10 cm before the hand	The robot starts driving backwards instead of stopping
practice exercise 7, moving object	Open the arms for 2 seconds	The robot only opens them for 1 second
practice exercise 8, moving object	Open the arms for a second, close them for a second, open them for a second, close them for a second, drive forward for 20 cm	The robot does this in the wrong order (open, closed, closed, open, drive forward)
Exam exercise obstacle detection and moving objects	Drive the route on the A1 sheet with obstacle detection while picking up and delevering an object	(No code is given)

Map

We created a map on A0 where the robot could drive. The students had to measure the distances themselves and then code this into the robot so it could follow the route. The idea was that the robot had to drive to the checkpoint and then drive backwards to the point where it should go right. This is to simulate a dead end and practice driving backwards.

Coloured version of A0 map that was used for the exam exercises

Survey

The survey is designed according to the MCC Survey Guidelines. Furthermore, 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. 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.

All questions in the survey are asked on a 7 point Likert scale

1 = Helemaal niet mee eens

2 = niet mee eens

3 = niet helemaal mee eens

4 = ik ben neutraal

5 = een beetje mee eens

6 = mee eens

7 = helemaal eens

The questions are as follows:

Hoe oud ben je?

Wat is je groepsnummer?

Ik heb ervaring met coderen.

1. Wanneer ik een nieuw stuk code zie, kan ik uitleggen wat het doet zonder het te testen.

2. Wanneer de robot zich niet gedraagt zoals ik wil, kan ik meestal ontdekken wat het probleem is.

3. Ik denk dat het testen van de robot mij heeft geholpen de code beter te begrijpen.

4. Ik denk dat ik beter ben geworden in coderen tijdens dit project.

5. Als ik de code zie, weet ik precies wat de robot gaat doen.

6.  Ik begrijp het doel van elk onderdeel van de code die ik heb geschreven of mee heb gewerkt.

7. Ik denk dat ik elk probleem dat komt door de code van de robot kan oplossen.

8. Ik denk dat ik beter werd in coderen na elke opdracht

9. Ik kan een groot probleem meestal opdelen in kleinere stappen.

10. Ik probeer verschillende oplossingen wanneer mijn code niet werkt zoals verwacht.

11. Ik vind het fijn wanneer ik mijn code kan testen om te zien of deze correct werkt.

12. Het is gemakkelijk voor mij om te begrijpen wat de code doet.  

13. Wanneer ik de code verander, weet ik wat de robot gaat doen.

14. Wanneer ik een probleem tegenkom in de code, kan ik meestal zelf de oplossing vinden.

The questions are divided into 3 categories, as can be seen by the number in front of them. Category 1 questions are about understanding the code, category 2 questions are about problem-solving skills and the 3rd category are questions about the learning process. The only question that has no category is about their prior knowledge.

Lesson plan

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

Lesplan op basis van debugging

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 enquêtes uitdelen	enquêtes 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 enquêtes worden uitgedeeld over hun ervaringen met de gastles. Er zullen ook observaties worden uitgevoerd, tijdens de les.

Lesplan traditionele lesstructuur

Identificatiegegevens

Naam: Gijs Kruize, Tom de Leeuw, Morgan van Til- burg	Start op: 13:00	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 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 lunchpauze. 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	13:00- 13:05	Gastheer	geen	De klas tot rust roepen en de aandacht vragen	Plaats nemen en stil zijn.
Introductie	13:05- 13:10	Presentator	Digibord/ beamer	Toelichten onderwerp, tevens enthousiasmeren	Actief meedoen in conversatie.
Theorie robot	13:10- 13:15	Didacticus	Digibord/ beamer	Algemene uitleg over de robot geven	Aandachtig luisteren
Voorbeeld programmeer opdracht	13:15- 13:20	Didacticus	Digibord/ beamer	Voordoen van de voorbeeld programmeer op- dracht.	Luisteren, aantekeningen maken
Oefenopdracht 1	13:20- 13:45	Didacticus/ Pedagoog	Robot, laptop	Rondlopen, vragen beantwoorden, leerlingen bij problemen in het programmeren	In groepsverband ”opdracht 1 Bewegen”
Eind-opdracht 1	13:45- 14:05	Didacticus/ Pedagoog	Robot, laptop	Rondlopen, vragen beantwoorden, leerlingen ondersteunen bij het leerproces.	In groepsverband ”opdracht 1 Parcours” maken
Omschakelen	14:05- 14:10	Presentator	geen	Klasikaal terug de aandacht pakken. Volgende opdracht introduceren	Aandachtig luisteren
Oefenopdracht 2	14:10- 14:25	Didacticus/ Pedagoog	Robot, laptop	Rondlopen, vragen beantwoorden, leerlingen bij problemen in het programmeren	In groepsverband ”opdracht 2 Obstakel ”
Eindopdracht 2	14:25- 14:45	Didacticus/ Pedagoog	Robot, laptop	Rondlopen, vragen beantwoorden, leerlingen helpen bij het doorlopen van de foutopsporings- cyclus.	In groepsverband ”opdracht 3 Wegversperring”
Afsluiting	14:45- 14:55	Afsluiter	geen	De lesstof afsluiten, herhalen wat we vandaag hebben gedaan en enquêtes uitdelen	enquêtes 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 enquêtes worden uitgedeeld over hun ervaringen met de gastles. Er zullen auch observaties worden uitgevoerd, tijdens de les.

Research Findings & Results

In this section, we will review our research process and present our findings from the testing day. We will begin by sharing our observations from the two different lessons we conducted.

Observations

Observations of testing

The observations are coded into five different categories, namely: enthusiasm, care for the robot, apparent understanding of coding, attention during explanations and behavior.

Enthusiasm

In both situations, all children were initially enthusiastic about the robots and coding in general. However, in the debugging group, the enthusiasm soon declined. By the end, there were only a handful of children working on the assignment. In contrast to the second group, where all except two participants kept working until the end. Strategy 2 seemed to lead to more enthusiasm, possibly because the participants felt like they did it themselves instead of feeling like it was being done for them. Some participants even said that they were unhappy that class was already over.

Care of the robot

The care of the robots is more or less similar between the two groups. The only difference was that some participants in the debugging group forcefully corrected the robot when it did not do what they wanted. Both groups took good care of the robots initially, corrected peers who did not take good care, and played with the robot from time to time.

Apparent understanding of the code

The debugging group had a lot of difficulties with all the exercises and needed a lot of explanation. All participants in this group needed help with almost all exercises. In the other group, participants needed a lot of help at first. The syntax was unclear and the participants used "normal language" to try and make the robot work. For instance, they typed "go forward 20 cm" instead of forward (20). Once this was clear, they went through the exercises quicker than the debugging group. They also seemed to understand the syntax and details of coding better than the debugging group. Both groups understood that the Arduino application was similar to the online environment and quicker than downloading from the online environment, so some of them programmed the exercises there instead of on the online learning platform.

Attention during the explanations

In the second group, there was a lot more attention given to the explanations. The children were quiet and present when their group got help. This was not the case for the debugging group. Some of the participants were distracted or walked away when their group got help.

Behavior

In the group that built the code from scratch, everyone immediately sat in such a way that everyone could see the screen. This was not the case in the debugging group, where there was usually one "coder" and a couple of helpers. The debugging group was also more playful than the other group, for instance, racing against each other and making the robots walk in infinite amounts. In the debugging group, children that were motivated would join up and work together as a new self-formed group.

Survey results of strategy 1

Survey results strategy 2

Results of surveys

All survey results were added together per strategy, as can be seen in the images on the right. The mode will be used to draw conclusions, the average of abstract concepts like "eens" and "oneens" cannot be computed.

All survey results were added together per strategy, as can be seen in the images on the right. The mode will be used to draw conclusions, the average of abstract concepts like "eens" and "oneens" cannot be computed. Most of the survey answers in both groups are similar to each other, however, there are some differences. The answer that was given to most for strategy 1 for the question "When i see a new bit of code, I know what it will do without testing" is neutral, whereas the mode in strategy 2 was disagree. Further, in strategy 2 almost half of the participants sayd totally agree in the question "iI feel like I got better understanding of coding during this project", this is supported by the observations, which also say that strategy 2 seemed to have a better understanding of the code. In general, strategy 1 seems to have more confidence in their coding skills. This is the opposite form the results of the observations and the quantitative results.

It is important to note that the validity of the results is questionable to say the least. It was filled in by children and a lot of them either filled all the dots on either neutral of totally agree, of left one page blank. The ones that seemed to be filled in seriously were used to determine the results as described above.

Quantitative results of the programming website

The goal of programming in a web interface was to be able to keep track of certain statistics for the group's progress. As mentioned in the observations, the lesson for the first strategy did not go to plan. This meant that students of the first group did not come as far when looking at the given assignments. We will still compare some statistics between strategy 1 (debugging) and strategy 2 (building code up). The most valuable quantitative comparison we can me make is comparing the average submission count and time spent per assignment between the two strategies.

Results of quantitative tests

Observations of results

Due to the low amount of data, which has turned out lower than expected, it is hard to draw conclusions from these results. One thing we can see for sure is that the second strategy has more submissions for assignments 3 and 4 since more groups reached those assignments in the given time.

For the differences in submission counts, one could argue that a lower amount of submissions could mean that the group has done it in fewer tries and thus understands it better. On the other hand, one could argue that more tries means that the children are more actively working on the assignments.

For the first two assignments, we can see that the second strategy, on average, takes quite a bit less time than strategy 1. For the latter two assignments, this is not visible; it seems that the first strategy is even quicker on average. This is not the full picture; looking at the number of submissions, we can see these significantly drop for strategy 1, also confirmed by the observations, not as many groups had time to seriously make the last two assignments. So a farsighted observation can be that overall strategy 2 took less time on average for the students to get to an answer for the assignment.

Conclusion

Regarding our 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?

We can draw the following conclusion based on our gathered results.

The bottom-up approach is more effective than the debugging-first method in terms of students' problem-solving skills and code comprehension.

Although our quantitative results have not reached the preferred numbers due to the overall lower results of our tests. The observations gave us a lot to work off. The pace the second group (bottom-up strategy) showed while working through the assignments was significantly higher, which can be confirmed by the quantitative results to some degree. This, in combination with the enthusiasm and level of questions the second group had, gave us, as observers, the idea that the students executing the bottom-up approach had a greater understanding of what they did, and why they did it.

Discussion

We were not able to get the Bluetooth module working, which had significant consequences for our testing setup. Without wireless code transmission, students had to manually download and upload the code to the Arduino using the Arduino software. This process was time-consuming and technically challenging, leading some groups to start correcting their code directly in the Arduino software. As a result, they noticed that the code was almost identical to what they had learned. This deviation affected our test results, as we could only perform quantitative testing on results generated by our website. If the Bluetooth module had worked, students would not have seen the code in the Arduino software, and this issue would have been avoided.

A solution to this issue is to perform the translation on the website side of the code. By handling the translation on the website, the code that students see in the Arduino software would be different from what they have learned. This approach would ensure that students rely on our website for coding, as they would not understand the code they see in the Arduino software. Ideally, our teaching portal (which ran on a local server) should have been able to send the code directly to the correct robot. This would have freed up a lot of time for the students to write code instead of struggling with getting the code onto the robot. This method would streamline the process, reduce errors, and ensure that all testing is based on the code generated by our website, leading to more consistent and reliable results.

While the debug group was given code quite similar to the working code, they often removed all the code to start writing what they thought was correct. For example, for turning, there was "draai(links)," but the students would remove this and write "[rechts].”. This was also the case for the bottom-up approach group, who would just write “[rechts]” instead. This behavior indicates a fundamental misunderstanding of the provided code and suggests that the students were not fully grasping the concepts being taught. Providing more time for exercises and practice would have allowed the students to better understand the code and its functionality, leading to more effective learning outcomes. If the group had more time, they would have been able to do more exercises and find more value in the faulty code provided. Additional time would have enabled the students to explore different coding scenarios, troubleshoot issues, and develop a deeper understanding of the coding principles. This extended practice would have reinforced their learning and improved their coding skills, ultimately leading to better performance and more accurate test results.

Our teaching portal was quite basic, simply converting code and outputting it. This meant that groups received their first compilation check in the Arduino software, then had to return to the teaching portal to edit their code, download it again, and load it into the Arduino software before they could check it again. This iterative process was demotivating for students and could be easily improved by adding a simple compilation check for common errors that non-programmers might make, such as indentations, opening and closing brackets {}, and semicolons. Although these elements were included in the pre-filled assignments, students often only focused on the lines of code. By incorporating a basic compilation check on the teaching portal, we could catch these common errors early, reducing the back-and-forth between the portal and the Arduino software.

Overview of existing research

Overview of existing resources for early childhood robotics education

Programming languages for kids

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

Block-based programming languages

A block-based programming language is a form 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 popular programming languages of this type, but there are also others, such as Tynker, a website that contains games and block-based 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 is English the primary spoken language; therefore, 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 to children, leads to a higher popularity amongst the text-based programming languages for children.  

Robots for children

Sequential robots

A type of robots made for children from ages 5-8 years is a 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 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.

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 starting 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

This paper demonstrates that early exposure to programming can significantly boost girls interest in technology-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 how preschool teachers learn how to code with and without the scaffolding method. The scaffolding method is a teaching strategy where support is provided and slowly decreased the further in education goes. In this research, the group taught via scaffolding and 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 were not asked to formulate hypotheses for why the code was not running and were 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 a 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 were divided amongst 3 groups. Two of the groups were using scaffolding methods and a third control group. Each group had an 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 were 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 focuses 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) + enquêtes(1h) + Wiki	16
Tom	Meetings(1+4+2h) + contact with school (1h) + creating new research questions (1h) + research (1h)	10

Week 6

Who	What	Hours
Gijs	Meetings(1+2+1h), Database redesign (1,5h), Backend programming (2,5h), Frontend programming (2,5h), setting up actual server environment (2h)	12,5
Morgan	Meetings(1+2+1h)+ working on the bluetooth module(3+3+3+5h), design and write code for the exercises (2h) + wiki (1.5h)	21.5
Naomi	Meetings(1+2+1h) + Lesplan (5h) + enquêtes(0.5h) + Ontwerpen opgaves (2h) + Werkblad (1h) + Wiki (1h)	13.5
Tom	Meetings(1+2+1h) + hypothesis (1h) extra research (2h) wiki (4h)	17

Week 7

Who	What	Hours
Gijs	Testing at the school(6h), Finalalizing webinterface (3h), filling in the assignments (1.5h), Finishing the network (1.5h), Server debugging (1.5h), publishing the GitHub Repo (3h), rewriting the assignments (3h), meeting(1+1h), wiki (1h)	23,5
Morgan	Testing at the school(2h+2h), debugging the robots (6h), preparing laptops (3h), making and printing the final exercise sheet on A0 (2h), writing different exercises and the codes(4h), preparing presentation for the school (1h), meeting(1+1h), wiki (2h)	22
Naomi	Testing at the school(3h), debugging the robots (1h), preparing laptops (1h), Meeting(1+1h), wiki(1h), writing the assignments (2h)	11
Tom	Testing at the school(6h) + survey results (4h) + observations (2h) + working out observations (4h) + preparing presentation for kids (3h)	19

Week 8

Who	What	Hours
Gijs
Morgan	Prepare presentation (2h), presentation(1h), finish the wiki (spell check and making sure the text is coherent) (2h)	5
Naomi
Tom