Grades 4-12 School Robot Projects

Dec02-04

Final Report

Faculty Advisors / Project Team Members / Client Name
Dr. John Lamont / Zachery R. Bowley / Senior Design
Dr. Ralph Patterson III / Joseph D. Rodgers
Dr. Lawrence Genalo / Joanie M. Lally
Jonathan Hodapp

December 18, 2002

1

Table of Contents

1 Executive Summary………………………..…………….…………....1

1.1Need for Project……………………………………………………………..1

1.2Actual Project………………………………………………………………..1

1.3Project Results……………………………………………………………….1

2 Acknowledgement…………………………………………………….1

3 Introduction…………………………………………………………...2

3.1 General Background………………………………………………………..2

3.2 Technical Problem………………………………………………………….2

3.3 Operating Environments…………………………………………………….3

3.4 Intended User(s)…………………………………………………………….3

3.5 Assumptions and Limitations……………………………………………….4

4 Design Requirements…………………………………………………4

4.1 Design Objectives ………………………………………………………….4

4.2 Functional Requirements…………………………………………………...5

4.3 Design Constraints………………………………………………………….5

4.4 Measurable Milestones……………………………………………………..6

5 End Product Description……………………………………………..6

6 Approach and Design………………………………………………...8

6.1 Technical Approaches………………………………………………………8

6.2 Technical Design……………………………………………………………8

6.3 Testing Description…………………………………………………………8

6.4 Risks and Risk Management………………………………………………..8

6.5 Recommendation for Additional Work…………………………………….. 8

7 Financial Budget……………………………………………………..9

8 Personnel Effort Budget…………………………………………….9

9 Project Schedule…………………………………………………….. 10

10 Evaluation of Project Success……………………………….………11

11 Commercialization………………………………………………….. 11

12 Recommendations for Additional Work…………………………… 11

13 Lessons Learned……………………………………………………..11

14 Project Team Information…………………………………………… 12

14.1 Team Members………………………………………………………… …12

14.2 Advisors…………………...…………………………………………… …12

14.3 Client…………………...…………………………………………… …….13

15 Summary……………………………………………………………… 13

16 References…………………………………………………………….. 14

Appendix A……………………………………………………………… .15

Appendix B……………………………………………………………… .16

Appendix C……………………………………………………………… .17
List of Figures

Figure 5.1: Lego MindStorms and Equipment……………...……………………………7

Figure 5.2: Lego MindStorms Arena………………………………………………….....7

Figure 9.1: First Semester Schedule……………………………………………………..10

Figure 9.2: Second Semester Schedule……………………………………………….. ...10

List of Tables

Table 7.1: Financial Budget……………………………………………………………9

Table 8.1: Personnel Effort Budget……………………………………………………. 9

1

1 Executive Summary

1.1 Need for Project

The purpose of this project was to identify a set of robot-related projects that could be conducted in conjunction with a collection of students ranging from fourth to twelfth grade. The goal was to help students learn how a robot works and how they can be in command of a robot’s actions. These students can then compete in a series of events to test their abilities in building and programming a robot for the task at hand. The project is important because robots are becoming more popular in today’s world. If younger students become exposed to robotics they could become interested in pursuing a career in science or engineering.

1.2 Actual Project

A list of possible events was constructed, outlining event descriptions and criteria. Each event contains the following information:

  • Event descriptions
  • Criteria for winning
  • Rules for that event
  • Assumptions and limitations
  • The equipment needed
  • Recommended grades

The outlines of events were compiled in a manual, which is available via the website. Along with that information, history of robots, sample coding, and sample building instructions are also available on the website. The website URL is:

1.3 Project Results

The robot competition manual created in this project meets and beats the expectations of the group. The goal that users can easily set up and implement competitions has been reached. Every aspect of the competitions is noted in the manual including specific competitions, materials used, samples, rules, and many other crucial aspects. This manual and other information regarding robots is available on the website.

2 Acknowledgement

Thanks to John Davidson for his input with the project and to Toying With Technology for the use of LEGO MindStorms robots.

3 Introduction

3.1 General Background

The objective of this project was to define a set of robot-related projects that could be conducted in conjunction with a group of students from fourth to twelfth grade. The project used LEGO MindStorms robots with various types of control possibilities. These possibilities range from hardwired robots to completely autonomous robots.

A hardwired robot is very similar to a radio-controlled robot. The only difference being that with hardwired robots, the control is linked to the robot through a wire that is hooked up to both the robot and the control.

Wireless robots are robots that are similar to a remote controlled car. The operator uses a remote to send a signal to the robot and the operator can control the robot with certain directional controls on the remote.

A completely autonomous robot uses a code that is typed into a computer or directly into the robot. If the code is written through the computer, it is then downloaded into the robot and the robot works completely on its own. All the operator gets to do is watch and hope that the robot does what it was intended to do.

A website was created in order to communicate the information needed to construct the robots and perform the competitions. A sample of an event outline can be found in Appendix B. The site also gives some history of robots, including Iowa State University robots.

