Robocup l.jpg
Advertisement
This presentation is the property of its rightful owner.
1 / 42

RoboCup PowerPoint PPT Presentation

RoboCup By: Paul Marlow Date: February 17, 2002 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

Download Presentation

RoboCup

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Robocup l.jpg

RoboCup

By: Paul Marlow

Date: February 17, 2002


Background l.jpg

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


Background ii l.jpg

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


Goals l.jpg

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


Simulation league l.jpg

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


Soccer server l.jpg

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


Soccer monitor l.jpg

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


Autonomous players l.jpg

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


Rules judged by the automated referee l.jpg

Rules Judged by the Automated Referee

  • Kick-Off

  • Goal

  • Out of Field

  • Player Clearance

  • Play-Mode control, including offsides

  • Half-time and Time-up


How to start the server l.jpg

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


Connection communication protocols l.jpg

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


Client control protocols l.jpg

Client Control Protocols


Client sensor protocol hear l.jpg

Client Sensor Protocol - Hear

  • (hear Time Sender Message)

    • Sender = online_coach_left/right, referee, self, Direction

    • Direction = -180 – 180 degrees


Hear example l.jpg

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 )


Client sensor protocol see l.jpg

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)


Client sensor protocol see ii l.jpg

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)


Client sensor protocol see iii l.jpg

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


See example l.jpg

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))


Client sensor protocol sense body l.jpg

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))


Sense body example l.jpg

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))


Krislet l.jpg

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


Stripslet l.jpg

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


Actors l.jpg

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


Sensors l.jpg

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.


Actions l.jpg

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”)


Actions ii l.jpg

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


Goallist l.jpg

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


Approach l.jpg

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.


Approach ii l.jpg

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).


Step 1 obtain a log file l.jpg

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).


Step 1 continued l.jpg

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))


Step 2 classification l.jpg

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.


Step 2 continued l.jpg

Step 2 – Continued …


Step 2 continued34 l.jpg

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.


Step 3 data mining l.jpg

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


Step 3 continued l.jpg

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))


Step 4 use of learning l.jpg

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.


Step 4 continued l.jpg

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.


Summary of process l.jpg

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).


References l.jpg

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


Slide41 l.jpg

Q & A

  • Feel free to ask any questions

  • If time permits, I will attempt to run a demonstration game.


Slide42 l.jpg

Demo

  • This small demo shows the three major components:

    • Soccer Server

    • Soccer Monitor

    • Soccer players (Krislet)


  • Login