Fútbol de Robots: Liga de Simulación 2D RoboCup

Transcripción

1 Instituto de Computación Facultad de Ingeniería Universidad de la Republica Tesis de Grado Fútbol de Robots: Liga de Simulación 2D RoboCup Características del Simulador Junio 2005 Raúl Canales Serrana Casella Pablo Rodríguez Tutor MSc. Gonzalo Tejera

2 Tabla de Contenido Tabla de Contenido Objetivo Introducción... 3 Organización del documento Resumen Monitor... 6 Logplayer Soccer Server Arquitectura La comunicación con el Simulador Objetos de la Simulación El Tiempo para el Simulador Modelado de la realidad Modelo auditivo Modelo de Visión Modelo Corporal (Sense Body) Modelo de Movimientos Modelo de Acciones Jugadores Heterogéneos El Referee Clientes Coach Trainer Conexión al Soccer Server con o sin juez automático Online Coach Comunicación con los jugadores Cambio de Tipo de Jugador (palyer types) Comandos Comandos utilizados solo por el coach trainer Comandos utilizados por el trainer y el online (con restricciones) Comandos utilizados por ambos coach Comandos utilizados solo por el coach online Referencias Apéndices Protocolos Comandos del Cliente Controles del Cliente Sensores del Cliente Parámetros del Soccer Server Página 2 de 2

3 1. Objetivo El objetivo de este documento es resumir las principales características del simulador de fútbol de la liga simulada 2D de RoboCup. La lectura del mismo debería dotar al lector de conocimientos generales del simulador y su funcionamiento; por información más detallada referirse al manual oficial de la Liga [CHEN]. 2. Introducción El componente más importante de la Liga de RoboCup es sin dudas su Simulador. Un simulador de fútbol es una herramienta que permite el desarrollo de un partido en forma virtual. Una de las principales ventajas que tienen estas herramientas son las abstracciones que realizan, permitiendo a los investigadores dejar de lado problemas asociados al manipular robots físicos, tales como son: el problema de reconocimiento de objetos, la comunicación, movimiento, etc., para focalizarse en conceptos de alto nivel tales como la cooperación y el aprendizaje. En el caso del simulador de la RoboCup, los jugadores son agentes con características propias, que no responden en forma directa a ningún modelo o formato de robot en particular, como si sucede con otros simuladores con fines similares [CAS]. Este simulador ha sido desarrollado para soportar competencias entre equipos de fútbol virtuales que se desarrollan en un determinado entorno multia-gente, con demandas de tiempo real contemplando una realidad cambiante. Uno de los mayores problemas que tienen los simuladores es que las intenciones de los jugadores no pueden ser deducidas automáticamente. Aunque el simulador incluye un arbitro artificial, este esta implementado de forma parcial en el sentido que solo puede detectar situaciones triviales, como por ejemplo cuando un equipo hace un gol. Hay situaciones que no son fáciles de detectar en el contexto del simulador, como pueden ser los bloqueos mutuos. A partir de lo anterior es que surge la necesidad de contar con un árbitro humano que supervise el flujo del juego. Aun así, todos los equipos que participen en esta liga están obligados a jugar de acuerdo a un código de honor. No es difícil engañar al simulador para sacar ventajas de determinadas situaciones no contempladas, pero esto es considerado como una acción deshonesta. El simulador junto con su manual oficial [CHEN] ha sido el resultado de un gran esfuerzo de investigadores de todas partes del mundo. La primera versión fue generada en el año 1993 como una librería para la demostración de un lenguaje llamado MWP, un tipo de sistema basado en Prolog que contaba con propiedades de multihilado. Esta versión fue evolucionando hasta lo que es hoy, una versión cliente-servidor escrita en C/C++, pasando anteriormente por versiones construidas en LISP. La versión actual, y desde la versión 2 del año 1996, se compone de dos programas principales, el soccerserver y soccermonitor. El primero es responsable de los movimientos de la pelota y los jugadores. Esto lo hace de acuerdo a las reglas definidas para la liga [CAN]. El soccermonitor es el responsable de la visualización del campo de juego virtual, para lo cual usa soporte de interfases graficas de la plataforma subyacente. Página 3 de 3

4 3. Organización del documento El documento esta organizado como sigue. La primera sección presenta un breve resumen de las características más relevantes del Simulador. Posteriormente hay una sección dedicada a cada uno de los componentes, donde la sección del servidor presenta un mayor grado de granularidad que el resto. A continuación se describen brevemente las características de los diferentes tipos de agentes o clientes que admite el simulador. Por último se encuentra la sección de bibliografía y referencias, seguida de una sección de apéndices donde se describen los protocolos de comunicación y el archivo de configuración del servidor. 4. Resumen El simulador de la RoboCup contempla muchas de las complejidades del mundo real. Plantea un gran desafío a los investigadores y brinda una plataforma realista para el desarrollo y manejo de agentes. Este simulador, Soccer Server de aquí en más, es casi un sistema de tiempo real que trabaja con intervalos de tiempo discretos usualmente de 100ms de duración. Estos intervalos de tiempo son denominados ciclos del simulador y son su unidad de tiempo. Durante un ciclo, un cliente conectado al servidor, al cual se denomina agente, recibe información de distinto tipo obtenida de los sensores que posee. Por este motivo, si los agentes desean decidir en función de información vigente, deben responder inmediatamente a cada ciclo para completar una acción. Esto requiere tomar decisiones en tiempo real. Cuando un agente decide lo que quiere hacer, la acción se ejecuta recién cuando se termina un ciclo del simulador. Por lo tanto, podemos decir que el servidor usa un modelo de acciones discretas, mientras que por otro lado, los agentes deben decidir en tiempo real. Cada agente es un programa cliente separado e independiente que puede ser desarrollado potencialmente en cualquier lenguaje. Estos agentes no pueden comunicarse directamente, la comunicación permitida en la liga es solo en forma indirecta a través del simulador. Todos los agentes del campo de juego usan el mismo canal de comunicación el cual tiene poco ancho de banda y es poco confiable. Para el simulador, hay dos grandes tipos de agentes, los jugadores y los entrenadores o coachs. Los agentes que son del tipo jugador, pueden desarrollar diferente tipo de acciones, las cuales están divididas en dos categorías: acciones primarias y acciones concurrentes. Durante un ciclo de simulador solo puede ejecutarse una acción primaria, mientras que varias acciones del tipo concurrentes pueden ejecutarse simultáneamente con una acción primaria. Aunque un agente solicite la ejecución de más de una acción primaria, el simulador solo ejecutara una de ellas. Por otra parte, los agentes del tipo Coach son clientes privilegiados del Soccer Server que tienen como objetivo dar asistencia a sus jugadores. Existen dos tipos de coach, online y trainer (este último también llamado offline). El primero solo puede ser usado en la etapa de desarrollo o aprendizaje del equipo y su principal cometido es interactuar con el servidor para generar sesiones de entrenamiento, para lo cual cuenta con acciones especiales. Por otra parte, el coach online puede ser conectado a los partidos oficiales. Su función principal es observar el partido y brindar información a sus jugadores en pos de mejorar su juego. Los sensores que el simulador brinda a cada agente jugador (también llamados modelos) son: el sensor auditivo, sensor físico y el sensor visual. El sensor físico brinda al agente datos como su energía o velocidad actual. También informa como fueron desarrolladas algunas acciones asociadas a él. El sensor auditivo provee al agente de los mensajes que fueron detectados desde otros agentes. La cantidad y calidad de los mensajes que un agente puede recibir esta limitada por determinados parámetros configurables. Por otro lado, es importante mencionar que los mensajes no son entregados por el servidor inmediatamente que son recibidos, este los Página 4 de 4

