Robocup Forwards
High Level Design
EEL 4884, Spring, 2004
Modification history:
|
Version
|
Date
|
Who
|
Comment
|
|
v0.0
|
08/15/00
|
G. H. Walton
|
Template
|
|
v1.0
|
02/03/04
|
Team
|
Update template for initial release of program
|
|
v1.1
|
03/16/04
|
Team
|
Update template for additional design issues.
|
Team Name: Killer Forwards
Team Members:
Contents of this Document
High-Level Architecture
Design Issues
High-level Architecture:
- Rcssserver: This server is the one that sends all data to us and no control is given to us for it.
- Broadcast: This is the function for receiving information from the server. This will take the message and verify that is was received correctly and can be passed to the parser. Broadcast shall handle any errors that are passed to it and will discard the information if received incorrectly.
- Parser: The parser shall receive messages from the Broadcast class and break the message up into easily readable chunks of data. The class will then take strings from its parsing and store them into structures for passing into the data storage class. Each one of these structures will have respective types for information such as int, strings, floats, etc.. The data is then passed to the data storage class.
- SendMsg: The SendMsg function will get data from the data storage class when told by the Forward class to send messages to the server. These messages will first be seen as structures containing ints, strings, floats, etc. and then will be converted into a format that can be sent to the server for interpretation.
- Data Storage: The Data Storage class will be the class where all important information is kept for communication between the server and the forward class. SendMsg and Parser will be the main functions that will access this class for transmission to the server. The Forward class will access this class to pass data to its interpreters for decision making and AI functions.
- Forward: This class will be the transition between the Artificial Intelligence functions and the data storage class. It will pull in information from the data storage class and pass it to the appropriate functions for decision making. If the forward sees that a player or coach has communicated with it then they will also interpret that and send that to the server.
- Coach Interpreter: The coach interpreter class will be given the structure that was passed to the data storage class and will implement the correct course of action depending on what was said. This class might have communications with the AI of the Forward or the Player interpreter to better handle the situation. Some examples of situations that might come up would be if the coach shouted that the ball was heading towards one of the forwards. This class should interpret this and the balls location to correctly move the player towards the ball.
- Player Interpreter: This interpreter will be similar to the coach interpreter, the only main differences will be that it will interpret what other players say to the forward. This function might be called several times during communication if several of the players communicate with the forward. The players may tell the forward that they are going to pass the ball to him/her and the program should move into position and decide what to do with the ball afterwards.
- Forward's Artificial Intelligence: This part of the AI will decide what to do with the sensory information that it has received from the server. It will take in information about the field, flags, and other players to decide what the next action should be to best run a play. The class might also pull the information in from what the coach and players say to better make a decision. An example would be if the forward had the ball then where should it kick it to further its position up field without giving it to the other team.
Design Issues:
- Limited knowledge of soccer plays and formations will limit our capabilites to perform complex plays.
- Some programing issues may be seen with the passing of information from one class to another. One such issue might be the passing of structures to and from classes. Should be able to fix this issue by trying several ways of implementing this.
- Program will be tested by actually running a beta version on the soccer server to verify that functions work correctly. Server may not be run all the time so may only have certain times that we are able to run.
- The forward program will be maintained by us(the programers) and will be updated as needed by the customer.
- The program will programed by us and maintained by us for use for our class EEL 4884. It will be saved on several computers for reliability.
- The program shall communicate at the level that the server communicates. If the program performs any slower than this modifications will be made to verify the integrity of the program and the correct communication with the server. Program might not be able to make decisions in the time it takes to receive antoher message, if this happens then our software me be altered to only interpret every other message from the server.
Updates for v 1.1
- Further complications arise from calculating and implementing math functions for the various higher-level player functions. Things such as implementing a function that will calculate an
intercept course between two objects, whether they be players or a player and a ball.
- Players must also now decide if they have a clearpath between them when they decide to pass or shoot. As of now, the players will shoot regardless of a clearpath.
- Another new requirement is being able to run to a specific location on the field. At the moment, players just run towards the ball. They have no concept of their actual position on the field. They are only aware of where their goal and the opponents goal is.
- Current code cannot handle all of the various game states that the game may enter. If it does, it does so on a very basic level without any strategy.
- Later on, it will be important also to determine when to do these higher level actions. This is another consideration that comes out due to these changes.
Template created by G. Walton (GWalton@mail.ucf.edu)
on October 8, 1999 and last modified on Aug 15, 2000
This page last modified by Rob Pescatore
( rp_cerberus@hotmail.com ) on 03/16/04