Session F3D COMPETITIVE ROBOT SOCCER: A DESIGN EXPERIENCE FOR UNDERGRADUATE STUDENTS James K. Archibald1 and Randal W. Beard2 Abstract This paper describes our approach to the culminating design experience for electrical and computer engineering majors, currently in its fourth year. In a single semester course, teams of students design, build, and program robots to play one-on-one soccer autonomously. Each robot has an onboard microcontroller and a wireless link to a dedicated computer that is connected to a camera above the playing field. Each team must fabricate its own robot and write the software required to process the camera image, communicate with the robot, implement the low-level control, and make high-level playing decisions. The likelihood of each team’s success is enhanced by a series of lectures and labs focusing on both technical and process management aspects of the project. Climaxing in a wellattended final competition in a public venue, the project has proven to be popular with students, faculty, and industrial sponsors alike. Index Terms Culminating design experience, robot soccer, senior design projects, teamwork.
fourth year, the project has completely changed the structure of senior projects in our department. Our original objective for the project was simply to give good students an opportunity to participate in a demanding, yet rewarding project that would make them aware of how much they can really accomplish. As the project matured, it became obvious that it offered an unparalleled opportunity to give our students important experiences that are in short supply elsewhere in our curriculum. The most noteworthy of these are working as part of an interdisciplinary team, honing presentation and writing skills, and discovering firsthand the challenges of managing an engineering design project with an aggressive schedule. In this paper, we describe the robot soccer competition and the structure of the course that prepares students for the competition. We also discuss the lessons we have learned over the years of refining this course and conclude with our plans for the future. We hope to motivate similar efforts at other institutions and welcome contact from interested faculty members.
INTRODUCTION AND BACKGROUND
COMPETITION DETAILS
Our primary motivation for developing a new approach to senior projects was a deep dissatisfaction with the approach that had existed for years in our department, in which students were essentially on their own in devising and completing their projects. Generally students lacked the perspective and experience required to pick a project of an appropriately size; cautious students would select projects that resembled slightly expanded class lab assignments, while ambitious students focused on problems that were far too challenging. While faculty mentoring helped to improve the situation, advising was uneven at best. Advisors were often assigned projects that had little if any connection to their areas of interest or expertise. Several years ago as we began a research project involving the creation of custom robots, we realized that mobile robots are ideal for undergraduate design projects, given the breadth of technical topics and the system integration issues that must be addressed in their construction. In our first robot-based undergraduate design competition, two teams of students built and raced linetracking robots that followed paths (including dead ends) consisting of black tape on a white-tiled floor. After the second year of line-tracking robots, we decided to switch to the more challenging venue of robot soccer. Now in its
A major challenge with any competitive project is to have enough rules in place to keep it fair and enough flexibility to encourage creativity. Of course, rules are also important to limit expenses and to allow the use of common equipment. In our project we make available to the students many different hardware resources that they are encouraged but not required to use. Some funds are available to purchase additional equipment if it will be too expensive for the students to purchase and if it is likely to be of use to teams in future years. Another challenge faced in a project of this type is avoiding design stagnation. To avoid this problem, we have changed project details over the years. For example, robots in our first year of competition were required to fit into a 12inch cube, while this year’s robots must fit into a 7-inch cube. While we strive to keep them consistent, the playing rules themselves are updated each year as yet another crop of bright students find loopholes or ambiguities to exploit.
1 2
Equipment The playing field, roughly the size of a ping-pong table, is green with white lines and enclosed by a 3.5-inch wall. A yellow golf ball is used as the soccer ball. Figure 1 shows two robots on the field during a practice competition.
James K. Archibald, Dept. of Electrical and Computer Engineering, Brigham Young University, Provo, UT 84602,
[email protected] Randal W. Beard, Dept. of Electrical and Computer Engineering, Brigham Young University, Provo, UT 84602,
[email protected]
0-7803-7444-4/02/$17.00 © 2002 IEEE November 6 - 9, 2002, Boston, MA 32 nd ASEE/IEEE Frontiers in Education Conference F3D-14
Session F3D
FIGURE 1 ROBOTS COMPETING IN A P RACTICE MATCH
Each team is provided with a Linux workstation complete with a frame-grabber connected to a video camera suspended over the playing field. Each team is also given a wireless transmitter/receiver pair used for communication between their robot and workstation. Jamming of the RF communications of another team is prohibited. Teams design and fabricate their own robots from their choice of materials. An MIT Handy Board [1] is provided to each team; students may choose another microcontroller but they are on their own regarding support and development tools. Motors, batteries and other relatively expensive components are available for checkout from the department storeroom. Less expensive items such as wheels, wiring, and the chassis must be provided by team members. Everything on a robot that is visible to the camera is required to be black or dark gray, with the exception of square colored markers that constitute the player’s uniform that must be placed atop each robot. Each robot has a permanently attached green marker; a blue or red marker is also added depending on whether the player is on offense or defense. No part of the robot, including the top markers, the RF antenna, and any moveable parts, is allowed to extend beyond the 7-inch limit. The playing field, camera, and computers are located in a room dedicated to this project for the semester, but the final competition is held in an open study area on the main floor of the engineering building that can accommodate more spectators. Because the entire west wall of the study area consists of windows, the natural lighting conditions during the tournament are constantly changing, in contrast with the static lighting in the windowless project room. Students must take this into consideration in their designs. Competition Format The current competition format is loosely based on one-onone MLS shootouts [2]. The offensive team places its player anywhere on its own half of the field outside the center circle. The defensive team then places the ball anywhere within the center circle and its own robot so that part of it
touches the goalie box. Strict timing of the placement sequence is enforced to keep the match moving along and spectator friendly. Once the robots and the ball are placed, the referee says “go” and play begins. After an initial keypress to tell the robot to start play, human involvement is prohibited. To reduce the impact of having a temporarily disabled robot (perhaps from RF interference on a particular channel, or too often because the team forgot to turn the robot on!), we divide each competitive match into several shorter periods of play. Each match consists of three innings, each of which consists of two plays, each of which lasts 30 seconds or until a goal is scored. On each play, the teams switch between offense and defense and they trade halves of the field. Thus, in every match, each player has three opportunities on offense and three on defense. Switching ends of the field avoids handicapping one team because of lighting anomalies or irregularities in the playing surface. Once play begins, offensive and defensive robots are free to go after the ball and attemp t to score, subject only to the playing rules described below. Thus, the assignment of a robot to offense or defense affects only its initial placement. The winner of each match is the team that scores the most goals in the six plays. In the event of a tie, the match is extended with overtime innings until one team is ahead. The final competition itself is organized as a double elimination tournament held on an afternoon near the end of the semester. Seeding for the tournament is based on performance in preliminary competitions. The scheduling of the tournament is fixed from the beginning of the semester, allowing the students to discover the challenges of meeting a hard deadline. Playing Rules Robots are not allowed to carry the ball, defined as trapping it or holding it in such a way that it cannot be taken away by an opponent. The use of adhesives or suction devices to physically attach the ball to the robot is prohibited. Also prohibited are robot shapes that allow unfair control of the ball or that block the view of the ball from overhead. Concave openings in the robot’s body can be no deeper than half the ball’s diameter, and half the ball’s diameter must be visible from directly over the side of the robot in contact with the ball. Physical contact between robots is unavoidable, but aggressive or uncontrolled movement that could damage an opponent or the playing field is prohibited. Similarly, kicking the ball hard enough to damage another robot is prohibited. Rule violations are penalized as fouls at the sole discretion of the referees. It practice, it is often difficult to identify an aggressor when robots collide, but some cases are obvious, such as when one robot moves at high speed into another stationary or slow moving robot, or when one robot shoves another out of the way. Fouls that are particularly egregious and damage the opponent may result in forfeiting a match and
0-7803-7444-4/02/$17.00 © 2002 IEEE November 6 - 9, 2002, Boston, MA 32 nd ASEE/IEEE Frontiers in Education Conference F3D-15
Session F3D disqualification from the tournament, but robots are generally quite sturdy and we’ve never had to exercise this option. For normal fouls, the current play is restarted with the fouled player on offense. The time left in the play is reset to at least 15 seconds so that fouled player has a realistic opportunity to score. To keep play moving along, referees may call tie-ups when robots are locked up for a few seconds and appear to be unable to disengage. Tie-ups cause a restart of the current play without any added time. To prevent robots from playing too conservatively (e.g., simply pinning the ball against the wall), referees may call obstruction or stalling on a particular player. The former is treated as a tieup, the latter as a foul.
COURSE STRUCTURE AND DETAILS Participants in robot soccer currently enroll in a onesemester, four credit-hour course offered every Winter Semester. In prior years participants registered for two separate courses of two credit hours each over consecutive semesters; this is our first year of having them complete the entire project in one semester. To increase their chances of success, we increased the size of each team from three to four members. Students are free to form their own teams, and some are organized and meeting well before the semester in which they are enrolled in the class. We strongly recommend that each team have at least one individual with a strong background in each of the listed prerequisites for the course, including control theory, realtime systems, and artificial intelligence. Regardless of other divisions of labor, all team members need to be competent programmers. Teams are finalized by the end of the first day of class so that responsibility for the labs and written documents can be worked out at the outset. This semester we have 40 students enrolled, or 10 teams of 4 students each. We have two dedicated TAs who competed in the contest last year and therefore have lots of practical knowledge to help students when they get stuck. The content of the course is carefully structured to guide the students through experiences in the first month that will ensure their success over the entire semester. The course is divided into three tracks, each of which meets one or more days each week for the first four weeks of the semester. These three tracks are business processes, low-level technical, and high-level technical. Figure 2 shows the semester schedule over each of the 14 weeks. As the semester schedule shows, much happens in the first 4 weeks, including 8 business process lectures (BP), 4 low-level technical lectures (LLT), and 3 high-level technical lectures (HLT). Most of these lectures are accompanied by writing assignments or labs to be completed be each team. While a lot of work is required of the students in the first month, they see tangible results from their labors, including a functional prototype robot and a good start on their control software and architecture. (In fact, the level of
effort required is such that the work can be completed only if good teamwork is employed and tasks are evenly distributed.) This experience gives them the confidence to design and construct their own robot from scratch, and to customize the control software for their own hardware and playing strategies. Although students are free to use the prototype robot throughout the entire semester, every team so far has elected to build their own custom robot. Week 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Mon BP 1 BP 3 BP 5 BP 7
Wed BP 2 BP 4 BP 6 BP 8 PC-sim DR
Thurs LLT 1 LLT 2 LLT 3 LLT 4
Fri HLT 1 HLT 2 HLT 3 PC DR
PC DR
PC DR
PC
PC Tourney DR
DR
FIGURE 2 SEMESTER SCHEDULE FOR ROBOT SOCCER SENIOR P ROJECT
Practice competitions (PC) are scheduled on a roughly monthly basis; the first of these uses a simulator rather than real hardware robots. The practice competitions give teams an opportunity to see how their robots and playing software work under pressure. Design reviews (DR) are held monthly for each team with the instructors, TAs, and representatives from industrial sponsors. In a short 15-minute presentation, team members are expected to address key elements of their design and strategy, and their progress relative to their team schedule. Students may not attend another team’s design reviews so all information presented remains confidential. Teams are given feedback on the spot regarding both the presentation itself and their design ideas. Absent a possible rule violation, our technical feedback is generally advice that they may follow or ignore as they choose. (Fortunately the team that hoped to do a hovercraft abandoned the idea; it was not our strong recommendations that convinced them, but rather a failed prototype.) Grading for the course is based on a combination of the quality of the team’s control documents, the quality of their presentations in design reviews, timely completion of assigned labs, and the quality of their entire system at the final competition. In the absence of unusual circumstances, all members of a team receive the same grade on all assignments completed as a team. The remainder of this section describes the content of the lectures and the assignments for each of the three tracks.
0-7803-7444-4/02/$17.00 © 2002 IEEE November 6 - 9, 2002, Boston, MA 32 nd ASEE/IEEE Frontiers in Education Conference F3D-16
Session F3D Business Process Track The goal of the lectures and assignments of this track is to teach a systematic design process that includes an evaluation of customer needs, product specification, and the designtest-debug cycle. These lectures are given by an adjunct faculty member with many years of industrial experience. The titles of these lectures are given below. • BP 1: Working in teams • BP 2: Capturing the voice of the customer • BP 3: From customer needs to product specifications • BP 4: Product architecture and concept generation • BP 5: Developing project schedules • BP 6: Giving effective presentations • BP 7: Business processes overview • BP 8: Engineering economics
•
•
• Major assignments in this track take the form of written control documents that each team must produce and then update as needed throughout the semester. They summarize the team’s work as it defines design objectives, evaluates a wide variety of design alternatives, makes concrete design decisions, and plans a detailed schedule. Required documents include: • Functional specifications, • Concept generation and selection, and • Project schedule. In addition to the team documents, student complete individual assignments on such subjects as team processes, lifelong learning, and contemporary issues. Although not shown on the schedule above, occasional guest speakers come after the first month to speak to class participants on a variety of subjects, including (this semester) product testing, business ethics, and legal aspects of product development. Each team is assigned file space and required to create and maintain a web site over the course of the semester. All documents must be made available via the team webpage which is password protected to restrict access to the team and the course instructors. At the end of the semester, all webpages become publicly available for teams in following years [3]. Providing access to design documents (and, in most cases, software) of previous teams ensures that the quality of the robots and their playing abilities increases noticeably every year.
•
LLT 1: Robot construction and design. Each team builds a prototype robot that can be driven from the computer keyboard. The RF link, the microcontroller, and the DC motors must be integrated. Unoptimized prototype software is provided to the students so they can get something working right away; most teams start optimizing that software from the outset. LLT 2: Computer vision. Students are given unoptimized software to process the image from the overhead camera. They must modify the software to return the ball position, the position and orientation of both robots, and the velocity and angular velocity of each. With some effort, most teams are successful in optimizing the code to achieve sample rates of 30 frames/sec, about three times the rate of the unoptimized code they start with. LLT 3: Low-level control. Students write the C code for a specified set of skills and related utilities. Skills developed in this lab include (a) moving with a particular angular speed for each wheel, (b) moving with a particular linear and angular speed, (c) moving to a particular point at a particular angle, and (d) turning to a particular angle. LLT 4: Motion planning. Students implement a waypoint path planning technique of their choosing that can be used in conjunction with a deliberative AI approach. They also explore a potential fields method that can be used in conjunction with a reactive AI approach. (The software architecture layers labeled AI, or artificial intelligence, and plays are created in the high-level technical track. and discussed in the next section.)
Low-Level Technical Track This track focuses on all components of the hardware block shown in Figure 3, including the construction of the robot, the RF communication, and the vision software. In addition, this track deals with the creation of skills, utilities, and conditions in our software architecture. (Hardware-specific details are encapsulated in utilities and conditions; skills correspond to low-level control routines.) Lectures present FIGURE 3 the information required to complete the associated lab. The SOFTWARE ARCHITECTURE AND SYSTEM OVERVIEW titles and contents of these labs are detailed below. 0-7803-7444-4/02/$17.00 © 2002 IEEE November 6 - 9, 2002, Boston, MA 32 nd ASEE/IEEE Frontiers in Education Conference F3D-17
Session F3D High-Level Technical Track
Although the simulator has been used for just one semester, we feel it has had a noticeable impact on the quality of play. The most recent addition to our course, this track focuses on The project is very successful in promoting teamwork. the creation of a mechanism to support intelligent play. Past In general, team members pull together, cover for each other teams too often put off plans for high-level playing strategies in times of need, and develop a strong team identity – often until their robots were complete, leaving too little time for to the point of having team shirts and logos. Students are the implementation of a well thought-out structure. All labs aware from the outset that they succeed or fail as a team, that of this track use a custom simulator that has the same they can’t complete the project on their own. We note that interface (desired velocity and angular velocity) as the only one team of 26 to date has failed to produce a robot that hardware robot, as shown in Figure 3. The simulator uses a could compete in the final competition. client-server execution model, making it easy for teams to While the expenses for the project are relatively modest, compete without recompiling or sharing source code. particularly after the initial investment, we have been The simulator makes possible the development of highfortunate in getting the necessary resources. Our department level software concurrently with the robot hardware. Since chair has been very supportive of our vision and generous in the interface is the same, the code developed can be used committing department resources for computers, teaching without modification on the robot. Labs focus on the assistants, and miscellaneous supplies. Industrial sponsors creation of AI and plays in the software architecture. have helped cover the exp enses of cameras, frame-grabbers, Lecture and lab content are summarized below. RF links, microcontrollers, and motors. • HLT 1: Simulator and software architecture. Once the basic hardware is in place, good TAs are the Students are introduced to the software architecture and most important resource in ensuring the success of the to the simulator and its operation. They are given project. From the first year, we have been successful in sample client code that handles the connection to the recruiting one or more of our best students in the class to server, and they are given object code for a set of serve as TAs for the next year. With good TAs the faculty unoptimized skills. Each team must write code to make overhead of this course is very reasonable. For the TAs its simulated robot score on a simple play against an themselves, the experience can be very positive, increasing immobile opponent. their self-confidence and their interest in further education. • HLT 2: Play construction. We present and discuss The class continues to increase in popularity every year. alternative methods of implementing plays, each a Enrollment has grown from 12 participants in each of the sequence of skills. An example play might be blocking first two years to 24 last year to 40 this year. Enrolling a moving ball, pushing it up field, and taking a shot. students tell us that they’ve heard the class is a lot of work Students are required to implement at least 4 plays of but worth the effort. (The $2000 in donated prize money their choosing, and they are to develop enough code to awarded to the top two teams probably helps to get their defeat a relatively unskilled opponent we provide. attention!) Many students have noted how this experience • HLT 3: Artificial intelligence. We discuss different AI completely changes their job interviews. Once they mention techniques, or methods to pick good plays given the their involvement in the project, conversation seldom shifts current game situation. Each team is required to have to any other topic. selected and implemented a consistent AI mechanism. When we began the robot soccer project, our colleagues Commonly selected approaches include deliberative, wished us well but most assumed we would ultimately reactive, and hybrid techniques [4]. Each team’s abandon our efforts just as others who had tried previously simulated robot must defeat a reasonably capable to revamp senior projects in the department. As the success opponent that we provide. of our project became more apparent, the general approach to senior projects became a serious topic in department OBSERVATIONS AND ASSESSMENT discussions, fueled in no small part by our concerns about our next accreditation visit under the new ABET guidelines The robot soccer project has been very successful, in many [5]. It became clear that robot soccer and similar projects ways more than we had initially hoped. In this section we offered excellent opportunities to address issues such as discuss some measures of its success, factors that have teamwork, writing, and presentation skills while satisfying contributed to its success, and some of the impact that this requirements for the culminating design experience. project has had in our department. The department faculty voted to change the BS degree Perhaps the most obvious measure of the overall success requirements to require the completion of robot soccer or of our project is the steady improvement in the quality and similar project. Within the same general framework, other reliability of the robots and their level of play in the final projects have been created, including: competition. We feel this is the result of many factors, • The design and testing of a VLSI chip. including an ongoing refinement of lectures and labs, and • The design of a software radio. the comprehensive webpages that facilitate the accumulation • The design of an embedded computer using Bluetooth. of knowledge over time. The latter allows teams to learn • The design of an isolinear chip and related system. from the lessons and avoid the problems of the past. 0-7803-7444-4/02/$17.00 © 2002 IEEE November 6 - 9, 2002, Boston, MA 32 nd ASEE/IEEE Frontiers in Education Conference F3D-18
Session F3D In any semester, each project offered has its own technical lectures and schedule, but all share the same business lectures. (This sharing requires some compromise on schedule and content.) Individual projects are created and discontinued as desired by groups or individual faculty members. Faculty propose new projects for several reasons: to expose students to something new, to lay the groundwork for new courses, or to recruit students to related research projects. The number of choices offered seems about right for our department (roughly 120 graduates this year). The impact of the project in our department is not limited to the creation of a new senior project framework. Enrollment in all three courses listed as prerequisites (realtime systems, AI, and control theory) has increased substantially in the last two years. For example, although the robot soccer class is surely not the only cause, enrollment in the control class has more than doubled. Most of the increase comes from computer engineering majors. Moreover, the control class itself was recently reorganized so that its labs focus on mobile robots. Since the control theory and robot soccer classes are taught alternate semesters, they are able to share the same lab facilities, including playing field, camera, and computers. We note that this project is well suited for interdisciplinary teams. While participants are typically our own computer or electrical engineering majors, we have had one mechanical engineer participate, and the project could easily accommodate computer science majors as well. Any problems involving students from other departments in the project are political in nature, not technical. The project has received very favorable response from industrial sponsors. None are interested in the specifics of preparing students for work in robotics per se; instead, they are attracted to the teamwork aspect of the project, the indepth exposure to the design process and management mechanisms, and the enthusiasm the project generates for engineering creativity. We invite our industry sponsors to send a representative to each of the design reviews; sponsors appreciate the increased visibility in the department and the opportunity to see how students perform in a setting similar in many ways to the engineering workplace. Moreover, our industrial partners have provided valuable input about possible improvements to the project and the course content. Finally, we have discovered that a robot soccer competition can be an effective outreach tool for all of engineering. Our final competition often makes local and regional news coverage in newspapers and TV. Unlike most technical things we spend our lives working on, a contest between highly skilled soccer-playing robots can be appreciated by just about anyone, regardless of their technical background. To those who experience the energy and excitement of the final competition, the project conveys the enthusiasm that we each feel for our own work as engineers. To the general public, and particularly potential engineering students, the project seems to say: “engineering is both challenging and fulfilling.”
FUTURE PLANS The technical aspects of the project will continue to evolve. As soon as it is feasible, we plan to reduce the size of the robots (to perhaps 5 inches on a side) and to move to twoon-two competition, with each team fielding two robots. Teamwork aspects such as passing and maintaining formation will expose students to current research challenges in multi-agent systems. The content of the high-level technical lectures and labs will be refined and expanded accordingly. The problem of playing well as a team will challenge students for many years to come. One of our goals is to expand industrial support for the project. We plan to use the increased funding to supplement department funding so that robot soccer TAs are supported year-round to keep up the pace of technical development, to continue our outreach programs, and to provide support to partner schools. We also hope to involve other schools and to create a level of inter-collegiate competition for the best teams at participating universities. In 2000, an IEEE Spectrumsponsored student team from San Diego State University participated in our tournament [6]; the interaction was very good for our students. Industrial sponsors have indicated a willingness to support such a competition. Interested parties are invited to contact us. We plan to continue our outreach efforts by extending special invitations to science and math clubs from local high schools to our final competition. We also plan to continue to produce video summaries of our tournaments for dis tribution on CDs and via the web. We hope our efforts make a difference in encouraging individuals to consider engineering as a career, and in encouraging other universities to consider robot soccer projects for their undergraduate students.
ACKNOWLEDGMENT We are grateful for our industrial partners, past and present, who have supported our efforts with funding, equipment, technical advice, and encouragement. These include Motorola, the International Foundation for Telemetering, and the Micron Technology Foundation. We are also very grateful for the generous financial support and encouragement of our department.
REFERENCES [1]
http://el.www.media.mit.edu/groups/el/projects/handy-board/
[2]
http://www.mlsnet.com/
[3]
http://www.ee.byu.edu/ee/srprojects/robot/
[4]
Arkin, R.C., Behavior-Based Robotics, MIT Press, 1998.
[5]
Accreditation Board for Engineering and Technology, “Engineering Criteria 2000”, March 2000.
[6]
Cass, S., "Robosoccer", IEEE Spectrum, Vol. 38, No. 5., May 2001, pp. 75-77.
0-7803-7444-4/02/$17.00 © 2002 IEEE November 6 - 9, 2002, Boston, MA 32 nd ASEE/IEEE Frontiers in Education Conference F3D-19
