Proyecto Grupal: Arbitraje Automático de partidos para RoboCup Small Size

Elo 329: Programación Orientado a Objetos

Autores: - Bernardo Farías
               - Francisco García
               - Marcela Polanco

Descripción del Problema

    Cada año a nivel mundial se desarrolla el evento RoboCup, donde se presentan diversas categorías, entre ellas, la Small Size. Esta competencia consiste en un juego de fútbol robótico, donde cada equipo dispone de 6 robots, donde al igual que un partido es necesario monitorear a través de un arbitro, el cumplimiento de ciertas reglas. La función de dicho arbitro, hasta el momento trabaja a través de un software manipulado por una persona parte de la organización, lo que provoca un retraso en la detección de faltas o situaciones que es necesario detener el partido, como por ejemplo los saques de costado o anotaciones, entre otras. Además, existe un factor subjetividad en la toma de decisiones, lo que puede generar sanciones indebidas o faltas sin cobrar.

 
Descripción del Proyecto

    Principalmente se estudió detalladamente el funcionamiento del sistema completo. Del cual está compuesto por la cancha con los 6 robots por equipos, más una cámara que está en conectado a un computador central. Además existe otro computador el cual ejecuta un programa de referee manual. Ambos envían su información respectiva a los computadores de cada equipo que están conectados en una misma red (Instrucciones del referee; posicionamiento de  los jugadores y pelota). Luego, cada equipo procesa la información y envía las instrucciones necesarias a sus robots para que estos realicen las jugadas necesarias para ganar el juego.

    En el desarrollo del proyecto, se logró realizar una interfaz que representa un árbitro donde se puede ver un contador de goles, botones para dar comienzo y fin al partido junto al tiempo transcurrido, además se muestra en que etapa del juego se encuentra este. En pocas palabras, se intentó hacer un correcto monitoreo de un partido simulado  donde los robots son autónomos, dado a la falta de tiempo se detectan los eventos, pero sin embargo no se alcanzó a implementar lo necesario para que fuera un árbitro automático completamente, por ejemplo el caso de quien cometió una falta.

    Por otro lado, para la detección de las situaciones que son realizadas por el árbitro se debieron tener en cuenta las reglas que son impuestas por la organización de la RoboCup, considerando las dimensiones de la cancha, entre otros.

Caso de Uso 1

Nombre: Gol equipo Amarillo/Azul.
Propósito: Detectar que la pelota esta en el arco del equipo azul/amarillo.
Actor: Simulador. 
Pre-Condición: El simulador debe estar funcionando. 
Evento: En la interfaz se incrementa el contador de goles en el marcado y se detiene el tiempo de juego. 
Post-Condición: Una persona debe presionar el botón Start para que el partido continúe. 
Tipo: Automático.
ActorSistema
1. En el simulador se produce un gol2. En la interfaz del referee se contabiliza el gol realizado
4. Se retira la pelota del arco y se posiciona en el centro de la cancha para reiniciar partido3. Se detiene el tiempo del partido
5. Desde la interfaz, se reinicializa el partido presionando el botón Start, reanudando la cuenta del tiempo

Caso de Uso 2


Nombre: Intruso en el área del arquero.
Propósito: Detectar si encuentra a cualquier robot en el áera del arquero.
Actor: Simulador.
Pre-Condición: Simulador debe estar funcionando.
Evento: En la interfaz se detiene el tiempo del partido.
Post-Condición: Una persona debe presionar el botón Start para que el partido continúe.
Tipo: Automático/Manual.

AutorSistema
1. En el simuladore se produce una infracción con un robot intruso en el área del arquero2. En la interfaz del referee se comunica en el display que se detectó un intruso.
4. En el simulador es retirado el robot del área del arquero.3. Se detiene el tiempo del partido
5. Desde la interfaz, se reinicializa el partido presionando el botón Start, reanudando la cuenta del tiempo

Caso de Uso 3

Nombre: Fuera del área.
Propósito: Detectar que la pelota salió del área de juego.
Actor: Simulador y usuario.
Pre-Condición: Simulador debe estar funcionando.
Evento: Se detiene el juego, es decir, se detiene el tiempo en la interfaz.
Post-Condición: Una persona debe presionar el botón Start para que el partido continúe.
Tipo: Automático/Manual.

AutorSistema
1. En el simuladore, la pelota sale del área de juego2. En la interfaz, se desplega por el display que la pelota esta fuera del área de juego
3. Se vuelve a ingresar la pelota en el área de juego.3. Se detiene el tiempo del partido
5. Desde la interfaz, se reinicializa el partido presionando el botón Start, reanudando la cuenta del tiempo






 Prueba Caso de Uso 1:
    A continuación se muestra como la interfaz contabiliza el gol realizado desde el simulador.




 Prueba Caso de Uso 2:
   A continuación se muestra como la interfaz avisa que se encuentra un intruso en el área del arquero, información entregada desde el simulador.



 Prueba Caso de Uso 3:
    A continuación se muestra como la interfaz avisa que la pelota ha salido del área de juego, información entregada desde el simulador.



Diagrama UML de clases:



Código Fuente:

Arbitraje Automatico




 Dificultades y Proyeccciones del Proyecto:

    Una de las dificultades del proyecto es el hecho de recibir paquetes desde el servidor. Generando las siguientes preguntas. ¿Cómo envía información el servidor?¿Que envía el servidor?¿Usa algún protocolo de comunicación conocido?
    El simulador envía datos por medio del protocolo de comunicación UDP realizando un multitask, esto implica que al servidor no le importa si alguien recibió un paquete, si lo recibió correctamente o si el paquete se perdió, ya que no hay un mecanismos que controle esto. Es por ello, que para recibir paquetes hay que definir la IP del simulador y el socket ocupado para tal efecto.
    Por otro lado observando la librería del simulador se determina que este entrega 3 arreglos de datos, uno con la posición de la pelota en (x,y), otro con las posiciones de los robots amarillos y un ultimo con las posiciones de los robots azules.
    Otra de las dificultades encontrada, es la subjetividad de algunas de las faltas que observa el arbitro, ya que eso no se puede automatizar, solo se permiten faltas objetivas.
    En lo que es proyecciones para este  proyecto, se podría aumentar los casos de usos, colocando más faltas a detectar, penales y tiros libres. Es importante recalcar que el referee funciona de manera dinámica por lo que si el servidor esta dinámicamente funcionando, esto no genera inconvenientes para la implementación de este.