RoboCup

1. RoboCup By: Paul Marlow Date: February 17, 2002

2. Background • Initially started as the J-League (Japan Robot Soccer League) • 1993, several American researchers became interested – bringing about the Robot World Cup Initiative (RoboCup) • The first games and conferences took place in 1997

3. Background II • Goal was to provide a new standard problem for AI – jokingly called “The life of AI after Deep Blue” • RoboCup differs by focusing on a distributed solution rather than centralized • The RoboCup Federation was started to coordinate the research through workshops, conferences and yearly competitions

4. Goals • Stated as: “By mid-21st century, a team of fully autonomous humanoid soccer players shall win the soccer game, comply with the official rules of the FIFA, against the winner of the most recent World Cup” • Right now, the various leagues consist of either robots or programs, which cooperate in order to defeat the opponent team

5. Simulation League • Provides a platform to develop software techniques, without the necessity of creating physical robots • Consists of three main applications: • Soccer Server • Soccer Monitor • Soccer Player(s) - agents

6. Soccer Server • A system allowing several autonomous program agents to play a virtual soccer game • The games are carried out in a client/server style – where each client = one player • The communication used is UDP/IP, and can therefore be used over a network connection, or even the Internet

7. Soccer Monitor • Used to display the visual progress of the game • Several Monitors can be connected to the server • It can also be used to interrupt game play by doing simple tasks such as dropping a ball • The latest version of the Soccer Server / Monitor is 8.03 – 5.24 was the last version for Windows

8. Autonomous Players • Are the “brains” of the players • Receive sensory information from the server, upon which decisions are made • Commands are formatted and sent to the server using UDP sockets

9. Rules Judged by the Automated Referee • Kick-Off • Goal • Out of Field • Player Clearance • Play-Mode control, including offsides • Half-time and Time-up

10. How to Start the Server • Download and install applications (running the configure and make scripts for the Unix / Linux systems) • Run the Server (default host is localhost and default port is 6000) • Run the Monitor, connecting to the host and port of the Server • Connect the players also to the Server host and port

11. Connection Communication Protocols • From client to server: • (init TeamName [(version VerNum)] [(goalie)]) • (reconnect TeamName Unum) • (bye) • From server to client: • (init Side Unum PlayMode) as a response for both client init and reconnect messages • Side = l | r; Unum = 1 ~ 11

12. Client Control Protocols

13. Client Sensor Protocol - Hear • (hear Time Sender Message) • Sender = online_coach_left/right, referee, self, Direction • Direction = -180 – 180 degrees

14. Hear Example • (hear 18 self FCPortugal ETV 18 world_status r 2 0.98 -10.95 16.64 1 0.95 0.00 0.00 1 0.95 0.00 0.00 3 0 OtGL- - fGXtZ 3F.- /sdhAl 1p.- 0 40.0 0.0 0 2 )

15. Client Sensor Protocol - See • (see Time ObjInfo) • ObjInfo: • (ObjName Distance Direction DistChange DirChange BodyFacingDir HeadFacingDir) or • (ObjName Distance Direction DistChange DirChange) or • (ObjName Distance Direction) or • (ObjName Direction)

16. Client Sensor Protocol – See II • ObjName: • (p [TeamName [UniformNum [goalie]]]) or • (b) or • (g [l|r]) or • (f c); (f [l|c|r] [t|b]); (f p [l|r] [t|c|b]); (f g [l|r] [t|b]); (f [l|r|t|b] 0); (f [t|b] [l|r] [10|20|30|40|50]); (f [l|r] [t|b] [10|20|30]); • (l [l|r|t|b]) • (B); (F); (G); (P)

17. Client Sensor Protocol – See III • See protocol has changed from version 5 (Windows) to version 8 (Unix/Linux). • The Windows version differs in the ObjName portion. Instead of using the first letter as the ObjName, the older versions use the fully qualified name: • b = ball, B = Ball, l = line, L = Line, p = player, P = Player, f = flag, F = Flag, g = goal, G = Goal

