TeamBots as a RoboCup Jr Simulation Platform

Tucker Balch
The Robotics Institute
Carnegie Mellon University

Overview

We propose enhancements to the TeamBots robot development environment to support RoboCup Jr simulator competition. The result will help make RoboCup Jr soccer accessible to a broad educational audience. The effort will focus on:

• Development of a Graphical User Interface (GUI) for robot team programming;
• Enhancements to the TeamBots simulator to make it easier to download, install and use;
• More realistic robot and ball dynamics.

The TeamBots simulator is written entirely in Java and runs easily on the computing platforms likely to be available in educational environments (e.g. Macintoshes and PCs) -- high-powered Unix workstations are supported, but not required.

TeamBots has already demonstrated seamless robot control in simulation and on real robots for Nomad-150, Nomad Scout (and soon, Cye robots). We anticipate F-180 league robots will be supported in the future (perhaps commercially).

The TeamBots source code is freely available for education and research.

We will now provide an overview of the TeamBots system and then proceed with more detail on the proposal.

Background: the TeamBots environment

The TeamBots simulator is easily configurable using a human-readable environment description file. The description file specifies which objects are present in the simulation, their positions and, for robots, the associated control system they should run. This flexibility enables a researcher to mix and match robot hardware with control systems and to test these systems in different environments.

In 1997, we developed a set of Java classes to support RoboCup F-180 league simulations in TeamBots (Figure 1). Since then, a number of researchers have used the system in RoboCup team development.

Figure 1: A RoboCup simulation in TeamBots. Five simulated robots on each team attempt to kick the ball (a simulated golf ball) into the opponent's goal. The currently active behavior is displayed next to each robot.

Extensions to TeamBots

We will provide three levels of programmability. The user may choose to program a team at a high level or drill down to more detail and complexity. At the highest level, in the Configure Team interface (Figure 2), the user is presented a team formation (with the goalie at the bottom). A multiple-choice menu is positioned next to each robot where the user can select which of several player strategies to assign to the corresponding robot. So, in the simplest case, programming a robot team is as easy as assigning a "brain" to each player.

Figure 2: Mock-up of highest-level GUI for robot team programming. The user can select which player strategy to assign to each robot.

If the user would like to specify a robot's behavior in more detail, he will be able to click on the robot's icon in the Configure Team window to open an Edit Player window (Figure 3).

In this window, a group of binary features (e.g. "closest to ball") appear on the left. In the column under each feature the user can enter symbols (0, 1 or X) to specify perceptual conditions he would like the robot to handle. Each row of 0s, 1s and Xs represents a perceptual state (or set of states) the player might experience. 0s represent false, 1s represent true and Xs represent "don't cares." So for instance, a 0 in the "center goal open" column and an X in the "closest to ball" column would mean that the goal must be blocked for the state to be triggered, but it doesn't matter whether the robot is closest to the ball or not.

On the right side of the Edit Player window, a menu appears next to each state. Using this menu, the user selects which action he would like the robot to execute in the corresponding state. In effect, the user is specifying a universal plan for the robot.

If the final design includes a large number of features and/or states, we will add scroll bars as necessary to enable the user to see all the possibilities.

Figure 3: Mock-up of the Edit Player window.

Finally, at the lowest level, the user can program the details of the individual actions triggered by the universal plan. We propose a motor schema-based system where behaviors are expressed as a weighed sum of vectors (other approaches are also feasible). So, for instance, if moving to the ball is very important, the weight, or "gain" for the move-to-ball vector could be set to a high value. The relative importance of other component behaviors are similarly indicated by their gain values. To enable the user to specify these weights, he will be presented an Edit Action window with a list of motor schemas (left) and slider bars (right). Figure 4 illustrates how the Edit Action window might look.

Figure 4: Mock-up of the Edit Action window.

Enhancements for usability

1. Single purpose soccer simulator: The present TeamBots simulator is a general-purpose program that reads in a scenario description from a file. One consequence of this in the case of soccer is that the specific teams to play must be specified by editing the file. This is fine in most research applications, but may be a bit confusing for educational users. We will code a special version of the simulator that is devoted specifically to soccer, teams for matches will be selected using a menu-based interface.

2. Logging and replay: We will add a logging feature to the simulator so that games can be saved and replayed.

3. Download and installation: Currently, TeamBots is distributed as a compressed Zip file. The user must download the file, uncompress it (perhaps after downloading a zip utility) then run it using a separately installed Java Virtual Machine. We would make this easier by repackaging the system using an installer utility -- all the user would have to do is download and run the install program.

1. Robot dynamics: In the present simulation robots can accelerate instantaneously to full speed. Rotational acceleration is similarly unrestricted. We will replace these with more realistic dynamics based on actual robot experiments. These experiments have already been conducted by Israel Munoz, but the code has not yet been integrated with TeamBots.

2. Sensor noise: We will add a noise model to the simulator so that sensors are not perfect as they are currently.

3. Control system scheduling In the current system there is no penalty for a control system that takes a great deal of time to run. It would be possible, for instance, for each robot to take as long as it likes to determine its move at each time step. This gives an unfair advantage to compute intensive deliberative systems when reactive systems might have an actual advantage on real robots due to their quicker response. We will revise the simulator's scheduler to ensure an equal amount of CPU time is allotted to each robot's control system.

Competition organization

In the remote phase, each competing team will submit a compiled version of their robot team strategy using an automated web interface. The remote system will automatically run the competition, and post results. Competitors (or others on the web) will be able to view replays of games once they are complete -- this is one of the capabilities we are proposing to add to TeamBots.

The overall schedule would run something like this:

• March - Regional competitions are held in each participating country. These competitions are run using the remote system. 10-20 teams are selected for national competition.

• June - National competitions are held in-person, in conjunction with workshops and student presentations of their teams. Competitors will be responsible for providing their own programming platform. They will submit their software on a floppy disk. Teams that are unable to travel can submit their team's software by email. Competition administrators will load the software onto the competition computer where the simulations will run. 5-10 teams are selected for international competition.

• December - International competition held in-person. A 5-6 month delay between national and international is provided to enable teams to make travel arrangements, etc. All computational resources will be provided on-site.