3.2 Technical Problem

The LEGO MindStorms robots use a simple version of C programming language and this is downloaded into the robots that are built. One problem was that the LEGO robots operating system would only work on the Windows 98 operating systems and before. Windows 2000 and NT operating systems will not work with the LEGO operating system.

The LEGO MindStorms robots also use a code similar to the C programming language. The Not-Quite-C, NQC, language is a simpler version of C programming making it easier to learn. NQC codes will work with all of the Windows operating systems. This is a significant advantage since not all computers have the same Windows operating systems on them. An example of the NQC code can be found in Appendix A.

There are multiple events used to create a competition amongst the competitors involved. There will be both multiple robot events and single robot events. Multiple robot events will use two or more robots. Single robot events use only one robot for the competition.

An example of a multiple robot event would be an egg relay. In this competition, the competitors create robots with the capability of holding an egg on top of the robot and then exchange the egg with another robot at the next point on the course. The egg would then be exchanged and the next robot would make its way to the next point on the course where the first robot started out. The winner of this event is determined on the basis of time. The shortest time wins.

An example of a single robot event is a distance dash. The rules of this event would be for everyone involved in the event to build a robot for speed. The competitors place their robot at a starting line. The coordinator of the race then starts a countdown for the race to begin. When the race begins, the competitors start their robots on the way towards the finish line a fixed distance away. The object of this event is to finish the course in the shortest amount of time. A sample of an event outline can be found in Appendix B.

The website was constructed using Microsoft FrontPage software. This software was chosen because of the groups’ previous experience with the software and because visually appealing sites can be created quickly and easily. Paint Shop Pro was used for the pictures that can be found on the site. This was also chosen because of the groups’ experience with this program.

3.3 Operating environments

These competitions should only be held in dry environments. There should be no moisture of any kind around the field of competition. This is for the safety of the robots since these robots are not waterproof. A good competition area would be a local high school gymnasium or cafeteria. The surface should have no impure features giving no one team a certain advantage in the competition.

Certain competitions require the use of inclined or declined surfaces. These surfaces need to be set on a flat surface as described previously. Special requirements are stated in the definition of the competition as needed.

3.4 Intended User(s)

The intended user(s) of this project are students in grades ranging from fourth grade to twelfth grade. Each event states what age group it is intended for. The basis behind this is that a fourth grader will not be in a competition with a twelfth grader. These events help the competitor to better understand the possibilities of robot technology and how certain robots can be controlled.

3.5 Assumptions and Limitations

During the planning of this project several limitations were addressed, also some assumptions were made.

Assumptions:

  • The programming language is not that hard to learn. The competing team can write a simple enough program to control the robots for the task at hand.
  • The LEGO MindStorms are available to the schools/competitors.
  • The students want to enter a competition to help them learn about the functions of robots.
  • The events are doable by the robots.

Limitations:

  • The competitor’s knowledge of the programming language that is needed to make the robots perform the event. Since there is a wide range of ages, the events were designed with the age of the user in mind. It could cause a problem within the competition if the events are not targeted for a specific age group.
  • Some robots will not have the capabilities to compete in certain events. The robots might not be equipped to handle certain duties required to do the event.
  • LEGO MindStorms are expensive and it might not be financially possible for a school to have a multi-robot competition.

4 Design Requirements

4.1 Design Objectives

The objective of this project was to use robot events to motivate and inspire student’s interest in science, math, engineering, and technology.

  • Design a manual.

The manual outlines “olympic” style events for LEGO MindStorms

robots. The list includes definitions of various events for individual and team competitions as well as different weight classes, age groups, and control types. Definitions also include criteria for winning, rules, and types of equipment needed for each event. The manual is a compilation of event outlines such as the sample located in Appendix B.

  • Design a website.

A website was created with tutorials explaining and aiding in the implementation of the robot contests. It explains the criteria of the events as well as ideas and plans for designing and building the robots. It also gives useful information about the history of robots and details about the Iowa State University robots, i.e. Oscar and Cybot.

4.2 Functional Requirements

The design of this project had the following functional requirements:

  • Fun and challenging events.

The events give students hands-on experience with robots and technology in a manner as to motivate and inspire future engineers. Contest difficulty is appropriate for various age levels.

  • User friendly website.

The website explains criteria and gives helpful hints for the various events in a manner that students in grades fourth through twelfth can understand. As well as providing information about the history of robots, applications of robots, and details about the Iowa State University robots.

4.3 Design Constraints

The following were the constraints related to the design of this project:

  • Age of Students.

The project needed to consider the amount of understanding at each age group and design events that will be understood at their level.

  • Cost of Robots.

There could be a difficulty in including a large group of students because some schools won’t be able to afford multiple robots.

  • Design of Robots.

There were limits on what types of events the robots could do and the amount and type of parts available, i.e. add-on kits.

  • Time constraint.

The project needed to consider the difficulty in designing the robots for the various events and how much time that will be given to construct the robot before the competition. One factor on the time is whether or not the robots will be built in advance.