5 entrega en su siguiente ciclo de simulación. Por ultimo, el sensor visual provee al agente de información de aquellos objetos que se encuentran dentro de su campo visual (distancias y direcciones de los objetos, etc.). Este sensor también trabaja como un sensor de proximidad que puede sentir objetos que están muy cerca del agente pero fuera de su campo visual (atrás, por ejemplo). La información que los agentes reciben es relativa a su perspectiva, pero también puede ser convertida a coordenadas globales usando marcas de referencia con las que cuenta el campo de juego. En el servidor, las acciones y las reacciones son operaciones asincrónicas. Esto significa que mientras la información visual es recibida por un agente a intervalos de 150 ms (configurable), este solo puede solicitar una acción primaria una sola vez en cada ciclo de simulación (100 ms). Esto significa que en algunos ciclos los agentes deben actuar sin recibir información nueva, lo que requiere dotar a los agentes de la habilidad para predecir el estado actual del mundo, en función de su pasado reciente. Cuando el soccer server simula el movimiento de un objeto, a la velocidad del mismo se le suma su posición. La velocidad disminuye de acuerdo a determinado factor configurable del servidor y se acelera como resultado de determinados comandos de los agentes. A los movimientos de todos los objetos, el simulador le agrega ruido de forma de reflejar los movimientos inesperados de los objetos en el mundo real. El soccer server evita que los jugadores se muevan constantemente a su velocidad máxima asignándole una cantidad limitada de energía. Cuando el jugador realiza un pique se consume parte de esta energía, sin embargo en cada ciclo de simulador este le repone un porcentaje de lo consumido. Los jugadores pueden ser divididos en diferentes tipos de jugadores, característica denominada jugadores heterogéneos. Si se desea jugar de este modo, cuando comienza un juego nuevo cada equipo puede seleccionar los tipos de jugadores que quiere tener, ya que cada tipo tiene características propias como velocidad de pique, energía, etc. El Soccer Server también cuenta con un árbitro automático que controla el juego. Este puede cambiar el modo de juego y cuando lo hace informa de estos cambios a los agentes conectados al servidor. Estos mensajes son privilegiados en el sentido de que los jugadores pueden escucharlos en cualquier situación independientemente del número de mensajes que hayan escuchado de otros jugadores (recordar que los mensajes a los jugadores están limitados). El objetivo de las secciones que siguen es describir cada uno de los componentes del simulador y desarrollar los conceptos más importantes de cada uno de ellos, enfatizando la descripción del simulador. Página 5 de 5

6 5. Monitor El Monitor es una herramienta de visualización que permite observar el transcurso de un juego simulado dentro el Soccer Server. Se han desarrollado varios Monitores para diferentes lenguajes y plataformas, pero el provisto por el Simulador es el rcssmonitor. Figura 1. La figura muestra el rcssmonitor durante la simulación de un partido La información que se muestra en la pantalla del Monitor incluye: el marcador de juego, los nombres de los equipos y la posición de los jugadores del campo y de la pelota. También es posible obtener más información, como ser velocidad, posición, etc. Se pueden visualizar por pantalla o por la consola. El Monitor permite la interacción con usuarios humanos (generalmente el juez humano). Este puede comenzar el partido, cambiar la posición de los jugadores o de la pelota, etc. En las últimas versiones se permite realizar acercamientos (zoom) de cualquier parte del campo de juego. Para la simulación de un partido en el Soccer Server no es necesaria la utilización de un Monitor. Si fuera necesario, se pueden conectar varios Monitores al Soccer Server vía sockets UDP. 6. Logplayer El Logplayer es usado para la reproducción de partidos ya jugados. Esta herramienta es muy útil cuando se desea analizar el comportamiento de los jugadores, las estrategias, o los algoritmos utilizados por un equipo. Cuando se simula un partido en el Soccer Server, se puede utilizar una opción que permite grabar en un archivo toda la información de ejecución del partido. El programa rcsslogplayer, que junto con el Monitor son utilizados para la reproducción del partido desde el archivo de log. El Logplayer le ofrece al usuario varias funcionalidades: play, stop, fast forward y fast Rewind. Estas funcionalidades permiten visualizar cualquier secuencia del partido en el momento que se desee. Página 6 de 6

