PRE2018 3 Group10

Group members

Janneke van Oosterhout - 1248448

Wouter Wolthuis - 0942103

Timo Aerts - 0963375

Dorien Brugman – 1238166

Esther Dommisse – 0930091

Problem

Currently, there are different robots that enable children to learn to program in a playful way. One example is Kids First Coding & Robotics . Here children with an age of four and up lay instruction cards in a specific order and the robot executes those instructions in that order. Instructions can be moving forward, turning, making a sound, etc. This should be an intuitive way to learn children the basics of programming. However, one big disadvantage is that the robot has different shapes and tasks, like a sandwich that wants to find peanut butter and jam, that are not interesting for children around eight years old. The easiness to program the robot has advantages though. Another example of a robot that helps children to learn to program is Lego Technic . Here children can program a robot in an online environment to do whatever they want the robot to do. The advantage is that the layout appeals a lot more to older children. However, the programming of the robot asks for more skills and might be a step too far for children that have no experience in programming at all.

With our project, we would like to close the gap between the currently existing robots that help children to learn the basics of programming. We want to develop a robot that looks appealing to slightly older children (age 9-12) but is still very intuitive to program. To add even more fun we will add some competitive games so that children can compete against each other and learn from each other.

Users

The users are children aged 9-12 and primary school teachers.

To make sure our idea and design will fit the interests of the children and primary school teachers, we created two questionnaires:

• For the children: https://goo.gl/forms/7ouclymloKLTKbGI3
• For primary school teachers: https://goo.gl/forms/DhLm1NKyYongOswd2

Results questionnaires

Last edited 28 March.

Based on the 5 filled in primary school children questionnaires and 11 filled in primary school teachers questionnaires, it follows:

• Robot that looks like a robot is preferred over a robot that looks like an animal.
• Both a cool robot and a cute robot are preferred.
• The robot should have eyes.
• Cool robot is preferred over a robot that looks like an animal.
• No visible wires is preferred over visible wires.

• Everyone thinks making your own puzzle board with puzzle pieces is better than a standard board.

• Working together is preferred over a competition, but half of the participants thinks both should be options.
• Working in a group is preferred over working alone. Most participants prefer a small group (2-3).

• 40% of the participants thinks the age should be 7-9. Others think the target group should be larger, from approximately age 7-12.

Objectives

• Create a design, to teach children programming
  • Software
  • Hardware
• Build a prototype

Deliverables

• The Wiki
• Prototype
• Presentation

Design concept

Prototype

We will design a robot that teaches children the basics of programming in a fun way by giving physical commands in the form of input blocks that the robot will execute.

The design consists of the following components:

• A robot that the children will program.
• Input blocks that the children will use to program the robot. These input block will be put in a certain order that the robot will execute.
• A board that the robot will move around on.
• A game storyline that the children can play.

The robot itself will consist of the following components:

• Arduino for the robot software. Project members already own Arduino’s.
• Caterpillar tracks, so that the robot can move forward, move backward and turn in place. We chose caterpillar tracks because it can turn on the spot and does not have a turning circle. These caterpillar tracks are store-bought and will be connected to the Arduino.
• Light sensor. We want the robot to be able to distinguish different colours so that we can utilize that in the game. This light sensor will be made by ourselves with a light diode because we have two students from electrical engineering in our group.
• A buzzer and LEDs to give feedback
• Breadboard that the input blocks will be put on.
• Design, so that the robot looks attractive to our target user group. As one of the group members has a 3D printer we have the possibility to make one or multiple custom designs.

The command blocks will consist of two resistors. By putting a voltage over the resistors and reading out the voltage in-between with the Arduino we can distinguish different blocks. These blocks will have different commands associated with them: move forward, move backward, turn clockwise, turn counterclockwise, and possible also if-statements and loops. The design of the blocks will make it visually explicit which command will be given by which block.

The board will consist of differently coloured squares that the robot will move on. By giving the robot a light sensor to read the colour of the squares we can give each square a different meaning. For example, a black square could represent a black hole that will kill the robot if it drives on that square, and white square could give extra point if the robot is on it. This option of having different squares gives more possibilities to the game storyline. Another advantage of having different squares is that the children may build and change their own board.

The game storyline consists of tasks that the children can accomplish with the robot. Different difficulty levels will possible so younger children or children with very little experience can start playing, as well as offering experienced children a challenging game. To give the game an extra dimension we will make it possible to play with multiple robots against each other. This will encourage children even more in the learning process. For this project, with the given time, we will make one robot only. We will, however, make a user guide as if the game consists of multiple robots.

Future improvements, that we will not implement because of the little time given for this project, are a hexagon board, more different input blocks, multiple robots, more different board shapes and colours, auto-calibration of the position of the robot on the board, and the possibility for the robot to shoot at other robots.

Puzzle board

Design puzzle board

Our ideas of the puzzle board are confirmed by the results of the questionnaires. We thought children would like to build their own "game" board with puzzle pieces. All the results of the questionnaires showed that everyone who filled in the questionnaire find this a good idea. The puzzle board consists of black and white puzzle pieces. All the puzzle pieces look the same, such that every possible combination of puzzle boards can be made. The design of the puzzle board can be found in appendix 2. The pieces will be 20x20cm, because the robot is 19,5 cm.