18. See Example • (see 18 ((f r t) 44.7 -22) ((f g r b) 47.9 30) ((g r) 44.7 22) ((f g r t) 42.5 13) ((f p r c) 30.3 34 -0 0) ((f p r t) 25.3 -7 0 0) ((f t r 40) 36.2 -37) ((f t r 50) 44.7 -29) ((f r 0) 49.4 20) ((f r t 10) 47 8) ((f r t 20) 46.5 -3) ((f r t 30) 48.4 -15) ((f r b 10) 53.5 30) ((f r b 20) 59.1 38) ((f r t) 44.7 -22) ((f g r b) 47.9 30) ((g r) 44.7 22) ((f g r t) 42.5 13) ((f p r c) 30.3 34) ((f p r t) 25.3 -7 0 0) ((f t r 40) 36.2 -37) ((f t r 50) 44.7 -29) ((f r 0) 49.4 20) ((f r t 10) 47 8) ((f r t 20) 46.5 -3) ((f r t 30) 48.4 -15) ((f r b 10) 53.5 30) ((f r b 20) 59.1 38) ((p "FCPortugal") 36.6 28) ((l r) 41.7 -89))

19. Client Sensor Protocol – Sense_body • (sense_body Time (view_mode {high | low} {narrow | normal | wide}) (stamina StaminaEffort) (speed AmountOfSpeed DirectionOfSpeed) (head_angle HeadAngle) (kick KickCount) (dash DashCount) (turn TurnCount) (say SayCount) (turn_neck TurnNeckCount) (catch CatchCount) (move MoveCount) (change_view ChangeViewCount))

20. Sense_body Example • (sense_body 19 (view_mode high normal) (stamina 4000 1) (speed 0 0) (head_angle 0) (kick 0) (dash 0) (turn 0) (say 98) (turn_neck 0))

21. Krislet • There does not exist many clients that run under the old Windows environment. Those that do, tend to connect to a Unix/Linux computer running the Server • Krislet is an extremely dumb program, which can be difficult to beat – as all the players run after the ball • Krislet however, can communicate using the later protocols, and therefore all the parsing is complete

22. Stripslet • Written by Aloke Wiki • Based off of Krislet • A Stripslet implementation is made up of four main concepts: Actors, Sensors, Actions, and a GoalList

23. Actors • These are designed to implement a specific action, such as run-to-ball or score-goal • Contains two main elements, an execute method – providing the functionality, and a name – which is used as a key into a hash table. • To add a new Actor • Add a new class to the Actor.java, implementing the Actor Interface • Add the new Actor to the ActorTable hash in StripsBrain.java

24. Sensors • These consist of objects which include a sense method, as well as a name for a hash table key. • Each is designed to determine the boolean outcome of a specific predicate, such as can-see-goal. • To add a new Sensor: • Add a new class to Sensor.java, implementing the Sensor Interface • Add the new Sensor to the SensorTable hash in StripsBrain.java.

25. Actions • Actions consist of four members: name, precoditionList, addList, deleteList. • name corresponds directly to that of the Actor name property (e.g. “score-goal”) • precoditionList is a list of predicates which must be true before execution of the action (e.g. “have-ball can-see-goal”) • addList is a list of predicates that will be true upon execution of the action (e.g. “ball-in-net”) • deleteList is a list of predicates that will be false upon execution of the action (e.g. “have-ball”)