7 Figura 2. El rcsslogplayer es desplegado en el marco inferior izquierdo de la pantalla del Monitor. Ofrece las funcionalidades de play, stop, forward, rewind, y el número de ciclo en el que se encuentra el partido. Página 7 de 7

8 7. Soccer Server 7.1. Arquitectura El servidor consiste en 3 módulos: Field Simulator (Simulador de campo) se encarga de calcular los movimientos de los objetos del campo y manejar las colisiones entre ellos. Referee controla varias de las reglas del juego, por ejemplo offside [CAN]. Este comando indica el modo de juego (play_mode) y es usado, por ejemplo cuando la pelota se va fuera del campo, cuando se marca un gol o cuando se termina el juego. Message-Boar (Pizarra de mensajes) maneja la comunicación con los clientes. Figura 3. Arquitectura del Simulador La comunicación con el Simulador La comunicación entre clientes y el servidor se realiza a través de UPD/IP. La incorporación de la arquitectura Cliente-Servidor ha permitido que los clientes puedan ser programados en cualquier lenguaje (que soporte sockets) y bajo cualquier plataforma. Cada cliente controla un único jugador ó coach. Por ahora solo diremos que en un partido contamos con 24 procesos clientes que se dividen en 22 jugadores (uno por cada jugador de cada equipo) y 2 coach. Luego veremos en detalle cada tipo de cliente. Los clientes pueden enviar (send) y recibir (recive) comandos para controlar los jugadores a través del servidor. Algunos de los mensajes habilitados para ser enviados al servidor son: mover, girar, girar el cuello, correr, hablar, patear, etc. Por otro lado, algunas de las funciones sensoriales (recive) disponibles son: ver, escuchar, etc. Página 8 de 8

9 Objetos de la Simulación Los objetos que maneja el simulador se pueden ver en el siguiente diagrama UML. Figura 4. Diagrama UML de los objetos que maneja el simulador Como se puede ver en la figura, todo objeto del juego posee una distancia y una dirección. Los objetos del campo poseen una posición en el mismo y se pueden dividir en móviles y estáticos. Los estáticos son marcas en el campo de juego [Figura 5]. Propiedades del Jugador: Nombre del Equipo Side (l r) por izquierda o derecha. Cambia en el medio tiempo Número de camiseta (1..11) Dirección del cuerpo ( ) Dirección de la cabeza (minneckang..maxneckang) relativo a la posición del cuerpo. Los objetos estáticos Uno de los objetos que maneja el simulador, son las marcas en el campo de juego. Las marcas son fundamentales para que el jugador pueda tener una noción de espacio dentro del campo. Desde ya queremos destacar que la información percibida por el jugador siempre es relativa a él mismo, por lo que, de la visualización de estas marcas no obtendrá direcciones absolutas sino que serán relativas a su campo de visión. Página 9 de 9

10 Figura 5. Marcas del campo de juego Las marcas están divididas en izquierda(r)-derecha(l) y arriba(t)-abajo(b) además tenemos la goal line o línea de gol (goal), la línea del medio campo (c) y la línea del área del penal(p). Ejemplo de algunas marcas o flags del campo de juego: (goal r) esta ubicada en el centro de la línea de gol del lado derecho. (f c) ó (flag c) como se ilustra en la figura es la marca del centro del campo. (f l b) es la esquina de la izquierda abajo. (f p l b) en el área del penal (p) del lado izquierdo la esquina de abajo (f t l 20) esta a 5 metros por encima de la banda y a 20 metros a la izquierda del centro. Notar que entre las dos líneas perimetrales hay 5 metros El Tiempo para el Simulador Al servidor de fútbol de la RoboCup lo podemos considerar como un sistema de tiempo real en muchos aspectos, pero el mismo trabaja con tiempos discretos (de 100ms - simulator_step) llamados ciclos de simulador. Por un lado el servidor utiliza un modelo de acciones discreto donde actualiza el estado del ambiente cada simulator_step, y por otro lado, cada uno de los clientes toma sus decisiones en tiempo real y se las envía al simulador en cualquier momento. El servidor recoge las acciones de los jugadores durante el curso de un ciclo fijo de longitud simulator_step, pero las ejecuta y actualiza solamente al final del ciclo. Si un cliente envía más de un comando de movimiento en un mismo ciclo del simulador, el servidor elige uno aleatoriamente para la ejecución. Esto hace que cada jugador trate de no enviar más de un comando de movimiento por ciclo. Por otro lado, si un jugador no envía un comando de movimiento durante un ciclo, perderá la oportunidad ya que hasta el siguiente ciclo no podrá realizar acciones, esto puede ser una gran desventaja en un sistema de tiempo real con adversario. Página 10 de 10

11 Si bien el simulador actualiza el estado de su mundo cada 100 ms, el servidor envía información del mismo a los clientes cada 150 ms aproximadamente en el caso de la visión, cada uno de los sensores del jugador es actualizado independientemente del simulator_step, esto lo veremos mas adelante. Los partidos se juegan a 6000 ciclos (ó 10 minutos, 5 minutos cada tiempo) aunque esto es configurable Modelado de la realidad Cada agente posee la capacidad de percibir la realidad a través de 3 sensores. El sensor auditivo recibe mensajes del referee, los coach y del resto de los jugadores (de ambos equipos). El sensor visual recibe la información de la posición de los distintos objetos del campo. Y por último, el sensor corporal, a partir del mismo, un jugador puede obtener información de su estado físico (energía, velocidad, ángulo del cuello, etc.) Modelo auditivo El sensor auditivo recibe información desde el servidor cuando se detectan mensajes que envía un jugador, coach o el referee a través del comando Say. Todos los mensajes son recibidos inmediatamente sin necesidad de que pase un ciclo. El formato de los mensajes recibidos del servidor es: (hear Time Sender Message ) Time es el tiempo transcurrido hasta el momento: número de ciclo. Sender es la dirección relativa del que envía el mensaje (aplica solo sí es un jugador). En otro caso, Sender es: self en caso de ser el mismo quién envió el mensaje referee si lo envío el referee. Luego veremos el formato de los mismos. online_coach_left si lo envió el coach del lado izquiero y online_coach_rigth en el otro caso. Message es el mensaje enviado, el mismo tiene un máximo de say_msg_size. Capacidad Auditiva Un jugador puede escuchar un mensaje, si al menos su capacidad auditiva es hear_decay, luego de escuchado el mensaje, su capacidad auditiva se decrementa este valor. El jugador va recuperando en cada ciclo su capacidad auditiva hear_inc unidades hasta llegar a hear_max. Para que un equipo no pueda perjudicar al contrario enviando mensajes de forma de quitarle capacidad auditiva, la misma esta separada por equipo. Hoy en día no esta definido que pasa cuando varios mensajes llegan al mismo tiempo y el jugador tiene capacidad de escucharlos a todos. La implementación hasta el momento es que los mensajes los recibe y escucha por orden de llegada. De todos modos es relevante expresar, que la configuración actual de los parámetros (server.conf) del servidor esta determinada para que se pueda escuchar por ciclo, un solo mensaje de cada equipo. La restricción de la capacidad auditiva no aplica si los mensajes vienen de uno mismo o del referee. Página 11 de 11