For our prototype, we will design a puzzle board on a wooden slab. On this slab there will be 18 squares, colored black, white and gray. The white squares are used to make a path to the goal (gray square). The black squares should be avoid because they are pits. You have to find a path from begin to the goal.

Command blocks

The command blocks are the instructions the user can give to the robot. The blocks are a visual representation of a piece of code, telling the robot to perform a certain action. To give instructions to the robot, the user can plug the command blocks into the command block spaces on the back of the robot. The robot will then execute these commands and follow the given path. With these command chains, the robot can move over the puzzle board. Because there is only space for three command blocks on the robot, there is also a save button on the robot, with which a longer command chain can be made. The blocks have a DC jack (with a resistor connected) with which they can be plugged into the robot. The command blocks are 3D printed. In our current design we have six different command blocks:

This picture shows the 6 different commandblocks: (from left to right) loop 3, loop 2, loop end, forward, turn left, turn right

Turn right: turn 90 degrees to the right on same position.

Turn left: turn 90 degrees to the left on same position.

Forward: move one tile forward.

Loop 2: Do the action(s) between the loop 2 and loop end, 2 times.

Loop 3: Do the action(s) between the loop 3 and loop end, 3 times.

Loop end: End a loop.

Storyboard

This storyboard describes our idea of the robot.

Future Improvements

There are many possible features that are not feasible for us to add due to either time or cost restraints. However, they are still worth considering when thinking about what a complete version of our robot would be. These features include hexagonally shaped puzzle pieces, additional piece colours, multiple robots, additional input blocks, a scoring system and, most interestingly, multiple concurrently active agents, the possibility to fire at other agents or objects and a programmable IDE. All of these options would help in keeping children interested, by adding more options, difficulty and complexity for those who find it too easy. However, the robot can also be used for other courses as well, for example for mathematics.

Multiple Concurrently Active Agents

By adding multiple agents, the complexity of the game would increase dramatically. Children could be en- or discouraged to interact with these robots, such as by colliding with them, entering the area nearby or using the aforementioned "fire" command. These agents could be the robot of other children, but they could also be autonomous NPCs (non-player characters).

In our current design, the robots execute their chain of commands based on an internal timer. This would lead to unpredictable behaviour based on the relative starting time of each agent compared to the others. For example, say the player's robot has a chain of commands consisting only of forward movements. Somewhere on this path, an NPC is moving repeatedly over a path perpendicular to the path of the player. Then the player's robot could possibly collide with this NPC. However, if the player would its execution a few seconds later, the NPC might have left the square as the player approaches it. Due to the ages of our target users, we must ensure we do not complicate things too much like this. We decided it would be best to have the game be more deterministic than that.

One way to implement the movement and execution order of each agent's actions, to achieve this determinism, would be to use a global tick-based system. Each agent would connect to the same network, likely one hosted by a computer. This computer would then periodically send out a signal to each robot all at once, signalling each one of them to execute their next command. Once a robot has finished executing its command, it lets the host know that it is awaiting a new signal. Once the host has received this signal from each of the connected robots, it sends out a new signal. Alternatively, a user may manually send the next signal, in case of weak connection strength.

Fire Command

A fire command would make the game a lot more complex. This new command would also require targets, which could be static targets or moving agents, and hitting these targets could award extra points. Additionally, firing without hitting anything, or hitting an ally, could deduct points, preventing users from permanently firing anywhere. Combining this with rules that increase points awarded for small command chains or faster times would mean players have to start making choices about whether to pursue the targets or race to the destination.

To implement such a command, we could use a system very similar to the ones used in laser tag. Each agent capable of firing would be outfitted with an infrared laser light, which would be its gun. This gun would be mounted straight forward, so to aim the robot would have to rotate to face the target. Each target would have a number of sensors around its vulnerable areas to detect the shots of the gun, as well as a number of lights to indicate whether it has been shot already or not.

If a scoring system has been implemented with rewards for successful hits and penalties for missed shots, each target would need to connect to the host of the network. Whenever the robot fires, it will let the host know that it has done so. Then, any targets that have been hit will also notify the host of this. This means that if the robot fires and the host is not notified of any hit targets, the robot must've missed. Using this information, it simply adjusts the score total.

Custom IDE

A custom IDE would be the most daunting, yet promising, feature. Adding this would allow the children to get familiar with IDEs and similar user interfaces of programs they are likely to use later in life. There are two ways the IDE could take shape. Naturally, it could consist of both forms, switching between the two via a toggle.

The IDE could be a software version of the building blocks. Children would be able to add a sequence of pre-made code blocks to the command chain of the robot. Once they're done, they'd upload it to the robot which, upon being given the start signal, executes all of the given commands like normal. This would likely take the form of a mostly graphical interface, where each code block is of a uniquely identifiable shape or colour. Loop code blocks would have an additional variable to indicate the amount of iterations. Additionally, they'd be able to contain other command blocks to form the body of the loop. To add a code block to the sequence, they could simply drag and drop it from a toolbox to the proper window.

