Functional Specification
This document defines the features and specifications of a soccer-playing robot. It also analyzes customer needs and how well the product meets these needs. This document serves as an outline for our product, and will be updated as new information becomes available. Our customers are interdisciplinary researchers who will use this robot to study control systems, system architecture, robotics, and artificial intelligence.
Robot Soccer is an international phenomenon, with elite teams from all over the world gather to pit technique, strategy, and brawn against each other to earn victory on the soccer field. There are currently two international organizations that regulate robot soccer competitions: The Federation of International Robot-soccer Association (FIRA) and RoboCup. Both of these organizations were founded in 1997 and have continued to gain international popularity.
Brigham Young University also hosts a robot soccer competition. Our robot soccer project is designed to be a dominant and competitive team in our BYU competition. This project is the second iteration of the senior project since it was put on hiatus and will involve completely new hardware components. Note that this semester, the final competition will be 1v1 rather than the original 2v2 to allow us time to properly develop and explore the new hardware components.
Robot soccer requires true system-level design. Our team must integrate a wireless communication system, computer vision, feedback control, real-time programming, artificial intelligence, and mechanical design. Second, the overall project is much too ambitious for a single student, so teamwork is essential.
The overall layout of the project is shown in the figure below.
The robots will be competing 1 vs. 1 on a small, walled soccer field. The field will be approximately 5 feet wide by 10 feed long. Goals will be 2 feet wide. An overhead IP camera will provide a video stream to each team's base computer to allow vision algorithms to compute the location and orientation of the two robots and the ball. This information will then be streamed via WiFi to the individual robots, who posses the artificial intelligence to analyze the data and make a competitive play.
Our project is to design the robot system, as well as the computer vision software. These robots will be completely autonomous and will require no human interaction after being activated and placed on the playing field. The scope of our project will involve mechanical design, computer vision, motion control systems, artificial intelligence, and system architecture. Most importantly, all of these systems will work seamlessly together while following the pre-programmed game rules.
Our robots will consist of several subsystems. Processing will be done on an ODROID-U3 running Ubuntu Linux from a microSD card. We will use Robot Operating System (ROS) to allow inter-process communication. All our robots will be equipped with a USB WiFi adapter to allow communication. Our robots will be powered by two 7.2 V NiMH batteries connected in series. Mobility will be provided by 3 omnidirectional wheels driven by motors. The Roboclaw 2x5A board will be used to control the motors. Finally, the robot will include a solenoid-powered kicker to allow it to shoot the ball at a distance.
Our project will need to meet requirements specified by both the BYU robot soccer competition and our customers. To design the best product possible, we gathered input from our customers and studied the competition rules. Our customers have provided several different constraints. Some are more important to the success of the project than others. Furthermore, some would require more resources than we have available for this project in our current time frame.
Our product cannot compromise in meeting game rules. Consequently, meeting all of the rule constraints are top priority. We then analyzed the customer requirements and prioritized them based on their importance to the success of the project.
Our mission is to create a fully autonomous robot that through superior hardware and software design is capable of playing within specified game rules and outperforming the competition.
####Game Rules#### One set of requirements come directly from the rules of the BYU robot soccer competition:
- Robots must fit within a cylinder of 8-inch diameter and 10-inch height.
- The ball is a standard golf ball, the color will be determined by majority vote.
- The playing field is 5 feet wide by 10 feet long. The sides of the field are angled so that a ball cannot get stuck against the sides or corners.
- Goals will be 2 feet wide.
- Robots must be designed in a way that will not damage other robots, the playing field, or human spectators.
- Kickers are not allowed to shoot the ball hard enough to damage other players.
- Robots must avoid collisions.
- Any contact with a defender while in the defense area will be a violation.
- Outside the defense area, contact that noticeably changes a player's orientation, position, or motion will be a violation.
- We will not observe the traditional off-sides rule.
- Robots cannot drop parts on the field.
- Robots are not allowed to fix the ball to their frame or encompass the ball in any way that prevents access by other players.
- Timing
- A game will consist of two 90 second halves.
- Half time will be 60 seconds.
- There will be a 120 second break between games, with at most a 15 second grace period.
- To signal that a team is ready, one team member raises his/her hand.
- Initial/Reset Positioning: At the beginning of play,
- The ball will be placed inside the center circle.
- Teams will place their robots outside of the center circle, but on their half of the field.
- Teams place their robots first, the ball is placed second.
- Time-outs
- Each team can take (at most) one 15 sec time-out during each half.
- Teams request a time-out to the referee. After a request has been made, referees will declare the time-out the first time when:
- The ball is no longer moving.
- The opposing team is not advancing the ball towards its goal.
- At their sole discretion, referees can call a 15 sec technical time-out when:
- The ball is no longer moving.
- The ball is not inside one of the two goal boxes.
- Both teams seem to be non-functioning.
- After each time-out, play will resume from the initial/reset position.
- Interacting with Robots/Ball on the Field
- Teams are not allow to bump, nudge, kick, or touch the ball or the robots during play.
- The only physical interaction with robots and the ball will be during time-outs or between play.
- When the clock is running, team members are not allowed to touch their computers.
- Scoring
- A goal is scored when the ball breaks the plane of the back line of the goal box.
- If a game ends in a tie, there will be a sudden death period lasting at most 90 seconds.
- Play stops when the first goal is scored.
- Teams will have (at most) one 15 sec time-out during the sudden death period.
- There will be a 60 second break between normal play and the sudden death period.
- If neither team scores during the sudden death period, the match will be determined by a coin toss.
- The Home team calls the coin toss.
- Robot Appearance/Construction
- The Uniform must be securely fastened to the top of the robot.
- All cables, wires, batteries, etc. must remain inside the robot and out of view of the overhead camera.
- Side panels must be sufficiently sturdy to keep the ball from being lodged inside the robot.
- Excessively Aggressive Play
- Robots are to avoid collisions with other robots.
- A robot that repeatedly causes substantive collisions may be penalized for excessively aggressive play.
- The first offense will receive a verbal warning, with no stoppage of play.
- The second offense will cause play to stop, and players will reset in the initial/reset position, except that the penalized robot will be placed near the side of the field (still near midfield).
- Penalties and warnings will be called at the sole discretion of the referee.
The table below specifies our customers requirements. We have ranked them by priority.
Priority: 1 = Very High, 2 = High, 3 = Moderate, 4 = Low
| Req. # | Customer Statement | Interpreted Need | Priority |
|---|---|---|---|
| 1 | Follow the rules of the game | Robot's AI must abide the BYU competition rules. | 1 |
| 2 | Win the game | Robot must be competitive and be able to score on the opposing team. | 1 |
| 3 | Be able to kick into the goal from any field position | Robot must be able to find goal and kick with enough strength to reach the goal. | 3 |
| 4 | Batteries last the whole match | Robot should be power efficient to maximize battery life. | 1 |
| 5 | Robots can block shots from going in goal | Robots can maneuver between ball and goal from any arbitrary position. | 1 |
| 6 | Robots are agile and move quickly | Robots can move in any direction, change direction quickly, and have high speed. | 3 |
| 7 | Robots are robust | Robots can survive being hit by ball or other robots without issues. | 3 |
| 8 | Robots look cool | Robots appearance well designed and constructed with precision. | 4 |
| 9 | Robots are not expensive | Robots use commercially available, low-cost components. | 3 |
| 10 | Robots have an easy to use API | Software is well organized and clear documentation is available. | 2 |
| 11 | Easy to add and modify tactics | Software is extensible so tactics can be added/modified without breaking it. | 2 |
| 12 | High cross compatibility with common protocols | Common communication standards and software are used (e.g., WiFi, Linux, C++) | 4 |
| 13 | The system is simple | Software has a minimal amount of code and the robot has minimal components. | 2 |
| 14 | Vision algorithms are accurate and fast | Computer vision software can precisely and accurate location robots and ball. | 1 |
Measurable engineering characteristics and target values are critical for our design. This section outlines both the metrics we will use along with ideal and actual results.
| Metric # | Req. # | Metric | Ideal | Margin | Units |
|---|---|---|---|---|---|
| 1 | 2,5 | Goals scored minus conceded goals | >2 | >0 | goals |
| 2 | 5 | Percentage of shots blocked given random speed angle (max 1m/s) | >99 | >80 | percent |
| 3 | 3,14,5 | Maximum difference between calculated positions and actual positions | <1 | <5 | cm |
| 4 | 9 | Maximum total cost of additional components of robot | <25 | <50 | USD |
| 5 | 13 | Maximum number of physical components in the robot | <10 | <20 | components |
| 6 | 6,5 | Maximum speed of robot in one direction | >200 | >100 | cm/s |
| 7 | 13,10,11 | Number of lines of code (total) | <5000 | <8000 | lines |
| 8 | 6,4 | Maximum weight of a single robot | <5 | <8 | kg |
| 9 | 4 | Minimum battery life while robot spins in place | >60 | >30 | minutes |
| 10 | 7 | Minimum weight that robot can withstand uninjured | >8 | >5 | kgs |
| 11 | 3 | Percentage of goals when robot moves to randomly placed ball and kicks | >99 | >80 | percent |
| 12 | 1 | Compliance to the rules | 100 | 100 | percent |
| 13 | 8 | Beta customer ratings on product aesthetics | >8 | >6 | scale from 1 to 10 |
| 14 | 12 | Compliance with 802.11b/g/n standards; Compatible with Linux 3.12 | 100 | 100 | percent |
Here, we list a description of each metric and how it will be tested.
Metric 1: This metric is simply a judge of how effective our robot soccer players are. We would like to win each match by a margin of 2 pts. We can gather data after each match.
Metric 2: This tests the effectiveness of both our computer vision algorithms and the ability of our onboard AI to react to the ball. The robot will be placed at a random location on the home-side of the field. A ball can then be shot towards the goal from the away side of the field with random starting location and varied speeds (with a maximum speed of 1m/s) and we can calculate the percentage of shots block out of 20 shots taken.
Metric 3: This tests the accuracy of our computer vision algorithms. We will give the robot commands to line up directly behind the ball, facing the goal. We can then measure how well-centered the robot is with the ball and goal.
Metric 4: We want our robot to be affordable on a student budget. We will track how much we spend on additional components outside of the hardware that was provided us (e.g., Odroid, RoboClaws, motors, etc.) and record the total.
Metric 5: For simplicity, we want our robot to be made of a few subsystem components as possible. This is simply the total count of these subsystems (e.g., 3 motors, 2 batteries, 1 power board, etc). We count systems as a unit, not minuscule components like resistors/capacitors/wires.
Metric 6: We want to measure the maximum speed of our robot moving forward in a straight line. To measure this, we can time how long to takes for the robot to travel a pre-measured distance.
Metric 7: This metric will count the total lines of code we produces for the software and artificial intelligence of the robot (including comments). This just provides a rough measure how our code's simplicity.
Metric 8: To improve battery life and speed, we want our robot to be lightweight. This is just the measure of the mass of the fully assembled robot as a whole (including batteries).
Metric 9: To get a sense of how long our battery will last during a game, we measure how long it takes to drain a fully-charged battery by simply spinning the robot in place.
Metric 10: This metric will not be tested until the failure point. Rather, we will simply place weight on the robot's top as well as placing weight on the robots side (by laying it down sideways) and confirm that the body can handle the specified amount of weight.
Metric 11: To test the accuracy of our robot's kicks, we randomly place the ball on the field. Then, we allow the robot to turn to face the goal and shoot. We measure the percentage of shots that went in out of 20 shots taken.
Metric 12: To participate, our robot must obey all competition rules. We need to go through all the rules and verify that all are met.
Metric 13: We will ask a sample of people to rate the aesthetics of our robot on a scale from 1 to 10 and take the arithmetic average.
Metric 14: In order to operate, our robot will need to run Linux and be able to receive data over WiFi.
Note that several of these metrics are related to each other. As we design our robot, we will need to be aware that changed made to meet one metric may affect another. For example, change in the weight of the robot may affect the maximum speed of the robot and how long the battery lasts.
In order to meet the expectations of our customer's need, we will create prototypes to test based on this Functional Specification Document. This document outlines our requirements and priorities. It also summarizes the hardware we will have to use along with a brief description of how our software should behave. The document also provides high level diagrams and descriptions of the robot soccer competition as well as the robots themselves. Most of the individual subsystems and components that will be used are well documented. Our principle challenge will be integrating these separate parts into a competitive soccer-playing robot. There will be two general stages of development. First, we will create a mechanical prototype and software architecture that allows us to communicate with and move the robot in simple patterns. Second, we will fine tune our artificial intelligence to utilize more effective and fine-tuned strategies. To accomplish this goal, we will create a schedule to meet different benchmarks. During development, we will work on meeting as many metrics as possible until the deadline.