12 Rango de Comunicación Un mensaje enviado por un jugador es transmitido solo en caso que el jugador receptor este dentro de un radio de audio_cut_dist metros del jugador emisor. Esta restricción simula, por ejemplo, que el golero no se pueda comunicar directamente con los delanteros del equipo si los mismos se encuentran lejos. Los mensajes del referee los pueden escuchar todos los jugadores. Figura 6. Parámetros de audición Modelo de Visión El sensor de visión le permite al jugador obtener por parte del servidor todos los objetos del campo que el mismo puede observar. La información es enviada por el servidor a los jugadores cada sense_step (actualmente el valor es 150 ms). Básicamente, el formato en que le llega la información al cliente es: (see ObjName Distancia Direccion DistChng DirChng BodyDir HeadDir) ObjName es el objeto visualizado, el mismo puede ser un jugador(p), la pelota(b) o una marca del campo (ver Figura 5): ObjName ::= (p "Nombre_equipo" Nro_camiseta goalie) ( g [ l r ] ) ( b ) ( 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 ] [ ] ) ( f [ l r ] [ t b ] [ ] ) ( l [ l r t b ] ) Veamos como calcular la Distancia, Dirección, DistChng (el cambio en la distancia), DirChng (cambio en la dirección), BodyDir (dirección del cuerpo) y HeadDir (dirección de la cabeza) Sean Posición absoluta del objeto observado Posición absoluta del objeto observador Velocidad absoluta del objeto observado Velocidad absoluta del objeto observador Página 12 de 12

13 Entonces Pr y Vr (posición y velocidad relativa entre los objetos) se calculan de la forma: Entonces tenemos que: Distancia Dirección DistChng DirChng Siendo: Ao = BodyDir (ángulo del cuerpo) + HeadDir (ángulo de la cabeza). La dirección hacia donde un jugador esta mirando. Vector unitario de posición relativa con coordenada x Vector unitario de posición relativa con coordenada en y La dirección de la cabeza y del cuerpo del jugador observado es relativa a la posición del cuerpo y de la cabeza del jugador observador, podemos calcular ambas como: BodyDir = Dirección de cuerpo del jugador observado A 0 HeadDir = Dirección de la cabeza del jugador observado A 0 Nota: cuando el objeto divisado es una línea, la distancia es en función de hacia donde esta mirando el jugador y la dirección es el ángulo relativo entre la línea y hacia donde mira el jugador. Rango de Visión La visión de un jugador depende de múltiples factores. Primeramente de los parámetros sense_step (150 ms) y visible_angle (90 grados), que corresponden a la frecuencia con la que se recibe información visual y los grados del cono de visión del jugador. El jugador puede influir en la frecuencia y calidad de la información que recibe, cambiando su ViewWidth (amplitud) y ViewQuality (calidad o profundidad) de visión. Para calcular la frecuencia y el ángulo de visión efectivo se usan las siguientes ecuaciones: View_frequency = sense_step * view_quality_factor * view_width_factor View_angle = visible_angle * view_width_factor El factor de calidad de visión view_quality_factor es 1 si ViewQuality es Alto ó 0,5 si es Bajo. El factor de amplitud de visión view_width_factor es 2 si ViewWidth es Estrecho, 1 si es Normal o 0,5 si es amplio. Página 13 de 13

14 Figura 7. Rango de visión de un jugador Visualización de un Jugador Ahora veremos un ejemplo basándonos de la Figura 7. Un jugador puede ver un objeto si se encuentra dentro del radio visible_distance, en caso que el objeto se encuentre fuera de su cono de visión (view_angle), el jugador solo podrá saber el tipo de objeto (ball, player, goal ó flag) y no conocerá su nombre (a). En el ejemplo de la figura, solo los objetos g y b no son visibles, el resto lo son. El cono de visión es de 90 grados, el jugador f se encuentra de frente con un ángulo relativo de 0, el e a 40 grados y el d a +20 grados relativos a la cabeza del jugador observador del ejemplo. También el ejemplo nos da una noción de distancia, de los jugadores que se encuentran cerca, se visualizará el nombre del cuadro al que pertenecen y su número de camiseta, mientras la distancia se incremente comenzará a bajar la probabilidad de ver el número de camiseta hasta que no se vea mas. En servidor cuenta con las siguientes distancias: unum_far_length=<unum_too_far_length=<team_far_length=<team_too_far_length Si tomamos como Dist, la distancia del objeto observador al objeto observado, tenemos que: Si Dist =< unum_far_length siempre se reconoce el equipo y el número de camiseta. Si unum_far_length < Dist < unum_too_far_length siempre se reconoce el equipo pero la probabilidad de ver el número de camiseta decrece de 1 a 0 mientras la distancia crece. Si Dist => unum_too_far_length el número de camiseta no es visible. Si Dist =< team_far_length siempre se reconoce el equipo. Si team_far_length < Dist < team_too_far_length la probabilidad de reconocer el equipo decrese linealmente de 1 a 0 mientras la distancia crece. Si Dist > team_too_far_length el equipo no es visible. En el ejemplo podemos notar que: de c conocemos con el equipo y el número de camiseta de d conocemos con el equipo y con 50% de posibilidades, su número de camiseta. de e solo conocemos con 50% de posibilidades, su equipo. Y a f lo vemos solo como un jugador anónimo. Página 14 de 14