Alternatively, the IDE could be a purely text-based IDE. This means that the IDE also needs a programming language. Since the robot uses an Arduino Uno, the Arduino language would seem like a perfect fit. However, using the Arduino language would open up too many options, some of which could damage the internal circuitry. Additionally, this would overwrite the preinstalled software the robot requires to work with the command blocks. Thus, a new language would have to be developed. Since this type of IDE would be for the more advanced users, we can open up various settings within it to add a very large amount of complexity and opportunity. Such options could include: real time controlling, parallel commands, conditional statements or the varying of certain attributes such as timings and speeds.

State of the art

Memorization based on doing instead of learning

[1] “The Physical Presence of a Robot Tutor Increases Cognitive Learning Gains” Summary: students learn faster when a robot tutor is used compared to a video or a voice speaking.

[2]“Peer-to-Peer Learning in Robotics Education: Lessons from a Challenge Project Class” Summary: learning by doing projects is more beneficial to students than learning by themselves or by lectures and exercises alone, although it requires to overcome a high learning curve and a lot of effort. In this paper a robotics project is used so this conclusion is especially useful for our goal to make a robot for in education. We use this information by developing a game where children compete against each other and where they can work together in teams. This provides a steeper learning curve because children can help each other out.

[3] “Learning through play: a review of the evidence” Summary: To strenghtening childeren's learning it is more useful to learn them through play.

[4] “Learning by doing” Summary: For a skill to develop, practice is needed. Thus it is best to teach by using cooperative projects than explanation.

[5] “How people learn” Summary: From a very young age, people are predisposed to learning by experimentation and discussion, rather than being told or explained things.

[6] “Classroom Reward Structures and Academic Performance” Summary: There are four typically used reward structures. Individual Reward Contingencies (IRC), where students are evaluated individually and independent of each other, Group Reward Contingencies (GRC), where students are evaluated as a group and independent of other groups, Individual Competition (IC), where students are evaluated individually based on their relative performance amongst their peers, and Group Competition (GC) where students are evaluated as a group based on their relative performance amongst all groups. In classrooms, it is found that GRC and GC strengthen collaboration skills, interpersonal relationships as well as the performance and attitude towards the tasks more than IRC and IC do. Additionally, IC and IRC are noted to be more suited to the top subset of students and to be poorly suited to the low performing ones.

[7] “Cooperation Contrasted with Intra-Group and Inter-Group Competition.” Summary: Competitive conditions lead to a higher quality of performance and higher motivation than purely cooperative or individual conditions.

Programming at a young age

Computer programming as a mandatory subject for children (primary school) will create a link between the younger generation and the technology. It will also result in children facing challenges and developing programming skills at a young age.[8] However, there are more advantages for teaching children programming at a young age, coding will improve the creative expression and children will learn by thinking about doing instead of just doing something without thinking about it. This sources also discusses the fact that we need more computer scientists. Although not every child wants to be a computer scientist, the other advantages of having programming as a mandatory subject are still important enough, because it will give them skills for life. [9]

[8] “Supporting the learning of computer programming in an early years education” Alghamdi, M. Y. Summary: Computer programming as mandatory subject will result in facing challenges and developing the programming skills.

[9] “Beginning computer programming for kids” PRIMO Summary: Reasons to teach kids programming: Coding nurtures creative expression, programming demystifies tech, it teaches problem solving and presistence, children learn by thinking about doing and children also learn to think about thinking.

[10] “Teaching coding to children: A methodology for Kids 5+”, Kaplancali, U.T. & Demirkol, Z. Summary: Teaching coding to children will give them a skill for life. Different techniques to teach children programming.

[11] “Problem solving by 5–6 years old kindergarten children in a computer programming environment: A case study”, Fessakis, G., Gouli, E., & Mavroudi, E. (2013). Summary: A case study where kindergarten children had to solve a series of computer programming problems, using a Logo-based environment. The results support the view that children enjoyed the learning activities and had opportunities to develop mathematical concepts, problem solving and social skills.

[12] "ToonTalkTM—An Animated Programming Environment for Children", Kahn, K. (1996). Summary: ToonTalk: An animated programming environment inspired by video games, representing the programming language in animated images of e.g. cities, houses, birds, etc.. It is well suited for giving children the opportunity to build real programs in an easy and fun way.

[13] "KIBO robot demo: engaging young children in programming and engineering", Sullivan, A., Elkin, M., & Bers, M. U. (2015). Summary: KIBO is a robotics kit for children of the age 4-7 to construct their own robot with motors, sensors and craft materials. Children can also learn programming by exploring sequences, loops and variables. It was developed collaboratively with teachers, children and a research team. The kit uses no computer, but tangible programming blocks. From interviews with teachers it was concluded that the robot should use minimal computer equipment, from both a logistical standpoint (not having enough computers in a classroom) and a developmentally appropriate standpoint (screen-time, or working with a keyboard and mouse). Also, the robotic parts should be physically and intuitively easy to connect.

The programming blocks are made of wood and can be connected to each other. A scanner in KIBO scans the barcodes on the blocks. Research has shown that computer programming can help young children with a variety of cognitive skills, like number sense, language skills and visual memory. The programming language of the blocks is based on the early ideas of tangible programming, which uses physical objects to represent concepts.

In the newer version of the KIBO, the electronics of the robot are visible. The sensors have specific designs that make them easier for children to recognize, like a telescope for a distance sensor.

