SoccerBeans: A Robocup Client

Introduction

SoccerBeans is an agent framework for the RoboCup domain. It is used as a research and educational tool for our graduate level course on Multiagent Systems. SoccerBeans builds on our previous work - Biter, and inherits all the features from its predecessor. Some of the other salient characteristics of the software are as follows:

1. It is based on the JavaBeans Technology, and it enables us to develop sophisticated soccer teams without writing any code!
2. It provides many player behaviors (e.g., dashing, turning, dribbling, etc.) and potential decision criteria (e.g., ball distance, number of opponents closing in, self position on the field, etc.) as beans. You can develop a player by simply plugging together the required components. (See the tutorial for further details).
3. We have to simply design decision tree-like plans for individual players, assuming that they play from the left side. The rest of the stuff is handled for us by the framework! (See the tutorial for further details).
4. It can be extended to incorporate other player behaviours and decisions not currently supported by the framework.

Download

• Here is the latest package built on Sept 24, 2003, containing the source code, bytecode, javadoc, documentation for all the beans in the package, and a sample team - soccerbeans.jar
• Javadoc API for online browsing.

In this tutorial, you will learn how to create and run a simple player that can dribble the ball to goal using the SoccerBeans framework.

• Install the soccer server

• Refer to the RoboCup soccer simulator's home page for further information.
• Students at USC can use the server installed on the SUN machines at /acct/f1/jmvidal/SUN/rcsoccersim-9.0.3. Run the shell script rcsoccersim from there.

• Install and setup the BDK

• Refer to the JavaBeans Architecture: BDK Download home page for further details.
• As mentioned in the website, there are some unresolved compatibility issues concerning J2SE v 1.4 and the BDK. So, we will have to use some older J2SE version, preferably J2SE v 1.3 (The software was tested for J2SE v 1.3.0 and J2SE v 1.3.1_04). Students at USC must modify the run.sh file at the location $(BDK_HOME)/beans/beanbox to

  	#!/bin/sh
  	export PATH
  	PATH=/usr/local/java1.3/bin:$PATH
  	export CLASSPATH
  	CLASSPATH=classes:../infobus.jar:../lib/methodtracer.jar
  	java sun.beanbox.BeanBoxFrame
  	

  where, $(BDK_HOME) represents the BDK installation directory.
• Copy the server configuration file, .rcssserver-server.conf, from the soccer server's home directory to the $(BDK_HOME)/beans/beanbox directory. The SoccerBeans package includes a sample server configuration file. Students at USC must use the server configuration file defined in FP and rename it to .rcssserver-server.conf
• Save the SoccerBeans package in the $(BDK_HOME)/beans/jars/ directory. To avoid inconvenience, move all the other contents of the directory to some new location.

• Create a soccer player

• Start the BDK application by executing ./run.sh from the $(BDK_HOME)/beans/beanbox directory. Four windows - BeanBox, Toolbox, Properties and Method Tracer, will appear. Also, the Toolbox will have all the beans from the SoccerBeans package.
• Click on the PlayerFoundation bean from the Toolbox window and then click somewhere in the top section of the BeanBox window. We now have a soccer player that can play the game, if we tell it what to do.
• Now we will add an activity that tells the player to incorporate the new information that it receives from the server at runtime into it's world model.
• Drop the Activity bean in the BeanBox, as shown in the adjacent figure. Change it's name property to Observe.
• Drop the other beans for the Observe activity, namely the DInputType bean, the two BBoolean beans and the BIncorporateObservation bean on the BeanBox.