15 Visualización de las marcas del campo Las marcas y líneas del campo siempre nos brindan información de su nombre, distancia y dirección. La distancia se toma por el bisector del ángulo de visión y en caso de ser una línea, la dirección es el ángulo relativo entre el bisector y dirección de la línea divisada. Modelo de Visión con Ruido De forma de incorporar ruido a la información de visión que proviene del servidor, la misma es cuantificada. Para el caso de jugadores y la pelota, se realiza de la siguiente manera: d = Quantize(exp(Quantize(log(d), quantize_step)), 0.1) Donde d y d son la distancia real y cuantificada respectivamente. Quantize se expresa de la siguiente manera: Quantize(V,Q) = Techo(V/Q)*Q Como podemos apreciar, el ruido depende de la distancia y por lo tanto podemos decir que mientras exista distancia, no vamos a conocer la posición exacta de los jugadores. Por ejemplo, si la distancia es alrededor de 100, el ruido es alrededor de 10 y si la distancia fuera 10 entonces el ruido sería alrededor de 1. Para el caso de las marcas del campo, se cuantifica el ruido de la siguiente manera: d = Quantize(exp(Quantize(log(d), quantize_step l)), 0.1) Figura 8. Parámetros del servidor para la visión Modelo Corporal (Sense Body) El modelo corporal nos brinda información del estado físico del jugador. La información es enviada automáticamente al jugador cada sense_body_sep (actualmente 100 ms). El formato del mensaje del servidor al cliente es: Página 15 de 15

16 Donde: ViewQuality es high (alto) ó low (bajo) ViewWidth es narrow (estrecho), normal ó wide (amplio) AmoutOfSpeed es aproximadamente la velocidad del jugador DirectionOfSpeed es aproximadamente la dirección del jugador HeadDirection es la dirección de la cabeza relativa al cuerpo. Las variables Count se refieren a la cantidad de comandos enviados al servidor durante el partido. Por ejemplo MoveCount nos informa de la cantidad de movimientos hechos por el jugador. La variable Stamina corresponde a la energía que posee el jugador en cada momento Modelo de Movimientos En cada ciclo del simulador, los movimientos de cada jugador se simulan según las ecuaciones que mostramos a continuación. La velocidad es influenciada positivamente por la aceleración y negativamente por el parámetro decay. La aceleración aparece en los jugadores al ejecutar el comando dash que básicamente significa correr y en la pelota cuando algún jugador la patea. El decay permanece constante (se puede ver como la fuerza de rozamiento que deben superar los objetos para movilizarse) y existe uno para los jugadores y otro para la pelota. Donde: posición del objeto en el ciclo t posición del objeto en el ciclo t aceleración del objeto en el ciclo t El cálculo para determinar la aceleración luego de la acción correr o de patear la pelota se calcula de la siguiente manera: Power es el parámetro que lleva el comando correr (ó dash) cuando es un jugador o el parámetro del comando Kick cuando es la aceleración de la pelota de la cual hablamos. Tita t, es la dirección de la cabeza del jugador o la de la pelota, esta última se calcula según la dirección de pateo incluida en el comando kick mas la dirección del jugador. Tasa de potencia power_rate la veremos mas adelante en el modelo de Acciones. Modelo de Movimientos con Ruido De forma de reflejar los movimientos inesperados de los objetos del mundo real, se les ha incorporado ruido a los movimientos y a los parámetros de los comandos que realizan los mismos. Ruido a los movimientos: Veremos la ecuación anterior con el parámetro del ruido: Página 16 de 16

17 Donde ~ r rmax es un número randómico de distribución uniforme en el rango [ r max..+r max ]. r max depende de la velocidad del objeto de la siguiente manera: rand, es un parámetro del servidor, existe uno para la pelota y otro para los jugadores. Ruido en los parámetros: Se le ha incorporado ruido a los comandos de movimiento de la siguiente manera: Ruido a raíz del viento: El simulador recientemente ha incorporado ruido a raíz del viento, incluyendo una nueva ecuación. Junto con esto se han incorporado dos nuevos parámetros: wind_force y wind_dir. Colisiones Si al final de un ciclo del simulador dos objetos se solapan, cada uno de ellos se lleva hacia atrás hasta que dejen de hacerlo. Luego, sus velocidades son multiplicadas por un factor de 0.1. Figura 9. Parámetros del servidor para movimientos Modelo de Acciones Cuando un jugador desea realizar un movimiento, lo hace a través de comandos que envía al simulador. Las acciones se pueden dividir en primarias (patear ó kick, correr ó dash, girar ó turn, agarrar ó catch y moverse ó move) y concurrentes (hablar ó say, girar el cuello ó turn_neck, modificar la visión ó change_view, consultar el estado ó sense_body, y anotar ó score). Durante un ciclo, solo se puede ejecutar una de las acciones primarias y simultáneamente a esta, se pueden ejecutar varias de las acciones concurrentes. Página 17 de 17

18 Comando Catch El golero es el único jugador habilitado a agarrar la pelota (catch). Solo puede hacerlo en el modo de juego play_on si la pelota se encuentra en una región factible donde pueda agarrarla (catchable_area) y dentro del área penal. Si el golero realiza por ejemplo un catch 45 (como se puede ver en la Figura 10), el rectángulo de lados catchable_area_l y catchable_area_w es la región donde el comando va a tener éxito con una probabilidad de catch_probability. Figura 10. Región donde el golero puede agarrar la pelota - comando catch 45 Fuera de esa área, el golero no podrá agarrar la pelota. En caso de no tener éxito en agarrar la pelota, el golero deberá esperar un tiempo de catch_ban_cycle para poder volver a intentarlo. Si el golero logró agarrar la pelota, el mismo podrá realizar comandos move para moverse dentro del área penal (hasta una cantidad de goalie_max_moves) antes de patear la pelota. Figura 11. Parámetros del servidor para el comando catch Página 18 de 18

