Robocup

Concept of Operations

EEL 4884 Spring 2004

 

Modification history:

Version

Date

Who

Comment

v0.0

08/15/00

G. H. Walton

Template

v1.0

1/14/04

Kristen Cannava, Rob Pescatore, Kip Carr

Initial concepts of this project are in this version

 

Team Name: Killer Forwards

Team Members:


Contents of this Document

The Current System

The Proposed System


The Current System

The current Robocup system consists of a soccerserver and a soccermonitor. The soccerserver is the device through which most of the control of the soccer game will take place; it provides the virtual field as well as the players. The soccerserver is the program through which the clients will connect to control each individual soccer player. Clients will be the ‘brains’ of the soccer players, connecting to the soccerserver and sending their commands for the players stored on the soccerserver. Each soccer team will be made up of a group of clients controlling one player apiece. The clients will receive information from the soccerserver, such as position as well as visual/audio signals. The clients will react to these given stimuli in a pre-described manor based on their code. The soccerserver will then relay all of this information; player positions, ball position, etc, to the soccermonitor.

The soccer monitor is a means of viewing the actions of the soccer players and the flow of each game. Through the soccermonitor, you will be able to view the soccer players, the ball and other important field features. The soccermonitor is a way to watch each player’s action and visually monitor the actions and decisions of the clients controlling the players, via the player’s movements onscreen. The monitor will also include a simple interface to interact with the server, for example, being able to start the game with the ‘kick off’ button.

 

The Proposed System: Needs

The needs for the project are the creation of a soccer team. The team will consist of 11 players and a coach. The initial goal is for the player to be able to move about the field, and perhaps able to follow the ball. This is a simple goal, through which much can be built upon. Intermediate goals may be giving the player specific actions and behaviors based upon their positions on the field. The offensive positions will move to score on the opposite team; the defensive players will sit back and defend their goal. Perhaps at some point the players will be able to coordinate themselves into plays and react based upon the ball location and locations of the opposing players. This team will be controlled by the client programs, which will interface with the soccerserver and be viewable on the soccermonitor.

 

The Proposed System: Users and Modes of Operation

The users would represent people outside of the system, starting and perhaps interrupting the game. This would include the person who would start the match, initiating kickoff. Another user may be the human referee who’s perhaps is to regulate game play and ensure hard-to-detect situations and rule breaking don’t go unchecked. Modes of operation include normal play in which the players behave according to the client code.

 

The Proposed System: Operational Scenarios

The operational scenarios for the proposed system would include a ‘regular play’ mode, in which an outside user, and the players all behave according to the client code start the game and the results are displayed and controlled on the soccermonitor by the soccerserver. This is the normal operating scenario. If errors where to occur, there would be a way for a user to interrupt or end play via the soccermonitor. This would allow for possible short-term fixes as well a preventing any possible damage.

 

The Proposed System: Operational Features

Must Have:

Would Like to Have:

 

The Proposed System: Expected Impacts

The impact of developing a team is one that is clear. Beforehand the soccerserver and soccermonitor have no function unless there is a team. With the addition of a soccer team these previous two components now have a function to perform.

 

The Proposed System: Analysis

Expected Improvements:

Disadvantages: N/A

Limitations:

Risks:

Alternatives and Tradeoffs:


Template created by G. Walton (GWalton@mail.ucf.edu) on August 30, 1999 and last modified on August 15, 2000.

This page last modified by Kristen Cannava (kristenc12@hotmail.com) on January 31, 2004