[14] "Kindergarten Children Programming Robots: A First Attempt" , Stoeckelmayr, K., Tesar, M., & Hofmann, A Summary: A research done to test the ability of programamble robots, to teach kinder garten childeren programming concepts

[15] "Learning graphical programming: An evaluation of KidSim™ " , Gilmore, D.J., Pheasey, K., Underwood, J., & Underwood, G 'Summary: an evaluation of Apples programming learning enviroment KidSim™, which is targeted at childeren aged 10-13

Robot in class

[16] “Robotics in the early childhood classroom: learning outcomes from an 8-week robotics curriculum in pre-kindergarten through second grade”, Sullivan, A. & Bers, M.U. Summary: A robot offers a playful way for children to engage them with technology and engineering.

[17] “A REVIEW OF THE APPLICABILITY OF ROBOTS IN EDUCATION”. Summary: the application of robots in different educational field (linguistics, science and technology) is reviewed, as well as the different roles that a robot can play in education (tutor, peer, tool).

[18] “Robots in the classroom - tools for accessible education” Summary: different roles of robots in education. There are many benefits of using robots with disabled students, unfortunately robots are currently little used in education.

[19] “Socialization between toddlers and robots at an early childhood education center” Summary: Toddlers first treat robots as tools but with frequent interaction the toddlers treat the robot like a peer rather than as a toy.

[20] "Robot education peers in a situated primary school study: Personalisation promotes child learning", Baxter, P., Ashurst, E., Read, R., Kennedy, J., & Belpaeme, T. (2017). Summary: Research about the use of personalised and non-personalised education robots at primary schools. Children with both kinds of robots learned, though there was increased learning of a novel subject with the robot that personalised its behaviours. There is also an increased acceptance when the robot is personalised.

[21] "Children, robotics and education", Johnson, J. (2003). Summary: Research about several questions about robotics and education. It addresses among other things topics like whether children learn from robotics, how it is different from other ways of learning and whether it is a fashion or permanent.

[22] "Learning Math Concepts by Visually Programming Robots" Bilotta, E., Pantano, P., & Talarico, V. Summary: Research about the possibility to learn primary school childeren mathemeatical concepts by use of a programmable robot

Interests of children aged 9-12

[23] "Using Robotics to Motivate ‘Back Door’ Learning", Petre, M. & Price, B. Summary: a paper about a robot vehicles ability to teach childeren about programming and robotics, by using their interests and appealing to them. this means, a child likes the robot and being able to control the robot, resulting in the child wanting to learn about it. this fenomenon is called ‘Back Door’ Learning, which is interest driven desire to learn. this fenomenon is mostly situational, since the learning goal and the interest of the child have to match. This article however agues that robotics sparks interest of nearly all childeren, even those with a non-technical background. It is in this paper done in a problem-based team-centered setting, which is worth noting.

Babuino-bot

[24] "Cheap, Easy Robotics for the Non-Programmer" ,James K. Larson1, Adeilton C. Oliveira Jr1, Victor M. Oliveira2, Brett Nelson3, Josue J. G. Ramos4 ,Lucas T. Alves2 Summary: a paper about the babuino bot a robot made for learning programming to someone without programming skills and, for whom normal coding is to overwelming. This robot design realatively easy to program, being based on the logo's language, however it does have a few limitations, the fact that the robot has to be connected to a laptop, with the appropriate software. and the fact it is lacking learning objective therefore solely reallying on the users will to learn program it better

Lego-technik patent

[25] “Lego Technik patent. Date Oct. 8, 2002.” Summary: The patent for Lego Technik. Specifically "A toy building set comprising toy building elements which may be coupled together to build structures."

Problem Statement

By looking at the babuino, the previous mentioned idea has already been tried. Based on the state of the art we can conclude that it is important that the robot is appealing to childeren since that would spark their interest and create a desire to learn. This appeal does not necceceraly have to be done by the looks of the robot, but can also be done by making the learning project appeal to other interest, by allowing creativity and needing teamwork. By doing this as many as possible childeren will be interested in working with the programmable robot.

Requirements

Must Have

1. Must be able to move forward a exactly the length of one provided puzzle tile. This is so that the robot is able to execute his command on moving exactly one tile

2. Must be able to turn 90 degrees in place. This is because the map in which the robot will move in a grid made of squares, and for changing direction, an exact turn of 90 degrees is needed

3. Must be able to discern between provided gray, white and black tiles underneath it. This is so that the robot is able to interact with the map and knows if it is on the road, has crashed or reached its goal.

4. Must be able to discern the difference between each provided “command block” (forward; backward; turn clockwise; turn counterclockwise; loop2; loop3; loop4; loopend). This is essential since this is the way children will be able to input their 'code' into the robot.

5. Must be able to store each command of inputted “command blocks”. Since it is possible that the children input a code longer than the reading slots the robot has the robot will have to be able to store the commands, allowing the robot to remember more 'lines of code' and not being limited by its hardware.

6. There must be at least 3 of each type of command block. (essentials being forward, turn clockwise and turn counter clockwise) Since at least a basic amount of commands is need to showcase its potential