19 Comando Dash El comando dash es utilizado para acelerar al jugador en la dirección de su cuerpo. Lleva como parámetro el poder de aceleración que debe estar dentro de un margen configurable entre minpower y maxpower. Cada jugador debe poseer la suma de energía requerida para realizar el comando dash. Al principio de cada uno de los medios tiempos, la energía de cada jugador es inicializada en stamina_max. Cuando un jugador acelera una cierta potencia, la misma se le quita de su energía y cuando un jugador desacelera (power<0) la energía gastada es mayor por lo que se le quita el doble de la potencia aplicada. En caso que el poder aplicado al correr sea mayor que la energía que posee el jugador, entonces el mismo se reduce para que pueda consumir lo que le queda de energía. Aunque lo veremos mas adelante, podemos mencionar que según el tipo de jugador se puede recurrir a energía adicional. Esta energía adicional esta en el rango de extra_stamina_delta_min y extra_stamina_delta_max. Luego de reducida la energía del jugador, el simulador calcula la potencia efectiva de la corrida edp (efective dash power). Esta tasa depende del parámetro dash_power_rate y del esfuerzo del jugador, el cual se mide con un valor entre effort_min y effort_max que depende del nivel de energía que posee el jugador. edp = effort * dash_power_rate * power La edp con la dirección del cuerpo del jugador se transforman en el vector de aceleración del jugador. Este vector de aceleración es 0 siempre que no exista un comando dash en un ciclo (y solo uno). No existe otra forma de que un jugador obtenga aceleración. La aceleración se aplicada en la transición del ciclo n al ciclo n+1 de la siguiente manera: el vector de aceleración Han es normalizado según el máximo de aceleración permitido player_accel_max Se le suma An al vector de velocidad actual del jugador (Vn). Vn se normaliza según el máximo de velocidad permitida player_speed_max. Este máximo depende del tipo de jugador. El ruido n y el viento w se le suman a la velocidad Vn. Los mismos son configurables a través de los parámetros de viento wind_dir, wind_force y wind_rand y de ruido player_rand. La nueva posición del jugador Pn+1 es la posición actual Pn más aplicar la velocidad Vn. Además, a la velocidad se le aplica una tasa de desaceleración constante player_decay para calcular la velocidad en el siguiente ciclo. (Vn+1= Vn * player_decay). La aceleración en el siguiente ciclo se reinicia con valor cero. Página 19 de 19

20 Modelo de Energía (Stamina) Acerca de la energía que posee un jugador aplican tres variables: la cantidad de energía (stamina), la recuperación (recovery) y el esfuerzo (effort). La energía disminuye al correr pero sin embargo en cada ciclo se recupera un porcentaje de esta energía. recovery se encarga de determinar cuanta energía un jugador puede recuperar luego de un ciclo y effort nos da una noción de la efectividad al correr. A continuación veremos el algoritmo que se aplica en el modelo de energía: Figura 12. Algoritmo del modelo de energía Página 20 de 20

21 Figura 13. Parámetros del servidor para el modelo de dash y stamina Comando Kick El comando Kick lleva dos parámetros: la potencia (entre minpowwer y maxpower) y el ángulo con el que se le pega a la pelota (entre minmoment y maxmoment). Una vez que llega el comando kick al servidor, se verifica que la pelota este en condiciones de ser pateada por el jugador y que no se halla producido offside. La pelota esta en condiciones de ser pateada por el jugador si la distancia entre ellos es entre 0 y kickable_margin (depende del tipo de jugador). La distancia entre ellos se calcula como la mínima, tomando como referencia el contorno de la pelota y del jugador. O sea, si tomamos la distancia desde el centro de ambos, tenemos que restar el radio del jugador y el radio de la pelota. Lo primero es calcular la potencia efectiva de la patada (ep). ep = kick_power * kick_power_rate Página 21 de 21

22 Si la pelota no se encuentra directamente frente al jugador, su ep se va a ver disminuida. Por lo tanto, el ángulo entre ambos va a determinar la reducción de ep hasta un máximo de 25%. El otro parámetro importante para ep es la distancia entre la pelota y el jugador, si la distancia es 0, ep no va a ser reducida, en cambio se llega a su máximo kickable_margin se reducirá en un 25%. El peor caso al patear la pelota será cuando su ep se reduzca un 50%. La formula queda entonces de la siguiente manera: Donde 0 <= dir_diff <= 180 grados y 0<=dist_ball<=kickble_margin. La potencia efectiva de pateo ep es utilizada para calcular el vector de aceleración aplicado a la velocidad de la pelota en el ciclo n+1. Recordar que varios jugadores pueden patear la pelota durante un mismo ciclo. También existe el parámetro kick_rand para incorporar ruido a la aceleración de la pelota similar a player_rand en los jugadores. La forma de aplicar la aceleración a la pelota es muy similar a la del jugador pero con sus parámetros propios. Algunos ejemplos con los valores de los parámetros actuales: la pelota luego de ser patada óptimamente puede cubrir una distancia de 45 metros. 53 ciclos después que la pelota es pateada (óptimamente) su distancia recorrida es de 43 metros y su velocidad de ciclos después que la pelota es pateada (óptimamente) su distancia recorrida es entre 27 y 18 metros y su velocidad es mayor a 1. Figura 14. Parámetros del servidor para el comando kick Página 22 de 22

