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 2Nombre: 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 3Nombre: 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.