7. Must be able to successively execute all stored commands without user intervention. Just like in actual programming, a robot should be able to act autonomously after having been programmed.

8. Must be safe to use according to the CE safety standard. This means that when the manual is followed and the users use the slightest form of commen sense, no one should get hurt whilst using the set-up.

Should Have

9. 95% of children aged 9-12 can use the product within 30 minutes. This is to make sure the product is simple and intuitive enough to use by our target audience.

10. The robot gives visual feedback when it is on a provided black tile to indicate this. The visual feedback makes sure that it is always clear if the robot has crashed or if it has frozen due to an error.

11. A manual details how to use the robot. The manual will make sure the robot is used as intended and no trial and error is required to use it correctly.

Could Have

12. The robot gives auditory feedback when it is on a provided gray tile. Similar to requirement 10, this would help differentiate between an internal error and the robot having reached its goal.

13. The robot discerns between provided red, green and blue tiles in addition to the tiles in requirement 3. Additional tile colours would add extra complexity and chances for competition, such as squares that grant extra points or deduct points. The three colours red, green and blue have been chosen arbitrarily based only on their contrast to each other.

14. There are different storylines with different goals. By creating storylines beforehand, we can provide layouts that specifically test certain aspects of programming with set difficulties as well as provide an easy entry point for new users.

Won't Have

15. The robot is able to execute a “fire” command. A fire command would add another layer of complexity due to adding a command outside of the movement set. This creates the opportunity for more challenging levels.

16. The provided puzzle pieces are hexagonal in shape. Hexagonal shapes will allow for more varied, and thus more complex, layouts, than square pieces will.

17. Loop blocks are able to vary the amount of iterations (e.g. with a switch or holes to put numbers in). In actual programming, loop code blocks aren't limited to only a set few repetitions. By having a variable amount we can better replicate the actual behaviour of loops. Additionally, this will cut down on the amount of blocks.

18. The robot detects collisions with enemies on the board. This would, like requirement 15, add more complexity outside of just movement.

19. All agents act at the same time based on a synchronized tick system. By using a synchronized tick system, the execution of commands is more deterministic, since users no longer need to worry about when aan agent starts executing its commands compared to the others.

Hardware

side view of the chassis with electronics, but without the cosmo top

top of the chassis with souly wires gearboxes and motors

The chassis of the robot is a platics base to which two catterpiller tracks are attached. underneath the chassis there is space for 4 AA-batterys in series, which power the system with a 6v supply (four times 1.5 volt). On top of the chassis a wooden plate is attached on which electronics or other things can be placed, one of which is an arduino, which funcitons as the 'brain' of the robot. Both caterpillar tracks are powered by a DC-motor thourgh a gearbox, which allows the motor to operate at a high RPM, whilst the caterpillartracks move slower but at a higher Torque. The lower torque at the DC-motor allows for a lower current, the lower current is needed since, the maximum current is limited by its powersupply and in general a low current is prefered due to the heat it creates. Each motor + gearbox are inside of a plastic case, which is screwed into the chassis. The DC-motors will be powered by a DC-motorcontroller, which recieves its power directly from the batteries and recieves command through i/o-ports from the arduino, which is located on the wooden plate. on the rear-end of the chassis a IR-sensro will be placed this sensor can, based on the different amount of IR-refelcted by different colour of tiles identify the current tile it is placed on. On the robot there will be a few slots for the commandblocks, these command blocks contain a resistor, which is read by use of a voltage divider. All wires in the system are stiff wires made form tinned copper coated with rubber due to them being durable and suited for arduino, breadboard, and the screw-based connector of the motor-controller. All the fragile copper wires which were deliverd together with the chassis were replaced due to them being not durable and therefore not suited for longer term usage

Software

The robot is programmed using an Arduino. Its software is made up of 2 phases: Setup and Execution. Additionally, some functions have been written for debugging and testing purposes, allowing greater control over the actions of the robot during its creation and validation.

Setup

Setup contains the code used by the robot while it is not currently executing a saved command chain. After initialization, the robot starts in the setup phase. During this phase it will first calibrate the sensors if needed, followed by the reading of the buttons. If the "Read commands" button is pressed, all inserted commands are read and stored. If the "Execute" button is pressed, the robot leaves the setup phase and enters the execution phase.

Sensor Calibration

Sensor Calibration is used to dynamically set the reading values of both black and white tiles, to minimize the impact of light pollution. The first time the robot is started, he must be placed on a black tile and afterwards a white tile to calculate the highest and lowest values read for both respective colours. To find the highest black value, the light is turned on and a set of 10 consecutive readings are performed. From these, the largest reading is used as an upper bound of light considered black. After this value is found and saved to black_up, the robot must be placed on a white tile instead. Then, just like with black_up, 10 readings are performed with the light on. Afterwards the lowest value is chosen to serve as a lower bound of light considered white. This value is then saved to a white_low variable. Once both these actions have been performed, the robot is done calibrating it's light sensor and will use these values until it is turned off.

Command Reading

Command Reading is done by sending a 5 volt current through the resistor inside each command block for a short amount of time. During this time, the returned value is read. Since each command block uses a different resistor, the returned value is unique for each one. Thus, when we know the value we've gotten back, we can compare it to the expected value for each command block. However, to account for slight fluctuations, the returned value is compared to a range instead. This range is gained by subtracting and adding a slight offset of 30 to the expected values. This ensures that any small fluctuations should not cause a block to go unrecognized. After all commands are read, the current is turned off again for safety purposes.