23 Comando Move El comando move sirve para colocar a un jugador en una posición determinada del campo. El comando move existe para colocar el equipo en el campo al inicio del juego y no se permite su uso dentro de un juego normal. Es habilitado antes de comenzar cada tiempo y luego de la anotación de un gol. Otro propósito importante del move y que es habilitado durante los partidos, es para cuando el golero agarra la pelota, en este caso el golero tiene la posibilidad de ejecutar move una cierta cantidad de veces antes de patearla. Comando Say Con el comando Say los jugadores pueden comunicarse a través de mensajes. Los mensajes pueden ser de un máximo de say_msg_size y los caracteres admitidos son: [ 0-9 a-z A-Z ( ). + * /? < > _ ] Los mensajes pueden ser escuchados por otros jugadores dentro de una distancia de audio_cut_dist de ambos equipos. Los mensajes son enviados inmediatamente. El uso del comando say solo esta limitado por la capacidad de escuchar de los jugadores. Figura 15. Parámetros del comando say Comando Turn Mientras que dash es utilizado para acelerar a un jugador en la dirección de su cuerpo, el comando turn cambia la dirección del cuerpo del jugador. El comando recibe el parámetro momento que esta en el rango de minmoment y maxmoment. Si el jugador no se esta moviendo, el momento es igual al ángulo que va a girar el jugador. Sin embargo, si consideramos la inercia, tenemos que si se esta en movimiento, resulta mas difícil girar. El ángulo con el que va a girar el jugador esta determinado por: actual_angle = moment / ( inertia_moment * player_speed ) El valor por defecto de inertia_moment esta configurado en 0.5. Si consideramos este valor y la velocidad del jugador igual a 1, el máximo giro que puede realizar es de +-30 grados. La inercia depende del tipo de jugador. Figura 16. Parámetros del comando turn Página 23 de 23

24 Comando Turn neck Con el comando turn_neck el jugador puede girar su cabeza independientemente de su cuerpo. En ángulo de la cabeza del jugador determina su ángulo de visión. Mientras que turn gira el cuerpo del jugador, turn_neck gira el cuello del jugador relativo a su cuerpo. Esto significa que el ángulo de visión del jugador también va a estar condicionado al giro del cuerpo y no solo al del cuello. Tener en cuenta que este comando se puede ejecutar junto (durante el mismo ciclo) con comandos como dash, turn y kick Jugadores Heterogéneos Figura 17. Parámetro del comando turn_neck Para simular las diferencias de energía, potencia y recuperación que existen entre los jugadores humanos, el soccer server introdujo el concepto de tipo de jugador, player_type. Los tipos de jugadores junto con sus habilidades se encuentran definidos en el archivo player.config. Ambos equipos tienen la misma cantidad de tipos de jugadores disponibles. A medida que se van conectando los jugadores al simulador, el mismo les informa los tipos que se encuentran disponibles El Referee El juez automático del soccer server envía mensajes a los jugadores indicándoles el modo de juego actual del partido. Adicionalmente, les envía información de otros eventos. En todo momento el jugador puede escuchar estos mensajes. En las siguientes tablas se muestran los modos de juegos validos y los mensajes que puede enviar el juez. Play Mode Descripción T c Sig. Play Mode before_kick_off antes de comenzar cada tiempo 0 kick_off_side play_on Jugando time_over juego terminado kick_off_side comienza el juego Side kick_in_side saca Side play_on free_kick_side tiro libre para Side play_on corner_kick_side corner a favor para Side play_on goal_kick_side saque de arco para Side play_on goal_side gol para Side drop_ball pelota afuera 0 play_on offside_side offside de Side 30 free_kick_side Mensaje Descripción T c Sig. Play Mode goal_side_n anuncia el gol nro. n para Side 50 kick_off_oside foul_side foul de Side 0 free_kick_oside goalie_catch_ball_side el arquero Side atrapo la pelota 0 free_kick_oside time_up_without_a_team si no hubo oponente hasta el fin 0 timer_over del segundo tiempo time_up termino el partido 0 timer_over half_time termino el primer tiempo 0 before_kick_off time_extended tiempo extra 0 before_kick_off Figura 18. Tablas de modos de juego y mensajes del referee donde Side puede ser l o r y representa al equipo que juega a la izquierda o derecha del campo de juego, Oside es el equipo contrario y T c es el tiempo (en cantidad de ciclos) que va a pasar hasta que el siguiente Play Mode sea anunciado por el server. Página 24 de 24

25 8. Clientes Coach Los coach son clientes privilegiados del Soccer Server que tienen como objetivo dar asistencia a sus jugadores. Existen dos tipos de coach, online y trainer (también llamado offline) Trainer Este coach solo puede ser utilizado en la etapa de desarrollo o aprendizaje del equipo. Su principal cometido es interactuar con el server generando sesiones de entrenamiento para ayudar y asistir a los jugadores en el aprendizaje de sus habilidades. El trainer tiene las siguientes habilidades: Tiene control sobre el modo del partido. Puede mandar mensajes a sus jugadores (comandos o información de estado). El formato de los mensajes es libre. Puede cambiar la ubicación, dirección y velocidad de cualquier objeto móvil dentro del campo de juego. Obtiene información libre de ruido de todos los objetos móviles del campo de juego Conexión al Soccer Server con o sin juez automático Por defecto, el soccer server tiene activado el juez automático. En caso de que se quiera que el trainer tenga el control total del partido, se puede desactivar el juez. Se debe tener en cuenta que todas la tareas de las que el juez es el encargado (cambiar el modo del partido, mover a los jugadores, etc.) ya no se realizan más automáticamente y deben ser realizadas por el trainer. La activación o desactivación del juez se debe indicar al levantar el soccer server, ya sea por comando o en la configuración del archivo server.config Online Coach A diferencia del trainer, el coach online puede ser conectado a los partidos oficiales. Su principal cometido es observar el partido y brindarles información a sus jugadores en pos de mejorar el juego del equipo. Las capacidades del coach online son: Puede comunicarse con sus jugadores (con restricciones) Obtiene información libre de ruido de todos los jugadores y de la pelota Desde el año 2001 existen grupos de investigación que se han enfocado en el desarrollo del coach online y no de los jugadores. Esto dio lugar en la RoboCup a la creación de la liga Coach. Para que se puedan desarrollar los coach online independientemente de que equipos lo utilicen, se creo el estándar coach language (CLang) para ser usado en la comunicación con el server y los jugadores. Por más información ver secciones 7.6 y 7.7 del manual del soccer server [CHAN] Comunicación con los jugadores La comunicación entre el coach y los jugadores se realiza por medio de mensajes alfanuméricos de largo configurable (say_coach_msg_size). Cuando el partido se encuentra en un modo distinto de play_on, el envío de estos mensajes es sin restricciones. Cuando el juego se encuentra en modo play_on existen restricciones en el tiempo de envío y la cantidad de mensajes. Cada 600 ciclos (especificado en freeform_wait_period) de modo play_on, puede mandar mensajes en los próximos 20 ciclos (especificado en freeform_send_period). Página 25 de 25