4.4 Measurable Milestones

Success of the project was based on the completion of the following key milestones:

  • Project Definition – Defining the project.

10 points expected 10 points received

  • Design – Creating events, rules, and equipment needed.

20 points expected 18 completed

  • Implementation – Creating manual, and website.

35 points expected 35 points received

  • Documentation – Recording all results in an easy to understand manner.

15 points expected12 points received

  • Testing – Have simulated competitions between group members and between actual students.

10 points expected 5 points received

  • Demonstration – Give presentation to Senior Design class and industrial review panel.

10 points expected 10 points received

A passing grade was a score of 80 out of the possible 100 points. The project received a score of 90 out of 100 points. The majority of points were lost in the area of testing because the group was unable to test the results with actual students.

5 End Product Description

The end product of this project was a collection of information about possible LEGO MindStorms robot events. The information contained event descriptions, rules, equipment needed, criteria for winning, age of competitors, and the assumptions and limitations. This material was presented in the form of a website that can help the students with their robot projects. The website also contains information about the history of robots. The purpose of the website was to motivate and inspire future engineers through fun and challenging exercises. Examples of some LEGO MindStorms robots can be seen in Figure 5.1 along with an example arena in Figure 5.2.

(a)(b)

(c)(d)

Figure 5.1: LEGO MindStorms and Equipment

(a) Hank 1.5 Bumper Robot. (b) The LEGO RCX Brick

which is the main controlling unit of the MindStorm.

(c) Lightseeker robot. (d) Minerva 1.5 Lineseeker robot.

Figure 5.2: LEGO MindStorms Arena

6 Approach and Design

6.1 Technical approaches

The different approaches used in this project are the different classes in which the robots participate, the limits to what the robots can be made of, and the activities the robots will do.

6.2 Technical design

There are several designs depending on the competition. The broad categories for the designs are autonomous, hardwired, and wireless. The autonomous design has all the information stored in the robot’s memory and it relies solely on that information to perform the task. The hardwired robots have the operator control the robot to do the task with a control mechanism. The wireless robots are controlled by an infrared, radio frequency, or ultrasonic controller. One technical design may favor the other in a competition when the hardware is at a limited supply.

6.3 Testing description

The robots are tested in competitions using students from targeted age groups. The competition categories include track, maze and obstacle course, weight and strength, vertical, barrier wall, gymnastic, and decathlon events. Acceptance criteria includes time, tasks performed, efficiency, and design style. Grading sheets are used by the judges to mark the performance of a robot in a specific competition. The grading sheets contain the designer, grader, event, place, date, time, results, retest required, and comments. The judging/grading sheet can be found in Appendix C.

6.4 Risks and risk management

One risk was the loss of a team member. To minimize this risk, tasks were performed in teams of 2 or more, so that if one person dropped out, then the other would not know the information. Fortunately, the team did not lose a team member over the year. Another risk was that the technical approaches do not work. To minimize this risk, every aspect of the approaches were tested to make sure they were a good design.

6.5 Recommendation for additional work

It is recommended that no additional work is required for this project. The competitions are fully explained and there are plenty of them. Over the last several years, technology has become a crucial part of the world. It is essential that students become interested and knowledgeable of the advances in technology. Robotic competitions are a great way to inspire and motivate students to become more familiar with technology.

7 Financial Budget

The cost estimates and final costs of this project are provided in Table 7.1. The source of these funds was individual team members. After more investigation into the budget, the original estimated cost was revised. There was no need to buy a LEGO MindStorms robot kit or additional parts due to the generous contributions from Toying With Technology.

Table 7.1: Financial Budget

Item

/ Original Estimated
Cost / Revised Estimated
Cost /
Cost to Date
Robot Kits / $200.00 / $0.00 / $0.00
Additional Robot Parts / $100.00 / $0.00 / $0.00
Printing / $50.00 / $0.00 / $0.00
Poster / $50.00 / $50.00 / $50.00
Total Cost / $400.00 / $50.00 / $50.00

8 Personnel Effort Budget

The amount of time put in by each member of the team contributed to the success of this project. Table 8.1 outlines the estimated, revised, and actual amount of time of each team members’ effort. The team defined a leader, who delegated tasks, and a communicator, who was responsible for correspondences as well as putting reports together. The team worked collectively on all pieces of the project. Each team members’ actual time contributed to date is the fourth column.

Table 8.1: Personnel Effort Budget

Personnel

/

Original Estimated

Effort

/

Revised Estimated Effort

/

Actual Effort

Jonathan Hodapp / 78 hours / 78 hours / 85 hours
Zachery Bowley / 74 hours / 74 hours / 70 hours
Joe Rodgers (Leader) / 90 hours / 90 hours / 81 hours
Joanie Lally (Communicator) / 81 hours / 81 hours / 79 hours
Total Effort / 323 hours / 323 hours / 315 hours

9 Project Schedule

Figures 9.1 and 9.2 are Gantt charts outlining the project schedule for the first and second semesters, showing estimated completion dates for various tasks.