Command Storage

Command Storage is done by way of an integer array. Each command is represented as an integer value: Forward is represented with 0, Backwards with 1, Rotate Clockwise with 2, Rotate Counterclockwise with 3, Loop 2 with 4, Loop 3 with 5 and Loop stop with 6. Whenever a valid command is recognized, the first empty spot in this array is filled with the corresponding command integer. By using a global index variable, and proper updating thereof, we are able to keep track of where this is, avoiding the need to search through the array for the first possible slot whenever a command is stored. Additionally, a second global variable is used to keep track of how many commands have been read, mainly to be used during the execution phase of the robot.

Execution

Execution contains the code used by the robot to execute a saved command chain. This phase starts after the "Execute" button is pressed during the setup phase. Upon starting the phase, first all read commands are parsed and translated to a command chain without loops, thus containing only movement commands. Then it will perform these movements and read the tile underneath alternatingly. If the read tile is white, it will continue with the next command in the parsed command chain. If the read tile is black or grey, it will give appropriate feedback and stop moving.

Command Parsing

Once the user has pressed the execute button during the setup phase, indicating they wish to have the robot execute their route, it will start parsing the read command chain. This parsing is done to remove the loops and loop-ends from the command chain, resulting in a chain of only forward, backward and rotation commands. This parsed chain is then easily executable by the robot in a smooth fashion, without the risk of it freezing due to long calculations mid-route.

This parsing is done via the aforementioned command-chain array, an integer keeping track of how many commands have been stored, an array to contain the parsed command chain and a global index to keep track of the index for the parsed commands, similarly to how the commands are stored. The software will run through each command in the chain, adding any movement commands to the parsed list without requiring extra actions. When it encounters a loop command, it will instead call a different function dedicated to parsing loops and its contents. This function will return the index of the relevant loop-end command in the command chain, allowing it to continue parsing any possible commands after that.

To parse either loop, a single function is used that can be called recursively by itself. Due to the recursion, we are able to correctly parse nested loops. This loop parsing requires two parameters. The first is firstCommand, containing the index of the first command inside the body of the loop. This index is used whenever one entire pass has been made through the contents of the loop for it to return to the start for the next pass. Additionally, the function requires an integer for how often it should loop. In the current version this is either 2 or 3, since we only have a loop 2 and loop 3 command. However, in later versions this can be any number while still working properly. The function works similarly to the regular parsing function. Any movement commands are added to the parsed command chain and any loops cause it to recursively call itself. However, if it encounters either a loop-end command or the end of the command chain this function has to take different actions. First it increments the loop count, since another pass has been made through the body of the loop. Then it sets the command reading index back to the given firstCommand parameter to prepare for another pass, or increments the index if no more passes should be done. Finally it returns the index.

Movement

The movement is handled by connecting the pins required by the tank tracks to the Pulse Width Modulation(PWM) pins of the Arduino. Because we use the PWM pins, we are able to control not only the duration while driving, but also the speed. This would help us in controlling the distance the robot travels when driving as well as rotating without needing to drive at full speed at all times.

Each tank track requires two pins to be connected, one for each direction. When a current is applied to both directions of a single track, you run the risk of damaging the hardware. Thus we have taken great care to make sure that each track has a current running on at most one pin. To drive forward, a current is applied to the forward pins of both tracks. Naturally, to drive backwards this current is applied to the backward pins instead. In either case, the tracks are turned off again after 1,000 milliseconds. To preserve the rotation of the robot, the current running through both tracks is the same in both cases.

Rotating could have been done in a number of ways. Since we had decided we wanted our robot to be able to rotate in place, a current has to be applied to the forward pin of one track, while that same current is applied to the backward pin for the other track. For example, to rotate left we apply a current to the forward pin of the right track, while also applying the same current to the backward pin of the left track. Rotation to the right happens by the inverse method. The current is now applied to the forward pin of the left track and the backward pin of the right track. In either case, the motors are turned off again after 900 milliseconds.

Tile Reading

Tile reading is done by turning on a small infra-red light and reading the reflection off of the tile underneath the robot using a sensor. Since the light is attached to a PWM pin however, we can't perform only a single instant reading as this would risk reading when the light is turned off. Therefore we instead read 10 values and store them in an array. From these 10 values, we first calculate the average reading and use this to filter out the values lower than this average. From the remaining values, we again take the average to minimize the effect of any outlying values. This final average is then compared to the calculated black_up and white_low variables to decide which tile the robot is currently standing on.

If the final value is less than black_up, the tile is recognized as black. If it is larger than white_low, it is instead considered white. In all other cases, meaning the value is between black_up and white_low, the tile is considered grey.

Final design

Based on the questionnaires, the prototype should look like a robot, it should have eyes, and there should be no visible wires. It was not completely clear from the questionnaires, if the robot should be cool or cute. Therefore, we decided to design the robot in such a way that it is both cute and cool. Moreover, the results of the questionnaires show that teachers think the target group should be children aged 7-9. Therefore, we change the target group to 7-9. The final design looks as follows:

