CONCEPT GENERATION AND SELECTION
Robot Soccer
ECEn 490 - Senior Project - Winter 2015
Aperture Science
Aaron Swenson (Leader)
Samuel Farnsworth
Derek Stewart
Craig Call
TABLE OF CONTENTS
Introduction 3
Overview 3
Purpose 3
Procedure 3
Body of Facts 4
Specification and Facts 4
Proposed Design 5
Concept Selection 6
Scoring 6
Methods of Scoring 6
Concept Definitions 6
Design Evaluation Metrics and Weighting 7
Design Cost Function Matrix 8
Results 8
Vision Tracking Markers 9
Methods of Scoring 9
Concept Definitions 9
Design Evaluation Metrics and Weighting 10
Design Cost Function Matrix 10
Results 11
Control Systems 12
Methods of Scoring 12
Concept Definitions 12
Design Evaluation Metrics and Weighting 12
Design Cost Function Matrix 13
Results 13
Conclusion 14
INTRODUCTION
Overview
Ever since man created the computer, he has dreamed of constructing an autonomous device with human sentience resembling his own. Though we are not quite there, this project is designed to take us a step or two further in that direction. We will construct a robot that is to fit within a 160π cubic inch cylinder. It has an ODroid embedded processing system inside the robot and a WiFi chip to connect to the vision processing desktop off-board. It has three wheels along with a control chip to power and move them. Except for the camera and image processing, everything that the robot needs to play the game is contained inside the robot.
The relative size, shape, layout and arrangement of all the physical components as well as the programming implementation are within the scope of design possibilities and the basis of our uniqueness versus other teams. Many of these design decisions are independent of each other and can be analyzed individually. However, some of them (like the vision and control systems) are inherently dependent on each other.
Purpose
This specification is intended not only to record our design decisions, but to document the reasoning and rationale behind them. This allows us to analyze the costs and benefits of other proposed solutions. Relatedly, it provides opportunity for consistency in our metrics, rubrics, and standards which, in turn, supplies a method for comparing the several concepts. Additionally, it may also inspire solutions to other, possibly unrelated, issues. The main categories we need to consider for this are Physical and Computational.
The physical category principally comprises the mechanical and control systems while the computational encompasses the image and vision processing alongside artificial intelligent functionality. This document is intended to enumerate the different possibilities as well as view them in conjunction with other options.
Procedure
Pursuant to a recommendation made in class, these critical decisions will be divided. Each possible solution will have a weight of how it contributes to the issue at hand. The sundry parts of that issue may have importance rankings to better tailor the solution to the problem. Visually, this is represented by a Design Cost Matrix showing the effect a given proposition has on the various parts of the query.
After scoring, the matrix entry with the best overall score is selected to solve the problem. If it is possible to merge some answers together, the resulting implementation might be benefited from such an approach. This allows for the best part of the differing implementations to be combined, if the design permits it.
BODY OF FACTS
Specification and Facts
Create an autonomous robot that can:
-Respond to visual image data input and move accordingly
-Modify its behavior according to different AI strategies
-Communicate via WiFi with other team-bots and the image desktop
-Move in any two dimensional space
-Fit into a 8 inch diameter cylinder
Because the vision and image processing is very time and resource intensive, it will not be done on the ODroid embedded system. Instead, it will be done on a separate desktop computer. All other processing and implementation will be on the ODroid.
This requires:
AI/Scoring
-A series of algorithms dictating gameplay and movement
-Different strategies for earning points
-A relatively optimized program to cut down on latency
-A ROS Architecture to abstract details
-Tracking objects and responding to temporally proximate events
Control
-A three-wheeled robotic structure
-A roboclaw to power and move the wheels
-A PID Controller
-Execute and Stop commands
Vision
-A program (written with OpenCV) to convert raw data to digital format
-A camera with video feed of the arena
-Video feed of the movements of the various robots
-A desktop computer station to process the raw feed
Communication
-A WiFi adapter
-An onboard UART
PROPOSED DESIGN
The proposed design is reflected in the assignments of the four team members: Mechanical, AI/System Architecture, Control, and Computer Vision. The mechanical design is composed of a multi-level acrylic plastic frame with three omnidirectional wheels (shown to the right). The basic design of the frame is a non-regular hexagon, as shown in the figure to the left.
Each of these wheels is powered by a small 12v motor. The motors are connected to a controller circuits called RoboClaws. The RoboClaws are the interface between the microcontroller and the motors, providing commands to the motors and feedback to the microcontroller. The microcontroller that we will be using is called the Odroid U3, and is running a kernel of Ubuntu Linux. The microcontroller has a wireless module that communicates via wifi with an offboard image processing PC. This PC receives image data from a camera located over the soccer playing field, and runs algorithms to track the ball, our robot(s), and the opponent’s robot(s). Once the data has been extracted from the image, it is sent to the Odroid, which is running a control algorithm based on the image data.
To provide DC power to the needed parts within the robot, we are using two 7v battery packs in series, providing a total of 14v. This voltage is first scaled down to 12v (through a 12v regulator) for the motors. A 5v switching regulator steps down the voltage to power the Odroid, and the RoboClaws pass the 12v on to the motors. The RoboClaws also scale the 12v to 5v for the encoder logic contained in the motors. The overall scheme is shown in the diagram st the top of the next page:
The AI control is a collection of algorithms based on current state of play, and will include defensive and offensive strategies based on strategy from our simulation: goalie functions, rushing the goal, bankshots, etc. The control system will translate strategies from the AI system into motor speeds and directions, to allow the robot to move to specific locations on the field and orient itself.
CONCEPT SELECTION: SCORING
Methods of Scoring:
The objective of robot soccer is to score more goals than your opponent.Therefore, scoring is one of the main concepts that needs to be effective if our team is to be successful.Many methods of scoring are possible, and they are not mutually exclusive. It may be possible to implement all of the ideas in this section, or the only the top idea or ideas. These methods of scoring need to be creative, so that the other teams will not anticipate our strategy and/or cannot implement an effective defense.
Concept Definitions:
Wall shot - The robot propels the ball against the wall such that the rebound will enter the opponent’s goal.
Electromagnetic kicker - The robot contains a “kicker” that hits the ball in a straight line out from the front of the robot.
Rush the goal - The robot ‘dribbles’ the ball, and simply brings it to the opponent’s goal (along with itself).
Swivel-kick shot - The robot propels the ball by swiveling quickly while the ball is near the edge of the robot.
Over-the-head-shot - The robot has a kicker that hits the bottom of the ball so that it is propelled upwards, over the top of an opposing robot.
Design Evaluation Metrics and Weighting:
Complexity of Hardware Implementation - We have limited time and understanding of mechanical engineering. If we decide to implement an infeasible hardware design, the method of scoring becomes a hindrance as it has used up our valuable time. A complex design is also more prone to break during a matchup. Because of this, this metric is weighted at 25%.
Complexity of Software Implementation - A more complicated software design will prove more difficult to implement, using up valuable time. A complicated design is also more prone to bugs and unforeseen complications from unforeseen circumstances. The simpler the software design, the better. For this reason, this metric is weighted at 25%.
Effectiveness against no defense - There is a good chance that the opponent’s robots will not be effective in stopping our attacks. Building a good, responsive defensive algorithm is difficult, and the robots will be prone to mistakes and failures. We can use this to score points with simple attacks against ineffective opponents. This metric is weighted at 15%.
Effectiveness against competent robotic defense - This metric also includes the previous metric, effectiveness against no defense (if an attack is effective against competent defense, it will also be good against no defense). This metric defines how well the concept will function, if we were to actually implement it effectively and correctly. This metric is weighted at 35%
Design Cost Function Matrix:
Each concept represented here is ranked from 1 to 10, with 10 being the best. The reasons for each ranking are discussed in the following section.
Weight / Metrics / Wall Shot / Electromagnetic Kicker / Rush the Goal / Swivel-kick Shot / Over-the-head Shot25% / Complexity of Hardware Implementation / 8 / 4 / 10 / 8 / 1
25% / Complexity of Software Implementation / 4 / 7 / 8 / 3 / 6
15% / Effectiveness Against No Defense / 5 / 8 / 9 / 7 / 7
35% / Effectiveness Against Competent Robotic Defense / 4 / 6 / 3 / 4 / 7
100% / Weighted Total / 4.05 / 5.27 / 5.9175 / 4.22 / 4.3225
Results:
Wall shot - The wall shot would require almost no additional hardware on the robot, resulting in a score of 8 in hardware complexity. However, simulation has shown that it is not the most effective attack, even when executed properly. The software will require extra calculation, so it gets a 4 for software complexity. Because the rebounds are hard to predict, and it is difficult to get into position with respect to the ball when the ball is moving. For this, it gets a 5 and 4 for effectiveness ratings. The shot is also easily blocked. All this results in a score of 4.05.
Electromagnetic Kicker - The electromagnetic kicker would require a significant amount of additional hardware, and would also draw additional power from the batteries. For this it gets a score of 4 for hardware complexity. However, it would be fairly simple to implement in software (resulting in score of 8), and could be a very effective method of scoring, especially against incompetent defense (thus the average score of 6 for effectiveness). Electromagnetic kicker has a score of 5.27
Rush the Goal - This method of scoring comes directly from our simulation testing. It is very easy to implement in software and hardware (hence the 10 and 8 respective scores), but is only effective against a weak defense (a score of 9). However, because of the ease of implementation, this attack has high “bang for the buck”, or scoring capability for amount of effort in implementation. Score of 5.9175.
Swivel-kick Shot - This method is easy to implement in hardware (a score of 8), but much more difficult in software (a score of 3). It was shown to be an effective method of scoring in the simulation, but this does not necessarily translate into real-world robot soccer. We would need high accuracy hardware control, as well as complicated software to pull it off. The average effectiveness rating is 5.5 because of this. Score of 4.22.
Over-the-head Shot - This method is almost entirely untested. The theory is that if we were able to launch a ball over the opposing robot, any defense would be rendered useless. However, this would take very careful and complex hardware design (a score of 1), and its effectiveness in scoring has not been tested in a controlled environment. It may or may not work well, and that would be a risky attach to invest much time into. The effectiveness is debatable, but comes to an average of 7, regardless of the competency of the defense. Score of 4.3225.
Looking at all the results, it seems logical to implement a rush-the-goal strategy. However, as the designs are not mutually exclusive, we may end up attempting to incorporate the electromagnetic kicker or other scoring methods into our final algorithm.
CONCEPT SELECTION: Vision Tracking Markers
Vision Tracking Markers:
The vision processing algorithms are dependent on what the camera can see. Therefore, it is important that we mark our robots so that their position and orientation are easily detected by the vision system. Whichever method we choose will have to be implemented by all teams
Concept Definitions:
Triangle LEDs - 3 leds would form a line near the center of the robot with a 4th LED towards the front to indicate direction. A colored triangle would be in between all of the LED’s distinguishing teams.
Checkerboard - A colored square would be surrounded with a black and white checkerboard pattern.
Dual Led’s - A colored LED would be near the center of the robot indicating team, while another LED would be located towards the front indicating direction.
Dual Colored Markers - A large colored marker would mark the center of the robot while a smaller colored marker would mark the front of the robot.
Single Colored Triangle - A large, colored, isosceles triangular marker would mark the center of the robot pointing towards the front.
Design Evaluation Metrics and Weighting:
Ease and Cost of Solution - Creating certain markers is harder than others. Colored paper is very easy to implement while LEDs take a little bit more work. Although, since none of the proposed solutions will take much work at all, this is only weighted at 5%.
Ease of software implementation: Some markers will be more easily recognized by the computer than others. Some of the more difficult solutions will require more fine-tuning. Since all will work, but our time is valuable, this gets a weight of 20%.
Scalability: In the future, we will want to add more robots. Some of the marker ideas will only work for a limited number of robots, as colors must be distinctive and LED colors are limited. This will determine the future of the project so we want to work on a solution now that we can scale in the future. Therefore, this gets a weight of 25%.
Effectiveness in various lighting conditions - This metric is by far the most important, because operating blind will be devastating for our final product. The final competition will be held in a different venue than the room we are currently working in. Our vision system must be robust enough to be reliable in almost any combinations of lighting conditions. This is the primary purpose of the system and is therefore weighted at 50%.
Design Cost Function Matrix:
Each concept represented here is ranked from 1 to 10, with 10 being the best. The reasons for each ranking are discussed in the following section.
Weight / Metrics / Triangle LEDs / Checkerboard / Dual LEDs / Dual Colored Markers / Single Colored Triangle5% / Ease and cost of solution / 3 / 8 / 5 / 9 / 10
20% / Ease of software implementation / 5 / 8 / 4 / 8 / 6
25% / Scalability / 5 / 7 / 5 / 7 / 7
50% / Effectiveness in various lighting conditions. / 10 / 8 / 9 / 5 / 6
100% / Weighted Total / 7.40 / 7.75 / 6.70 / 6.30 / 6.45
Results:
Triangle LEDs - The triangle LEDs would be the hardest to implement in hardware, so it got a 3. The software for doing this tracking is fairly unknown, and since unknown is rarely good, i gave it a score of 5. I feel like scalability for LEDs is is smaller than that of colored paper simply because there are fewer varieties of LEDs available, so it got a five. Most people feel, however, that LEDs will be the best for different lighting conditions because they create their own light, therefore they got a 10. Overall score of 7.40.
Dual LEDs - Still fairly hard to implement, although there will be fewer LEDs, so a 5 was appropriate for ease and cost. The software would be the hardest to implement, as 2 robots next to each other would be hard to distinguish, so it got the lowest score. Scalability is the same as the triangle LEDs. And effectiveness is high, but not as high as Triangle simply because there are fewer LEDs. Final score of 6.70.
Checkerboard - Much easier to implement since it is just paper - score of 8. There are built in tools for recognizing grids in OpenCV, so software implementation gets the highest score of 8. Scalability is a seven, with the rest of the paper solutions. I feel like there may be better solutions for scalability out there so we left some room for improvement. Finally, a checkerboard is very high-contrast and gets a good effectiveness score.
Single Colored Marker - Implementation is the same as the other paper solutions. Software gets a failry low score because if is not inherently easy to track orientation with a single triangle that may get distorted by angle or lighting - score of 6. Scalability is the same as the other paper solutions and effectiveness is low, but just above dual markers because only having one means you can make it bigger, which is more visible. Total score of 6.45.
Dual Colored Marker - Implementation is the same as the other paper solutions. Software gets the same score as checkerboard because effective solutions have been implemented already. Scalability is the same as the other paper solutions and effectiveness is low, but just below dual markers because the markers must be smaller to fit on the robot. Total score of 6.30.
Looking at these results, The best marker to implement would be the checkerboard. The LEDs however must be explored because many of the score i gave them were based on uncertainty. In the end the decision will be made as a class, and i am interested to see other teams’ decision matrices.
CONCEPT SELECTION: Control Systems
Methods of Control:
One major obstacle in Robot Soccer is how the robot will be controlled. Obviously the robots will need motors and the microcontroller will be used to send commands over the uart to those motors. The real problem lies in how the robot will know how to get from point A to point B. The robot needs to be able to move in a straight line without deviating and without overshooting its target. This section identifies ways the robot can keep track of where it is and how to get to where it wants to go. The robot receives input from the vision system namely: current robot positions and orientations, and the current ball position.