RoboCup Forwards
Detailed Design
EEL 4884, Spring, 2004
Modification history:
|
Version
|
Date
|
Who
|
Comment
|
|
v0.0
|
08/15/00
|
G. H. Walton
|
Template
|
|
v1.0
|
02/10/04
|
Kip Carr, Kristen Cannava, Rob Pescatore
|
Initail Update
|
|
v1.1
|
03/16/04
|
Kip Carr, Kristen Cannava, Rob Pescatore
|
Update to incorporate additional functionality issues
|
Team Name: Killer Forwards
Team Members:
Contents of this Document
Design Issues
Detailed Design Information
Trace of Requirements to Design
Design Issues:
- Response Time shall be at a minimum to allow the player to communicate with the server at the fastest rate. This may not be able to be acheived due to simplicity of code, if modifications need to be made then we will try and at least communicate with the server every other time cycle.
- Our player shall be able to handle multiple shouts from the couch as well as other players. These will determine how the player will react to situations.
- Since our player will be automated once the client starts it there shouldnt be many invalid user inputs. We will handle invalid inputs at the beginning of the code to hadle starting the player incorrectly and for any buttons that might be pressed during play.
- The player shall be able to perform task whenever the client starts the program, unless we, the coders, are altering the code to improve on the current system.
- We will not handle many erroneous situations due to our server being in an inclosed enviroment and having plenty of bandwidth to communicate with the server.
- Security and Safety shouldnt be a real issue with our program. If it should malfunction then no one should be hurt by a program, also no malicious attacks should be attempted on our code to the enclosed enviorment.
- Our program is for school so we are doing this at no cost.
- Adding functions to our system will be easy so that we can make improvements to our forwards later in development.
- Since our code will be sort of modular, adding functionality will be easy.
- Our code will be written in C++ so if Robocup changed to Windows instead of Linux our code should be portable with minimal changes to the communications pack for UDP.
- Our code is going to be commented so that each function will be well defined and commented so that it is readable.
Updates for v 1.1
- Designing and implementing the appropriate functions that will produce the various high level behaviors will be a challenge. These are specific math functions that either must
be designed or be found.
- Players must be able to verify a clearpath when shooting or passing. As of right now, passing is not even implemented, and shooting is performed under any condition as long as it's
towards the goal. The AI routine will have to augmented in order to take more situations into consideration.
- Calculations also must be able in order to determine where exactly the player is on the field, and also how to run to an absolute location on the field. In addition to an absolute
position on the player must be able to move to a position relative to another object on the field.
Detailed Design Information:
Trace of Requirements to Design:
| CLASS |
REQUIREMENTS |
| Forwards Class |
(101) The software shall parse information from the soccer server.
(102) The software shall understand communication from the coach to the players.
(103) The software shall understand communication from another player to the current player.
(104) The player shall acknowledge kick-off and move to appropriate position.
(105) Player shall move around the field.
(106) Player shall pass the ball to another player.
(107) Player shall verify a clear path before passing or shooting.
(108) Player shall lead a target player while passing.
(109) Player shall anticipate players stealing the ball.
(110) Player shall intercept passes and players.
(111) Player shall run to a specific spot on the field.
(112) Player shall handle all fouls and game states.
(113) Player shall kick the ball towards the goal.
(601) Client shall calculate trajectoies and velocities.
|
| Data Storage Class |
Used for a central storing area for relevent information. Not necessary however, it is being implemented for ease of use.
|
| Communications Class |
(201) Client software shall handle broadcasts from the server.
(202) Client software shall communicate with server every millisecond.
(203) Client software shall be able to communicate asynchronously.
|
Template created by G. Walton (GWalton@mail.ucf.edu)
on October 8, 1999 and last modified on August 15, 2000
This page last modified by Rob Pescatore
( Email ) on March 16, 2004