The name of our robot is Cosmo. The colors in the picture are variables, so they can be changed. This final design follows the needs of the users because the users asked for a robot that looks like a robot, has eyes and has no visible wires. This is the prototype Cosmo:

Cosmo can be attached to the caterpillar tracks by four bolts and nuts. The model for Cosmo was made in the 3D modelling software Blender and 3D printed afterwards. In making the model we had to take into account that the robot should have a large enough area underneath it to place all the electronics there. Also, the robot should not be too large (or it might fall over), or too heavy (or the caterpillar tracks would not be able to drive and turn anymore). In the model we also made space for three command blocks and the DC jacks that should fit in there.

User manual

To explain how Cosmo works, and which games can be played, we have made a user manual. This manual is meant for both teachers and children, to understand how the robot should be operated and how the games work. There are also examples of game boards that children can build. The user manual describes an ideal version of Cosmo, with some extra functions and commands. The manual consists of an introduction, an explanation of how it works, instructions of different games, and example puzzle boards (and their answers). It can be found in appendix 5.

Discussion

Requirements review

Must Have

Requirement	Fulfilled?
1. Must be able to move forward exactly the length of one provided puzzle tile	Yes, by using the caterpillar tracks en motor control
2. Must be able to turn 90 degrees in place	The robot can turn 90 degrees in place, but not on all surfaces since some surfaces have too much friction for the motor of the caterpillar tracks to be able to turn. Hence Requirement 2 is only fulfilled on certain, and not all, surfaces
3. Must be able to discern between provided gray, white and black tiles underneath it	Yes, by using a light sensor
4. Must be able to discern the difference between each provided “command block” (forward; backward; turn clockwise; turn counterclockwise; loop2; loop3; loop4; loopend)	Yes, by connecting a different voltage to each block and reading that voltage with the Arduino
5. Must be able to store each command of inputted “command blocks”	Yes, by using the Arduino
6. There must be at least 3 of each type of command block	No because we only printed one command block of each type for the prototype. This was enough because it is possible to plug in blocks, scan the input, and then plug in new blocks for several times. Would we commercialize our product then we would have printed multiple command blocks per type.
7. Must be able to successively execute all stored commands without user intervention	Yes
8. Must be safe to use according to the CE safety standard	We did not have accidents with respect to safety during extensive testing of our prototype. However, we did not "prove" the safety standard.

Should Have

Requirement	Fulfilled?
9. 95% of children aged 9-12 can use the product within 30 minutes	Unfortunately, due to time constraints we did not have the opportunity to test our robot with children. Furthermore, we changed the target group age from 9-12 to 7-9
10. The robot gives visual feedback when it is on a provided black tile to indicate this	No because we chose audio feedback instead of visual feedback
11. A manual details how to use the robot	Yes (see User Manual)

Could Have

Requirement	Fulfilled?
12. The robot gives auditory feedback when it is on a provided gray tile	Yes by using a buzzer and a light sensor
13. The robot discerns between provided red, green and blue tiles in addition to the tiles in requirement 3	No, we did not focus on this requirement
14. There are different storylines with different goals	Yes, see User Manual

Won't Have

Requirement	Fulfilled?
15. The robot is able to execute a “fire” command	No due to time constraints
16. The provided puzzle pieces are hexagonal in shape	No due to time constraints
17. Loop blocks are able to vary the number of iterations (e.g. with a switch or holes to put numbers in)	No due to time constraints
18. The robot detects collisions with enemies on the board	No due to time constraints
19. All agents act at the same time based on a synchronized tick system	No due to time constraints

Not all "Must Have" requirements are fulfilled. However, for the prototype it did not result in problems. One requirement of "Should Have" is not fulfilled because we swapped it with a "Could Have" requirement, so this is not much of a problem either. It is unfortunate that we did not have time to test the system with children because the system being easy to use by children (and teachers) is a big part of the goal of this product. From the "Could Have" requirements only Requirement 13 has not been fulfilled. We did not focus on this requirement because we expected this to be difficult to realize and we already fulfill Requirement 3. Since it is a Could Have and hence has a lower priority this is not a big problem. As expected we did not fulfill any "Won't Have" requirements. This gives the opportunity to extend this project in the future.

What could have gone better

Everything went well in accordance with our planning, except the game board which snowballed the planning to test with children. With making the game board we first had the problem that we wanted the board to exist of different pieces that all fit together. To do this the puzzle pieces have to be exactly the same. This is very hard to do if we would cut the pieces ourselves manually. Hence we decided to make one big board with different colored squares. At the testing of the board, we found out that paint has a high resistance and that this resistance is not equal over the entire board since not all squares are painted equally. This resulted in the robot not being able to drive the exact same amount over the board every time. Even trying other board materials, e.g. sanding the board or use paper or plexiglass, did not help. This problem could have been prevented by either building a detection system so that the robot can calibrate its position after every move, or by using some other material that is more slippery (e.g. 3D printing the puzzle pieces). Unfortunately, we did not have enough time to test these solutions. Searching other materials for the board took so much time that the testing of the complete system was delayed and hence also the testing with children. Unfortunately, we did not have extra time to arrange a testing session with children.

