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 23 March.

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

• Robot that looks like a robot is more preferred than a robot that looks like an animal.
• Cool robot is more preferred than cute robot.
• It doesn't matter whether or not the robot has eyes.
• Cool robot is more preferred than animal looking robot.
• No visible wires is more preferred than visible wires.

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

• Working together is more preferred than a competition.
• Working in a group is more preferred than working alone.

• The age should be 7-9 or 8-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 (see “game experience”). 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 input 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, and the possibility for the robot to shoot at other robots.

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.

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.

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

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” Yahya Alghamdi, M. 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" , Kerstin Stoeckelmayr, Michael Tesar, Alexander Hofmann 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™ "' , David J Gilmore, Karen Pheasey, Jean Underwood & Geoffrey Underwood 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" ,E. Bilotta, P. Pantano and V. Talarico 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" ,MARIAN PETRE and BLAINE PRICE 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 hard ware.

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.

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	Design robot finished	Test with kids if possible		Design robot finished

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
7 (28-3 / 1-4)

Appendices

Appendix 1: software code

A document with the code can be found in File:TotalSoftwarev2.pdf. The last update of this file was on 21-03-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 20-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 21-03-2019.