26 El coach puede enviar say_coach_cnt_max mensajes por partido. En caso de que el partido tenga tiempo adicional se le acreditan say_coach_cnt_max mensajes cada 6000 ciclos (o lo que dure el tiempo adicional) Cambio de Tipo de Jugador (palyer types) Usando el comando change_player_type el coach online puede cambiar el tipo de los jugadores. Cuando el partido se encuentra en modo before_kick_off, el coach puede cambiar cuantas veces quiera el tipo de sus jugadores (según los existentes en el archivo player.config). Luego de comenzado el partido se le permite cambiar hasta 3 veces el tipo de jugador (especificado en subs_max). A los jugadores de ambos equipos se les informa de las sustituciones Comandos A continuación se describen los distintos comandos con los que los coach pueden interactuar con el server Comandos utilizados solo por el coach trainer change_mode PLAY_MODE Este comando permite cambiar el modo del partido. Notar que algunos de los modos pueden generar el cambio de posición de la pelota o de los jugadores. move OBJECT X Y [VDIR [VEL X VEL Y ]] Este comando permite mover OBJECT (puede ser jugador o pelota) a la posición absoluta {X,Y}. Si VEL X y VEL Y están especificadas, el objeto se moverá con esas velocidades. check_ball Devuelve la posición de la pelota: - in_field: dentro del campo de juego - goal_l: dentro del área que se encuentra en el lado izquierdo del campo de juego - goal_r: dentro del área que se encuentra en el lado derecho del campo de juego - out_of_field: fuera del campo de juego start Este comando inicia al server. recover Este comando vuelve a cargar la energía de los jugadores a la capacidad inicial del partido. ear MODE Este comando activa o desactiva los mensajes de auditoria al trainer. El MODE deber ser on, se activa el envío de mensajes, o off, se desactiva el envío de mensajes. Página 26 de 26

27 Comandos utilizados por el trainer y el online (con restricciones) init (versión VERSION) para el coach trainer y init TEAM_NAME (versión VERSION) para el coach online Estos comandos le indican al server la versión del protocolo que se va a utilizar en la comunicación con los coach. Para el caso del coach online, TEAM_NAME indica el nombre del equipo al cual pertenece. El coach se debe conectar luego de hacerlo el último jugador del equipo. Por defecto, el coach se comunica por el puerto 6002 y el trainer por el say MESSAGE El comando realiza un broadcasts del mensaje MESSAGE a todos los clientes en el caso del coach trainer y solo a sus jugadores para el caso del coach online. change_player_type TEAM_NAME UNUM PLAYER_TYPE para el coach trainer y change_player_type UNUM PLAYER_TYPE para el coach online Este comando es usado para cambiar las características (player_type) del jugador número UNUM del equipo TEAM_NAME al tipo PLAYER_TYPE. PLAYER_TYPE es un número entre 0 y 6, donde 0 es el tipo por defecto. Para el caso del coach online no es necesario indicar el equipo ya que solo puede modificar jugadores de su equipo Comandos utilizados por ambos coach look Este comando provee información acerca de la posición de los siguientes objetos: - de la pelota - de todos los jugadores activos eye MODE Si el modo es on, el server le enviara información visual de los objetos móviles del partido cada 100 ms (un ciclo), en caso de que el modo sea off, el server suspenderá el envío de información. En este caso los coach podrán utilizar el comando look para obtener información visual. team_names Este comando le informa a los coach el nombre de ambos equipos y el lado de la cancha donde se encuentran jugando Comandos utilizados solo por el coach online Team_graphic (X Y XPM line... XPM line ) Página 27 de 27

28 9. Referencias [CAN] Raúl Canales, Serrana Casella, Pablo Rodríguez. Tutor: Mr. Gonzalo Tejera. Reglas de la Liga Reglas de la competencia Osaka2005. Proyecto de grado, Fútbol de Robots: Liga simulación 2D RoboCup Junio [CAS] Claudia Castelo, Héctor Fassi, Flavio Scarpettini. Tutor: Dr. Juan Santos. Informe de Proyecto - Tesis de licenciatura, Fútbol de Robots: Revisión del Estado del Arte y Desarrollo del Equipo UBASot de Simulación Diciembre [CHEN] Chen, Dorer, Foroughi, Heintz, Huang, Kapetanakis, Kostiadis, Kummeneje, Murray, Noda, Obst, Riley, Steffens, Wang, Yin. User Manual - RoboCup Soccer Server, versión 7.07 and laters - Febrero Fecha de visita: Abril [2DR2005] Reglas de competencia para la liga de Simulación 2D - Osaka Fecha de visita: Mayo [FIFA] Reglas del Juego. - Fecha de visita: Mayo de [CMU] Peter Stone Layered Learning in Multi-Agent Systems December Fecha de visita: Junio [ROB] RoboCup Federation - Fecha de visita: Junio [SLS] Sitio oficial de la liga simulada. - Fecha de visita: Mayo Página 28 de 28

29 10. Apéndices Protocolos Comandos del Cliente Controles del Cliente Página 29 de 29