Futbol Robotico estrategia Defensa
141
DESARROLLO DE ESTRATEGIAS BÁSICAS DE DEFENSA PARA JUEGO DE FUTBOL ROBÓTICO BAJO AMBIENTE SIMULADO Trabajo recepcional bajo la modalidad de Tesis Que para obtener el grado de Licenciado en Sistemas Computacionales Presentan: Roxana Díaz Aguilar Emmanuel Palomera May Directores de Trabajo Recepcional: M. en C. Jose Luis Gómez Ramos M.C. Guillermo de los Santos Torres Cuerpo Académico: Sistemas Inteligentes Líneas de Generación y Aplicación del Conocimiento: Agentes, Robótica y Visión Computacional UNIVERSIDAD JUÁREZ AUTÓNOMA DE TABASCO DIVISIÓN ACADÉMICA DE INFORMÁTICA Y SISTEMAS Cunduacán, Tabasco Febrero 2012
description
El fútbol robótico es una disciplina que exige al robot percibir su entorno, utilizar los datos para razonar y emprender las acciones apropiadas, esto resulta útil para personas que están iniciando en áreas de la robótica porque les permite poner a prueba los conocimientos adquiridos.Esta investigación será antecedente para crear en la División Académica de Informática y Sistemas un banco de estrategias que pueda ser utilizada por alumnos de la institución con fines de investigación. Esta investigación se realizó utilizando la metodología Desarrollo Adaptable de Software (ASD), la cual es una metodología ágil y consta de un ciclo de vida iterativo de constantes mejoras. Apoyándose del Lenguaje Unificado de Modelado (UML), para la elaboración de la documentación y planeación, siendo muy útil al momento de realizar la parte de programación.Las estrategias de defensa desarrolladas fueron probadas a largo de treinta partidos teniendo como oponente la estrategia de ejemplo que trae el simulador, los resultados fueron mejorando durante el desarrollo de las pruebas.
Transcript of Futbol Robotico estrategia Defensa
DESARROLLO DE ESTRATEGIAS BÁSICAS DE DEFENSA PARA JUEGO DE FUTBOL ROBÓTICO BAJO AMBIENTE
SIMULADO
Trabajo recepcional bajo la modalidad de TesisQue para obtener el grado de
Licenciado en Sistemas Computacionales
Presentan:
Roxana Díaz AguilarEmmanuel Palomera May
Directores de Trabajo Recepcional:
M. en C. Jose Luis Gómez RamosM.C. Guillermo de los Santos Torres
Cuerpo Académico:
Sistemas Inteligentes
Líneas de Generación y Aplicación del Conocimiento:
Agentes, Robótica y Visión Computacional
UNIVERSIDAD JUÁREZ AUTÓNOMA DE
TABASCO
DIVISIÓN ACADÉMICA DE INFORMÁTICA Y SISTEMAS
Cunduacán, Tabasco Febrero 2012
DESARROLLO DE ESTRATEGIAS BÁSICAS DE DEFENSA
PARA JUEGO DE FUTBOL ROBÓTICO BAJO AMBIENTE
SIMULADO
Trabajo recepcional bajo la modalidad de TesisQue para obtener el grado de
Licenciado en Sistemas Computacionales
Presentan:Roxana Díaz Aguilar
Emmanuel Palomera May
Directores de Trabajo Recepcional:M. en C. Jose Luis Gómez Ramos
M.C. Guillermo de los Santos Torres
Jurado Revisor:M.I.S. Homero Alpuin Jiménez
M.C. Carlos Arturo Custodio IzquierdoI.S.C. Mauricio Arturo Reyes Hernández
L.I.A. Martha Patricia Silva PayróM.I.S. Laura Beatriz Vidal Turrubiates
Cuerpo Académico:
Sistemas Inteligentes
UNIVERSIDAD JUÁREZ AUTÓNOMA DE
TABASCO
DIVISIÓN ACADÉMICA DE INFORMÁTICA Y SISTEMAS
Cunduacán, Tabasco Febrero 2012
Dedicatoria
A Dios
Por permitirme llegar hasta este punto importante en mi vida y darme salud para lograr mis objetivos, además de su infinita bondad y amor. Gracias también por los momentos difíciles que me han enseñado a valorarte cada día más, por la experiencia adquirida y la sabiduría que me ha dado.
A mi Familia
Principalmente a mis padres quienes me han heredado el tesoro más valioso que puede dársele a un hijo: Amor. A quienes sin escatimar esfuerzo alguno, han sacrificado gran parte de su vida para formarme y educarme. A quienes la ilusión de su vida ha sido en convertirme en persona de provecho. A quienes nunca podré pagar todos sus desvelos ni aun con las riquezas más grandes del mundo. A mis hermanas que las amo como todo mi corazón y gracias por apoyarme y quererme, a mi abuelita que siempre me aconsejaba y a todos mis tíos que de alguna u otra manera siempre me apoyaron.
A mis Amigos
Alex, Carlos, Emma, Irving, Ise, Karen, Keane, Kike, Lalo, Loli, Migue, Neto, Román, Watson y a todos que no menciono pero que siempre estuvieron en todos los momentos bellos y difíciles, que hicieron que las risas desahogaran mi estrés y pasar ratos agradables, gracias pos su apoyo y consejos los llevo en mi corazón.
<Roxana >
A Dios
Por darme la vida y fuerzas necesarias para salir adelante, sobre todo por permitir culminar una de las etapas más importante de mi vida, nunca me ha dejado solo, me protege y guía en cada paso que doy.
A mis Padres
Por la herencia más valiosa que pudiera recibir, fruto del inmenso apoyo y confianza que en mi se deposito, para que los esfuerzos y sacrificios hechos por mí no fueran en vano. ¡Con admiración y respeto!
A mis Amigos
Alex, Carlos, Irving, Ise, Karen, Kike, Lalo, Loli, Migue, Neto, Román, Rox, Watson y a todos aquellos que hicieron que esos momentos difíciles fueran aliviados con ratos de sus alegrías y compañía, los llevo en mi mente y corazón.
<Emmanuel >
xii
Agradecimientos
Principalmente a Dios por darnos la vida y esta gran bendición de
cumplir un logro más en nuestras vidas, gracias por su sabiduría
que nos regala a diario.
A nuestros padres que hicieron un gran esfuerzo y sacrificio para
darnos este gran regalo. ¡Este logro también es de ustedes,
gracias!
Al M. en C. José Luis Gómez Ramos por su comprensión, atención
y por habernos confiado tan valioso proyecto. Al M. en C.
Guillermo de los Santos Torres por su apoyo y por brindarnos la
oportunidad de adquirir nuevos conocimientos al desarrollar el
proyecto.
A nuestros revisores M.I.S. Homero Alpuin Jiménez, M.C. Carlos
Arturo Custodio Izquierdo, I.S.C. Mauricio Arturo Reyes Hernández,
L.I.A. Martha Patricia Silva Payró, M.I.S. Laura Beatriz Vidal
Turrubiates, por su ayuda, tiempo y apoyo dedicado a las mejoras
de esta tesis.
A todos nuestros amigos de la DAIS que fueron de apoyo en esta
etapa y que siempre se preocuparon por darnos ánimo y algunos
consejos para seguir.
xiii
A nuestros compañeros que también trabajaron en la otra parte
del proyecto. Guadalupe, Gerardo, Caro y Tilo.
A todos aquellos de que de alguna manera siempre fueron de
gran apoyo y ayuda en el desarrollo de esta tesis.
¡Gracias!
xiv
Índice
Resumen.........................................................................................................................................19
Capítulo I. Generalidades.........................................................................................................20
1.1 Antecedentes...................................................................................................................20
1.2 Planteamiento del problema...........................................................................................23
1.3 Objetivo general.............................................................................................................24
1.4 Justificación....................................................................................................................24
1.5 Delimitación...................................................................................................................25
1.6 Metodología a utilizar.....................................................................................................26
Capítulo II. Marco Teórico........................................................................................................28
2.1 Marco Legal....................................................................................................................29
2.1.1 Visual C++.................................................................................................................29
2.1.2 3D Robot Soccer Simulator........................................................................................29
2.2 Marco Conceptual..........................................................................................................30
2.2.1 Conceptos y teorías relacionados con la investigación..............................................30
2.2.1.1. Robótica..................................................................................................................30
2.2.1.2. Futbol Robótico......................................................................................................31
2.2.1.3. Estrategia de defensa..............................................................................................31
2.2.1.4. SimuRoSot..............................................................................................................37
2.2.1.5. Software de desarrollo............................................................................................38
2.3 Conceptos y teorías relacionados con el marco tecnológico..........................................38
2.3.1 FIRA...........................................................................................................................38
2.4 Conceptos y teorías relacionados con el método a utilizar.............................................40
2.4.1 POO............................................................................................................................40
xv
2.4.2 UML...........................................................................................................................43
2.4.3 Desarrollo Adaptable de Software..............................................................................45
2.5 Marco Tecnológico.........................................................................................................49
2.5.1 Simulador Robot Soccer.............................................................................................49
2.5.2 Interfaz de Usuario.....................................................................................................50
2.5.3 Lenguaje de Programación.........................................................................................55
Capítulo III. Aplicación de la metodología y desarrollo.........................................................56
3.1 Desarrollo de la metodología..........................................................................................56
3.1.1 Especular....................................................................................................................56
3.1.2 Colaborar....................................................................................................................63
3.1.3 Aprender.....................................................................................................................65
Capítulo IV. Pruebas y Resultados..........................................................................................67
4.1 Elaboración e implementación de la estrategia de defensa basada en roles...................67
4.1.1 Pruebas de la estrategia de defensa basada en roles...................................................68
4.1.2 Análisis de resultados de la estrategia de defensa basada en roles.............................72
4.2 Elaboración e implementación de la estrategia de defensa basada en áreas..................73
4.2.1 Pruebas de la estrategia de defensa basada en áreas...................................................74
4.2.2 Análisis de resultados de la estrategia de defensa basada en áreas............................79
Capítulo V. Conclusiones y trabajos futuros..............................................................................81
5.1 Conclusiones...................................................................................................................81
5.2 Trabajos futuros..............................................................................................................83
Bibliografía.....................................................................................................................................84
Glosario..........................................................................................................................................88
Anexos............................................................................................................................................90
xvi
Índice de Ilustraciones
Ilustración 1.1.- Ciclo de Vida del Modelo ASD...........................................................................26
Ilustración 2.1.- Estrategias de Defensa.........................................................................................33
Ilustración 2.2.- Jerarquía de diagramas UML 2.0, mostrados como diagrama de clases.............43
Ilustración 2.3.- Ejemplo de un Diagrama de Caso de Uso y su Simbología.................................44
Ilustración 2.4.- Ejemplo de un Diagrama de estado y su simbología...........................................45
Ilustración 2.5.- Ejemplo de un diagrama de secuencias y su simbología.....................................45
Ilustración 2.6.- Ciclo de Vida del Modelo ASD...........................................................................48
Ilustración 2.7.- Pantalla de bienvenida del Simulador Robot Soccer de la FIRA........................50
Ilustración 2.8.- Menú Strategies del Robot Soccer de la FIRA....................................................51
Ilustración 2.9.- Menú Time/Score del simulador Robot Soccer de la FIRA................................52
Ilustración 2.10.- Menú en el juego Robot Soccer de la FIRA......................................................53
Ilustración 2.11.- La barra de visión Robot Soccer de la FIRA.....................................................54
Ilustración 2.12.- La barra de visión 2 del simulador Robot Soccer de la FIRA...........................54
Ilustración 3.1.- Formación estrategia basada en roles...................................................................57
Ilustración 3.2.- Caso de uso de la estrategia basada en roles........................................................58
Ilustración 3.3.- Diagrama de Estado de la estrategia Basada en Roles.........................................59
Ilustración 3.4.- Formación estrategia basada en áreas..................................................................60
Ilustración 3.5.- Caso de uso de la estrategia basada en áreas.......................................................60
Ilustración 3.6.- Diagrama de Estado de la estrategia basada en áreas..........................................61
Ilustración 3.7.- Entorno de trabajo de Microsoft Visual C++ 6.0.................................................63
Ilustración 3.8.-Fragmento de código de la función run................................................................64
Ilustración 3.9.-Fragmento de código de la función cerc...............................................................64
Ilustración 3.10.-Fragmento de código de la función go................................................................64
Ilustración 3.11.-Fragmento de código de la función kick.............................................................65
xvii
Ilustración 4.1.-Ubicación de los jugadores en el campo...............................................................68
Ilustración 4.2.- Promedio de autogoles realizados en las pruebas................................................69
Ilustración 4.3.-Promedio de goles a producidos durante las pruebas...........................................69
Ilustración 4.4.-Promedio de goles recibidos.................................................................................70
Ilustración 4.5.-Promedio del número de veces que el balón entró al área....................................70
Ilustración 4.6.-Promedio de despejes realizados de manera correcta...........................................71
Ilustración 4.7.-Promedio del número de obstrucciones por los jugadores....................................71
Ilustración 4.8.-Tiempo en promedio que se tuvo controlado el balón..........................................72
Ilustración 4.9.-Ubicación de los jugadores en el área de juego....................................................74
Ilustración 4.10.- Promedio de autogoles producidos por los jugadores........................................75
Ilustración 4.11.- Promedio de goles a favor durante las pruebas..................................................76
Ilustración 4.12.- Promedio de goles producidos por el equipo contrario.....................................76
Ilustración 4.13.- Promedio del número de balones que se tuvieron en el área defendida............77
Ilustración 4.14.- Número de veces que se despejó de manera correcta........................................77
Ilustración 4.15.- Promedio del número de obstrucciones realizadas por los jugadores................78
Ilustración 4.16.- Tiempo en promedio que se tuvo controlado en balón......................................79
Ilustración 1.- Entorno de trabajo visual 6 C++.............................................................................91
Ilustración 2.- Archivos de código fuente......................................................................................91
Ilustración 3.- Entorno de trabajo visual 6 C++.............................................................................92
Ilustración 4.- Archivos DLL.........................................................................................................92
Ilustración 5.- Directorio para cargar las estrategias......................................................................93
Ilustración 6.- Entorno del simulador.............................................................................................93
Ilustración 7.- Panel de estrategias.................................................................................................94
Ilustración 8.- Panel de estrategias.................................................................................................94
Ilustración 9.- Panel de estrategias.................................................................................................95
xviii
Índice de Tablas
Tabla 3.1.- Descripción del caso de uso de la estrategia basada en roles.......................................59
Tabla 3.2.- Descripción del caso de uso de la estrategia basada en áreas......................................61
Tabla 4.1.- Resultados obtenidos en las pruebas de calidad...........................................................68
Tabla 4.2.- Tabla Comparativa de la estrategia basada en roles....................................................73
Tabla 4.3.- Resultados obtenidos durante las pruebas de calidad..................................................75
Tabla 4.4.- Tabla Comparativa de la estrategia basada en áreas....................................................79
Tabla 1.- Resultados obtenidos en la prueba de control.................................................................90
Tabla 2.- Resultados obtenidos en la primera prueba de calidad...................................................96
Tabla 3.- Resultados obtenidos en la segunda prueba de calidad...................................................96
Tabla 4.- Resultados obtenidos en la tercera prueba de calidad.....................................................96
Tabla 5.- Resultados obtenidos en la primera prueba de calidad...................................................97
Tabla 6.- Resultados obtenidos en la segunda prueba de calidad...................................................97
Tabla 7.- Resultados obtenidos en la tercera prueba de calidad.....................................................97
xix
Resumen
El fútbol robótico es una disciplina que exige al robot percibir su entorno, utilizar los datos para
razonar y emprender las acciones apropiadas, esto resulta útil para personas que están iniciando
en áreas de la robótica porque les permite poner a prueba los conocimientos adquiridos.
Esta investigación será antecedente para crear en la División Académica de Informática y
Sistemas un banco de estrategias que pueda ser utilizada por alumnos de la institución con fines
de investigación.
Esta investigación se realizó utilizando la metodología Desarrollo Adaptable de Software (ASD),
la cual es una metodología ágil y consta de un ciclo de vida iterativo de constantes mejoras.
Apoyándose del Lenguaje Unificado de Modelado (UML), para la elaboración de la
documentación y planeación, siendo muy útil al momento de realizar la parte de programación.
Las estrategias de defensa desarrolladas fueron probadas a largo de treinta partidos teniendo
como oponente la estrategia de ejemplo que trae el simulador, los resultados fueron mejorando
durante el desarrollo de las pruebas.
Es conveniente mencionar que la estrategia de defensa basada en roles en el proceso de las
pruebas demostró tener un mejor desempeño al realizar sus tareas, que la estrategia de defensa
basada el áreas.
Para realizar las pruebas se tomaron en cuenta los siguientes aspectos: número de autogoles,
número de goles producidos, número de goles recibidos, número de veces que el balón estuvo en
el área, numero de obstrucciones de los jugadores y el tiempo en posesión del balón; los
resultados obtenidos se presentan a través de gráficas, donde se muestra la eficiencia de la
estrategia de defensa basada en roles y la estrategia de defensa basada en áreas.
20
Capítulo I. Generalidades
I.1 Antecedentes
Desde el principio de los tiempos, el hombre ha deseado crear artefactos capaces de realizar
tareas diarias, pesadas, difíciles y comunes para el ser humano, o bien, para facilitar las labores
cotidianas; se daban cuenta que habían tareas repetitivas que se podían igualar con un complejo
sistema, es así como se comienza a crear “vida artificial” con máquinas capaces de repetir las
mismas labores que el hombre realizaba; tal es el caso de los primeros modelos de ordenadores
analógicos, que comenzaron a construirse a principios del siglo XX, estas evaluaban las
aproximaciones numéricas de ecuaciones demasiado difíciles como para poder ser resueltas
mediante otros métodos. Al paso de los años hasta nuestros días, las ramas de la computación
fueron tomando un giro revolucionario impresionante; tal es el caso de la robótica que a partir de
su aparición se empezaron a desarrollar sistemas inteligentes capaces de desempeñar diversas
tareas que van desde la más simple a la más compleja. [Robótica, 1999]
El término robótica fue acuñado en 1939 por Isaac Asimov para describir la tecnología de los
robots. Él mismo predijo hace años el aumento de una poderosa industria robótica, predicción
que ya se ha hecho realidad. La robótica es un área interdisciplinaria formada por la ingeniería
mecánica, eléctrica, electrónica y sistemas computacionales. La informática provee de los
programas necesarios para lograr la coordinación mecánica requerida en los movimientos del
robot, dar un cierto grado de inteligencia a la máquina, es decir, adaptabilidad, autonomía y
capacidad interpretativa y correctiva. [González, 2002]
El término de robótica inteligente, combina cierta destreza física de locomoción y manipulación,
que caracteriza a lo que conocemos como robot, con habilidades de percepción y de
razonamiento residentes en una computadora [Alcalá, 2005]. Recientemente se ha producido una
explosión en el desarrollo y uso industrial de los robots tal que se ha llegado al punto de hablar de
"revolución de los robots" y "era de los robots". Los robots se han involucrado en una diversidad
21
de campos, es por ello que en al año de 1992 se plantea la idea de construir robots jugadores de
futbol, en un artículo del profesor Alan Mackworth de la University of British Columbia en
Canadá, titulado On Seeing Robots.
En el año de 1993 un grupo de investigadores japoneses, deciden aplicar sus conocimientos de
informática, electrónica e inteligencia artificial, en una competencia de futbol robótico, a la cual
le dieron tentativamente el nombre de Liga Profesional Japonesa de Fútbol Robótico (JLeague), a
lo largo del mes recibieron gran número de reacciones de investigadores fuera de Japón,
solicitando que esta iniciativa fuera ampliada más allá de las fronteras de Japón como un
proyecto de índole internacional, gracias a este apoyo a nivel mundial nació lo que hoy
conocemos como Copa Mundial de Futbol Robótico (RoboCup).[RoboCup, s.f.]
En septiembre de 1993, el primer aviso público de la iniciativa fue hecho, y regulaciones
específicas fueron bosquejadas. Por consiguiente, las discusiones sobre organización y
especificaciones técnicas eran sostenidas en las numerosas conferencias y talleres impartidos,
incluyendo el simposio de The Twelfth National Conference on Artificial Intelligence (AAAI-
94), de The Japanese Society for Artificial Intelligence (JSAI), y en varias reuniones de la
sociedad robótica.
Los primeros juegos y conferencias oficiales de RoboCup fueron llevados a cabo en 1997 con
gran éxito. Alrededor de 40 equipos participaron (simulación y reales combinados), y asistieron
alrededor de 5.000 espectadores. [RoboCup, s.f.]
Hoy en día son dos los campeonatos a nivel mundial que reúnen a los mejores equipos de futbol
robótico en sus diferentes categorías, la RoboCup y FIRA.
La Federation Internacional de Robot-Soccer Asociation (FIRA), surgió en 1995, su primer
campeonato se llevó a cabo en KAIST, Daejeon, Corea en 1996. La FIRA fue fundada en el
espíritu ciencia y la tecnología de la robótica. El futbol robótico puede ser interpretado como una
competencia de la tecnología de los robots en un espacio confinado. Ofrece un escenario difícil
para las nuevas generaciones y los investigadores que trabajan con sistemas autónomos móviles
de la robótica. [FIRA, 2004]
Con el paso de los campeonatos se ha requerido que nuevas categorías sean añadidas al torneo:22
MiRoSoT: Micro-Robot Soccer Tournament (Torneo de Soccer de Micro. Robots).
HuRoSoT: Humanoid Robot Soccer Tournament (Torneo de Soccer de Robots
Humanoides).
NaRoSoT: Nano Robots Soccer Tournament (Torneo de Soccer de Nano Robots).
KheperaSoT: Khepera Soccer Tournament (Torneo de Soccer de robot Khepera).
RoboSoT: Robot Soccer Tournament (Torneo de Soccer de Robot).
SimuRoSot: Simulated Robot Soccer Tournament (Torneo de Soccer de Robots
Simulado). [FIRA,2004]
Las ramas en las que se encuentra dividido el torneo de la FIRA son dos: los robots físicos y los
que trabajan mediante un ambiente simulado. Dentro de este último, se tomará como caso de
estudio la Middle League SimuRoSot [FIRA, 2004], que consiste en un ambiente simulado donde
se llevan a cabo partidos de cinco robots contra cinco. El sistema comprende un servidor que
contiene el juego perse (cancha, robots, tanteador, etc.) y dos programas clientes con las
estrategias de juego. Los cuadros pueden construir su propia estrategia y competir entre sí sin
hardware (robots) adicional. El servidor provee a los jugadores con la información de posición de
jugadores y balón en todo instante. Vale la pena notar que el tiempo interno de la aplicación no
corresponde al tiempo real (externo), dado que cada jugador es llamado una vez por iteración y
puede demorar un lapso arbitrario en responder.
23
I.2 Planteamiento del problema
Las competencias de futbol robótico fueron creadas básicamente para estimular la investigación y
desarrollo en los campos de la robótica e inteligencia artificial, es por ello que muchas
investigaciones se han realizado en estos campos ya que existe una amplia gama de temas
relacionados. Muchas instituciones en México forman parte de estas investigaciones, tal es el
caso del Tecnológico de Monterrey que se ha esforzado en investigar más en la categoría de
simulación y gracias a esto ha participado ya en varios torneos de la RoboCup desde hace varios
años; los Pumas-UNAM, del Laboratorio de Bio-robótica de la Universidad Nacional Autónoma
de México que participa en el torneo internacional de futbol con robots de forma humana y el
Instituto Tecnológico Autónoma de México(ITAM) que con su equipo de robots humanoides
llamado “Eagle Knights” participan desde el 2003 en la categoría “Small-Size” y posteriormente
en las categorías “Standard -Platform” y “@Home” habiendo obtenido importantes logros a lo
largo de estos años; por mencionar algunas.[Tri, 2009]
Dentro de los beneficios que las instituciones obtienen al realizar trabajos de investigación dentro
del área de la robótica se puede mencionar: el desarrollo de tecnología robótica que pueden ser
aplicadas en la vida cotidiana e impulsar a los estudiantes a realizar investigaciones dentro de esta
área, entre otras.
Es por esto que en la DAIS se ha tomado la iniciativa de crear Antecedentes ya que actualmente
este tipo de áreas no cuentan con tal desarrollo, por eso se ha decidido seguir los ejemplos de las
universidades mencionadas que se han esforzado por sacar adelante proyectos de investigación
aportando con esto una valiosa oportunidad de formar un equipo de futbol robótico capaz de
participar en competencias y torneos de acuerdo a las reglas establecidas y pueda desarrollar
eficientemente las estrategias de juego con el objetivo de anotar un gol y con esto ser reconocidos
como participantes en los torneos de la FIRA en la categoría de SimuRoSot.
24
I.3 Objetivo general
Desarrollar estrategias básicas de defensa que puedan ser aplicadas dentro del juego de futbol
robótico simulado, con la finalidad de jugar un partido de acuerdo a las reglas establecidas en la
Middle League de la categoría SimuRoSot.
1.3.1 Objetivos específicos
Desarrollar estrategias de defensa que cumplan las funciones básicas para cuidar la
portería, de los ataques del equipo contrario.
Identificar patrones de juego para poder utilizar una estrategia de juego apta.
Crear antecedentes y darlos a conocer como avances en el campo de la robótica dentro de
la DAIS.
I.4 Justificación
El motivo de esta investigación, es poder elaborar antecedentes de juego de futbol robótico
simulado en la DAIS, que sirvan para estimular y acelerar la educación, la investigación
acompañado de tecnologías en el campo de inteligencia artificial y robótica, con esto se pretende
que los estudiantes de la DAIS puedan llegar a formar un equipo de futbol robótico capaz de
desempeñarse como uno de los mejores hasta llegar a ser reconocidos a nivel mundial como una
de las universidades que cuenta con material tanto humano como tecnológico capaz de dejar
huella ante la sociedad.
Un sistema de fútbol robótico es una disciplina que requiere de vastos conocimientos de
robótica; los estudios y conocimientos adquiridos en el desarrollo de estos sistemas
pueden servir como base para formular nuevos proyectos afines que puedan ser de gran
utilidad para aquellas instituciones que están directa e indirectamente involucradas en este campo
de investigación, como lo son: el Tecnológico de Monterrey y el Tecnológico de Guadalajara,
que son los que se encuentran activos en los torneos de la SimuRoSot.
25
Cabe mencionar que las técnicas y métodos implementados en el sistema de fútbol
robótico pueden ser aprovechados como base para ser aplicados en diversos dominios,
como son: misiones espaciales, búsqueda y rescate (de información, personas, entre otros.),
mantenimiento de hospitales y fábricas, combates en el campo de batalla,
exploración submarina y enrutamiento de redes, pueden beneficiarse de las técnicas usadas
en los sistemas de fútbol robótico.
Con esta investigación la DAIS, podrá ser representada en diferentes torneos de futbol robótico
por futuros investigadores con ayuda de los recursos que se aportan, como son las estrategias
programadas para la creación de un banco de estrategias, recursos de programación con que
fueron elaboradas las estrategia y el manejo de un simulador que no ha sido aprovechado de
manera amplia para fines de investigación.
I.5 Delimitación
1.5.1. Alcances
Desarrollar la estrategia básica de defensa del juego de futbol robótico en el simulador de
Robot Soccer actualizado.
Brindar a la División Académica de Informática y Sistemas conocimientos que puedan ser
útiles para la formación de un equipo de futbol robótico.
1.5.2. Limitaciones
Solamente se desarrollarán estrategias para el rol de defensa del equipo.
La ejecución de las estrategias será bajo ambiente simulado con el simulador vigente en el torneo.
Los roles, portero, defensor y delantero, determinados para el partido desempeñarán la
misma labor desde que inicie hasta que finalice el encuentro.
26
I.6 Metodología a utilizar
La metodología que se decidió utilizar es Desarrollo Adaptable de Software (ASD), apoyándonos
de UML para la documentación que sea requerida en la investigación.
En la ilustración 1.1 se muestra el proceso y etapas de ASD.
Ilustración 1.1.- Ciclo de Vida del Modelo ASD. Fuente: [Huarachi, 2009]
Especular
Inicio de la investigación:
Investigar y documentarse sobre el tema, (se encuentra comprendido en el capítulo 2), estudiar
las estrategias cargadas por defecto para ver la manera en que se pueden defender, identificando
los patrones o maneras de ataque además de identificar las posibles maneras de defender el arco
de los ataques de los oponentes.
Documentarse sobre el tema.
Planeación:
Definir las estrategias así como las funciones que serán realizadas en cada una de las estrategias y
documentadas mediante UML (lo cual está comprendido en el capítulo 3), además definir qué
tipos de pruebas serán realizadas, cantidad y tiempo de duración.
27
Identificación de patrones de juego.
Proponer estrategias a realizar.
Definición de las funciones básicas para la operación de las estrategias.
Planeación de las estrategias realizando diagramas UML.
Definir pruebas de calidad.
Colaborar
Comprende la construcción de las funciones definidas en la etapa de "planeación", así como la
integración de las mismas para la creación de las estrategias propuestas (lo cual está comprendido
en el capítulo 3).
Construcción de las estrategias.
Atender soluciones planteadas.
Aprender
Revisión de calidad:
Probar cada una de las estrategias creadas, así como identificar los problemas presentes que
deben de ser corregidos (se encuentra comprendido en el capítulo 4). Realizar las pruebas que se
definieron, anotando cada uno de los resultados obtenidos.
Análisis de resultados.
Identificación de problemas y debilidades.
Plantear soluciones.
28
Capítulo II. Marco Teórico
El fútbol robótico, pretende estimular la investigación en áreas como la Inteligencia Artificial, la
robótica y la visión computacional.
En el campo de fútbol robótico existen diferentes situaciones a afrontar con los robots. Una de las
situaciones más complejas es la estrategia de juego, aquí se desarrolla una estrategia para la
defensa del juego bajo un ambiente simulado. Cada defensor tiene como función primordial
evitar que su arco corra peligro de gol, realiza su tarea manteniendo la pelota fuera del área penal
propia, ya sea interceptando, despejando, pasando, marcando, entre otros. Cuando una situación
se sale de control debe extremar los cuidados ya que su actuación podría derivar en perjuicios
para su equipo.
En la actualidad existen diversas competencias de fútbol robótico. El interés teórico detrás de
estas experiencias es el uso del fútbol como un prototipo de sistema complejo y adaptativo que
permita el desarrollo de técnicas para la construcción de robots capaces de llevar a cabo tareas
más útiles.
29
II.1 Marco Legal
Para el desarrollo correcto de este proyecto de investigación se necesitará software que brinde
soporte al desarrollo de la programación o a la metodología usada para calcular tiempos y costos
del mismo.
Se presenta a continuación una descripción breve acerca de la situación legal a la que los
desarrolladores se enfrentan a la hora de utilizar el software correspondiente.
II.1.1 Visual C++
Actualmente la Universidad Juárez Autónoma de Tabasco sostiene un convenio con la empresa
Microsoft México la cual brinda licencias de tipo académico del programa MSDN a los
estudiantes de esta máxima casa de estudios.
La Librería MSDN es un recurso imprescindible para los programadores que trabajan con
herramientas, productos y tecnologías de Microsoft. Contiene una gran cantidad de información
técnica de programación, incluidos código de ejemplo, documentación, artículos técnicos y guías
de referencia.
Como ya se mencionó, para el desarrollo de la parte de programación de esta investigación,
utilizamos la herramienta Visual C++, misma que los alumnos de la UJAT pueden obtener de
manera gratuita.
II.1.2 3D Robot Soccer Simulator
El Robot Soccer Simulator desarrollado por el equipo de desarrollo de RSS es para uso exclusivo
del cliente y se ha emitido sin ningún tipo de garantía expresa o implícita, incluyendo pero no
limitada las garantías implícitas de comerciabilidad o aptitud para un propósito particular. La
totalidad del riesgo en cuanto a la calidad y el rendimiento de los datos, software o servicios
suministrados son con el cliente. Si los datos, software o servicio defectuoso, asume el coste de
cualquier servicio, reparación o corrección. En ningún caso, menos que sea requerido por la ley
aplicable será el equipo de desarrollo de RSS, es responsable ante usted por daños, incluyendo
30
cualquier pérdida de beneficios, dinero perdido, o de otro daño especial, incidental, ejemplar o
consecuente que surja del uso o la imposibilidad de utilizar los datos, software o servicios
proporcionados por el Equipo de Desarrollo de RSS.
El uso de este software también está pensado para aquellos con un fondo o una cierta
comprensión de las tecnologías aplicables. Se señaló de manera expresa que todos los individuos
que significa el desarrollo de este nuevo programa o desarrollar estrategias a su voluntad tengan
un conocimiento de trabajo de Director y su lenguaje de programación, Lingo. Programación de
las estrategias se incluye en el manual, sin embargo, se supone que el usuario tenga conocimiento
en lingo y el conocimiento básico de programación orientada a objetos en general. El diseño de
este programa se entiende como un motor para que otros puedan desarrollar estrategias, como tal,
el equipo de programación en sí aún no comienza a comprender las infinitas formas posibles de
la programación de los robots. El equipo, sin embargo, proporcionar los elementos básicos para
desarrollar estrategias, algunas que son necesarias y otras sugerencias basadas en investigación y
las pruebas hasta la fecha.
II.2 Marco Conceptual
II.2.1 Conceptos y teorías relacionados con la investigación
1.1.1.1. Robótica
En el término robot confluyen las imágenes de máquinas para la realización de trabajos
productivos y de limitación de movimientos y comportamientos de seres vivos. [Ollero, 2001]
En siglo XXI el desarrollo de máquinas ha estado fuertemente influido por el progreso
tecnológico. De esta forma se pasa de máquinas que tienen como objetivo exclusivo la
amplificación de la potencia muscular del hombre, sustituyéndolo en si trabajo físico, a máquinas
o instrumentos que son también capaces de procesar información, complementando, o incluso
sustituyendo, al hombre en algunas actividades intelectuales.
31
La noción de robótica atiende a una idea de estructura mecánica universal capaz de adaptarse,
como el hombre, a muy diversos tipos de acciones. La robótica, en sentido general abarca una
amplia gama de dispositivos con muy diversas cualidades físicas y funcionales asociada a la
particular estructura mecánica de aquellos, a sus características operativas y al campo de
aplicación para el que sea concebido. Todos estos factores están íntimamente relacionados, de
forma que la configuración y el comportamiento de un robot condicionan su adecuación para un
campo de aplicación especifico. La robótica se apoya en gran medida en los progresos de la
microelectrónica y la microinformática, así como en nuevas disciplinas como el reconocimiento
de formas y la inteligencia artificial. [Noción, s.f.]
1.1.1.2. Futbol Robótico
Competencia de futbol llevada a cabo con robots tanto físicos, como simulados, que tratan de
asemejarse lo más posible a un juego de futbol de humanos.
Las competencias de fútbol con robots fueron creadas básicamente para estimular la
investigación y el desarrollo en los campos de la robótica y la inteligencia artificial,
además de las áreas de visión computacional, procesamiento de imágenes, electrónica e
informática por mencionar unas cuantas. Los competidores, estudiantes y científicos de
universidades, deben diseñar robots equipados con sistemas de visión que detectan la pelota y
que distinguen entre los jugadores de su equipo y los del equipo contrario. Cada robot posee
inteligencia y actúa individual o colectivamente de acuerdo a la situación del juego,
siempre con el objetivo de meter gol al equipo oponente.
1.1.1.3. Estrategia de defensa.
Un defensor, en general, realiza su tarea manteniendo la pelota fuera del área penal propia y
quitando la pelota al oponente. Cuando un defensor está en posesión de la pelota, la pasa a un
compañero en lo posible que esté más arriba dentro de la cancha, a un compañero que esté libre
de manera de asegurar la pelota, o bien la despeja enviándola a un lugar seguro lejos de los
rivales y del arco propio, evitando el centro de la cancha. El defensor debe mantener una posición
defensiva dentro del campo de su equipo entre la pelota y el arco propio, aunque no siempre esto
32
es posible. Cuando un defensor ha sido superado por la pelota, debe tener especial cuidado de no
generar una jugada peligrosa que desemboque en un gol en contra. En esta situación, algunos
defensores optan por sólo obstruir el paso de los oponentes, sin acercarse a la pelota, lo que
permite que un compañero mejor posicionado pueda ir a controlar la pelota [Veloso, 1999].
Las tácticas de desplazamiento descriptas para el arquero son aplicables a los defensores. El
desplazamiento en línea recta es ampliamente utilizado como táctica de defensa. Se pueden
organizar variantes teniendo en cuenta la coordenada X sobre la cual actúa cada robot y la
amplitud de desplazamiento en coordenada Y. Es decir, se puede tener a más de un defensor
desplazándose en forma paralela al arco, pero a distintas distancias del mismo, y además puede
que estos defensores recorran todo el ancho de la cancha o sólo el lateral que les toca defender.
La trayectoria curva sólo puede ser ejecutada con centro en el arco por uno o más defensores. El
radio de esta curva debe ser lo suficientemente amplio de manera de no entorpecer al arquero.
Una posible implementación puede ser tener un defensor en trayectoria curva y uno o más
defensores, o mediocampistas, en trayectoria recta, por delante del primero formando así dos
niveles de defensa.
Cuando un equipo tiene más de un jugador cumpliendo con el rol de defensor, aparecen distintos
subroles o modos de comportamiento dependiendo de la situación actual. En el equipo de
simulación CMUnited-98 se definen los siguientes modos de comportamiento para los
defensores:
Defensa activa: el agente irá al encuentro de la pelota, decidiendo luego si la pasa, la
lleva o la despeja, dependiendo de sus posibilidades.
Defensa auxiliar: el jugador marca a un rival ubicándose cerca de él en una posición
que le dificulte recibir o pasar la pelota.
Defensa pasiva: el defensor se interpone en la línea entre un rival y el arco propio a una
distancia mayor a la de marcado, de manera de evitar un posible tiro al arco.
33
La tarea de defensa puede ser llevada en forma activa o pasiva como se observa en la Ilustración
2.1.
Ilustración 2.1.- Estrategias de Defensa. (a)Defensa activa de despeje (DAD) (b) Defensa activa de encuentro (DAE) (c) Defensa pasiva en arco (DPA) (c) Defensa pasiva en trayectoria (DPT).
Fuente: [Castelo, 2002]
Se considera activa la defensa cuando el jugador va al encuentro de la pelota, ya sea para
apoderarse de ella ejecutando acciones tendientes a alejarla del arco propio y, de ser posible,
acercándola al arco rival (Defensa Activa de Despeje: DAD) o cuando intenta obstruir su paso
dirigiéndose a un punto sobre la trayectoria actual de la pelota para que no siga avanzando en
campo propio (Defensa Activa de Encuentro: DAE).
Es una defensa pasiva la que lleva a cabo un jugador cuando su comportamiento tiende a cubrir una
zona con su presencia. La estrategia de defensa pasiva también presenta dos posibilidades en la
implementación actual: una es ubicarse sobre la línea que va desde la posición actual de la pelota y el
centro del arco, evitando así dejar libre el camino hacia el arco, sin importar hacia donde se mueve
actualmente la pelota (Defensa Pasiva en Trayectoria: DPT); la otra acción posible es ubicarse
frente al arco, ya sea para cubrir el centro o un lateral. Aquí tampoco se tiene en cuenta donde está
la pelota, ya que ésta está siendo cubierta, supuestamente, por el otro defensor. De esta manera se
trata de dejar menos espacio libre frente al arco, ya que un pase o rebote puede hacer que la pelota
cambie bruscamente de dirección y quedar así el defensor principal mal ubicado (Defensa Pasiva en
Arco: DPA). 34
A diferencia del arquero, donde un único jugador cubre el rol y por lo tanto éste es el responsable
de todas las acciones que el mismo requiere, al haber dos defensores sus tareas deben ser
complementarias y sus acciones coordinadas. Por ello, cada uno debe analizar que parte de la
defensa le toca llevar a cabo. El caso más sencillo es aquel en el que la pelota está en poder del
equipo propio y en ataque. Aquí ambos defensores ejercen una defensa pasiva posicionándose a
ambos lados del frente del arco (DPA) por fuera del área grande. Cuando la pelota está dentro del
campo propio o viene hacia él, ya los defensores deben tomar acciones acordes a la
circunstancia.
En el caso que uno de los defensores resulta el mejor ubicado para llegar a la pelota, lleva a cabo
un comportamiento llamado Despejar Pelota convirtiéndose así en el defensor principal. El
segundo defensor deberá ejecutar el comportamiento de Cubrir Arco convirtiéndose así en el
defensor secundario. Cuando ninguno de los dos defensores es el responsable de ir por la pelota,
ambos defensores desarrollan el comportamiento de Cubrir Arco, siendo aquí más compleja la
decisión de cuál será el defensor principal y cual el secundario. En este caso se toman en cuenta
las siguientes condiciones:
Si uno de los defensores está más lejos del arco propio que la pelota, es el defensor
secundario.
Si ambos están más lejos que la pelota del arco, el más cercano a la pelota tomará el rol de
defensor principal ya que tiene más posibilidades de llegar a interceptarla.
Si ambos defensores están más cerca de su arco que la pelota, entonces se analiza cual
está sobre el lateral al cual se proyecta la pelota.
Si sólo uno está sobre este lateral, esto da el orden de los defensores.
En el caso que, por alguna circunstancia, ambos están sobre el mismo lateral es defensor
principal aquel que esté más cerca del punto de intercepción entre su trayectoria (en
dirección paralela al arco) y la trayectoria actual de la pelota.
Cuando el defensor tiene que acudir a la pelota como representante del equipo, se pueden dar
distintas situaciones. Las posibilidades contempladas en la implementación tienen en cuenta los
siguientes factores: cercanía de rivales a la pelota y posición relativa del defensor con respecto a
la pelota. El caso más simple es aquel en el que no hay rivales cerca y por lo tanto se cuenta con 35
tiempo suficiente para controlar de la mejor manera posible la pelota. Para hacer esto se utiliza el
comportamiento de patear la pelota al arco, el cual hace que el defensor lleve la pelota hacia el
arco rival, o al menos la deje mejor posicionada para este fin. Esta jugada es una DAD ideal.
Un caso más complejo y más habitual durante el juego, es cuando el defensor debe acudir a la
pelota y hay rivales cerca. Aquí no puede perder tiempo en conseguir una buena ubicación. En
este caso lo que se trata de hacer es alejar la pelota de la zona de peligro para el arco propio. Si el
defensor está más abajo que la pelota, es decir más cerca del arco propio en coordenada X, o la
pelota superó la línea de defensa propio en coordenada Y pero por fuera del ancho del arco
(cercano a las paredes laterales de la cancha), entonces su tarea es ir directamente hacia el punto
donde está la pelota intentando colisionarla y así alejarla del arco propio, ambos casos son
variantes de Defensa Activa de Despeje (DAD). [Castelo, 2002]
Cuando ninguna de las situaciones antes mencionadas se presenta, significa que hay una situación
de alto riesgo ya que si el defensor en cuestión es el mejor ubicado para ir a la pelota y no se
cumplieron las condiciones anteriores, o bien la pelota está muy cerca del arco o todos los
jugadores del equipo propio están muy mal ubicados. En este caso lo que se intenta hacer es ir a
un punto intermedio entre la pelota y el arco propio, siempre y cuando haya lugar para tomar esta
ubicación sin entrar en el área chica, lo cual constituye una Defensa Pasiva en Trayectoria
(DPT). Si esta estrategia tampoco se puede ejecutar, el defensor vuelve a su posición dejando ya
la tarea de defensa en manos del arquero evitando así entorpecer su tarea y que, eventualmente,
sea cobrado un penal por la presencia de más de un jugador en el área chica o que genere un
rebote que descoloque al arquero y termine en gol. Aquí el defensor principal se ve forzado por la
situación a ejecutar una Defensa Pasiva en Arco (DPA).
Cuando, una vez determinado el defensor principal y el defensor secundario según se detalló con
anterioridad, tanto el uno como el otro deben cumplir con el comportamiento Cubrir Arco, las
acciones ejecutadas son las siguientes:
36
Defensor Principal: si la pelota y él mismo están por delante del área grande propia, se
ejecuta el comportamiento DAE. Caso contrario, si el jugador está más cerca del arco que
la pelota, ejecuta DAD. Si no, se queda dónde está sin ejecutar acción alguna.
Defensor Secundario: ejecuta DPA, decidiendo el lugar donde se sitúa en base a donde
está el defensor principal. Si éste último se encuentra fuera del radio del área grande, el
defensor secundario se ubica frente al arco y en el centro del mismo. Caso contrario, se
ubica desplazado hacia el lado de la cancha contrario al que se encuentra el defensor
principal.
En cualquiera de los casos, cuando un defensor ya está en el lugar que le corresponde ocupar por
el estado de juego actual, trata de orientarse paralelo al arco, 90º o –90º, de manera que sea rápida
la ejecución de la acción DAE, la cual es muy similar al comportamiento que implementa el
arquero salvo que a lo ancho de toda la cancha. Otra diferencia en comportamiento con el arquero
es que, generalmente, la acción de Defensa Activa de Encuentro desemboca en una defensa activa
de despeje ya que, al acercarse la pelota, el defensor pasa a ser el mejor ubicado para controlar la
pelota.
Otros comportamientos que poseen los defensores y que no están directamente relacionados con
la tarea de defender son los siguientes:
Desbloquearse: cuando se detecta que el jugador está bloqueado, es decir que en varios
ciclos consecutivos se le ha dado velocidad a las ruedas y sin embargo no se obtuvo
desplazamiento, el jugador intenta girar sobre sí mismo para poder destrabarse. Esto lo
hace sólo si no tiene en su poder la pelota o sí la tiene pero se está fuera del área grande.
Se implementan estas restricciones para evitar perder el control de la pelota estando muy
cerca del arco propio.
Salir del Arco Propio: dado que desarrollan su tarea muy cerca del arco muchas veces,
ya sea por haber sido empujados o porque el algoritmo de navegación al evitar obstáculos
los llevó por allí, terminan entrando al arco propio. Cuando se detecta esta situación se
activa un comportamiento que los envía con dirección hacia el centro de la cancha. Dicho
37
comportamiento se desactiva cuando ya han salido del arco restableciéndose el
desempeño normal del defensor.
Pateo Lateral: cuando se está en contacto con la pelota bajo las condiciones de pateo
lateral, se ejecuta el mismo. [Castelo, 2002]
1.1.1.4. SimuRoSot.
Torneo Simulado de Soccer de Robots. La categoría de simulación Middle League SimuRoSot
es una competencia de fútbol entre agentes de software. En el simulador los agentes son
una representación de los robots de la competición Middle League MiRoSoT, de igual forma
las condiciones del ambiente (Campo), la bola y demás condiciones son modelos de
esta categoría. El propósito del Robot Soccer Simulator es simular los trabajos
implementados físicamente con los Robots Yujin Robots de todas las formas posibles en un
ambiente virtual. Se pretende el desarrollo de estrategias que puedan ser usadas en
los robots físicos y el fortalecimiento de una nueva competencia virtual . El software
es desarrollado en la Universidad Griffith, Australia por los estudiantes del departamento de
Tecnología de la información, bajo Macromedia Director.
El Software consta de dos equipos (Amarillo y Azul) cada uno de cinco jugadores. El equipo
es controlado por medio de una estrategia que puede ser desarrollada en lenguaje Lingo
de Macromedia Director, la cual es llamada en un archivo TXT; o se puede desarrollar en
Lenguaje C/C++ como una Librería DLL.
SimuRoSot, consiste de un servidor que tiene un ambiente de fútbol y dos programas clientes
con las estrategias del juego. El partido es jugado en una computadora entre dos equipos.
Sin un robot físico, el partido se decide por medio de complejas estrategias desarrolladas
usando técnicas avanzadas de Inteligencia Artificial.
38
1.1.1.5. Software de desarrollo
Herramienta que permite crear programas y software, a continuación se presentan programas los
cuales pueden ser utilizados para el desarrollo del código de las estrategias, ya que son los
leguajes en los cuales se puede desarrollar el código, y puede ser introducidos en el simulador.
C♯ o C# es un lenguaje de programación orientado a objetos desarrollado y estandarizado por
Microsoft como parte de su plataforma .NET.
2. Su sintaxis básica deriva de C/C++ y utiliza el modelo de objetos de la plataforma.NET el
cual es similar al de Java aunque incluye mejoras derivadas de otros lenguajes (entre ellos
Delphi).
II.3 Conceptos y teorías relacionados con el marco tecnológico
II.3.1 FIRA
Federación Internacional del Robot-Soccer Asociation (FIRA) fue fundada en junio de 1997 con
un objetivo básico deteniendo el espíritu de la ciencia y la tecnología de la robótica a los jóvenes,
a través del juego de fútbol de robots.
II.3.1.1 FIRA Cup
Competencia de futbol que realiza la FIRA anualmente, son organizadas en varias categorías,
incluyendo el Torneo de Fútbol de Microrobot (MiRoSoT), el Torneo de Fútbol de Robot
Simulado (SimuRoSot) y el Torneo de Fútbol de Robot Humanoide (HuRoSoT). Estos juegos
son jugados bajo los ojos vigilantes de un árbitro humano y los participantes que son los gerentes
de los jugadores (actores) de robot y entrenadores.
El fútbol de robot puede ser retratado como una competencia de tecnología de robot avanzada
dentro de un espacio limitado. FIRA espera ayudar a entender y apreciar, con intereses, los
conceptos científicos y acontecimientos tecnológicos complicados. FIRA cree que algunos de
39
estos intereses abastecerán de combustible habilidades científicas y de la ingeniería que en última
instancia se desarrollan en resultados de investigación para servir la humanidad de muchas
maneras.
II.3.1.2 Simulador.
El simulador provee el entorno que soporta las competencias entre equipos de fútbol virtuales,
considerando un ambiente con múltiples agentes, cambiante y con respuestas en tiempo real.
Estas herramientas también proveen una interfaz gráfica que permite visualizar el desarrollo de
los partidos en una pantalla.
El fútbol en ambiente simulado presenta una ventaja importante con respecto al fútbol
implementado mediante robots físicos: permite focalizar la investigación en técnicas de
cooperación y aprendizaje, abstrayéndose de los inconvenientes propios que pueden presentar los
robots y el entorno físico. En este ambiente no es necesario considerar ni resolver problemas en el
hardware de los robots, en los mecanismos de comunicación o en el reconocimiento de objetos.
Los simuladores desarrollados y disponibles en la actualidad son los utilizados en las
competencias de las categorías de simulación de RoboCup y de FIRA. Aunque ambos
simuladores brindan el entorno necesario para que se desarrolle el juego, a la hora de definir las
características de los jugadores, cada uno ha aplicado distintos conceptos. En el caso de FIRA,
los jugadores simulan a los robots de la categoría MiRoSoT, conservando la disposición de las
ruedas, el tamaño y el peso. Esto hace que tanto los movimientos como las estrategias de juego
deban planificarse teniendo en cuenta estas características especiales. En cambio para 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. [Castelo, 2002]
II.3.1.3 Lenguaje C++.
C++ es heredero directo del lenguaje C que, a su vez, se deriva del lenguaje B. C se mantiene
como un subconjunto de C++.
C++ comenzó su proyecto de estandarización ante el comité ANSI y su primera referencia es The
Annotated C++ Reference Manual [Joyanes, 2006].
40
C++ es una extensión de C con características más potentes. Estrictamente hablando, es un
superconjunto de C. Al igual que sucede con java y C# que son superconjuntos de C++. El ANSI
C estándar no solo define el lenguaje C sino que también define una biblioteca de C estándar que
las implementaciones de ANSI c deben soportar. C++ también utiliza esa biblioteca. Además de
su propia biblioteca estándar de clases.
C++ continúa evolucionando y se habían realizado ya trabajos para producir la próxima versión
del estándar.
II.3.1.4 DLL.
DLL - Dynamic Link Library ("Biblioteca de vínculos dinámicos") es un archivo que contiene
funciones que se pueden llamar desde aplicaciones u otras DLL [Descripción, s.f.]. Los
desarrolladores utilizan las DLL para poder reciclar el código y aislar las diferentes tareas. Las
DLL no pueden ejecutarse directamente, es necesario llamarlas desde un código externo.
Las bibliotecas DLL serían una evolución de las bibliotecas estáticas. Usarlos en el desarrollo de
programas trae ciertas ventajas como:
- Reducción del tamaño de los archivos ejecutables: pues parte del código puede estar en las
bibliotecas y no en el ejecutable.
- Compartir bibliotecas entre aplicaciones.
- Facilitar la gestión y aprovechar la memoria del sistema.
- Brindar flexibilidad frente a cambios: la solución de errores o la implementación de mejoras
puede solucionarse sólo con distribuir una nueva versión de la biblioteca. Esta corrección, en
general, será válida para todas las aplicaciones que la utilicen [DLL, 1998].
II.4 Conceptos y teorías relacionados con el método a utilizar
II.4.1 POO
La programación Orientada a objetos (POO) es una forma especial de programar, más cercana a
como expresaríamos las cosas en la vida real que otros tipos de programación.
41
Con la POO tenemos que aprender a pensar las cosas de una manera distinta, para escribir
nuestros programas en términos de objetos, propiedades, métodos y otras cosas que veremos
rápidamente para aclarar conceptos y dar una pequeña base que permita soltarnos un poco con
este tipo de programación.
La tecnología orientada a objetos se define como una metodología de diseño de software que
modela las características de objetos reales o abstractos por medio del uso de clases y objetos
[Ángeles, s.f.]. Hoy en día, la orientación a objetos es fundamental en el desarrollo de software,
sin embargo, esta tecnología no es nueva, sus orígenes se remontan a la década de los años
sesenta. De hecho Simula, uno de los lenguajes de programación orientados a objetos más
antiguos, fue desarrollado en 1967.
El objeto, es el concepto principal sobre el cual se fundamenta la tecnología orientada a objetos.
Un objeto puede ser visto como una entidad que posee atributos y efectúa acciones.
En el mundo real podemos encontrar cientos de ejemplos que cumplen con ésta definición,
algunos de ellos son: una bicicleta, un automóvil, una persona, una computadora, etcétera.
Bases sobre las cuales se fundamenta la POO
Los elementos más importantes que deben tener los objetos de software, para cumplir con el
paradigma de orientación a objetos son:
Abstracción: La abstracción es el proceso en el cual separamos las propiedades más
importantes de un objeto, de las que no lo son. Es decir, por medio de la abstracción definimos
las características esenciales de un objeto del mundo real, los atributos y comportamientos que lo
definen como tal, para después modelarlo en un objeto de software.
En el proceso de abstracción no debemos preocuparnos por la implementación de cada método o
atributo, solamente debemos definirlo de forma general. Por ejemplo, supongamos que deseamos
escribir un programa para representar el sistema solar, por medio de la abstracción, podemos ver
a éste sistema como un conjunto de objetos, algunos de estos objetos son los planetas, que tienen
un estado, dado por sus características físicas, digamos, tamaño, masa, entre otras, estos objetos
42
tendrán también comportamientos: la translación y la rotación, pueden mencionarse como los
más evidentes.
Modularidad: Dentro de la programación orientada a objetos, la modularidad juega un papel
muy importante. Una vez que hemos representado una situación del mundo real en un programa,
tenemos regularmente como resultado, un conjunto de objetos de software que constituyen la
aplicación. La modularidad, nos permite poder modificar las características de la clase que
definen a un objeto, de forma independiente de las demás clases en la aplicación.
Encapsulamiento: También referido como ocultamiento de la información, el encapsulamiento
es la propiedad de la orientación a objetos que nos permite asegurar que la información de un
objeto le es desconocida a los demás objetos en la aplicación. Es muy frecuente referirse a los
objetos de software como cajas negras, esto se debe principalmente a que no necesitamos, dentro
de la programación orientada a objetos, saber cómo esta instrumentado un objeto para que este
interactúe con los demás objetos. Generalmente una clase se define en dos partes, una interfaz por
medio de la cual los objetos que son instanciados de la misma interactúan con los demás objetos
en la aplicación, y la implementación de los miembros de dicha clase (métodos y atributos).
Jerarquía: Una vez que hemos definido una clase, por ejemplo la clase bicicleta, con sus
atributos y métodos, tal vez necesitemos definir una nueva clase específica para las bicicletas de
carreras.
Es obvio que ésta nueva clases compartirá elementos en común con la clase bicicleta, es decir, la
clase bicicleta de carreras será un subconjunto de la clase bicicleta.
Polimorfismo: Dentro de la programación orientada a objetos puede modelarse esta situación
del mundo real, en objetos de software, gracias al polimorfismo. El polimorfismo es la propiedad
por la cual una entidad puede tomar diferentes formas. Generalmente está entidad es una clase, y
la forma en que se consigue que tome diferentes formas es por medio de nombrar a los métodos
de dicha clase con un mismo nombre pero con diferentes implementaciones.
43
II.4.2 UML
El lenguaje unificado de modelado o UML (Unifield Modeling Language) es el sucesor de la
oleada de métodos de análisis y diseño orientados a objetos (OOA&D) que surgió a finales de la
década de 1980 y principios del siguiente. El UML unifica, sobre todo, los métodos de Booch,
Rumbaugh (OMT) y Javcobson, pero su alcance llegara a ser mucho más amplio. El UML es un
lenguaje de modelado, y no un método. La mayor parte de los métodos consisten, al menos en
principio, en un lenguaje y en un proceso para modelar. Las técnicas en el UML fueron
diseñadas en cierta medida para ayudar a los usuarios a hacer un buen desarrollo de OO, pero
cada técnica tiene distintas ventajas a las de las demás.
El lenguaje de modelado es la notación (principalmente gráfica) de que se valen los métodos para
expresar los diseños. El proceso es la orientación que nos dan sobre los pasos a seguir para hacer
el diseño [Fowler&Scott, 1999].
UML cuenta con diferentes tipos de diagramas, como se observa en la ilustración 2.2, los cuales
muestran diferentes aspectos de las entidades representadas [Schumuller, 2001].
Ilustración 2.2.- Jerarquía de diagramas UML 2.0, mostrados como diagrama de clases.
Fuente: [Schumuller, 2001].
44
UML define 13 diagramas, que se dividen en tres categorías: estructura (clases, objetos,
componentes, estructura de composición, paquetes, despliegue), que representan los elementos de
una especificación sin tomar en consideración el tiempo, comportamiento (casos de uso, máquina
de estados y actividades), que describen las características dinámicas de un objeto, tales como sus
operaciones y métodos, e interacción , que se derivan de los diagramas de comportamiento y que
hacen énfasis en la manera como los objetos interactúan entre sí [Zapata, 2008]. A continuación,
se detallan algunos de los diagramas:
– Diagrama de casos de uso. Ayuda al cliente, al interesado y a los desarrolladores a utilizar el
sistema. Cada tipo de usuario se representa mediante un actor, quien utiliza el sistema al
interactuar con los casos de uso, los cuales representan los requisitos funcionales del sistema. En
la Ilustración 2.3 se muestra un ejemplo del diagrama de casos de uso.
Ilustración 2.3.- Ejemplo de un Diagrama de Caso de Uso y su Simbología.
Fuente: [Zapata, 2008]
– Diagrama de estado: Los diagramas de estado muestran el conjunto de estados por los cuales
pasa un objeto durante su vida en una aplicación en respuesta a eventos (por ejemplo, mensajes
recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones. También ilustran qué
eventos pueden cambiar el estado de los objetos de la clase. Normalmente contienen: estados y
transiciones [Otero, s.f.]. Los estados y las transiciones incluyen, a su vez, eventos, acciones y
actividades. En la ilustración 2.4 se muestra un ejemplo:
45
Ilustración 2.4.- Ejemplo de un Diagrama de estado y su simbología.Fuente: [Otero, s.f.]
– Diagrama de secuencias: Hace énfasis en la ordenación temporal de los mensajes. Muestra
cómo el control se transmite de un objeto a otro a medida que se envían mensajes. Un mensaje
enviado por un objeto dispara la toma del control en el objeto receptor y la realización de las
operaciones de su clase. En la Ilustración 2.5 se presenta ejemplo del diagrama de secuencias, en
el cual también se definen sus principales símbolos.
Ilustración 2.5.- Ejemplo de un diagrama de secuencias y su simbología.
Fuente: [Zapata, 2008]
II.4.3 Desarrollo Adaptable de Software
El método ágil Desarrollo Adaptable de Software (ASD) es un modelo de implementación de
patrones ágiles para desarrollo de software. Al igual que otras metodologías ágiles, su
46
funcionamiento es cíclico y reconoce que en cada iteración se producirán cambios e incluso
errores. [Huarachi, 2009]
El ASD es una metodología de desarrollo que hace énfasis en aplicar las ideas que se originaron
en el mundo de los sistemas complejos, adaptación continua del proceso al trabajo.
Sus principales características del ASD son:
Iterativo.
Orientado a los componentes de software (la funcionalidad que el producto va a
tener, características, etc.) más que a las tareas en las que se va a alcanzar dicho
objetivo.
Tolerante a los cambios.
Guiado por los riesgos
La revisión de los componentes sirve para aprender de los errores y volver a
iniciar el ciclo de desarrollo
Ciclo de vida
ASD utiliza un "cambio orientado hacia el ciclo de vida", que tiene tres componentes que son:
especular colaborar y aprender.
Especular
Una primera fase de iniciación para establecer los principales objetivos y metas del proyecto en
su conjunto y comprender las limitaciones (zonas de riesgo) con las que operará el proyecto.
En ASD se realizan estimaciones de tiempo sabiendo que pueden sufrir desviaciones. Sin
embargo, estas son necesarias para la correcta atención de los trabajadores que se mueven dentro
de plazos de forma que puedan priorizar sus tareas.
Se decide el número de iteraciones para consumir el proyecto, prestando atención a las
características que pueden ser utilizadas por el cliente al final de la iteración. Son por tanto
necesarios, marcar objetivos prioritarios dentro de las mismas iteraciones.
47
Estos pasos se puede volver a examinar varias veces antes de que el equipo y los clientes están
satisfechos con el resultado.
Colaborar
Es la fase donde se centra la mayor parte del desarrollo manteniendo una componente cíclica. Un
trabajo importante es la coordinación que asegure que lo aprendido por un equipo se transmite al
resto y no tenga que volver a ser aprendido por los otros equipos.
Aprender
La última etapa termina con una serie de ciclos de colaboración, su trabajo consiste en capturar lo
que se ha aprendido, tanto positivo como negativo. Es un elemento crítico para la eficacia de los
equipos.
Jim Highsmith identifica cuatro tipos de aprendizaje en esta etapa:
Calidad del producto desde un punto de vista del cliente. Es la única medida legítima de éxito,
pero además, dentro de las metodologías ágiles, los clientes tienen un valor importante.
Calidad del producto desde un punto de vista de los desarrolladores. Se trata de la evaluación de
la calidad de los productos desde un punto de vista técnico. Ejemplos de esto incluyen la
adhesión a las normas y objetivos conforme a la arquitectura.
La gestión del rendimiento. Este es un proceso de evaluación para ver lo que se ha aprendido
mediante el empleo de los procesos utilizados por el equipo.
Situación del proyecto. Como paso previo a la planificación de la siguiente iteración del
proyecto, es el punto de partida para la construcción de la siguiente serie de características.
48
Ilustración 2.6.- Ciclo de Vida del Modelo ASD.
Fuente: [Huarachi, 2009]
Ventajas
La tercera fase del ciclo de vida, revisión de los componentes, sirve para aprender de los
errores y volver a iniciar el ciclo de desarrollo.
Apunta hacia el Rapid Application Development (RAD), el cual enfatiza velocidad de
desarrollo para crear un producto de alta calidad, bajo mantenimiento involucrando al
usuario lo más posible.
Utiliza información disponible acerca de cambios para mejorar el comportamiento del
software.
Promulga colaboración, la interacción de personas.
Anticipa cambios y trata automáticamente con ellos dentro de un programa en ejecución,
sin la necesidad de un programador.
Desventajas
Aunque el ciclo entre el aprendizaje y la especulación es bueno permitiéndonos entregar
productos con alta calidad, la prolongación de dicho ciclo por errores o cambios que no
son detectados en reuniones anteriores afecta tanto a la calidad del producto como a su
costo total.
Dado a que es una metodología ágil implica no realizar procesos que son requeridos en las
metodologías tradicionales o por lo menos no realizarlos en procesos diferentes, lo cual
implica que empresas grandes las cuales necesitan llevar un mayor control a procesos y
personas, tener tareas asignadas a un estado o proceso especifico, y en las cuales dicho
incremento de procesos no afectan en gran medida al costo final del producto, para dichas
49
empresas el elegir una metodología tradicional resulta mucho más rentable tanto por el
gran volumen de personal, de productos, y de costos que se manejan y para los cuales se
tendrá un mayor control.
II.5 Marco Tecnológico
II.5.1 Simulador Robot Soccer
El simulador a utilizar es “3D Robot Soccer Versión 1.5” el cual está desarrollado en
Macromedia Director 8.5 ShockWave Studio, por el equipo de desarrollo del cual forman parte
Roger Smith, Annabel Rodwell, Mathew Clarke y Shaw Truesdell dirigido por el Doctor Jun Jo,
de la Universidad Griffith, Australia, para el juego de futbol robótico simulado en la categoría
Middle la cual consiste en equipos de cinco jugadores.
Uno de los propósitos del “3D Robot Soccer Simulator” es simular el funcionamiento en todo
entorno posible a los robots físicos Yujin. Así como también el desarrollo de estrategias que
puedan ser aplicadas en competencias de robots físicos de tipo Yujin en futuras competencias de
la FIRA. [Help, s.f.].
Los requerimientos físicos para el funcionamiento adecuado de simulador son:
Procesador Pentium III 600 MHz
256 megabytes de memoria RAM
Tarjeta de video de 64 megabytes
Lector de CD-ROM24x
Pantalla con resolución de 800 x 600
16 bit en Tarjeta de sonido
10 megabytes libres de espacio en disco
Los requerimientos de software para el requerimiento del simulador son:
Microsoft Windows 98
50
Direct X 8.0
Los requerimientos de software para poder continuar desarrollando el simulador son:
Director 8.5
Experiencia de programación en Lingo
El libro “Director 8.5 Shockwave Studio: training from the source”
II.5.2 Interfaz de Usuario
Al iniciar la ejecución se presenta una pantalla de bienvenida, que se muestra en la ilustración
2.7.
Ilustración 2.7.- Pantalla de bienvenida del Simulador Robot Soccer de la FIRA
El campo se muestra, junto con la barra de menús e información del juego. El usuario puede
seleccionar la posición inicial de los robots en el campo para el inicio del juego, las instrucciones
de esta serán cubiertas en Inicio del juego.
El usuario puede hacer clic en cualquier cosa en la barra de menú para abrir una lista de opciones.
Este menú también se muestra cuando hay una parada del juego y el árbitro debe llamar a faltas y
tomar decisiones.
Menús
A continuación se detalla cada uno de los menús que se encuentran en el interfaz del usuario:
51
Strategies - El usuario debe hacer clic aquí para acceder al menú para la carga de las
estrategias para cada equipo de robots, como se observa en la Ilustración 2.8.
Las estrategias son escritas en código Lingo y se colocan en un archivo de texto o en un archivo
DLL de C + +.
1. Los cuadros de texto se usan para escribir el nombre de los archivos de texto o
archivos DLL que contienen las estrategias de los equipos de azul o amarillo. La
estrategia debe ser colocado en la carpeta que se crea al instalar el programa. Estas
carpetas se crean en la dirección C: \Strategy, en la cual se crean dos carpetas con el
nombre de los equipos, para cargar la estrategia simplemente escriba el nombre del
archivo en el cuadro sin la extensión.
2. Haga clic en la palabra LINGO (para archivos de texto) para alternar y C + + (para
DLL's).
3. Send - Una vez que haya ingresado en los nombres de los archivos de texto o archivo
DLL que contiene las estrategias clic en Send para cargar los archivos con las
estrategias de juego.
4. Open Viewer - Abre un visor que permite ver los valores de variables cuando el juego
se ejecuta.
Ilustración 2.8.- Menú Strategies del Robot Soccer de la FIRA
Falta y botones de posición - Estos son para el árbitro deberán utilizarse para comunicar
una falta sobre un equipo específico, y declarar que estarán en posesión de la pelota. Una 52
vez hecho clic en el mensaje correspondiente se mostrará en la ventana de mensaje en una
nueva línea. (Las variables globales y Gamestate WhosBall son establecidos por estos
botones - ver Guía de Estrategia / Elementos sugerida)
Start –inicia el juego.
Tiempo - El tiempo de juego actual.
Puntuación - La puntuación actual.
Time/Score - Este botón muestra el minuto la de la anotación o anotaciones. Si por
motivos de tiempo o puntuación es necesario realizar cualquier cambio, el árbitro puede
usar esta interfaz para realizar ajustes, mostrada en la ilustración 2.9.
a) Time: El árbitro puede ajustar el tiempo con cualquiera de estos botones, se pueden sumar
o restar por intervalos de un segundo o por intervalos de un minuto.
b) Time: Este muestra el tiempo de juego actual después de la modificación.
c) Score: Aquí es donde el puntaje se altera. El árbitro sólo debe marcar la puntuación que
desea cambiar y escriba un nuevo número.
Ilustración 2.9.- Menú Time/Score del simulador Robot Soccer de la FIRA
Una vez hecho los cambios el árbitro debe marcar la continuación del juego.
53
New Game - reinicia todo y se prepara para un nuevo juego.
Help - El usuario puede hacer clic en el botón Help para acceder a una versión electrónica
de este manual de usuario, mientras que en el juego.
Menú del juego
Este menú es mostrado cuando el juego está en ejecución, el menú del juego se muestra en la
ilustración 2.10.
Ilustración 2.10.- Menú en el juego Robot Soccer de la FIRA
a) REPLAY: Te lleva a la interfaz de reproducción
b) PAUSE: Pausa el juego
c) STOP: Sirve para detener el juego y te lleva a los menús para tomar decisiones.
Menús de la Interfaz de repetición
La barra de visión: Localizada a la derecha de la pantalla de repetición es donde el
usuario puede seleccionar el punto de vista deseado mientras ve la repetición, que es mostrado en
la ilustración 2.11 y la ilustración 2.12.
54
Ilustración 2.11.- La barra de visión Robot Soccer de la FIRA
a) Este selecciona el punto de vista de la bola y la sigue mientras se mueve por todo el
campo.
b) Este elige el punto de vista arriba y abajo, que es muy similar a la vista por defecto
del juego.
c) Este elige el punto de vista mirando hacia abajo en la meta de equipo azul.
d) Este elige el punto de vista mirando hacia abajo en la meta de equipo amarillo.
e) Esto elige la vista mirando a través del campo de la meta azul.
f) Esto elige la vista mirando a través del campo de la meta amarilla.
g) (G Y H) Muestra la vista desde los diferentes lados del campo, uno con el lado del
equipo azul por el lado izquierdo y el amarillo por el derecho y el otro con el equipo
azul en el lado derecho y el equipo amarillo con el lado izquierdo.
Ilustración 2.12.- La barra de visión 2 del simulador Robot Soccer de la FIRA
55
a) Hace retroceder la repetición del partido al principio del juego.
b) Rebobina los últimos 300 frames y las repeticiones.
c) Reproducciones las repeticiones a velocidad normal.
d) Reproducciones a la repetición en cámara lenta.
e) Le permite reproducir el menú en el modo de parada frame.
f) A continuación, puede utilizar los botones de adelante y atrás en el menú para avanzar o
retroceder fotograma a fotograma. Alternativamente, puede utilizar la izquierda y la
derecha teclas de flecha para el mismo efecto, pero si se mantiene presionada la tecla se
obtiene una reproducción súper cámara lenta.
h) Sale de la reproducción.
i) Sale de la reproducción sin acepar anotación (si la reproducción no ha sido causada por un
gol, entonces simplemente sale de la repetición).
II.5.3 Lenguaje de Programación
El lenguaje de programación en el cual se programarán las estrategias será C++, debido que
cuenta con la posibilidad de crear y manipular objetos. La introducción de las estrategias en el
simulador se hará a través de un archivo DLL (Librería de Enlace Dinámico) el cual contendrá
las estrategias elaboradas y programadas.
56
Capítulo III. Aplicación de la metodología y
desarrollo
III.1 Desarrollo de la metodología
La metodología que se decidió utilizar es ASD, para la elaboración del proyecto, es una
metodología ágil la cual permite por medio de sus tres etapas (especular, colaborar y aprender) y
un ciclo de vida repetitivo, realizar constates cambios en cuanto a requerimientos y cambios en la
programación cuando sea necesario con la finalidad de que la entrega final sea de la mejor
calidad.
III.1.1 Especular
Antes de poder proponer alguna estrategia fue necesario observar a los defensas en un juego, y
así identificar sus patrones de juego, debilidades y fortalezas, para poder tomar una decisión más
adecuada.
Para la identificación de los patrones de juego, fue necesario observar las estrategias cargadas en
el simulador como ejemplo a lo largo de un partido, para que de esta manera se pudieran
identificar debilidades en la estrategia de defensa, identificar los puntos fuertes de la estrategia de
defensa, y poder tener noción de las posibles manera en que puede ser defendido el arco por
medio de estrategias de defensa.
Los patrones que la defensa presento fueron las siguientes:
La defensa en ningún momento del partido intentan despejar del área defendida.
1. No existía colaboración, lo que resulta múltiples colisiones entre los defensas y los
delanteros.
2. La defensa se realiza en base a áreas
57
3. No existe intercambio de área
4. No se retoma posición al ser movido
5. Los delanteros son los encargados de despejar el balón
De acuerdo a los patrones, debilidades y fortalezas que se lograron observar en la prueba de
control, se noto que tuvieron deficiencias es por eso que se propone dos tipos de estrategias:
Estrategia de defensa basada en roles: Consistirá en asignar a los defensas roles diferentes para
defender de manera más ordenada, y así tener mayor control en el área de defensa.
Estrategia de defensa basada en áreas: en dividir el campo en áreas para que cada robot sea el
encargado de defender un área, de esta manera aminorar el número de colisiones entre los
jugadores.
Planeación
Estrategia de defensa basada en roles
La estrategia de defensa basada en roles consiste en asignaran prioridades a los defensores, para
que de esta manera el robot secundario sirva de apoyo o soporte al momento tratar de despejar el
balón cuando defensor principal no pueda cumplir del todo con su tarea que consiste en impedir
que el balón se acerque al arco propio.
Como se muestra en la Ilustración 3.1, el robot secundario se ubicara detrás del robot principal,
siguiendo siempre la posición del balón pero sin entrar en acción hasta que este se encuentre en
dirección hacia el arco despejando o impidiendo que el balón sobre pase su posición.
58
Principal
Secundario
Ilustración 3.1.- Formación estrategia basada en roles.
Defensa principal: Será el encargado de interceptar el balón para evitar que se acerque al arco
propio y despejar permitiéndole a los delanteros tener posibilidades para anotar un gol.
Defensa secundario: Será el jugador cuya función será brindar un apoyo cuando el defensor
principal no sea capaz de evitar que el balón se acerque al arco, interceptando el balón y
despejándolo, siempre y cuando el balón no sea interceptado por el defensor principal.
A continuación en la ilustración 3.2, se muestra el diagrama UML de caso de uso de la estrategia
de defensa basada en roles.
Ilustración 3.2.- Caso de uso de la estrategia basada en roles.
CASO DE USO: Estrategia basada en roles
DESCRIPCIÓN: se asignan las posiciones a los defensas, ya sea principal o secundario, es necesario que se revise constantemente la trayectoria del balón con la finalidad de que el defensa principal, intercepte el balón en un área más alejada del campo, dado caso que el defensa principal no pueda cumplir esta tarea el defensa auxiliar será el encargado de esto.ACTOR: Defensa.
59
PRECONDICIONES: 1. El defensa toma su posición2. Esta constantemente revisando la ubicación de la pelota3. Verifica la trayectoria del balón
Flujo normal Flujo alternativo1. El defensa verifica que la trayectoria del balón
entra en su área2. Procede a interceptar el balón3. Despeja el balón
1. Al no poder despejar adecuadamente procede a notificar al defensa auxiliar para que este sea el encargado de despejar
POS CONDICIONES: al despejar el balón del área, el defensa procede a tomar nuevamente su posición Tabla 3.1.- Descripción del caso de uso de la estrategia basada en roles.
A continuación se muestra en la ilustración 3.3 el diagrama de estado de la estrategia de defensa basada en roles.
Ilustración 3.3.- Diagrama de Estado de la estrategia Basada en Roles.
Estrategia de defensa basada en áreas
La estrategia de defensa basada en áreas consiste en dividir el campo de juego de tal manera que
los defensores sean los encargados de resguardar cada un área asignada, estas deben de ser
respetadas con la finalidad evitar interferir con la tarea del otro defensor.
De esta manera cada uno debe de evitar que la pelota se acerque al arco propio y despejar hacia el
arco contrario o simplemente alejarlo del área.
En la ilustración No. 3.4, se muestra la distribución en la que el campo estará dividido.
60
Ilustración 3.4.- Formación estrategia basada en áreas.
A continuación en la ilustración 3.5 se muestra el diagrama UML de caso de uso de la estrategia
de defensa basada en áreas.
Ilustración 3.5.- Caso de uso de la estrategia basada en áreas.
CASO DE USO: Estrategia basada en áreas
DESCRIPCIÓN: A cada defensa debe de consultar su posición para respetar los límites del área, si el balón se encuentra cerca de esta, o con dirección al área, el defensa procede a despejarla de la misma, retornando a la posición de la cual partió.ACTOR: Defensa.
61
PRECONDICIONES: 1. El defensa toma su posición2. Esta constantemente revisando la ubicación de la pelota
Flujo normal Flujo alternativo1. El defensa verifica que la trayectoria de la
pelota entre en su área2. Procede a interceptar el balón3. Despeja el balón
Al no poder despejar adecuadamente procede a pasar el balón al área del otro defensa, quien despeja
POS CONDICIONES: al despejar el balón del área, el defensa procede a tomar nuevamente su posición Tabla 3.2.- Descripción del caso de uso de la estrategia basada en áreas.
A continuación se muestra en la ilustración 3.6 el diagrama de estado de la estrategia de defensa basada en áreas.
Ilustración 3.6.- Diagrama de Estado de la estrategia basada en áreas.
Definición de pruebas de calidad
Las pruebas de calidad de las estrategias radicó en analizar las estrategias programadas, y detectar
las fallas y errores, de lo cual se tomó registro, para darle una solución a dicho problema, de esta
manera realizar mejoras constantes.
Los puntos a tomarse en cuenta para analizar las estrategias son:
62
1. Número de autogoles: En este punto se analizará las veces que los defensas anotan
autogoles, lo que no favorece al partido y por ello se pretende en la pruebas de calidad
que el número de estos se vea reducido.
2. Número de goles producidos: Cabe la posibilidad de que los defensas puedan anotar goles
sin ayuda de los delanteros, este dato puede indicar que los defensas pueden influir en el
marcador del partido.
3. Número de goles recibidos: El número de goles que se el equipo contrario anote, nos
permitirá saber cuan eficaz es la estrategia al momento de defender.
4. Número de veces que el balón estuvo en el área: este dato permitirá saber las veces que el
balón entró al área defendida y la reacción de los defensas.
5. Número de de veces que se despejo de manera correcta: en conjunto de las veces que se
tuvo el balón en el área defendida nos permitirá saber la efectividad de los defensas al
momento de despejar el balón.
6. Número de obstrucciones de los jugadores: podremos verificar que tan bien desempeñan
su labor los defensas al momento de despejar el balón del área defendida y regresar a sus
lugares.
7. El tiempo en posesión del balón: este dato nos permitirá saber cuánto tiempo, por medio
de las estrategias de defensa, se tiene la posesión del balón durante el partido.
Cada una de las estrategias fueron probadas a lo largo de cinco partidos, que comprende de
dos tiempos de cinco minutos, tomando nota de cada uno de los aspectos mencionados.
Además se realizó el mismo tipo de prueba a la estrategia cargada por defecto en el
simulador, los resultados de estas pruebas se muestran en el anexo A.
63
III.1.2 Colaborar
En esta etapa es donde las estrategias son programadas mediante el entorno de trabajo Microsoft
Visual C++ 6.0, el entorno de trabajo se muestra en la ilustración 3.7.
Ilustración 3.7.- Entorno de trabajo de Microsoft Visual C++ 6.0
Al tener las estrategias programadas en un archivo DLL se procede a introducirlas en el
simulador Robot Soccer v1.5 (ver Anexo B), que es el simulador oficial del torneo (ver Anexo
C).
Alguna de las estrategias tienen funciones que son utilizadas en las otras estrategias, al tener
realizadas ya estas partes de código fue útil para la programación de otras estrategias como por
ejemplo:
La función “run” es la que proporciona a los robots la velocidad máxima al momento de dirigirse
a un punto determinado, ya sea interceptar el balón o cuando es necesario que tome una posición
lo más rápido posible, el código se muestra en la ilustración 3.8.
64
Ilustración 3.8.-Fragmento de código de la función run
Función “cerc” es la que determina cual es la distancia de un punto al robot, ya sea el balón o de
un robot oponente, que es tomada para poner a los defensas en estado de espera o determinar
cuándo entrara en acción, esta función se muestra en la ilustración 3.9.
Ilustración 3.9.-Fragmento de código de la función cerc
Función “go” la encargada de indicar a qué punto del campo se debe dirigir el robot así como la
velocidad en apoyo con la función rotateTo para darle la dirección, esta es mostrada en la
ilustración 3.10.
Ilustración 3.10.-Fragmento de código de la función go
65
Función “kick” la encargada evitar los bloqueos cuando el paso se ve obstruido por parte de
algún robot oponente, gira sobre su propio eje siempre y cuando el balón se encuentre cerca, en
caso de que el balón se encuentre atrás del robot se posiciona detrás del balón y de esta manera
evitar un autogol, el fragmento de código se muestra en la ilustración 3.11.
Ilustración 3.11.-Fragmento de código de la función kick
De esta manera reutilizando código se logró reducir el tiempo de programación de las estrategias.
III.1.3 Aprender
Esta etapa ha sido aplicada al terminar la etapa de colaborar, radicó en analizar las estrategias
programadas, y detectar las fallas y errores, de lo cual se tomó registro, para darle una solución a
dicho problema, de esta manera realizar mejoras constantes.
Lo que se tomó en cuenta para poder analizar las estrategias será:
Número de autogoles
Número de goles producidos
Número de goles recibidos
Número de veces que el balón estuvo en el área
Número de de veces que se despejo de manera correcta
66
Número de obstrucciones de los jugadores
El tiempo en posesión del balón
El porcentaje de efectividad de la estrategia será medido utilizando una regla de tres simple, y
comparando los resultados serán comparado con los resultados de la estrategia de control y
posteriormente comparando entre las mismas para identificar cual tuvo un mejor desempeño.
Es decir, el porcentaje de la efectividad de despeje será igual a:
El porcentaje de la efectividad de la estrategia será medido mediante:
67
Efectividad de despeje =No. de veces que el balón entro en el área
Numero de despejes correctosX 100
Efectividad de estrategia =No. de veces que el balón entro en el área
(Numero de goles recibidos + Autogoles) X100
Capítulo IV.Pruebas y Resultados
En este capítulo se presentan los resultados de las pruebas de calidad realizadas a las estrategia
de defensa basada en roles y a la estrategia de defensa basadas en áreas.
IV.1 Elaboración e implementación de la estrategia de defensa basada en
roles.
Se realizaron tres pruebas de calidad de la estrategia, en la primera la rotación y el avance se
realizaron de manera adecuada; pero, se observó que no se tenía control de acercamiento por lo
tanto no era preciso al momento de dirigirse a un punto o al tratar de interceptar el balón, por este
motivo no se lograba despejar de manera adecuada; además, el número de autogoles producidos
era mayor al número de goles recibidos, y en múltiples ocasiones los robots se obstruían
mutuamente al tratar de retomar su posición.
En la segunda prueba se implementó el control de acercamiento y el método de despeje
obteniendo buenos resultados, el número de goles se vio reducido, así como el de autogoles; pero,
se detectó que cuando el robot secundario despeja de manera adecuada y se ubica adelante del
robot que desempeña la tarea de robot primario, se ve interferido por el robot secundario
impidiendo que ejecute su rol de manera adecuada.
En la tercer prueba de calidad se implementó el cambio de roles de manera que si el defensa
secundario lograba despejar el balón y se posicionaba en una posición más cerca que el defensa
principal el robot secundario se veía obligado a ceder su rol y tomar el rol de defensa principal, y
así se lograban realizar despejes correctos y los bloqueos entre ellos disminuyó de una manera
muy notoria.
En la ilustración 4.1 se muestra la ubicación que toma cada jugador de acuerdo con el rol que
desempeñan, defensa principal y secundario.
68
PrimarioSecundario
Ilustración 4.1.-Ubicación de los jugadores en el campo
IV.1.1 Pruebas de la estrategia de defensa basada en roles
A continuación se presentan los resultados obtenidos en las diversas pruebas realizadas. El total
de las pruebas se muestran en el anexo D. En la tabla 4.1 se pueden observar los promedios
obtenidos de estas pruebas y enseguida las gráficas con los resultados logrados.
Prueba de calidad(1)
Prueba de calidad(2)
Prueba de calidad(3)
Autogoles 12.8 4 0.8Goles Producidos 0.2 0.8 1.2Goles Recibidos 11 4.2 1.6Balón en Área 61.4 42.8 41.8Despejes Correctos 15 25.6 35.2Obstrucciones 32.4 20.4 4Tiempo con el Balón
02:08:24 02:10:48 04:17:36
Tabla 4.1.- Resultados obtenidos en las pruebas de calidad.
En la ilustración 4.2 se muestra una gráfica donde el número de autogoles en la primera prueba
de calidad tuvo un promedio de 12.8 autogoles, el cual se ve mejorado desde la segunda prueba al
momento de implementar el método de acercamiento y despeje, logrando que en la tercera estos
resultados se vieran reducidos hasta realizar solamente un autogol.
Ilustración 4.2.- Promedio de autogoles realizados en las pruebas.
69
En la ilustración 4.3 se muestra una gráfica del promedio de goles producidos durante las pruebas
de calidad, donde podemos observar que a partir de la segunda prueba de calidad cuando se
aplicó el método de despeje se pudieron producir goles sin participación de los delanteros.
Goles Producidos0
0.2
0.4
0.6
0.8
1
1.2
1.4
0.2
0.8
1.2
Prueba de calidad(1)Prueba de calidad(2)Prueba de calidad(3)
Ilustración 4.3.-Promedio de goles a producidos durante las pruebas.
En la ilustración 4.4 se muestra una gráfica con el promedio de goles recibidos por el equipo
contrario, que se vieron reducidos hasta un promedio de 1.6 goles recibidos en la tercer prueba
gracias a que se implementó el cambio de roles y se mejoró el método de despeje logrando que al
equipo contrario le fuese más difícil de anotar.
70
Autogoles0
2
4
6
8
10
12
1412.8
4
0.8
Prueba de calidad(1)
Prueba de calidad(2)
Prueba de calidad(3)
Goles Recibidos0
2
4
6
8
10
12 11
4.2
1.6
Prueba de calidad(1)Prueba de calidad(2)Prueba de calidad(3)
Ilustración 4.4.-Promedio de goles recibidos
En la ilustración 4.5 se muestra una gráfica donde se puede observar el promedio de las veces que
el balón entró al área defendida, cabe mencionar que la manera de despejar intervino en el
número de veces que el balón ingreso al área, por este motivo se nota que de la primera a la
tercera prueba se redujo las veces que el balón estuvo en el área defendida.
Balón en Área0
10
20
30
40
50
60
7061.4
42.8 41.8
Prueba de calidad(1)Prueba de calidad(2)Prueba de calidad(3)
Ilustración 4.5.-Promedio del número de veces que el balón entró al área.
En la ilustración 4.6 se muestra una gráfica donde se puede observar que la implementación del
método de despeje en la segunda prueba mejoró muy notoriamente los resultados, se observa que
71
en la tercer prueba se obtuvo un promedio de 41.8 balones en el área, en promedio de 35.2 de
ellos fueron despejados correctamente.
Despejes Correctos0
5
10
15
20
25
30
35
40
15
25.6
35.2
Prueba de calidad(1)Prueba de calidad(2)Prueba de calidad(3)
Ilustración 4.6.-Promedio de despejes realizados de manera correcta.
En la ilustración 4.7 se puede observar una gráfica con el promedio de obstrucciones entre sí
producidas por los jugadores, donde podemos notar, que debido a que se implementó el
intercambio de roles dependiendo de la distancia en que se encontraban los defensas con respecto
al balón y su ubicación con respecto al otro defensa, éstos se vieron reducidos en un promedio de
32.4 obstrucciones en la primera prueba hasta lograr un promedio de 4 obstrucciones en la tercer
prueba.
Obstrucciones0
5
10
15
20
25
30
35 32.4
20.4
4
Prueba de calidad(1)Prueba de calidad(2)Prueba de calidad(3)
Ilustración 4.7.-Promedio del número de obstrucciones por los jugadores.
72
En la ilustración 4.8 se muestra una gráfica donde se puede observar que en las pruebas de
calidad se tuvo el control del balón en un promedio de 4:17 minutos por partido, debido en parte
a que los defensas interceptaban en una manera más adecuada el balón, así como en la manera de
recuperarlo cuando los delanteros del equipo contrario tenían el control de éste en el área
defendida.
Tiempo con el Balón00:00:00
00:28:48
00:57:36
01:26:24
01:55:12
02:24:00
02:52:48
03:21:36
03:50:24
04:19:12
04:48:00
02:08:24
02:10:48
04:17:36
Prueba de calidad(1)Prueba de calidad(2)Prueba de calidad(3)
Ilustración 4.8.-Tiempo en promedio que se tuvo controlado el balón.
Como se muestra en cada una de las gráficas esta estrategia dio resultados favorables durante el
desarrollo de las pruebas realizadas, los despejes correctos, los goles producidos y el tiempo que
se tuvo controlado el balón mejoraron; el número de obstrucciones, los autogoles y los goles
recibidos disminuyeron notablemente; mientras que el tiempo en que el balón estuvo en el área
defendida también se vio reducido.
IV.1.2 Análisis de resultados de la estrategia de defensa basada en roles
Como se aprecia en cada una de las gráficas que se presentan en el apartado de pruebas de la
estrategia de defensa basada en roles, la estrategia dio resultados favorables durante el desarrollo
de las pruebas realizadas, los despejes correctos, el tiempo que se tuvo en balón en el área
73
defendida y el tiempo que se tuvo controlado el balón mejoraron; el número de obstrucciones, los
autogoles y los goles recibidos disminuyeron notablemente; mientras los goles producidos no
tuvo cambio alguno.
Estrategia de Control
EstrategiaBasada en roles
Goles Recibidos17 1.6
Autogoles6.8 0.8
Goles Producidos0.4 1.2
Obstrucciones31.6 4
Balón en Área52.4 41.8
Despejes Correctos14.4 35.2
Tiempo con el balón1:50:00 04:17:36
Tiempo sin el balón 08:10:00 05:42:24Tabla 4.2.- Tabla Comparativa de la estrategia basada en roles
Como se muestra en la tabla 4.2, la estrategia basada de defensa basada en roles demostró tener
un 82.62% de efectividad al despejar el balón de manera adecuada del área defendida lo que nos
indica una mejoría ya que la estrategia de control solo mostro el 24.32% de efectividad, y la
posibilidad de que se recibiera un gol por parte del equipo contrario fue de únicamente de 4.45%,
además en la estrategia de control los defensas tuvieron el control del balón el 18% del tiempo y
con la estrategia basada en roles los defensas tuvieron el control del balón el 43.8% del tiempo.
IV.2 Elaboración e implementación de la estrategia de defensa basada en
áreas.
De igual manera para esta estrategia se realizaron tres pruebas de calidad, en la primera la
rotación y el avance se realizaron de manera adecuada; pero, se observó la imprecisión que había
entre los jugadores al momento de interceptar el balón o al tratar de tomar la posición , lo que
provocaba que los despejes no sucedieran de manera adecuada; además, en múltiples ocasiones
los robots se obstruían mutuamente en su tarea cuando el robot al momento de interceptar el
74
balón e intentaba despejar invadían el área que tenía a su cargo el otro defensor impidiendo así
que el defensa desempeñara su tarea de manera adecuada.
En la segunda prueba se implementó el control de acercamiento y el método de despeje, el
número de goles se vio reducido, así como el de autogoles, pero al estar en completa inmovilidad
en el centro del área no podía anticipar y despejar de manera correcta.
En la tercer prueba se pudo tener el control en el cambio de posición el cual se producía cuando
el robot ocupado de proteger el área se encontraba más lejos, y así se lograban realizar despejes
correctos y los bloqueos entre ellos disminuyó de una manera muy notoria. En la ilustración 4.9
se muestra el área que corresponde a cada jugador.
Ilustración 4.9.-Ubicación de los jugadores en el área de juego.
IV.2.1 Pruebas de la estrategia de defensa basada en áreas
A continuación se presentan los resultados obtenidos en las diversas pruebas realizadas. El total
de las pruebas se muestran en el anexo E. En la tabla 4.3 se pueden observar los promedios
obtenidos de estas pruebas y enseguida las gráficas con los resultados logrados.
75
Prueba de calidad(1)
Prueba de calidad(2)
Prueba de calidad(3)
Autogoles 6.2 2.6 1.6Goles Producidos 0.4 0.6 0.4Goles Recibidos 13.4 9 4.4Balón en Área 55.2 67 64Despejes Correctos 17.4 42 50.8Obstrucciones 32 16.2 4.6Tiempo con el Balón 02:08:00 02:45:12 04:06:24
Tabla 4.3.- Resultados obtenidos durante las pruebas de calidad.
En la ilustración 4.10 se muestra una gráfica donde podemos observar el promedio de los
autogoles producidos por los jugadores, se puede hacer notar que cuando se implementó el
método de despeje en la segunda prueba de calidad y el intercambio de área a partir de la tercera
prueba de calidad, los jugadores estaban más activos y despejaban de manera correcta logrando
con esto reducir el número de autogoles.
Autogoles0
1
2
3
4
5
6
76.2
2.6
1.6
Prueba de calidad(1)Prueba de calidad(2)Prueba de calidad(3)
Ilustración 4.10.- Promedio de autogoles producidos por los jugadores.
En la ilustración 4.11 se puede notar en la gráfica el promedio de goles producidos tras
implementar en los defensas mejoras en el cubrimiento del área, rotación de posiciones y el
método de despeje, se produjeron anotaciones por los defensas sin participación de los delanteros.
76
Goles Producidos0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.4
0.600000000000001
0.4Prueba de calidad(1)Prueba de calidad(2)Prueba de calidad(3)
Ilustración 4.11.- Promedio de goles a favor durante las pruebas.
En la ilustración No 4.12 se muestra una con el promedio de los goles recibidos durante las
pruebas, se nota que se vieron reducidos a solo una tercera parte de los recibidos en la prueba de
calidad uno, cuando no se contaba con el método de despeje, y el intercambio de áreas.
Goles Recibidos0
2
4
6
8
10
12
14
16
13.4
9
4.4
Prueba de calidad(1)Prueba de calidad(2)Prueba de calidad(3)
Ilustración 4.12.- Promedio de goles producidos por el equipo contrario
En la ilustración 4.13 se muestra una gráfica con el promedio de las veces que el balón estuvo en
el área defendida, el método de despeje y cambio de áreas resultó ser de utilidad al
77
implementarlos puesto que gracias a ellos los jugadores no se obstruían el paso y podían controlar
el balón con mejor precisión.
Balón en Área0
10
20
30
40
50
60
70
80
55.2
67 64
Prueba de calidad(1)Prueba de calidad(2)Prueba de calidad(3)
Ilustración 4.13.- Promedio del número de balones que se tuvieron en el área defendida.
En la ilustración 4.14 se muestra una gráfica donde se observa el promedio de los despejes
logrados de manera correcta durante las pruebas, al implementar el método de despeje se obtuvo
un mejor desempeño de los jugadores en su área, por que en vez de pasar el problema al otro
defensor se lograba despejar el balón del área defendida.
Despejes Correctos0
10
20
30
40
50
60
17.4
42
50.8
Prueba de calidad(1)Prueba de calidad(2)Prueba de calidad(3)
Ilustración 4.14.- Número de veces que se despejó de manera correcta
78
En la ilustración 4.15 se observa una grafica con el promedio de obstrucciones que producían los
defensas por partido, pudimos notar que desde la primera prueba de calidad los jugadores tenían
problemas entre ello impidiendo que defendieran y despejaran de manera correcta, al
implementar el cambio de áreas se pudo tener un mejor desempeño ya que los jugadores no
interrumpían el camino de el otro defensor.
Obstrucciones0
5
10
15
20
25
30
35 32
16.2
4.6
Prueba de calidad(1)Prueba de calidad(2)Prueba de calidad(3)
Ilustración 4.15.- Promedio del número de obstrucciones realizadas por los jugadores.
En la ilustración 4.16 se muestra una gráfica del promedio del tiempo en que se tuvo controlado
el balón en el área defendida por los defensas, se puede notar que con respecto a la primera
prueba se tuvo el control casi el doble de tiempo en la tercera prueba de calidad, gracias a que los
métodos implementados dieron resultados favorables por los jugadores logrando defender,
recuperar el balón y despejar de una manera más adecuada.
79
Tiempo con el Balón00:00:00
00:28:48
00:57:36
01:26:24
01:55:12
02:24:00
02:52:48
03:21:36
03:50:24
04:19:12
02:08:00
02:45:12
04:06:24
Prueba de calidad(1)Prueba de calidad(2)Prueba de calidad(3)
Ilustración 4.16.- Tiempo en promedio que se tuvo controlado en balón.
IV.2.2 Análisis de resultados de la estrategia de defensa basada en áreas
Como se aprecia en cada una de las gráficas, la estrategia defensa basada en áreas dio resultados
favorables durante el desarrollo de las pruebas realizadas, los despejes correctos, el tiempo que se
tuvo en balón en el área defendida y el tiempo que se tuvo controlado el balón mejoraron; el
número de obstrucciones, los autogoles y los goles recibidos disminuyeron; mientras los goles
producidos por los defensas se vieron disminuidos.
Estrategia de Control
EstrategiaBasada en áreas
Goles Recibidos 17 4.4
Autogoles 6.8 1.6
Goles Producidos 0.4 0.4
Obstrucciones 31.6 4.6
Balón en Área 52.4 64
Despejes Correctos 14.4 50.8
Tiempo con el balón 1:50:00 04:06:24
Tiempo sin el balón 08:10:00 05:53:36Tabla 4.4.- Tabla Comparativa de la estrategia basada en áreas
80
En la tabla 4.4 la estrategia basada en áreas tuvo un 77.43% de efectividad al despejar el balón
de manera adecuada del área defendida, lo que indica la mejora ya que la estrategia de control
solo mostro el 24.32% de efectividad, y la posibilidad de que se recibiera un gol por parte del
equipo contrario fue solamente de 8.66%, además en la estrategia de control los defensas
tuvieron el control del balón el 18% del tiempo y con la estrategia basada en áreas los defensas
tuvieron el control del balón el 41% del tiempo.
81
Capítulo V. Conclusiones y trabajos futuros
V.1 Conclusiones
Las soluciones planteadas en esta investigación permiten afirmar que fue posible desarrollar
estrategias de defensa aplicables para el juego de futbol robótico, con un porcentaje de
efectividad aceptable.
Durante el desarrollo del presente trabajo, se identificaron los siguientes patrones de juego:
La defensa en ningún momento del partido intentan despejar del área defendida.
No existía colaboración, lo que resulta múltiples colisiones entre los defensas y los
delanteros.
La defensa se realiza en base a áreas
No existe intercambio de área
No se retoma posición al ser movido
Los delanteros son los encargados de despejar el balón
Dichos patrones permitieron identificar las debilidades con las que contaba la estrategia de
control, lo que facilito el trabajo al proponer las estrategias desarrolladas en esta investigación.
Además con esta investigación, se aportan importantes recursos lo que permite afirmar, que se
han creado bases en el tema de fútbol robótico que quedarán a disposición para aquellos que
decidan continuar con el desarrollo de esta investigación y se pueda formar en la DAIS un equipo
que explote favorablemente las estrategias de defensa en un juego de fútbol robótico.
De acuerdo con los resultados obtenidos y mostrados en las tablas 4.3 y 4.4 podemos afirmar que
la estrategia de defensa basada en roles logró el mejor desempeño, a lo largo de las pruebas:
82
El promedio de los goles que recibió la estrategia de defesa basada en áreas fue de 4.4 por
partido, cuando la estrategia de defensa basada el roles presento un promedio únicamente
de 1.6 goles por partido, lo que indica que se recibe un 63.63% menos de goles.
El promedio de autogoles realizados por los defensas con la estrategia de defensa basada
en áreas fue de 1.6 autogoles mientras que la estrategia de defensa basada en roles solo
logró producir 0.8 autogoles por partido, lo que indica que la estrategia de defensa basada
en roles produce 50% menos de autogoles con respecto a la estrategia basada en áreas.
En promedio los defensas ejecutando la estrategia de defensa basada en áreas produjeron
en promedio 0.4 goles por partido y ejecutando la estrategia de defensa basada en roles
produjeron en promedio 1.2 goles por partido lo que significa un aumento del 200% en
cuanto a goles producidos por los defensas
Aunque el número de despejes realizados de manera correcta fue mayor por parte de la
estrategia de defesa basada en áreas, su efectividad para despejar la pelota fue de tan solo
77.43% mientras que la estrategia de defesa basada en roles obtuvo un 82.62% de
efectividad al realizar la misma tarea.
Además la metodología ASD en conjunto con UML, fueron un gran acierto, gracias a los cuales
la documentación y elaboración del proyecto, resultaron más fácil de elaborar, es muy acertado
señalar que esta metodología puede ser aplicada en proyectos de elaboración de software, debido
a su simplicidad.
83
V.2 Trabajos futuros
Se recomienda que esta investigación sirva para incentivar a jóvenes a participar en este tipo de
competencia y de esta manera desarrollar sus habilidades en programación.
Como trabajos futuros se proponen:
Integrar todos los casos de estudio del juego de futbol robótico
Crear estrategias colaborativas con los otros miembros del equipo
Desarrollar nuevas estrategias
Integrar métodos predictivos del balón
Planificación de rutas
Desplazamiento mediante trayectorias ortogonales
Adaptar la estrategia para 11 jugadores del SimuRoSot
Generar aprendizaje relacionados al tema
84
Bibliografía
Referencias Impresas
[Cáceres, 1996] Álvarez Cáceres R. (1996) El método científico en las ciencias de la salud. Las bases de la investigación biomédica. Madrid: Díaz de Santos. Pág. 56
[Fowler&Scott, 1999] Fowler Martin, Scott Kendall (1999) “UML Gota a Gota”, Addison Wesley Longman de México, S.A. de C.V. Pág. 1
[Joyanes, 2006] Joyanes Aguilar Luis, 2006, “Programación en C++: Algoritmos, estructuras de
datos y objetos”, 2ª. Edición, McGraw-Hill, pág. 39, 40.
[Ollero, 2001] Ollero Baturone Aníbal, 2001,”Robótica: Manipuladores y robots móviles”,
coedición MARCOMBO S.A. pág. 1
[Sampieri, 2008] Hernández Sampieri Roberto, Fernández Collado Carlos, Baptista Lucio Pilar
(2008), Metodología de la Investigación, 4ta.Edición, Editorial McGraw-Hill,
Pág. 587
[Sommerville, 2005] Sommerville Ian “Ingeniería del Software”, Séptima Edición, Pearson
Educación, S. A. Madrid 2005. Pág. 76.
[Schumuller, 2001] Joseph Schumuller, Prentice Hall, “Aprendiendo UML en 24 horas”, 2001.
[Veloso, 1999] M. Veloso, M. Bowling, S. Achim, K. Han, P. Stone. “TheCMUnited-98 ChampionSmall-Robot Team”. M. Asada, H. Kitano (Eds.), RoboCup-98: Robot Soccer World Cup II, páginas 77-92.Springer, 1999.
85
Referencias electrónicas
[Alcalá, 2005] Tesis “Diseño y construcción de un robot manipulador de dos grados de libertad”,
M.C. Janeth Aurelia Alcalá Rodríguez, M.I. Norberto López Luiz, recuperado del
día30 de abril del 2010 en la web con dirección electrónica:
http://www.ucol.mx/acerca/coordinaciones/cgic/cuii/pdf/McJanet.pdf
[Ángeles, s.f.] Artículo “Introducción a la Programación Orientada a Objetos” recuperado el día
25 de mayo del 2010 en la web por “José Arturo de los Ángeles” con dirección
electrónica:
http://luis.izqui.org/resources/ProgOrientadaObjetos.pdf
[Castelo, 2002] Tesis “Futbol de Robots: Revisión del Estado del Arte y Desarrollo del Equipo
UBASot de Simulación” Castelo C., H. Farsi y F. Scarpettini. Facultad de Ciencias
Exactas y Naturales, Universidad de Buenos Aires, recuperado el 29 de abril del
2010 en la dirección electrónica:
http://www-2.dc.uba.ar/cafr2003/arc/TesisFutboldeRobots.zip
[Descripción, s.f.] Artículo “”Descripción DLL” recuperado el día 17 de mayo del 2010 en la
web con dirección electrónica:
http://www.svetlian.com/dll/articulos_descripcion_dll.htm
[DLL, 1998] Artículo “DLL”; recuperado el día 17 de mayo del 2010 en la web con dirección
electrónica:
http://www.alegsa.com.ar/Dic/dll.php
[FIRA, 2004] Federation of International Robot-Soccer Association (FIRA) Homepage
recuperado el 28 de abril del 2010 en la dirección electrónica:
86
http://www.fira.net
[González, 2002] Artículo “Introducción a la robótica” recuperado el día 9 de marzo del 2010 en
la web por “Víctor R. González” con dirección electrónica:
http:// cfievalladolid.net/tecno/ctrl_rob/robótica/intro.htm
[Help, s.f.]Artículo “3D Robot Soccer Help” recuperado el día 15 de abril del 2010 en la web con
dirección de electrónica:
http://www.fira.net/~fira/?module....
[Huarachi, 2009] “Trabajo de Investigación y Exposición”, Maritza Huarachi, Universidad Unión
Bolivariana. Recuperado el 11 de Junio del 2010 en la dirección.
http://www.adolfo.mex.tl/images/18149/informe.doc
[Noción, s.f.] Artículo “Noción de la Robótica” recuperado el día 17 de mayo del 2010 en la web
con dirección electrónica:
http://www.ilustrados.com/
[Otero, s.f.] Parte de un artículo “Diagramas de estado” Mari Carmen Otero Vida, recuperado el
día 10 de diciembre del 2011 en la web con dirección electrónica:
http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r33019.PDF
[RoboCup, s.f.] Página principal de RoboCup –Robot World Cup, recuperado el 20 de mayo del
2010 en la web con dirección electrónica:
www.robocup.org
[Robótica, 1999] Artículo “La Robótica como Herramienta del Hombre”, recuperado el 9 de
marzo del 2010 en la web del “Instituto Tecnológico de Durango” con dirección
electrónica:
87
http://montelpz.htmlplanet.com/robot/antecede.html
[Tri, 2009] Artículo “el Tri del mundial “RoboCup””, recuperado el 10 de marzo del 2010 en la
web con dirección electrónica:
http://www.cnnexpansion.com/tecnologia/2009/09/09/siguiente-el-tri-delmundial-
robocup
[Zapata, 2008] Zapata Jaramillo, Carlos Mario y Duarte Herrera, Mary Inés autores de la Revista
“Consistency game: a didactic strategy for software engineering”, publicado en el
2008, recuperado el día 16 de mayo el 2010 en un artículo publicado en la web con la
dirección electrónica:
http://www.scielo.org.ve/pdf/rtfiuz/v31n1/art02.pdf
88
Glosario
A
Agente: Entidad que toma decisiones dependiendo del estado de su entorno.
E
Electrónica: Es el campo de la ingeniería y de la física aplicada relativo al diseño y aplicación de
dispositivos, por lo general circuitos electrónicos, cuyo funcionamiento depende del flujo de
electrones para la generación, transmisión, recepción, almacenamiento de información, entre
otros.
F
FIRA: Siglas en ingles de la federación internacional de robot soccer y asociados (Federation
International robot soccer Asociation).
I
Informática: es la ciencia aplicada que abarca el estudio y aplicación del tratamiento automático
de la información, utilizando dispositivos electrónicos y sistemas computacionales.
Inteligencia Artificial: Disciplina que se encarga de construir procesos que al ser ejecutados
sobre una arquitectura física produce acciones o resultados que maximizan una medida de
rendimiento determinada, basándose en la secuencia de entradas percibidas y el conocimiento
almacenado en tal arquitectura.
J
JLeague: Fue la primera competencia de futbol robótico, la cual se celebró en Japón, esta tomo
el nombre de la liga japonesa de futbol profesional.
L
LeJOS: Java for LEGO MindStorms.
M
Multiagentes: Es un sistema en el cual pueden ser aplicados más de un agente para resolver
cierta tarea o problema.
89
P
Perse: De por sí, por sí mismo.
R
Robot: Es un sistema electromecánico que, por su apariencia y sus movimientos, ofrece la
sensación de tener un propósito propio.
Robótica: Es la ciencia y la tecnología de los robots. Se ocupa del diseño, manufactura y
aplicaciones de los robots.
V
Visión Computacional: El objetivo de la visión computacional (VC) es tomar decisiones útiles
acerca de los objetos físicos reales del mundo (de escenas) en base a imágenes adquiridas
digitalmente.
90
Anexos
Anexo A Resultados de prueba de control
Número de pruebas p1 p2 p3 p4 p5
Promedio
Goles Recibidos 15 11 10 18 14 17Autogoles 8 5 8 6 7 6.8Goles Producidos 1 0 0 0 1 0.4Obstrucciones 30 35 29 30 34 31.6Balón en Área 40 51 55 60 56 52.4Despejes Correctos 12 20 16 14 10 14.4Tiempo con el Balón 01:06
01:56
02:10
01:50
01:37 1:50
Tabla 1.- Resultados obtenidos en la prueba de control
91
Anexo B Creación del archivo DLL.
Paso 1.- Al tener elaborado las estrategias se procede a su compilación
Ilustración 1.- Entorno de trabajo visual 6 C++
Paso 2.- El archivo con extensión dll se encuentra con la carpeta debug ubicada en el directorio
de nuestro código.
Ilustración 2.- Archivos de código fuente
92
Anexo C Introducir las Estrategias en el Simulador.
Paso 1.- Se compila el código para crear el archivo con las estrategias cargadas con extensión dll.
Ilustración 3.- Entorno de trabajo visual 6 C++
Paso 2.- Se copia el archivo “strategy.dll” ubicado en la carpeta debug de nuestro proyecto.
Ilustración 4.- Archivos DLL
93
Paso 3.- Se pega el archivo“strategy.dll” en la dirección C:\Strategy\blue o C:\Strategy\yellow
según el color del nuestro equipo.
Ilustración 5.- Directorio para cargar las estrategias
Paso 4.- Se ejecuta el simulador.
Ilustración 6.- Entorno del simulador
94
Paso 5.- En la opción Strategies se elige el lenguaje de programación en el cual se programaron
las estrategias en nuestro caso se elije C++.
Ilustración 7.- Panel de estrategias
Paso 6.- Se introduce el Nombre del archivo donde se encuentran programadas las estrategias
.
Ilustración 8.- Panel de estrategias
95
Paso 7.- Se Cargan las Estrategias en el simulador.
Ilustración 9.- Panel de estrategias
Paso 8.- Se inicia el partido con la opción Start
96
Anexo D Pruebas de calidad de la estrategia basada en roles.
Número de pruebas p1 p2 p3 p4 p5 PromedioGoles Recibidos 10 11 12 9 13 11Autogoles 13 12 11 13 15 12.8Goles Producidos 0 1 0 0 0 0.2Obstrucciones 35 37 33 28 29 32.4Balón en Área 63 65 59 67 53 61.4Despejes Correctos 19 15 13 12 16 15
Tiempo con el Balón
02:1
3 02:18
01:5
7 02:03
02:1
1 02:08:24
Tabla 2.- Resultados obtenidos en la primera prueba de calidad.
Número de pruebas p1 p2 p3 p4 p5 PromedioGoles Recibidos 4 5 3 5 4 4.2Autogoles 5 4 3 5 3 4Goles Producidos 2 1 0 1 0 0.8Obstrucciones 23 22 17 19 21 20.4Balón en Área 43 41 39 44 47 42.8Despejes Correctos 25 28 27 23 25 25.6
Tiempo con el Balón02:0
8 01:5902:1
7 02:1902:1
1 02:10:48Tabla 3.- Resultados obtenidos en la segunda prueba de calidad.
Número de pruebas p1 p2 p3 p4 p5 Promedio
Goles Recibidos 1 3 1 2 1 1.6
Autogoles 0 0 1 2 1 0.8
Goles Producidos 1 1 2 1 1 1.2
Obstrucciones 6 3 5 3 3 4
Balón en Área 38 45 43 37 46 41.8
Despejes Correctos 33 37 35 32 39 35.2
Tiempo con el Balón 04:21 04:17 04:09 04:13 04:28 04:17:36
Tabla 4.- Resultados obtenidos en la tercera prueba de calidad.
97
Anexo E Pruebas de calidad de la estrategia basada en áreas.
Número de pruebas p1 p2 p3 p4 p5 PromedioGoles Recibidos 13 11 14 17 12 13.4Autogoles 6 5 7 6 7 6.2Goles Producidos 0 1 0 0 1 0.4Obstrucciones 37 33 31 27 32 32Balón en Área 46 51 57 63 59 55.2Despejes Correctos 17 23 19 15 13 17.4
Tiempo con el Balón 02:0301:5
6 02:11 01:5302:3
7 02:08:00Tabla 5.- Resultados obtenidos en la primera prueba de calidad.
Número de pruebas p1 p2 p3 p4 p5 PromedioGoles Recibidos 7 9 11 8 10 9Autogoles 3 4 2 1 3 2.6Goles Producidos 1 0 0 1 1 0.6Obstrucciones 17 15 19 14 16 16.2Balón en Área 71 57 69 65 73 67Despejes Correctos 43 38 41 49 39 42
Tiempo con el Balón 02:4302:5
7 02:38 02:4102:4
7 02:45:12Tabla 6.- Resultados obtenidos en la segunda prueba de calidad.
Número de pruebas p1 p2 p3 p4 p5 Promedio
Goles Recibidos 4 3 5 4 6 4.4
Autogoles 2 1 1 3 1 1.6
Goles Producidos 1 0 0 1 0 0.4
Obstrucciones 6 5 4 5 3 4.6
Balón en Área 65 67 64 63 61 64
Despejes Correctos 48 51 47 53 55 50.8
Tiempo con el Balón 03:58 04:03 04:13 04:11 04:07 04:06:24
Tabla 7.- Resultados obtenidos en la tercera prueba de calidad.
98
