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.

Actor	Sistema
1. En el simulador se produce un gol	2. 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 partido	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 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.

Autor	Sistema
1. En el simuladore se produce una infracción con un robot intruso en el área del arquero	2. 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.

Autor	Sistema
1. En el simuladore, la pelota sale del área de juego	2. 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.