Darmstadt Dribblers 
Usage of Referee / Game Controller Software in the RoboCup Humanoid League
Important notice:
The GameController project has moved to SourceForge.
All source files, an up-to-date documentation and binaries can be found there.
The content of this page may be out of date and will not be updated.
Visit RoboCup GameController SourceForge project page.
Introduction
Purpose of the usage of a referee or game controller software is to provide the robots more information about the current game state. This allows a higher level of autonomy of the players. It also facilitates the work of the main referee and the organization of a game with three or more players per team.
The game state is periodically broadcasted via network and contains information about the game phase, remaining time, score and any penalties. An operator (assistant referee) controls the Referee/GameController Software running on an external PC or laptop and transforms the decisions of the main referee via a graphical user interface (GUI).
The original application and protocol of the software described here was developed by William Uther for the RoboCup Four-Legged League. Some changes where applied to match the rules of the Humanoid League.
Basics
To allow an unambiguous identification of a robot, each team is assigned a color (magenta or cyan). To circumvent any disadvantages, the colors are changed for the second halftime.
The robots of a team are numbered (beginning at 1). This is an interpretation Section 4.5.3 of the current rules of the RoboCup Humanoid League. The player number should be applied at the body or head of the robot in a way that it is easily readable from all sides. Then in a team with three or more players the referee and assistant referees can easily keep track of each robot and penalties assigned to a robot. With the teamcolor and the player number, a robot can uniquely be identified by the referee.
Internally a team is identified with another unique number the so-called team-id. Each team can be assigned a team-id at the beginning of the competitions, which does not change during the tournament. The GameController GUI shows the team-ids and ensures an assignment of the team color respecting the current halftime.
A game is divided into the phases Initial, Ready, Set, Play and Finished (see figure). During Initial the robots are not allowed to move, except stand-up. In phase Ready they should walk to a feasible starting position for kick-off. The transmitted game state contains information about the team which performs the kick-off. The time span allowed for this phase should be long enough to enable all robots to reach their positions for kick-off. During the phase Set, announced by the command Set from the main referee, the robots are not allowed to change their positions by themselves, but may be repositioned by the referee to comply with the rules in case the positions they reached autonomously are not allowed for kick-off. The game then starts with the opening whistle of the main referee and the operator of the GameController changes the game phase to Play.
When one team scores, the operator triggers the corresponding button in the GUI. The game state is automaticaly set to Ready and the other team obtains kick-off.
The data structure also allows information about possible penalties of each robot. Since these are not included in the current humanoid rules, the corresponding fields are left empty and preserved for future use. According to this fact, the state Penalized is currently not available, but may be added in future versions.
After expiration of the halftime and whistle of the referee, the game state changes to Finished. Until the GameController is terminated, the data package is still transmitted. The robots are allowed to move freely.
Advantages
Since the robots know more about the current situation of the game, they can reach a higher level of autonomy and interaction with human team members can be reduced. The team communication can be simplified, because the game state contains information about penalties. Additionaly, dependent on the score and penalized players, a team can adopt its strategy accordingly.
For the audience the game is more interesting, as the players act more intelligently. The robots can walk to their kick-off position without needing intervention of the human team members, which allows a better game progress. It is also possible to let the robots exhibit emotional reactions as to cheer or to complain, respectively, after a goal has been scored. Also team tactics can be adapted to the current score.
For the main referee it is easier to keep track of the game and penalties if he or she is supported by a assistant referee operating a game controller software and also keeping track of the overall time as well as of any certain time spans.
Technical implementation
The GameController is realized as a platform independent Java application. The main graphical user interface contains several buttons, with which the game state, goals, kick-off and penalties are set (see figure below, click on figure enlarges it, the maximum number of players per team in this version may be four).
The data package is broadcasted via UDP port 3939 at regular intervals of 500 ms and contains the game state in this moment. The package can be specified in C++ as follows:
// data structure header
#define STRUCT_HEADER "RCGC"
#define STRUCT_VERSION 2
// team colours
#define TEAM_CYAN 0
#define TEAM_MAGENTA 1
// goal colours
#define GOAL_BLUE 0
#define GOAL_YELLOW 1
// game states
#define STATE_INITIAL 0
#define STATE_READY 1
#define STATE_SET 2
#define STATE_PLAYING 3
#define STATE_FINISHED 4
// penalties
#define PENALTY_NONE 0
typedef unsigned long uint32;
// Information that describes a player.
struct RobotInfo {
uint32 penalty; // penalty state of the player, reserved for future use
uint32 secsTillUnpenalised; // estimate of time till unpenalised
};
// Information that describes a team.
struct TeamInfo {
uint32 teamNumber; // unique team number
uint32 teamColour; // colour of the team
uint32 goalColour; // team's goal colour, defend this goal !
uint32 score; // team's score
RobotInfo players[4]; // the team's players
};
// Information that describes the game state.
struct RoboCupGameControlData {
char header[4]; // header to identify the structure
uint32 version; // version of the data structure
uint32 state; // state of the game
uint32 firstHalf; // 1: game in first half, 0 otherwise
uint32 kickOffTeam; // the next team to kick off
uint32 secsRemaining; // estimate of number of seconds remaining in the half
uint32 dropInTeam; // team that caused last drop in
uint32 dropInTime; // number of seconds passed since the last drop in
TeamInfo teams[2]; // team information
};
The format already allows four players per team and is thus suited for further extensions of the number of team players as well as for test games with four players per team. The resulting overhead is minimal and should not affect any robot's performance.
For internal processing, it is suggested to convert the data in an own format. It should be kept in mind, that the index of arrays in C++ starts with 0. For retrieving the data for one robot, the by one decremented player number has to be used as index.
Organisational issues
This GameController has been used by the Darmstadt Dribblers in RoboCup 2006 and 2007 according to Section 4.4.3 of the current rules. Besides the use of a GameController, a manual interaction with the robots is still allowed. In RoboCup 2008 and later on as the number of players per team increases manual interactions should gradually be decreased until they are not longer supported and the use of a GameController for the humanoid league is promoted from a suitable date on. The timeline, however, depends on the overall progress of the humanoid league.
Unlike other remote control operations for start or stop signals which may be used at RoboCup in the humanoid league and which may be difficult to control by the referees, a standardized and open source GameController is very transparent with respect to the information exchanged by the external PC and the robot's onboard computer.
Download
The sourcecode is available via SourceForge.
If you would like to contribute or have questions or feedback send an email to Sebastian Petters.
Changes
2009-05-01:
- Moved sourcecode to sourceforge
- Added support for RoboCup Standard Platform League (SPL)
Notice: Changed STRUCT_HEADER to "RCGC"
2006-06-07:
- Changed UDP port to 3939 to avoid collisions with Four-legged League
- Changed packet header and version
- Added field goalColour to TeamInfo struct
- Updated user interface to use cyan and magenta as team colors
2007-11-09:
- Most recent version available for download.