26. Actions II • To add an Action: • StripsBrain maintains a list of actions, so any new actions must be added to this list • Note that multiple predicates in a list are separated by spaces actionList.add(new Action("score-goal", // name "have-ball can-see-goal", // pre "ball-in-net", // add "have-ball")); // delete

27. GoalList • Contains a list of goals for which the agents try to achieve • Currently the default list consists of only one predicate: “ball-in-net” • Interesting possibilities include • Adding multiple goals • Re-evaluating the goal list each cycle depending on the environment

28. Approach • The difference between our approach and those of others, is human supervision. • The goal, is to provide a process with which one can create a symbolic log file as a representation of the socket communication during a game. • In addition, use machine learning techniques on this data.

29. Approach II • Instead of learning from mistakes/success as reinforcement learning does, the human user will actually help classify the data to be learned. • However, there are problems with this approach, in that it can be tedious (as will be shown).

30. Step 1 – Obtain a Log File • In order to learn, the communication between the client and server need to be logged to a file – thus the reason for our Logger. • It acts like a router, sitting in-between the agent and the soccer server. • The agent(s) connect to the Logger, which establishes a connection to the Soccer Server, forwarding communication – all the while logging also writing them to file(s).

31. Step 1 – Continued … • An entry in the log file will look something like the following: (see 0 ((g r) 23.8 -19) ((f g r t) 27.1 -33) ((f g r b) 22.4 -2) ((f r t 10) 32.8 -33) ((f r 0) 28.5 -16 0 0) ((f r b 10) 27.7 4 -0 0) ((f r b 20) 30 23) ((f r b 30) 35.2 38) ((p "EW_02" 1) 22.2 -21 0 0 0 0) ((l r) 22.4 -89))

32. Step 2 - Classification • Once the log file has been obtained, it must be used in order to classify the data into symbolic form. • Our Classifier application provides the user with a GUI such that objects can be classified as the user deems appropriate.

33. Step 2 – Continued …

34. Step 2 – Continued … • After all the classification required has been completed, use of the Generate button will create an ARFF file. • The ARFF file is used in WEKA – a machine learning repository – as a data file.

35. Step 3 – Data Mining • For some aspects of soccer, the determination of a particular action depends on more than one player. • The LogMiner is used to filter out unwanted data, and may be used in the future to obtain particular entries – i.e. relating to passing. • It makes use of the ARFF file(s) to convert the numerical data into a symbolic representation

36. Step 3 – Continued … • The new log entry will look as follows: (see 0 ((g r) 23.8 -19) ((f g r t) 27.1 -33) ((f g r b) 22.4 -2) ((f r t 10) 32.8 -33) ((f r 0) 28.5 -16 0 0) ((f r b 10) 27.7 4 -0 0) ((f r b 20) 30 23) ((f r b 30) 35.2 38) ((p "EW_02" 1) 22.2 -21 0 0 0 0) ((l r) 22.4 -89)) (see 0 (Goal Left_Near) (Flag Left_Near) (Flag Front_Near) (Flag ExtremeLeft_Far) (Flag Front_Near) (Flag Front_Near) (Flag Right_Far) (Flag Right_Far) (Teammate Left_Near) (Line ExtremeLeft_Near))

37. Step 4 – Use of Learning • A GUI called IAS (In then Agent’s Shoes) was developed by Tarek Hassan, allowing a human to play as one of the agents. • Instead of playing via commands, the goal is to convert the server communication to symbols – using these for visualizing the objects.

38. Step 4 – Continued … • The problem, is that with any sort of symbolic representation, there will be a loss of detail – therefore the objects displayed will not be exact – just approximations. • However, in real soccer, this is exactly the case! A player does not know that a teammate is 20 metres ahead, and 22 degrees to the left.

39. Summary of Process • The process involves 4 main steps: • Obtain a log file (Logger) • Classification of objects (Classifier) • Data mining (LogMiner) • Using learned material (Advanced IAS).

40. References • Most of the information about RoboCup itself was taken using from the RoboCup Soccer Server manual. • For the latest manuals and code, visit the RoboCup project website at: • http://sourceforge.net/projects/sserver

41. Q & A • Feel free to ask any questions • If time permits, I will attempt to run a demonstration game.

42. Demo • This small demo shows the three major components: • Soccer Server • Soccer Monitor • Soccer players (Krislet)