Planning

Who is doing what?

Hardware robot - Wouter

Command blocks - Dorien

Software robot - Timo, Esther

Sensors software - Timo, Esther

Sensors - Wouter

Puzzle board - Janneke

Design - Dorien, Janneke

User manual/scenarios - Dorien

Planning

Week	All	Janneke	Wouter	Timo	Dorien	Esther
1 (7-2 / 14-2)	Set up requirements, Read and summarize at least 25 papers	Edit Wiki	Order electronics part 1, design electronics	Divide robot-software in separate modules.		Divide robot-software in separate modules.
2 (14-2 / 21-2)	Summarize important papers	Design questionnaire	bare command blocks, Make and sensors MK1, Problem statement		User manual MK1, Design questionnaire	Concept problem statement
3 (21-2 / 28-2)		Board idea finished, Finish and translate Questionnaires	Make and sensors MK2, Requirements	Command blocks are read correctly, Light sensors read in optimal situations	User manual MK2, Design command blocks, Finish and translate Questionnaires	Command blocks are read correctly, Light sensors read in optimal situations, Design idea
4 (28-2 / 14-3)	Distribute questionnaire	Start design idea & Board material	Make and sensors MK3 & Requirements & Hardware/Software	Requirements	User manual MK3 & Start design idea & Design and print command blocks	Software
5 (14-3 / 21-3)		Board finished (begin week 13) & Results questionnaires on the wiki & Puzzle board description wiki	Drive train	Add a section about future improvements to the wiki		Light sensors are able to calculate spectrum and detect within those
6 (21-3 / 28-3)		Update results questionnaires, Finish puzzle board, storyboard	Robot hardware and software testable and working	Robot hardware and software testable and working	Ideal user manual (with won't haves)	Robot hardware and software testable and working
7 (28-3 / 1-4)	Prepare presentation, invent a name	Design robot finished			Design robot finished
8 (1-4 / 8-4)	Wiki

Logbook

Week	All	Janneke	Wouter	Timo	Dorien	Esther
1 (7-2 / 14-2)	Set up requirements, Read and summarize at least 25 papers	Edit Wiki	Order electronics part 1, design electronics	Divide robot-software in separate modules.		Divide robot-software in separate modules.
2 (14-2 / 21-2)	Summarize important papers	Design questionnaire	Problem statement & tile sensor MK1	Study Arduino programming language	Design questionnaire, started working on user manual	Concept problem statement, programming of the wheels and light sensor
3 (21-2 / 28-2)		Board idea finished, Finish and translate Questionnaires	definied command block; build tested and adjusted sensor MK1; did some research in order to improve the filter so it can be used more reliably	Arduino Command Block reading software, Start contact with teaching subreddit mods for survey	Finished and translated questionnaires, worked on command block designs, worked on user manual	Writing design concept, testing light sensor software with the hardware
4 (28-2 / 14-3)	Distribute questionnaires	Start design	addtions to requirements && did some testing with elektronics	Made some requirements more specific. Added justification to requirements	Worked on design command blocks	Merged individual software modules into one software file, completed the software
5 (14-3 / 21-3)		Board material, Puzzle board wiki, Results questionnaires wiki	tested Drivetrain && new light sensor && outputs signals && repair wires left track, repaired blocking rotor right engine	Added Future Improvements section to wiki	Ordered electronics, worked on design command blocks, made first 3D print, improved command block design, worked on user manual	Improved software, tested hardware
6 (21-3 / 28-3)		Results questionnaires & Storyboard & Puzzle board	made& tested new IR sensor wire repairs chassis and upgrade to chassis	Tested Hardware and software, corrected values in software, added light calibration	Improved command block design, 3D printed command blocks, added electronics to command blocks	Tested software and hardware
7 & 8 (28-3 / 11-4)	Prepare presentation, name, finish prototype	Edit wiki	Final testing prototype, some additions to wiki. prepared for presenting presentation	Final testing prototype. Add software section to wiki. Finalize comments in code and upload to wiki	Finished command blocks and tested in final prototype, made design for robot, 3D printed design, edited videos, finished user manual, edited wiki	Final testing prototype, editing presentation slides, editing wiki

Presentation

The presentation can be found in appendix 6.

The demonstrations in the presentation:

• Cosmo intro: https://youtu.be/CyhjM6jVMgU
• Cosmo command blocks: https://youtu.be/mxiMvZVF0Ws
• Cosmo command chain: https://youtu.be/aHqFTn58h_U

Appendices

Appendix 1: software code

A document with the code can be found in File:TotalSoftwarev5.pdf. The last update of this file was on 11-04-2019.

Appendix 2: board idea

The board idea can be found here: https://www.tinkercad.com/things/7anyPipSlgq-puzzelbord/edit

Appendix 3: command blocks

A document with images of the command block design can be found in File:CommandBlocks.pdf. The last update of this file was on 27-03-2019.

Appendix 4: electrical schematics

zipzcontaining electrical schemetics for parts of the robot. Media:Schematics.zip

Appendix 5: user manual

The user manual can be found in File:UserManual.pdf. The last update of this file was on 07-04-2019.

Appendix 6: Presentation

The presentation of group 10. File:PresentationGroup10.pdf