• Select the DInputType bean in the BeanBox. It's inputType property must be set to SensorInput. Now select the Observe activity bean, and from the Edit menu, go to Events > canHandle Decision > decide. A red line will appear connecting the mouse pointer to the activity bean. Then click on the DInputType bean, and in the window that appears, select decide and OK it. By this action, we say that the Observe activity can be handled or executed by the player when a particular condition on the type of the input received from the soccer server is satisfied. The canHandle Decision > decide event was selected for the source bean (Activity) because the listener bean (DInputType) was a decision bean.
• Select the first BBoolean bean. By default, the bean's properties are set such that it sets the canHandle property of the concerned activity to true. Now select the DInputType bean, and go Edit > Events > then behave > behave. Select the first BBoolean bean and say select and OK. Here we say that if the received input type is a SensorInput, i.e. see message from the server (see the server manual for more information), then the concerned activity, i.e. Observe, can be handled. The then behave > behave event was selected for the source bean (DInputType) in this case, as the listener bean (BBoolean) was a behavior bean.
• Select the second BBoolean bean. Change it's value property to false. Then select the DInputType bean, go Edit > Events > else behave > behave, select the second BBoolean bean, and say behave and OK. Here we say that if the received input type is not a SensorInput, then the Observe activity cannot be executed by the player for the current simulation step.
• Observe that the BIncorporateObservation bean has no properties. Select the Observe activity bean, go Edit > handle Behavior > behave, select the BIncorporateObservation bean, and say behave and OK. Here we described how the player will execute the activity, should the player's scheduling mechanism select this activity for execution in the current simulation cycle. We say that the player will simply call the BIncorporateObservation bean to handle the current activity.
• Finally, we have to associate our Observe activity to the player. For this, select the PlayerFoundation bean. The PlayerFoundation bean can generate an addActivity event, so go Edit > Events > activity > add activity, then select the Observe activity bean, and select it's addActivity method. Repeat the process for the PlayerFoundation bean's canHandle and handle events, associating those with the canHandle and handle methods of the activity bean. We have now successfully designed one activity for our player.
• We will next add an activity that teaches the player to dribble the ball.
• Drop the Activity, BBoolean and BDribble beans from the Toolbox onto the BeanBox, as shown in the adjacent diagram.
• Select the Activity bean and modify it's name property to Dribble. Associate the activity's canHandle Behavior > behave event with the behave method of the BBoolean bean, and the handle behavior > behave event with the behave method of the BDribble bean. The default properties of the BDribble bean are set such that the player dribbles the ball to the opposite goal. Here we tell the player to execute this activity all the time.
• Associate the Dribble activity with the player exactly as we associated the Observe activity.
• There is one more thing that we need to take care of. We would like to give a higher priority to the Observe activity, as the player should always have the correct picture of it's environment. To do this, select the Observe activity, and for it's inhibits property, say Dribble. So, we tell tha player to Dribble all the time, but whenever it can Observe, it must.
• Our player is now ready for action. Ensure that the soccer server is running, and select the PlayerFoundation bean in the BeanBox. The default values for the player's properties serve our current purpose, so we won't modify them. Simply set the online property to true. A player should appear on the soccer monitor. Click on kick-off and the player will do what we taught it.

P.S.: The red lines showing the connections between the beans and the green rectangles for activities in the adjacent figure were added externally to the actual image for descriptive purposes only.

Running the Sample Team

• For reloading a JavaBeans application created in multiple sessions, we have to incrementally load every previous session in the BDK. So, say we create a player with one activity and save the session, and then load the player an hour later and create another activity for the player in this new session. Then, if we want to reload the player the next day, we will have to first load the file holding the first session's work and then the file holding the second session's work to open the complete player with two activities. An attempt to directly open the second session file will result in a ClassNotFoundException being thrown. The players in the sample team were developed in multiple sessions.


• The sessions can be loaded by the File > Load option, and saved by the File > Save option in the BDK.


• The sampleteam folder in the SoccerBeans package has 23 files for the 23 different sessions that the 11 players are created in. The observe session is the first session for all the players, and is always followed by the startplay session. The rest of the session files are named such that the alphabetically increasing order of individual player session files represents the actual session order for the player. So, to load player1 completely, we will have to load the following files in the specified order - observe, startplay, player1a, player1b, player1c, and player1d. Note that some of the session files are shared by multiple players - player2a3a is the third session for both player2 and player3, and player4c5c6c is the fifth session for player4, player5 and player6.

P.S.: For convenience, copy the 23 sample team files in the $(BDK_HOME)/beans/beanbox folder.

Credits

SoccerBeans was written by Hrishikesh Goradia. Biter was written by Paul Buhler, Shaun Wood, and José M. Vidal.