CAFR 2005 - F:I:C:C:T:E:
Transcripción
CAFR 2005 - F:I:C:C:T:E:
WCAFR 2005 II Workshop en Inteligencia Artificial aplicada a Robótica Móvil Índice I. II WorkShop de Inteligencia Artificial Aplicada a la Robótica Móvil I.a Artículos seleccionados 1- LogBall: un equipo de fútbol implementado como un sistema heterogéneo de múltiples agentes lógicos. Mauro J. Gómez, José H. Moyano, Nicolás D. Rotstein, Telma Delladio, Alejandro J.García. Grupo de Robótica Cognitiva, Laboratorio de Investigación y Desarrollo en Inteligencia Artificial (LIDIA). Departamento de Ciencias e Ingeniería de la Computación, Universidad Nacional del Sur Bahía Blanca. 2- F.R.U.T.O: Fútbol de Robot Uruguayo para Torneos Copello, Ernesto Castromán, Alvaro Tejera, Gonzalo Calero, Nelson. Facultad de Ingeniería, Universidad de la República Montevideo, Uruguay. 3- Human-Droid Prototype: Primeros pasos en robótica bípeda Workshop del CAFR2005 Lezama, Damián Sklar, Alexander Tejera, Gonzalo. Facultad de Ingeniería, Universidad de la República Montevideo, Uruguay. 4- Un aporte al diseño de Redes Neuronales Artificiales: Javier Antonio Martinez. Facultad de Informática Ciencias de la Comunicación y Técnicas Especiales, UNIVERSIDAD DE MORÓN. Morón, Buenos Aires. 5- El equipo Morasot: Potenza, Aníbal. CIENTIC, Universidad de Morón. Morón, Buenos Aires. 6- Equipo de Fútbol de Robots UTNfrba: Maximiliano L. Muzzio, Leandro M. Di Matteo, Andrea C. Mangone. Grupo de Inteligencia Artificial, Facultad Regional Buenos Aires, Universidad Tecnológica Nacional. Ciudad Autónoma de Buenos Aires. 7- Proxies para la comunicación con el 3D Robot Soccer Simulator: Alvaro Castroman, Ernesto Copello, Gonzalo Tejera Instituto de Computación, Facultad de Ingeniería, Universidad de la República, Montevideo, Uruguay. 8- Navegación de robots un caso práctico: Marcos Lambolay, Ezequiel Lazaga. Facultad de Informática de Morón, Universidad de Morón. Morón, Buenos Aires. 9- Experimentación de una conducta basada en Subsumición sobre QuiBot V1.0: Oscar Enrique Goñi. Facultad de Ciencias Exactas, Universidad Nacional del Centro de la Provincia de Buenos Aires Tandil, Buenos Aires. 10- QuiBot V1.0 Diseño de un Robot Experimental Autónomo: Oscar Enrique Goñi. Facultad de Ciencias Exactas, Universidad Nacional del Centro de la Provincia de Buenos Aires Tandil, Buenos Aires. I.b Otros artículos 1- Investigación en Sistemas Multi-agente y Robótica Cognitiva aplicada a la Robótica Móvil: en el dominio de Fútbol de Robots. Alejandro J. García, Telma Delladio, Mariano Tucat, Nicolás D. Rotstein, Diego R. García. 2- Grupo de Robótica Cognitiva, Laboratorio de Investigación y Desarrollo en Inteligencia Artificial (lidia): Departamento de Ciencias e Ingeniería de la Computación, Universidad Nacional del Sur. Bahía Blanca. 3- Robot Físico Autónomo Colaborativo MSL: Ing. Balich, Néstor Adrián. Centro de Altos Estudios en Tecnología Informática, Universidad Abierta Interamericana. Ciudad autónoma de Buenos Aires. 4- Reconocimiento de imágenes, aplicado a agentes robóticas: Norberto Carlos Mazza. Facultad de Informática, Cs. de la Comunicación y Técnicas Especiales, Universidad de Morón. Morón, Buenos Aires. 5- El equipo SimpSot (Robótica 11x11): Norberto Mazza, Leandro Rodríguez. Facultad de Informática, Universidad de Morón. Morón, Buenos Aires. 6- LogViewer: Javier Silveira – Gonzalo Zabala. Centro de Altos Estudios en Tecnología Informática, Facultad de Tecnología Informática. Universidad Abierta Interamericana. Ciudad autónoma de Buenos Aires. II. Descripción Técnica de equipos II.a Nivel de enseñanza Universitaria y Particulares 1- El Equipo Futbol Robots GallitoSoT: Corlevich, María Lorena – Escobar, Daniel Pascal – Guerrero, Alejandro – Montenegro, Victor. Facultad de Informática. Universidad de Morón. Morón, Buenos Aires. 2- Spiritual Machine Team: Freedman, Hernán G. – Mon, Gonzalo. Ciudad autónoma de Buenos Aires. 3- EvoluSOT JSI: Claro, Martín - D´Alessandro, Gabriel – Gazolli, Andrés - Lorusso, Emiliano – Pereira, Gustavo. Robótica Facultad de Informática, Universidad de Morón. Morón, Buenos Aires. 4- Presentación del equipo Caeti – UAI: Silveira, Javier – Aguirre, Facundo - Lic. Zabala, Gonzalo. Centro de Altos Estudios en Tecnología Informática, Facultad de Tecnología Informática, Universidad Abierta Interamericana. 5- Chinchulín 2005: Facultad de Ingeniería, Universidad de Buenos Aires. Cruz Fernández, Juan Pablo Saraceno, Gabriel Lerendegui, Ariel Kogan. Ciudad autónoma de Buenos Aires. 6- SimpleSot: Agustín Rafael Martínez – Germán Viscuso Pablo Andres Diaz Mazzaro – Gabriel Diaz Mazzaro – Nicolás Navarro – Martín Roslán. Colegio Schönthal. Ciudad autónoma de Buenos Aires. II.b. Nivel de enseñanza Secundaria 1- Equipo PollitoFive: Ladiani, Damián – Sisi, Lucas – Escobar, Adrián – Morel, Emmanuel – Cardozo, Roberto - Barrios, Pamela - Sierra, Mayra - Prof. García Mónica. Colaboradores: Perei ra Gustavo, Brizzi Teresa. E.EM Nº 5 Navier y Bailen Ing. Pablo Nogués. 2- Presentación del Equipo Mukeniosot: Avila, Diego; Hughes, Tomás; Lorusso, Emiliano; Puchetta, Fernando; Shrewsbury, Lucas; Shrewsbury, Tomás; Solotum, Gerardo; Solotum, Roberto. Instituto José Manuel Estrada, Don Torcuato, Buenos Aires. 3- Equipo SimulARLT III: El Fútbol de Robots como Entorno Educativo Coordinador: Profesor Julio Fernández. Alumnos Integrantes: Alderete Mauro, Báez Matías, Fuentes Carolina, García Maria de los Ángeles, Milanese Elías. Colaboradores: Barreto Ariel, Campos Nicolás, Colman Mauricio, Corbacio David, Coronel Ezequiel, Fortunato Lucas, Fretes Héctor, Lobo Ezequiel, Rodas Sebastián, Urih Ariel, Zarate Facundo, Corso Sabrina, Fuentealba Yésica, González Mercedes, Maldonado Pamela, Molina Patricia, Montenegro Vanesa, Valdez Maria Sol, Villaverde Estefanía. Escuela de Educación Media Nº 7 “Roberto Arlt”. Tortuguitas, Buenos Aires. ORGANIZACIÓN Autoridades Dr. Héctor Norberto Porto Lemma Rector. Universidad de Morón (UM), Argentina Ing. Agr. Jorge Raúl Ottone Vicerrector. Universidad de Morón (UM), Argentina. Ing. Hugo René Padovani Decano Facultad de Informática, Ciencias de la Comunicación y Técnicas Especiales. Universidad de Morón (UM), Argentina. Lic. Liliana Mazzi Vicedecana Facultad de Informática, Ciencias de la Comunicación y Técnicas Especiales. Universidad de Morón (UM), Argentina. Lic. Marcelo Vinjoy Secretario Académico Facultad de Informática, Ciencias de la Comunicación y Técnicas Especiales. Universidad de Morón (UM), Argentina. Liliana Lipera Directora de Estudios Facultad de Informática, Ciencias de la Comunicación y Técnicas Especiales. Universidad de Morón (UM), Argentina. Comité Organizador Presidente - Coordinador General Jorge Salvador Ierache Facultad de Informática, Ciencias de la Comunicación y Técnicas Especiales. Universidad de Morón (UM), Argentina. Miembros del Comité Organizador Juan Miguel Santos - UBA, Argentina. José A. Fernández León - UNCPBA, Argentina. Hugo René Padovani - UM, Argentina. Secretaria Comité Organizador Ángela Moreira-UM, Argentina. Miembros del Comité Evaluador del II Workshop de Inteligencia Artificial Aplicada a la Robótica • • • Patricia Miriam Borensztejn (Departamento de Computación, Facultad de Ciencias Exactas y Naturales UBA) Andrés Gastón Stoliar (Departamento de Computación, Facultad de Ciencias Exactas y Naturales UBA) Juan Miguel Santos (Departamento de Computación, Facultad de Ciencias Exactas y Naturales UBA) Comité de Programa Miembros del Comité de Programa Jorge Salvador Ierache - UM, Argentina. Liliana Mazzi - UM, Argentina. José A. Fernández León - UNCPBA, Argentina. Juan Miguel Santos - UBA, Argentina. Flavio Scarpettini - UBA, Argentina. Héctor Fassi - UBA, Argentina. Gonzalo Zabala - UAI, Argentina. Nestor Balich - UAI, Argentina. Alejandro Javier García - UNS, Argentina. Pablo Coll - E.T. ORT, Bs. As., Argentina. Julio Fernández - E.E.M. N° 7, Bs. As., Argentina. Gonzalo Tejera - Universidad de la República, Montevideo, Uruguay. Fernando Puchetta - Instituto José Manuel Estrada, Don Torcuato, Bs. As., Argentina. Alejandro Garcia - UNS, Bahía Blanca, Bs. As., Argentina. Comité de Reglamento Miembros del Comité de Reglamento Gonzalo Zabala - UAI, Argentina. Julio Fernández - E.E.M. Nro 7, Bs. As., Argentina. Flavio Scarpettini - UBA, Argentina. Gonzalo Moon - Particular, Argentina. Andrés Gazzoli - UM, Argentina. Comité de Fair Play del CAFR 2005 Colaboradores Coordinador General Andrés Gazzoli - UM, Argentina. Sitio web oficial del CAFR 2005 Responsable: Martín Claro - UM, Argentina. Auxiliar: Gustavo Pereira - UM, Argentina. Diseño: Lourdes Gazzoli - UM, Argentina. Traducción: Ivana Villar Laskiewicz - Particular, Argentina. Edición del CAFR 2005 y WCAFR 2005 Lourdes Gazzoli - UM, Argentina. Sabrina Spengler - UM, Argentina. Sandra Lujan Centro de Medios de la Universidad de Morón - UM, Argentina. Difusión y Promoción Centro de Medios de la Universidad de Morón - UM Sandra Lujan. Luis Schiebeler Ivan C. Azzariti Colaboración en Robótica Física Sebastián Ramírez - UM, Argentina. Néstor Balich - UAI, Argentina. Colaboración General Walter Acuña - UM, Argentina. Ángela Moreira - UM, Argentina. Mónica Machin - UM, Argentina. María de las Mercedes Liolios - UM, Argentina. Andrea González Ortega Sanz - UM, Argentina. Claudia Edith Acevedo - UM, Argentina Asuntos Institucionales. Marcelo Osvaldo Freddi Clarisa Rodríguez Barreiro Camila Fenoglietto Paula Quiroga Cecilia Cop Mariana Fernández Maria Soledad Suarez Grabación y Edición Tec. Geraldine Trotta Ximena Cofre Vega. German Noval Pablo Martín Diseño Digital Video Apertura Néstor Rodríguez. Claudio Álvarez Áreas de la Universidad de Morón que prestaron Servicio al CAFR 2005 Intendencia Carlos Auteri Gabriel Olivera Construcciones Edgardo Litovich Soporte Técnico José Grano Luis Palmier Hugo Tantignone Noberto Puch Veron Miguel Daniel Mayam Instituciones • • • • • • • • • • UR - Universidad de la República - Uruguay. UNCPBA - Universidad Nacional del Centro de la Provincia de Buenos Aires, Facultad de Ciencias Exactas - Buenos Aires, Argentina. UBA - Universidad de Buenos Aires, Facultad de Ciencias Exactas y Naturales Buenos Aires, Argentina. UBA - Universidad de Buenos Aires, Facultad de Ingeniería - Buenos Aires, Argentina. UAI - Universidad Abierta Interamericana - Buenos Aires, Argentina. UM - Universidad de Morón - Buenos Aires, Argentina. UNS - Universidad Nacional del Sur - Buenos Aires, Argentina. Instituto José Manuel Estrada, Don Torcuato, Bs. As., Argentina. E.E.M Nº 5 , Pablo Nogués, Bs. As, Argentina E.E.M. N° 7 Roberto Arlt, Tortuguitas, Bs. As., Argentina. AUSPICIANTES Auspicio institucional Universidad de Morón Facultad de Informática, Ciencias de la Comunicación y Técnicas Especiales http://www.unimoron.edu.ar http://ficcte.unimoron.edu.ar Patrocinantes Auspiciantes GRAPHIPACK S.A. http://www.graphipack.com.ar XiOR http://www.xior.org Adherentes Dirección General de Cultura y Educación Gobierno de la Provincia de Buenos Aires. http://www.gba.gov.ar Comisión de Investigaciones Científicas Gobierno de la Provincia de Buenos Aires. http://www.gba.gov.ar Red UNCI Red de Universidades Nacionales con Carreras en Informática. http://redunci.info.unlp.edu.ar Foro CYTP Foro de Ciencia y Tecnología para la Producción. http://www.forocytp.org.ar RedPIBA Red Provincial de grupos de Investigación y desarrollo en áreas de Ciencia de la Computación e Informática. http://weblidi.info.unlp.edu.ar/RedPIBA/ CPCIBA Consejo Profesional de Ciencias Informáticas de la Provincia de Buenos Aires. http://www.cpciba.org Laboratorio de Sistemas Inteligentes Facultad de Ingeniería. Universidad de Buenos Aires. http://www.fi.uba.ar/laboratorios/lsi/ CAETI - Centro de Altos Estudios de Tecnología Informática Universidad Abierta Interamericana. http://www.vaneduc.edu.ar Auspiciante protector FIRA Federation of International Robot-soccer Association. Presentación II Workshop de Inteligencia Artificial aplicada a la robótica móvil Desde 1997 se vienen desarrollando diversas competencias en el mundo que utilizan al fútbol como un ambiente de investigación de sistemas multiagentes cooperativos. En estos desarrollos intervienen, entre otros, temas relacionados con robótica, inteligencia artificial, procesamiento de imágenes y control. En nuestro país esta actividad ha cobrado mayor importancia y atención desde el año 2002. A mediados del año 2003 se desarrolló el Campeonato Argentino de Fútbol de Robots 2003 (CAFR 2003), organizado por el Departamento de Computación de la Facultad de Ciencias Exactas y Naturales de la Universidad de Buenos Aires. En el año 2004, la Universidad Nacional del Centro de la Provincia de Buenos Aires tomó la posta y fue la sede del CAFR 2004. En esta última edición del CAFR, que tuvo por sede a la Universidad de Morón, se ha visto un claro y fuerte desarrollo de la actividad tanto en la cantidad de equipos como en la calidad de los mismos. Conjuntamente con el Campeonato Argentino de Fútbol de Robots 2005, se desarrolló el II Workshop de Inteligencia Artificial aplicada a la robótica móvil (WCAFR 2005), sobre adelantos en robótica e Inteligencia Artificial brindando la posibilidad de presentar los avances realizados en los tópicos relacionados con fútbol de robots y robótica móvil en carácter de exposiciones. Esta actividad, es organizada por la institución elegida como sede, elección realizada durante el desarrollo del Campeonato Argentino de Fútbol de Robots por los participantes. El primer Workshop se llevó a cabo en la Universidad Nacional del Centro de la Provincia de Buenos Aires (UNCPBA) y fue organizado por la Facultad de Ciencias Exactas teniendo como marco las sierras de Tandil. Continuando con esta iniciativa, asumió la responsabilidad de su planificación y desarrollo la Facultad de Informática, Ciencias de la Comunicación y Técnicas Especiales de la Universidad de Morón. En el WCAFR 2005, contamos con la concurrencia de las siguientes Instituciones: • • • • • • • • • UR - Universidad de la República - Uruguay. Instituto José Manuel Estrada, Don Torcuato, Bs. As., Argentina. E.E.M. N° 7 Roberto Arlt, Tortuguitas, Bs. As., Argentina. UAI - Universidad Abierta Interamericana - Buenos Aires, Argentina. UBA - Universidad de Buenos Aires, Facultad de Ciencias Exactas y Naturales – Buenos Aires, Argentina. UBA - Universidad de Buenos Aires, Facultad de Ingeniería - Buenos Aires, Argentina. UNCPBA - Universidad Nacional del Centro de la Provincia de Buenos Aires, Facultad de Ciencias Exactas - Tandil, Buenos Aires, Argentina. UNS - Universidad Nacional del Sur – Bahía Blanca, Buenos Aires, Argentina. UM - Universidad de Morón - Buenos Aires, Argentina. Además de lo expresado, el ambiente de trabajo, genera un espacio inmejorable para la difusión de las actividades de investigación científica y técnica vinculadas con el área disciplinar, a través de artículos presentados por los integrantes de los equipos, alumnos de distintas entidades educativas, y/o investigadores, los que son sometidos a la evaluación de destacados profesionales especialistas, permitiendo así la selección para su publicación con referato. Nuestro agradecimiento al comité evaluador, Patricia Miriam Borensztejn (Departamento de Computación, Facultad de Ciencias Exactas y Naturales UBA); Andrés Gastón Stoliar (Departamento de Computación, Facultad de Ciencias Exactas y Naturales UBA) y Juan Miguel Santos (Departamento de Computación, Facultad de Ciencias Exactas y Naturales UBA) Muchas otras personas acompañaron a los responsables de la organización para que el II Workshop de Inteligencia Artificial aplicada a la Robótica Móvil fuera realidad. Elaborar la lista para que nadie quede fuera, sería una tarea abrumadora y con alto grado de riesgo, ya que se podría cometer el error de omitir a algún colaborador que con su granito de arena favoreció el logro de los propósitos buscados. Por eso, sólo resta decir: ¡Gracias!, muchas gracias a todos. Hugo René Padovani Decano Jorge Salvador Ierache Presidente Comité Organizador I. II WorkShop de Inteligencia Artificial Aplicada a la Robótica I.a Artículos Selecciónados LogBall: un equipo de fútbol implementado como un sistema heterogéneo de múltiples agentes lógicos Mauro J. Gómez José H. Moyano Nicolás D. Rotstein Telma Delladio Alejandro J.Garcı́a Grupo de Robótica Cognitiva Laboratorio de Investigación y Desarrollo en Inteligencia Artificial (LIDIA) Departamento de Ciencias e Ingenierı́a de la Computación Universidad Nacional del Sur. Av. Alem 1253, (8000) Bahı́a Blanca, Argentina Tel: ++54 291 459 5135 - Fax: ++54 291 459 5136 {mjg,jhm,ndr,td,ajg}@cs.uns.edu.ar Resumen El presente trabajo describe el desarrollo de un equipo de fútbol simulado con el objetivo de participar en el CAFR 2005 en la categorı́a Simurosot. El equipo fue concebido y diseñado como un sistema multi-agente heterogéneo. Cada jugador está modelado como una entidad computacional autónoma que tiene un rol determinado dentro del equipo y coopera con sus compañeros para enfrentar al equipo contrario. El sistema fue desarrollado utilizando el lenguaje de programación Prolog para implementar las componentes de alto nivel de los agentes (razonamiento, conocimiento, etc.), y el lenguaje C para implementar la interfaz entre el sistema de agentes y el simulador provisto por la liga. El objetivo principal de plantear el equipo como un sistema multi-agente es poder aprovechar las caracterı́sticas de un dominio dinámico, como lo es un partido de fútbol, para poder realizar investigación básica en temas centrales en el área de Sistemas Multiagente: coordinación, protocolos de interacción, comunicación, arquitecturas de agentes, etc. El planteo del equipo como un sistema multi-agente presenta numerosas ventajas: la ejecución de los agentes puede realizarse en forma distribuida en una o varias máquinas, en forma transparente. Los agentes que componen el equipo pueden reemplazarse de la misma manera que en el fútbol real. De esta manera, puede sustituirse un agente por otro con diferentes caracterı́sticas, roles o habilidades, sin modificar el resto de la lógica del sistema o los demás agentes. El diseño del equipo está planteado en dos módulos principales: el módulo de interfaz y el módulo de comportamiento. El módulo de comportamiento implementa el sistema multi-agente compuesto por cinco agentes, cada uno de los cuales controla a uno de los robots simulados. Por otra parte, el módulo de interfaz obtiene la información del entorno provista por el simulador, la cual, luego de ser pre-procesada, queda disponible a los agentes Prolog (pertenecientes al módulo de comportamiento) para que éstos analicen y decidan las acciones a realizar. Estas acciones son comunicadas al simulador a través del mismo módulo de interfaz. 1. Introducción El presente trabajo describe consideraciones de diseño e implementación en el desarrollo de un equipo de fútbol de robots simulado. La principal motivación para desarrollo de este trabajo está asociada a la posibilidad que ofrece un dominio dinámico como el fútbol para realizar investigación básica en al área de sistemas multi-agentes [3, 7, 2, 4, 5]. El equipo presentado se diseña siguiendo un modelo de sistema multi-agente y este diseño se plantea en forma modular, separando los aspectos de interfaz relacionados al entorno de simulación en particular (categorı́a Simurosot en este caso), de aquellos aspectos relacionados al comportamiento del sistema de agentes. Esta separación permite que el entorno de simulación considerado sea transparente al sistema de agentes propiamente dicho, el cual es implementado en Prolog debido a su utilidad como herramienta de representación de conocimiento y razonamiento [6, 1]. El trabajo se organiza de la siguiente manera: en la sección 2 se describen los módulos principales del sistema; en la sección 3 se describen las consideraciones de diseño de la arquitectura de los agentes desarrollados; finalmente, en la sección 4, se exponen las conclusiones del trabajo realizado. 2. Los módulos principales del sistema: interfaz y comportamiento El sistema implementado consta de dos módulos. El primer módulo, o módulo de interfaz, implementa la dll del equipo, necesaria para la interacción con el simulador. El segundo, o módulo de comportamiento, implementa el comportamiento de los cinco agentes lógicos que conforman el equipo, siguiendo el paradigma de programación en lógica usando el lenguaje Prolog. La dll descrita es la que requiere el simulador, y su única función es actuar como interfaz entre éste y el módulo de comportamiento, donde se implementa el equipo propiamente dicho. En la inicialización del módulo de interfaz (dll) se crea e inicializa un intérprete Prolog sobre el cual se ejecutará el código de los agentes lógicos implementados en el módulo de comportamiento. En cada ciclo de la simulación, el módulo de interfaz realiza una transformación de los datos contenidos en la variable de entorno provista por el simulador, generando, a partir de éstos, un término Prolog que será manipulado por los agentes del módulo de comportamiento. Este término representa para cada agente su percepción actual del entorno. A partir de esos datos, cada uno de los agentes lógicos evalúa la situación actual, establece un objetivo y decide la acción a realizar en ese instante de tiempo. Las acciones decididas por cada agente, las cuales son representadas también por términos Prolog, son procesadas por el módulo de interfaz para actualizar la estructura de entorno que será retornada al simulador en cada ciclo de la simulación (Figura 1). Figura 1: Arquitectura del Sistema 3. El Sistema de Agentes: módulo de comportamiento El sistema fue desarrollado utilizando el lenguaje de programación Prolog para implementar las componentes de alto nivel de los agentes, representación de conocimiento y razonamiento. El módulo de comportamiento implementa el sistema multi-agente compuesto por cinco agentes, cada uno de los cuales controla a uno de los robots simulados. Los agentes lógicos fueron desarrollados utilizando Prolog debido a las ventajas que este lenguaje ofrece al ser una herramienta de representación altamente declarativa. Por lo tanto, la mayorı́a de los aspectos relacionados al diseño del comportamiento del equipo de agentes y a los procesos de decisión que estos agentes realizan son implementados a alto nivel. Entre otras cosas, esta herramienta permite la definición de estructuras de datos complejas a través de términos que pueden manipularse uniformemente. La simplicidad en el manejo de estos términos, combinada con el mecanismo implı́cito de backtracking y la unificación, posibilita la clara definición de rutinas de comportamiento y de acceso a las estructuras de información definidas. Eso permite, entre otras cosas, diseñar rápidamente agentes funcionales cuyo comportamiento básico puede refinarse incrementalmente, a medida que se avanza sobre el diseño del sistema multi-agente; esto es, el equipo. 3.1. Perfil de los agentes: comportamiento básico En esta sección se describe brevemente el diseño de la arquitectura de los agentes jugadores que conforman el equipo. En la Figura 2 se muestra un esquema de dicha arquitectura. Los cinco jugadores difieren entre sı́ en el proceso de razonamiento y toma de decisiones en la determinación de sus metas inmediatas o de corto plazo. Cada agente jugador posee un estado interno, en el cual se almacena información acerca del estado actual del mundo: posición, orientación y velocidad de la pelota y de cada jugador en la cancha, estado actual del marcador, estado del juego (play, free-ball, free-kick, penalty), etc. Figura 2: Arquitectura de un agente jugador En cada ciclo del simulador, el agente recibe una percepción y retorna una acción. Cuando el agente recibe una percepción, la procesa y actualiza su estado interno (burbuja 1 de la figura 2). Una vez actualizado su conocimiento del mundo, el agente debe razonar acerca de ese conocimiento para determinar qué debe hacer. El razonamiento consiste en un proceso de refinamiento de metas para determinar una meta a corto plazo (burbuja 2 de la figura 2). El agente parte de la meta global de alto nivel “ganar”, y la va refinando en base a su rol (defensor, delantero, arquero) y al estado actual del mundo, hasta obtener una meta de bajo nivel a corto plazo. Finalmente, la meta de bajo nivel obtenida del proceso de razonamiento puede traducirse casi directamente a una primitiva Prolog de movimiento para determinar la velocidad efectiva a imprimir a las ruedas del jugador (burbuja 3 de la figura 2). Por ejemplo, la meta “llegar a la pelota”, representada por el término llegarA(ball), puede lograrse utilizando la primitiva de movimiento: irA(+Or_jugador, +Pos_jugador, +Destino, +Velocidad,-Accion). Esta primitiva Prolog halla la velocidad que se debe imprimir a las ruedas para llegar a la pelota, dadas la posición y orientación del jugador, y la velocidad a la que se desea ir durante el trayecto. 3.2. Primitivas de Movimiento La única forma de controlar el movimiento de los jugadores simulados es determinando una velocidad a cada una de sus ruedas. Fácilmente se pueden modelar movimientos primitivos básicos para que un robot se desplace en lı́nea recta (dando la misma velocidad a ambas ruedas), gire sobre una de sus ruedas (anulando la velocidad de una de las ruedas) o gire sobre sı́ mismo (dando velocidades iguales y opuestas a las ruedas). No obstante, el diseño de los procesos de razonamiento y toma de decisiones requieren contar con primitivas de movimiento de más alto nivel. Por esta razón, se desarrollaron primitivas Prolog de movimiento que permiten llevar a cabo movimientos más sofisticados y complejos. Por ejemplo: llegar a un determinado punto en la cancha, mirar hacia un determinado punto o llegar a la pelota perfilado hacia una dirección determinada. Algunas de las primitivas Prolog de movimiento desarrolladas son: - mirar Halla la velocidad a imprimir a cada rueda (Accion) para que el jugador quede mirando hacia un determinado punto (Referencia), dado que se encuentra en una determinada posición (Pos_jugador) y tiene una determinada orientación (Or_jugador). Encabezado del predicado Prolog implementado: mirar(+Pos_jugador, +Or_jugador, +Referencia, -Accion) donde + significa argumento de entrada y - significa argumento de salida. - irAConArco Halla la velocidad a imprimir a cada rueda (Accion) para que el jugador vaya hacia un determinado punto (Destino) describiendo un arco, dado que se encuentra en una determinada posición (Pos_jugador) y tiene una determinada orientación (Or_jugador). Encabezado del predicado Prolog implementado: irAConArco(+Or_jugador,+Pos_jugador, +Destino, +Velocidad, -Accion) - irA Halla la velocidad a setear a cada rueda (Accion) para que el jugador vaya a un determinado punto (Destino), dado que se encuentra en una determinada posición (Pos_jugador) y tiene una determinada orientación (Or_jugador). También recibe como argumento la velocidad a la que se desea ir durante el trayecto. Si el jugador está muy desenfocado con respecto al punto Destino, irA invocará a mirar, en caso contrario invocará a irAConArco. Encabezado del predicado Prolog implementado: irA(+Or_jugador, +Pos_jugador, +Destino, +Velocidad,-Accion). - irAPerfilado Halla la velocidad a imprimir a cada rueda (Accion) para que el jugador vaya hacia un determinado punto (Destino), llegando perfilado en dirección a otro punto (Objetivo), dado que se encuentra en una determinada posición (Pos_jugador) y tiene una determinada orientación (Or_jugador). Encabezado del predicado Prolog implementado: irAPerfilado(+Or jugador,+Pos jugador,+Destino,+Objetivo,-Accion) Es importante notar que, para lograr un comportamiento más preciso, es necesario tener un buen control de la velocidad. Por esta razón, el diseño de las primitivas de movimiento consideran parámetros de velocidad, los cuales son determinados previamente a la ejecución de los movimientos, luego de un análisis de la situación actual en la que se encuentra cada agente. Para esto, se han desarrollado primitivas de control de velocidad, las cuales son utilizadas por los agentes al momento de la ejecución de la acción. Durante el proceso de decisión de las acciones a realizar, los agentes se abstraen de los detalles especı́ficos relacionados a la velocidad de desplazamiento. Estos detalles son considerados en una última instancia antes de la ejecución efectiva de cada acción. Se entiende que, en este entorno simulado, la ejecución de las acciones seleccionadas por cada agente, en cada instante de tiempo, se traducen finalmente en la determinación de dos valores que representarán las velocidades de las ruedas que deben asignarse a cada robot en cada ciclo de la simulación. 3.3. Razonamiento: Árbol de refinamiento de metas Como fue mencionado anteriormente, el razonamiento consiste en un proceso de refinamiento de metas para determinar una meta a corto plazo a partir de una meta de alto nivel. Una forma muy natural para especificar cómo debe refinarse una meta de acuerdo al conocimiento acerca del mundo, es utilizar un árbol de refinamiento de metas. Los nodos del árbol se etiquetan con metas y los arcos con expresiones lógicas cuyo valor de verdad puede determinarse de acuerdo al conocimiento acerca del mundo. Los hijos de un nodo representan las metas alternativas en las que puede refinarse la meta que etiqueta dicho nodo. La expresión booleana asociada a un arco de un nodo padre a un nodo hijo representa la condición que debe darse para que la meta del nodo padre se refine en la meta del nodo hijo. En la figura 3 se presenta un árbol de refinamiento para la meta “atacar”. Se asume, en principio, que las condiciones que etiquetan los arcos son mutuamente excluyentes y contemplan todos los casos posibles. Esto es, si en el proceso de razonamiento se llega a un determinado nodo, una y sólo una de las condiciones que etiquetan los arcos salientes será verdadera. De esta manera, dado el conocimiento actual acerca del mundo, el camino a seguir dado por el árbol de refinamiento está unı́vocamente determinado. El algoritmo para razonar usando estos árboles consiste en partir de la raı́z e ir moviéndose hacia abajo siguiendo los arcos cuya expresión es satisfecha por el estado actual del mundo, llegando eventualmente a una hoja. La meta de bajo nivel asociada a dicha hoja es el resultado del proceso de refinamiento. La implementación del razonamiento usando estos árboles es directa en Prolog. Se puede definir un predicado refinarMeta/2. refinarMeta(+Meta, -Meta inmediata) Este predicado halla la meta de bajo nivel (Meta inmediata) resultado de refinar la meta dada, de acuerdo a lo especificado por el árbol. Este predicado tendrá una regla por cada arco del Atacar soy el más cercano a la pelota Dominar_pelota puedo llevar la pelota Llevar_pelota(arco) NO soy el más cercano a la pelota Acompañar_ataque NO puedo llevar la pelota Llegar_a_perfilado(pelota, arco) Figura 3: Ejemplo de un árbol de refinamiento árbol. Por ejemplo, para el caso del árbol de la figura 3 deberı́a escribirse el siguiente código Prolog: refinarMeta(atacar, Meta inmediata) ←− soy el más cercano a la pelota, refinarMeta(dominar pelota, Meta inmediata). refinarMeta(atacar, Meta inmediata) ←− NO soy el más cercano a la pelota, refinarMeta(acompa~ nar ataque, Meta inmediata). refinarMeta(dominar pelota, llevar pelota(arco))←− puedo llevar la pelota. refinarMeta(dominar pelota, llegar a perfilado(pelota,arco)) ←− NO puedo llevar la pelota. Ası́, en cada momento del proceso de razonamiento, el agente considera las condiciones que mejor describen su situación actual y de acuerdo a ellas refina sus metas. Si la meta obtenida en el paso de refinamiento es una hoja, significa que existe una primitiva de movimiento cuya ejecución consigue dicha meta. Por ejemplo, la meta llegar a perfilado(pelota,arco) está asociada a la primitiva ir a perfilado/5. 4. Conclusiones Como se mencionó al comienzo, una de las motivaciones para el desarrollo de este trabajo es la realización de investigación básica en sistemas multi-agentes. En el caso particular de este trabajo, el énfasis está en modelar los procesos de razonamiento y toma de decisiones de los agentes. Se plantea un modelo de razonamiento y toma de decisiones basado en el refinamiento de metas el cual se traduce en forma directa en programas lógicos. Una ventaja de esto es que posibilitarı́a la definición de agentes lógicos con la habilidad de adaptarse a cambios del entorno. Estos cambios podrı́an verse reflejados en la decisión de cambiar la forma de refinar las metas. Dicho de otra forma, un agente podrı́a variar dinámicamente su polı́tica de comportamiento a través de la reestructuración del arbol de refinamiento lo cual puede realizarse actualizando dinámicamente su base de conocimiento. Al estar representados estos árboles a través de programas lógicos Prolog la reestructuración se lograrı́a directamente con la actualización dinámica del código Prolog que ejecuta cada agente. Referencias [1] Bratko, I. Prolog Programming for Artificial Intelligence, first ed. Addison-Wesley, Reading, Massachusetts, 1986. [2] Georgeff, M. Communication and interaction in multiagent planning. In Proceedings of the Eighth International Joint Conference on Artificial Intelligence (Aug. 1983), pp. 125– 129. [3] Huhns, M.Ñ., and Singh, M. P., Eds. Readings in Agents. Morgan Kaufmann, San Francisco, CA, USA, 1998. [4] Jennings, N. R. Commitments and conventions: The foundation of coordination in multiagent systems. Knowledge Engineering Review 8, 3 (1993), 223–250. [5] Jennings, N. R., and Wooldridge, M. J., Eds. Agent Technology: Foundations, Applications, and Markets. Springer-Verlag, Berlin, 1998. [6] Sterling, L., and Shapiro, E. The Art of Prolog. Logic Programming Series. MIT Press, 1987. [7] Wooldridge, M. J. An introduction to Multi-agent systems. Wiley, 2002. Workshop del CAFR2005 F.R.U.TO. Fútbol de Robot Uruguayo para Torneos Workshop del CAFR2005 Copello, Ernesto Castromán, Alvaro Tejera, Gonzalo Calero, Nelson Facultad de Ingeniería Universidad de la República Montevideo, Uruguay Resumen: Este artículo presenta un equipo de fútbol de robots para la categoría Middle League SimuroSot de FIRA. El mismo, es una evolución del equipo desarrollado en el contexto de un proyecto de grado “Fútbol de Robots” realizado en la Facultad de Ingeniería de la Universidad de la República. El principal objetivo de este proyecto es el desarrollo de un equipo competitivo de fútbol de robots, aplicando distintas técnicas de inteligencia artificial. Para esto se siguió un enfoque en capas orientado a objetos, donde los robots son dotados de una serie de acciones o habilidades. Así, la formación del equipo es determinada mediante aprendizaje por refuerzo, lo que determina que el equipo se adapte a su adversario de turno, ejecutando las mejores acciones para derrotarlo. Palabras clave: capas, control, coach, referee, debugger, aprendizaje, refuerzo. I. Introducción Este artículo presenta un equipo de fútbol de robots para la categoría Middle League SimuroSot (FIRA, 2004) de FIRA. El mismo, es una evolución del equipo presentado en el CAFR 2004, desarrollado en el contexto de un proyecto de grado “Fútbol de Robots” (Fing, 2003) realizado en la Facultad de Ingeniería de la Universidad de la República. Dentro de las principales características de este equipo se destacan: el uso de una arquitectura en capas orientada a objetos, la inclusión de un conjunto de acciones o habilidades de las cuales los robots son dotados, un mecanismo de predicción basado fuertemente en el estudio del ambiente en donde se desarrolla el juego, la creación de varios mecanismos de control para el movimiento de los robots, y el desarrollo de herramientas auxiliares de soporte como un simulador propio llamado GSim, y un debugger altamente flexible capaz de permitir fácilmente la visualización de objetos internos de la estrategia durante la reproducción de un partido. II. Arquitectura Hemos identificado ciertos niveles de abstracción a partir de un análisis del problema de fútbol de robots, a partir del estudio de las arquitecturas propuestas por otros equipos, principalmente (Laplagne, 2002), y basándonos también en nuestra propia experiencia de partidos jugados con versiones anteriores de FRUTO. Así, el modelo propuesto consiste de seis capas, las cuales hemos numerado de 0 a 4 (0, 1, 1.5, 2, 3, y 4), siendo la capa 0 la de más bajo nivel. La capa 0 es la encargada de proporcionar la interfaz con el robot (salida), es decir, es la que permite enviar los comandos al robot, en nuestro problema los comandos son velocidad la rueda izquierda y derecha. En la capa 1 se implementan los algoritmos de control de movimiento, o lo que en la literatura se denomina path planning (Gray, 1996). El problema de path planning puede definirse en nuestro contexto como el obtener los comandos necesarios para que el robot se desplace desde un punto a otro siguiendo en lo posible cierta trayectoria deseada y llegando al punto de destino con cierta orientación. Por su parte, y relacionado con lo anterior, está la capa 1.5 que, por encima de la capa de control de movimiento, proporciona un mecanismo para evitar colisiones y atascamientos utilizando el o los controles de movimiento ofrecidos en la capa 1. La capa 2 contiene lo que hemos denominado el conjunto de habilidades que tienen capacidad de mostrar los robots. Esto es, comportamientos básicos que usarán las capas superiores para obtener cooperación entre los integrantes de un equipo. Ejemplos de éstos son: patear al arco, despejar la pelota, marcar a un oponente, posicionarse en cierta zona libre de la cancha, etc. La idea es entonces implementar ciertas habilidades básicas deseables en los robots observando en principio también el fútbol de humanos. Subiendo un nivel más, la capa 3 es donde se encuentra el concepto de rol. Precisamente, la idea es la misma que en el fútbol tradicional, en donde los equipos poseen defensores, mediocampistas y atacantes, con sus respectivas posiciones izquierda, derecha o central, de acuerdo a la zona de la cancha en la que preferentemente desarrollen su juego. De esta manera, y aprovechando los servicios de la capa de habilidades (capa 2) se implementarán los mencionados roles. Finalmente, la capa de mayor nivel es la capa 4. En dicha capa está definida la estrategia del equipo en sí, es decir: la formación, el rol que desempeña cada jugador, la política de intercambio dinámico de roles, etc. 4 En realidad, en nuestro equipo coexisten dos módulos usados por varias de las capas y por lo tanto sería incorrecto colocarlos como pertenecientes a alguna de ellas. Los módulos de trackeo y predicción representados en la siguiente figura. sensores estrategia tracking roles modelo de comportamiento acciones modelo del mundo control de colisiones control de movimiento comandos Figura 1. Arquitectura Final. El módulo de trackeo es el encargado de mantener información histórica sobre los objetos del juego como la pelota y los robots. Dicha información puede ser por ejemplo posiciones, velocidades, comandos enviados, comportamientos activados, etc. Además, el módulo de trackeo puede ayudar en la estimación de estados futuros de los robots adversarios, basándose precisamente en dicha información histórica (en la literatura esto se conoce como opponent modeling y presenta un de los principales desafíos dentro del fútbol robótico (Asada, 2000) Por otro lado tenemos el módulo de predicción que será el encargado de estimar estados futuros de los robots propios de acuerdo a supuestos comandos a enviarles. Aquí, es imprescindible contar con un modelo lo más preciso posible del mundo en el cual se está trabajando. Tabla 1. Descripción de nuestras capas Capa 0 1 1.5 2 3 Estrategia Descripción Interfaz de comandos Control de movimiento Control de colisiones Habilidades básicas Roles 2 Workshop del CAFR2005 III. Capas A continuación se describen con mayor profundidad las capas de nuestra arquitectura. 1. Control de Movimiento. En está sección se detallan los controles utilizados por nuestro equipo englobados en esta capa. A excepción del presentado a continuación, en donde se presenta un control ya conocido (aunque fue necesario adaptarlo), todos los controles fueron creados por nosotros. 1.1 Control LV El control LV (Linear Velocity Lyapunov Approach) presentado en (Webers, 2002) consiste en aplicar dos fórmulas, una para hallar la velocidad lineal y otra para hallar la velocidad angular del robot, para que éste llegue al destino deseado. Este método supone que el destino se encuentra en las coordenadas cartesianas (0,0) y que el robot se encuentra en el cuadrante II o III de los ejes, logrando que el robot arribe hacia el destino con orientación horizontal. Inicialmente, este método calcula la velocidad lineal del robot como directamente proporcional a la distancia al objetivo. Esto puede ir en contra de las limitaciones físicas del robot. Por ejemplo, si el robot se encuentra lejos del punto destino, la velocidad lineal calculada con este método sería muy grande y posiblemente imposible de alcanzar por el robot. Peor aún, si el robot estuviera cerca del objetivo entonces la velocidad lineal calculada sería muy pequeña, y por lo tanto, el robot se quedaría prácticamente quieto cerca de dicho objetivo. Esto último es algo no deseable ya que nosotros queremos, entre otras cosas, que los robots puedan patear una pelota lo suficientemente fuerte como para vencer al arquero contrario y/o para despejarla lo más lejos posible de nuestro arco. Entonces, para solucionar estos dos problemas decidimos adaptar este control utilizando las siguientes fórmulas: vl = vl LV × MaxVel max(vl LV , vrLV ) vr = vrLV × MaxVel max(vl LV , vrLV ) Donde MaxVel es una variable que indica la velocidad máxima que tendrá al menos una de las ruedas. La idea es entonces normalizar las velocidades vl y vr de forma tal que se mantengan las proporciones entre vlLV y vrLV, que son las velocidades calculadas inicialmente a partir de las velocidades lineal y angular obtenidas del control LV. Así, al menos una velocidad contendrá el valor MaxVel. 1.2 Control Direct El control de movimiento Direct es una propuesta de nuestro proyecto en respuesta a la necesidad de contar con un control de movimiento simple pero altamente efectivo. Este control resuelve entonces el problema de alcanzar un punto destino sin tener en cuenta el ángulo de llegada. (vl, vr) = (MaxVel+ f (α), MaxVel) (MaxVel, MaxVel− f (α)) si α < 0 si α ≥ 0 (1) La ec. (1) muestra los comandos necesarios para lograr esto, donde es el ángulo (en radianes) diferencia entre la rotación del robot y el ángulo al punto destino (ver figura 3) y MaxVel una variable que indica la velocidad máxima a alcanzar por al menos una de las ruedas del robot. La función ƒ: [-π, π] → ℜ normaliza el ángulo , actualmente simplemente transforma el ángulo a grados. distinguidos equi-espaciados sobre la curva y hacer que el robot se traslade usando el control DirectAng entre dichos puntos. Al alcanzar uno de estos puntos con cierta precisión configurable, el robot pasa a dirigirse al siguiente punto y así sucesivamente hasta llegar al destino. Figura 3. Variables usadas en el control Direct. Es importante destacar que, a diferencia del control LV, este método no supone ninguna restricción posicional del robot o del punto destino, por lo que puede ser aplicado en cualquier parte del campo de juego. 1.3 Control Direct-LV Combinación de los dos controles anteriores, mediante la cual logramos un control sin restricción posicional que llega a cierto destino con un ángulo dado. Figura 4. Trayectoria hallada por CS. 1.4 Control DirectAng El control DirectAng surgió naturalmente como un desarrollo del control Direct descrito en 1.2. La principal diferencia es que no se distingue entre la parte de adelante y la parte de atrás de un robot. Esto es debido a la simetría de los robots de las categorías SimuroSot y MiroSot, ya que las ruedas de ambos no tienen por qué encontrarse en el eje central del robot (y de hecho no lo hacen). 2. Capa de Control Atascamiento. de Colisiones y 2.1 Control de Colisiones El control de colisiones utilizado se basa en (Veloso1997, Bowling1999), y puede ser usado con cualquiera de los controles de movimiento descritos antes. Se basa en detectar futuras colisiones (mediante el uso de una estrategia de predicción) con algún objeto dentro del campo de juego. Luego de detectada una posible colisión lo que se hace es desviar convenientemente la trayectoria actual hacia uno de los lados del objeto con el cual se está por colisionar, sin perder de vista el destino inicial. 1.5 Control CS (Cubic Splines) Este control se basa en primero hallar una curva paramétrica en el tiempo (x(t), y(t)) que describa una trayectoria, para luego tratar de seguirla. La trayectoria se halla utilizando el método de Cubic Splines, de forma de lograr las velocidades y orientaciones deseadas (figura 4). El método usado para seguir la trayectoria anteriormente hallada consta en tener puntos 2.2 Control de Atascamiento Inspirado en (Veloso1997), donde un robot se 4 Workshop del CAFR2005 considera atascado cuando se mantiene durante un intervalo de tiempo en un mismo estado por razones ajenas a él. La detección de un atascamiento depende de los recientes comandos enviados al robot y de sus también recientes cambios de estado (por estado nos referimos concretamente a la posición del robot y a su orientación). Entonces, dos estados serán considerados iguales si la norma de su diferencia es menor a cierto umbral. En caso de ser detectado un atascamiento, simplemente se cambia el signo y se invierten los últimos comandos enviados (velocidad rueda izquierda y derecha) que, supuestamente, provocaron el atascamiento. 3. Habilidades básicas Una acción o habilidad básica puede verse como un comportamiento a ser ejecutado por un robot en un corto plazo, como ser una iteración. Así, los robots de nuestro equipo estarán dotados de un conjunto de habilidades básicas que serán capaces de ejecutar en respuesta a ciertas situaciones de juego. En la siguiente tabla se aprecian las acciones con que fueron dotados nuestros jugadores. Tabla 2. Acciones Shoot Clear ClearH ClearV Relocate Intercept DefendGoal Patear la pelota al arco Despejar la pelota. Patear la pelota hacia una zona libre Patear la pelota con ángulo 0 Patear la pelota con ángulo 90 Moverse a una zona libre Posicionarse entre un robot oponente y la pelota Atajar. Interceptar la pelota tomando como referencia el arco propio Es importante mencionar que el conjunto de acciones provisto para nuestro equipo es totalmente extendible y escalable. Esto significa que se pueden agregar nuevas acciones fácilmente, proporcionando únicamente las clases que las implementan y dándolas de alta en un archivo de configuración. 3.1 Tipos de Acciones Definimos que toda acción es o bien activa o bien pasiva. Las acciones denominadas activas son aquellas que al ser ejecutadas por un robot tienen una influencia directa sobre la pelota, es decir, sobre su estado (posición y velocidad). Análogamente, una acción pasiva es toda acción que no cambie de manera directa el estado actual de la pelota. Así, se tiene que las acciones Shoot, Clear, ClearH y ClearV son acciones activas, mientras que las acciones Relocate, Intercept y DefendGoal son acciones pasivas. 3.2 Éxito de las Acciones El éxito de una acción para un robot dado se define como success : R × A × E → [ 0,1] , donde R es un robot, A es la acción en consideración y E es el estado actual del juego. Así, dicha función indica qué tan bien un robot puede ejecutar una acción determinada en cierto estado de juego. Un valor cercano a 1 indicaría una bondad alta mientras que un valor cercano a 0 diría que el robot no está en condiciones de ejecutar la acción de manera exitosa. La función éxito será usada por la capa de estrategia como herramienta para la toma de decisiones, i.e. para definir qué acción ejecutará cada robot en la próxima iteración. Antes de describir como se calcula el éxito de una acción detallaremos algunas herramientas auxiliares utilizadas en dicho cálculo. 3.2.1 Ángulos Un ángulo está formado por un vértice v y dos ángulos alfa1 y alfa2. El vértice suele ser el punto coincidente con el centro de la pelota, y el espacio comprendido entre las semirrectas de origen v y ángulos alfa1 y alfa2 respectivamente, representan un área sin obstáculos de libre recorrido para la pelota. 3.2.4 Modelo La idea de este módulo es encontrar un modelo aproximado para el comportamiento de los robots en el simulador FIRA. Entendemos por un modelo para el comportamiento de los robots, una función m, que como entradas recibe la velocidad actual de un robot (velocidad lineal v y angular w) y una secuencia de comandos (velocidad rueda izquierda vl, y velocidad rueda derecha vr) a ser enviados a dicho robot, y devuelve las verdaderas velocidades resultantes (vRes, wRes) con las que responderá el robot en el simulador de FIRA. De esta forma, sabiendo los comandos enviados a un robot y su estado actual, podremos estimar el comportamiento del robot (sus próximos estados) gracias al modelo m. Figura 5. Ejemplo de un Ángulo al arco. 3.2.2 Zonas Libres Una zona libre hace referencia a un área del campo de juego en la cual no se encuentra ningún obstáculo. Dicha área debe tener una superficie mínima para ser considerada zona libre. Un obstáculo, por su parte, puede ser cualquier objeto móvil dentro de la cancha, es decir: robots propios, robots contrarios y/o la pelota. En la siguiente figura se presenta un ejemplo de lo que es considerado zona libre en una situación dada de juego. 3.2.5 Cálculo del éxito de una Acción. La idea principal es iterar sobre un intervalo de tiempo a futuro, de manera tal de poder encontrar la mejor situación futura para la ejecución de la acción y finalmente cuantificar el éxito de dicha situación. Entonces, para cada iteración se avanza primero el estado de los actores involucrados en la acción. Así, el avance del estado de los actores un determinado intervalo hacia el futuro se hace de la siguiente manera. La pelota y los obstáculos (ya sean robots propios o adversarios) se manejan como se describe en 3.2.3, mientras que para el robot ejecutante se utiliza el modelo del simulador (sección 3.2.4). Esto es porque, mientas se calcula el éxito de determinada acción, los únicos comandos que se conocen son los comandos a envirarle al robot encargado de la ejecución de dicha acción (es decir, todavía no se sabe lo que harán los demás robots propios y menos los ajenos). A continuación, se toma la acción de tirar al arco como ejemplo, para explicar mejor la forma en que estimamos el posible éxito de Figura 5. Zonas Libres (imagen extraída del debugger). 3.2.3 Tracking Este módulo es el encargado de guardar datos históricos de un objeto del juego (robots, pelota) durante un partido, y predecir próximos estados de éste teniendo en cuenta dicho historial. Actualmente, se cuenta con un módulo de este tipo para la pelota y otro para los robots. 6 Workshop del CAFR2005 una acción. Para las demás acciones el cálculo del éxito es muy similar. Para estimar el éxito de tirar al arco, como mencionamos anteriormente avanzamos primero el estado de los objetos involucrados en la acción, De esta forma, con el estado de los objetos llevado al tiempo t, es necesario preguntarse si el robot responsable por del tiro se encuentra lo suficientemente cerca de la pelota como para patearla. Estar suficientemente cerca de la pelota implica, estar cerca de la posición de la pelota y, estar cerca del ángulo con el cual hay que patear a la misma para proporcionarle la dirección deseada (esto puede verse como que la distancia euclideana entre los puntos (rob.xt, rob.yt, rob. t) y (pel.xt, pel.yt, t ) sea menor que una constante). De ser así, a continuación se procede con el cálculo de lo que nosotros denominamos el éxito de una foto. Esto hace referencia a estimar, basándose en propiedades geométricas, un número que indicaría el éxito de un tiro al arco (en este caso), suponiendo estáticos a todos los objetos participantes. Para ello se utiliza la herramienta de manejo de ángulos descrita en Error! Reference source not found., pasándole como segmento referencia el arco que se desea batir. En definitiva, el éxito de un tiro al arco es proporcional a la amplitud del mayor ángulo (libre de obstáculos) con vértice en la posición al tiempo t de la pelota, teniendo en cuenta el arco al cual se desea tirar. 4. Roles Nuestro equipo cuenta con tres roles bien diferenciados: golero, defensa y atacante. Cada robot, en cada instante de juego, estará cumpliendo con un y sólo uno de estos roles. Cada rol tiene asociado un conjunto de acciones que podrá ejecutar. De esta forma, el rol de atacante podrá ejecutar por ejemplo las acciones Shoot, Clear y ClearH, pero no la acción DefendGoal. Las acciones que pueden ser ejecutadas por un rol son completamente configurables. Así, a cada acción se le asigna un atributo rol que puede tomar los siguientes valores: goalie, backward, forward ó multi. El valor multi indica que una acción puede ser ejecutada en cualquier rol. La tabla siguiente resume la configuración actual del equipo en cuanto a acciones a ser ejecutadas por rol. Tabla 3. Roles de las Acciones Accion Shoot Clear ClearH ClearV Relocate Intercept DefendGoal Rol forward Multi Multi Multi Multi backward Goalie 5. Estrategia La capa de estrategia tiene dos objetivos muy importantes. En primero instancia será la encargada de determinar la formación del equipo, y luego, para dicha formación, será la encargada de determinar qué robot ejecutará qué acción en el siguiente instante de juego. 5.1 Formación Una formación se define como el conjunto de roles que los robots jugadores deberán cumplir, por ejemplo: 1-2-2 (un golero, dos defensores y dos delanteros), o 1-1-3 (un golero, un defensor y tres delanteros). El módulo Coach es el encargado de seleccionar una de las formaciones posibles. Para esto, utiliza el módulo Referee encargado de brindar información útil como ser: el tiempo real de partido jugado, los goles hechos por nuestro equipo y el adversario, además del porcentaje de tiempo que la pelota estuvo en nuestra mitad de la cancha y en campo contrario. 5.1.1 El módulo Referee El módulo réferi es el encargado de obtener información útil y real del estado del juego, a un nivel de abstracción mayor que el proporcionado por el simulador. En base a los datos proporcionados por el simulador en cada llamada y además teniendo en cuenta el tiempo entre llamada y llamada este modulo es capaz de estimar la siguiente información: • cantidad de goles convertidos por nuestro equipo. • cantidad de goles convertidos por el equipo contrario. • tiempo real transcurrido. • el porcentaje de tiempo que la pelota se encontró en el terreno oponente. • si es el primer o segundo tiempo. nForwd // cantidad de atacantes // acciones del rol forward, // para cadar robot Action[] aForwd aForwd = getActionsByRol(FORDWARD) // acciones del rol forward, // para cada robot Action[] aMulti aMulti = getActionsByRol(MULTI) Action[] all = aForwd + aMulti for each a in all { all.calculateSuccess() } all = sort(all) // retorno las mejores acciones // a ser ejecutadas para este rol return all.getTop(nForwd) 5.1.2 El módulo Coach Este módulo es el encargado de definir la alineación del equipo en base a la información proporcionada por el réferi. Para esto se utilizan redes neuronales RBF tal como se propone en (Santos, 1999). Al sistema neuronal se le proporciona el estado del juego proporcionado por el módulo Referee y da como acción la alineación que debe tener el equipo. Este sistema es entrenado contra si mismo en una etapa temprana para luego adaptar estrategias según la característica del equipo oponente. IV. Debugger El Debugger es una herramienta desarrollada en Java para la verificación de estrategias que permite, entre otras cosas, visualizar nuevamente un partido paso a paso, observar el estado de variables y apreciar gráficamente cualquier objeto que sea de nuestro interés. Así, la idea es que a partir de un archivo de log que contiene la información de un partido de fútbol, éste se pueda reproducir completamente con la posibilidad de detenerse en los aspectos internos particulares de la estrategia que queremos verificar. Eventualmente, esta herramienta puede usarse también como simple reproductor para observar nuevamente partidos ya jugados. El archivo de log utilizado por el Debugger contiene únicamente información relevante del partido de fútbol en sí, sin ningún tipo de información que tenga que ver con una estrategia en particular. Efectivamente, la idea es que, una vez jugado un partido (o parte de él) utilizando la estrategia que se quiere verificar y, por ende, una vez generado el archivo de log correspondiente, se deberá ejecutar el Debugger pasándole, además del log, dicha estrategia a verificar. Lo que se 5.2 Asignación de Roles Una vez establecida la formación será preciso determinar qué robot ejecutará qué rol, y qué rol ejecutará qué acción. Para ello, se calculan los éxitos de las distintas acciones para todos los robot y luego, de acuerdo a los éxitos más altos, se elige la acción que un robot puede ejecutar mejor. Este algoritmo se detalla a continuación para el rol de atacante. Algoritmo 1. Asignación de Acciones para el rol de Atacante 8 Workshop del CAFR2005 pretende con esto es mantener un archivo de log estándar y de tamaño manejable, de manera de no acoplarlo a ninguna estrategia concreta. VI. Conclusiones Nuestro objetivo principal puede resumirse como la construcción de un equipo competitivo de fútbol de robots para la categoría Middle League SimuroSot de FIRA, utilizando distintas técnicas de aprendizaje. Para ello, se decidió mejorar el equipo FRUTO participante en el CAFR 2004 agregándole asignación dinámica de formaciones. Dicha asignación no es aleatoria, sino que es aprendida durante el juego mediante un algoritmo de aprendizaje por refuerzo. Dentro de las posibles mejoras a considerar estaría la creación de un nuevo módulo cuyo trabajo sería recolectar información de la forma de jugar del oponente, como su formación, roles en sus jugadores, etc. De esta forma, se podría brindar información más detallada al Coach para decidir la formación. Además, se podría utilizar también esta información para mejorar el cálculo del éxito en las acciones. Referencias (Asada, 2000) M. Asada, M. Veloso, M. Tambe, I. Noda, H. Gitano y G. Kraeztzschmar, “Overview of Robocup-98”, AI Magazine, 2000. (FIRA, 2004) Sitio oficial de la FIFA, http://www.fira.com (Fing, 2003) Sitio oficial del proyecto de grado Fútbol de Robots, http://www.fing.edu.uy/~ecopello/pgfutrob (Gray, 1996) S. Gray, “What is Path Planning”, Autonomous Solutions, Inc., 1996. (Laplagne,2002) I. Laplagne, “Aspectos de Estrategia y Control en un Equipo de Fútbol de Robots”, Diciembre 2002. (Santos, 1999) J. M. Santos y C. Touzet, “Exploration tuned reinforcement function, Special Issue of Neurocomputing, Septiembre de 1999. (Webers, 2002) C. Webers y U. Zimmer, “Motion Control of Mobile Robots – From Static Targets to Fast Drives in Moving Crowds”, Australian Nacional University, in Autonomous Robots – Vol. 12, No. 3, 2002. (Veloso, 1997) M. Veloso, P. Stone y K. Han, “The CMUnited-97 Robotic Soccer Team: Perception and Multiagent Control”, Octubre de 1997. Workshop del CAFR2005 Human-Droid Prototype: Primeros pasos en robótica bípeda Workshop del CAFR2005 Lezama, Damián Sklar, Alexander Tejera, Gonzalo Facultad de Ingeniería Universidad de la República Montevideo, Uruguay Resumen: En este artículo se presenta la construcción de un prototipo de robot bípedo capaz de caminar cuasiestáticamente. Entre los aportes originales se encuentra la estrategia para caminar del prototipo, que utiliza un enfoque análogo a la técnica de stop-motion utilizada en animación, la lectura de la posición de los motores en lazo semiabierto, y una técnica de coordinación de motores llamada Clamping (encepado). El Proyecto incluye elementos de electrónica, mecánica, programación a bajo nivel y embebida, programación a alto nivel y programación de interfaces gráficas, control, y tratamiento de señales.. Palabras clave: Robótica, Bípedos, Construcción de Robots, Sistemas de tiempo real, Programación embebida. 1 INTRODUCCIÓN En este artículo se presenta la construcción de un prototipo de robot bípedo - denominado Human-Droid Protoype (HDP) - capaz de caminar cuasiestáticamente (a bajas velocidades). Se logró desarrollar una estrategia de caminata innovadora utilizando servomotores de hobby, aluminio, técnicas de construcción casera y elementos de bajo costo para obtener un desarrollo en extremo económico. Además, en este trabajo se desarrolló una placa de control para robótica móvil, y se propone una arquitectura extensible genérica para robótica, parte de la cual fue implementada para el prototipo. 2 MORFOLOGÍA Al momento de construir un robot bípedo, hay que decidir cuál será la configuración de las articulaciones, así como la cantidad de articulaciones y segmentos. Al ser cada pie un efector del sistema, tenemos dos efectores. Para especificar cada efector se necesita un punto en el espacio y sus ángulos directores, es decir seis parámetros. Esto da un total de doce parámetros para describir los efectores del sistema. En este caso se apuntaba a que el sistema cinemático fuera compatible determinado, por lo que se eligió tener doce articulaciones, seis por pierna. Cada pierna cuenta con un tobillo, una rodilla y una cadera, así como con un muslo y una pantorrilla. El tobillo cuenta con dos grados de libertad (DOF): el primero permite mover el pie hacia arriba y hacia abajo, mientras que el segundo es el que permite inclinar hacia la izquierda y la derecha. La rodilla cuenta con un único grado de libertad, que es el que le permite doblarse. Por último la cadera posee tres grados de libertad, uno en cada eje. 2.1. El cuerpo humano como un sistema redundante Si bien con doce DOF se resuelve el posicionamiento de los efectores, el cuerpo humano posee más grados de libertad (es decir, es redundante), y la solución al problema de la cinemática inversa [1] a veces no es única: una persona sentada con los pies fijos en el piso, puede mover la rodilla hacia los costados. El efector está fijo, sin embargo hay un grado de bajo nivel (mover los actuadores), y el segundo la lógica de alto nivel (dar un paso, etc.). Esto presenta varias ventajas: en primer lugar desacopla los dos niveles de lógica, lo que provee una gran flexibilidad. Por otro lado, promueve el enfoque en capas, lo que mejora la mantenibilidad y claridad de la arquitectura del sistema. El nodo PIC es el encargado del sistema motriz de bajo nivel del robot, es decir que contiene la inteligencia necesaria para que el cada articulación pueda moverse, aunque sea sin coordinación. Algunos animales presentan la misma división del sistema nervioso: por ejemplo, los gatos y otros mamíferos tienen una parte de su sistema motriz integrado en la columna vertebral, mientras que el resto de su inteligencia está concentrada en el encéfalo [4]. El sistema motriz de mayor nivel es el que impone la coordinación entre las articulaciones para lograr movimientos coherentes del robot. El mismo está implementado en un nodo distinto, llamado nodo PC. El nodo PC está compuesto por un PC y el software de control del robot. Este software es el responsable de la lógica motriz de mayor nivel: saber como mover el conjunto de articulaciones disponibles, coordinar los movimientos, y también recibir, interpretar y reaccionar ante estímulos, sean estos originados en el robot o en el ambiente. Desde el punto de vista del flujo de información a nivel lógico, el nodo PC envía señales de comando (mover el motor i-ésimo a la posición i con velocidad i, encender o apagar una salida lógica, etc.), y recibe la medición de las posiciones de los motores. Además de esta información, se notifica si cada motor ha llegado a su destino, y se agrega un bit de reconocimiento del último paquete enviado (ACK). libertad redundante. Esto le permite al cuerpo humano efectuar movimientos que en el HDP no son posibles, pero que no son imprescindibles para caminar. 2.2 Tipos de articulaciones e implementaciones Las articulaciones en el reino animal son de tres tipos: "bola y cavidad", rotativa, y charnela. El primer tipo permite movimiento en los tres ejes (hombro, cadera), el segundo en dos ejes (articulación radio-cubital) y el último en un solo eje (dedos, codos, rodillas, articulación temporo-maxilar). Ya que usamos motores para implementar las articulaciones, fue necesario pensar en una forma de realizar articulaciones de varios grados de libertad. En el HDP, los ejes de los DOF correspondientes a articulaciones de más de un DOF, se intersectan en un punto imaginario que sería el centro de la articulación "bola y cavidad" o de la rotatoria. Esto es una gran ventaja sobre las implementaciones de articulaciones de múltiples DOF que utilizan otros robots [2][3] (es decir, una cadena de segmentos unidos por las articulaciones ortogonales), ya que el giro de uno de los DOF en nuestro caso no afecta la posición relativa a los demás DOF, cosa que sí sucede en las otras implementaciones. Figura 1. Esquema mecánico del prototipo. 3 ESTRUCTURA DE LA SOLUCIÓN En la solución propuesta, la lógica se encuentra distribuida entre dos nodos. El primero es un nodo que controla la lógica de 2 Workshop del CAFR2005 4 ARQUITECTURA PROPUESTA El sistema se estructura en diferentes capas, y se utiliza el patrón Observer para la notificación de eventos asincrónicos. Además, se utiliza el patrón Abstract Factory para obtener los manejadores de distintas capas. Dicho Factory es configurable a través de un archivo de configuración XML. El uso de interfaces permite reemplazar componentes existentes por otros con iguales funcionalidades. A continuación se describen las funcionalidades de las diferentes capas de la arquitectura. 4.1 pic En este componente se realiza el control motríz a bajo nivel (generación de las ondas PWM para comandar a los servomotores, ramping, lectura de sensores, etc.) 4.2 comm Este componente es el encargado de implementar la comunicación a nivel de flujo de bytes con el PIC. En este sentido, debe poder enviar bytes hacia el PIC y recibir bytes desde el PIC. Los servicios ofrecidos por esta capa son el envío de un arreglo de bytes del PC al PIC, algunos servicios de configuración y estadística del puerto serial, y una operación para registrarse para recibir notificaciones de bytes entrantes (paquetes desde el PIC hacia el PC). 4.3 motor Este componente es el que conoce el formato de los paquetes que se envían desde el PIC al PC y viceversa. Además, permite esperar a que un motor determinado llegue a la posición a la que debe llegar, o que todos los motores lleguen. Cabe notar que el término "llegue a la posición" significa que el PIC envíe el bit de Reached encendido, en oposición a que el motor realmente se encuentre en la posición que deba estar. Esta distinción implica que cada motor puede seguir las órdenes del PIC sin atrasarse (de la misma manera, que las velocidades enviadas por el PIC son lo suficientemente bajas). 4.4 stance La primera responsabilidad de este componente es la implementación de un diccionario de poses del robot. Una pose (stance) es una configuración en el espacio de valores de posición de los motores, es decir un vector de 12 elementos, y se identifica por un nombre. La segunda responsabilidad es proveer una interfaz que permita comandar al robot hacia una posición con una cierta velocidad para cada articulación. A este efecto utiliza los servicios de la capa motora. 4.5 gait Este componente es el encargado de implementar un diccionario de andares del robot. Un andar (gait) es una máquina de estados de poses, y se identifica por un nombre. Además ofrece el servicio de realizar un andar, para lo que utiliza las operaciones de la capa stance. 4.6 walk Este componente provee una interfaz que permite comandar al robot a que realice una caminata, concatenando servicios de la misma. Esta capa se comporta de manera similar a las ordenes disponibles en el lenguaje LOGO. Los servicios que provee son dar un paso hacia adelante, atras, izquierda o derecha y rotar hacia la izquierda o derecha. Para ello, podrá utilizar la lectura de sensores u otra información para poder generar andares en tiempo real. 4.7 pathPlanning Este componente es el encargado de, dado una ubicación adonde se desea llegar y sabiendo la ubicación actual, calcular el camino que debe seguir el robot. El componente debe permitir especificar ciertas restricciones, cuya especie a principio es desconocida, pero que son del estilo "no pasar por un punto dado", o "pasar por un punto dado". 4.8 biped Este componente es el componente lógico de mas alto nivel, y es el que ofrece el servicio de desplazamiento. Dentro del mismo, se envían los pedidos de cálculo de trayectorias a la capa inferior, y los mismos se retroalimentan mediante las notificaciones que se reciben desde el PIC, a través de las lecturas de sensores analógicos, que pueden ser de proximidad, temperatura, etc. 4.9 ui Este componente implementa la lógica de interfaz de usuario que permite comandar al robot. Está constituido por clases que implementan tres tipos de lógica: por un lado, la interfaz gráfica de los casos de uso. Por otro, clases auxiliares que implementan controles que se utilizan en la UI. velocidad, no se aseguraba que los 256 niveles resultantes fueran utilizables (es decir, que a la máxima velocidad admisible, el servomotor coincidiera con el nivel más alto de velocidad). Esto significa que para realizar movimientos más lentos, podríamos quedar limitados a unos pocos niveles de velocidad, lo que perjudicaría la coordinación. Lo segundo es importante debido a que queremos poder leer las posiciones de los motores y en lo posible otros dispositivos sensores para poder tomar decisiones. Esta característica permite capturar (digitalizar) la pose en la que se encuentra actualmente el robot. La segunda razón para crear nuestro propio controlador es que las placas representan un costo bastante alto, aumentado por el hecho de que no se consiguen en el mercado local. Adicionalmente el controlador presenta un valor agregado al proyecto, ya que el mismo puede ser utilizado en otros proyectos de robótica. Debido a que se requería control embebido a nivel de tiempo real, y se precisaba una gran cantidad de puertos de E/S, se optó por utilizar un microcontrolador. Para implementar el control de los motores se eligió utilizar un microcontrolador de la línea PIC de Microchip. Los requerimientos que determinaron la elección se resumen a continuación: • Velocidad de clock suficientemente alta como para poder cumplir con requerimientos de tiempo real. • 12 generadores de onda PWM o bien suficientes salidas digitales que permitan generar las ondas. Esto es necesario para comandar los motores. • 12 entradas analógicas (a través de conversores A/D). Esto es necesario para poder leer la posición de los motores. • Empaquetado DIP para simplificar el montaje en Protoboards y circuitos 5 ELEMENTOS DE PROCESAMIENTO Como se comentó en la descripción de la Arquitectura, por un lado se tiene el robot construido, con un elemento de procesamiento que lo controla, específicamente un microcontrolador. El mismo se encuentra dentro de una plaqueta de control embebido, y está ejecutando continuamente el software de control embebido. Este conjunto de elementos (robot, plaqueta controladora y software embebido) compone el nodo PIC. 5.1 Nodo PIC Se decidió desarrollar una placa controladora propia en lugar de utilizar una comercial. Esta decisión estuvo respaldada por dos razones. La primera razón es que los controladores comerciales no contaban con las prestaciones necesarias, ya que no proveían una resolución de velocidades adecuada, ni una cantidad de conversores A/D suficiente. Lo primero es necesario porque es importante la correcta coordinación de los motores para poder llegar a caminar. Si bien las placas existentes en el mercado proveían ocho bits de resolución de 4 Workshop del CAFR2005 impresos. Comunicación hacia afuera según algún protocolo estándar de forma simple. Varios timers, ya que se trata de un sistema de tiempo real que debe poder interactuar con el mundo exterior (comunicarse, manejar motores, etc.) interfaz de usuario fue desarrollada usando Java Swing. 5.3 Comunicación entre nodos La decisión de utilizar una interfaz serial RS232 viene a raíz de que muchos microcontroladores vienen con el protocolo RS-232 integrado, otros proveen un puerto de comunicación inalámbrica, pero son los menos. Es deseable que la programación del PIC se realice sin tener que desmontar el PIC del protoboard a través del puerto serial. Esta modalidad se denomina ICSP (In-Circuit Serial Programming) • Es deseable la posibilidad de expansión mediante la conexión de más de un PIC en cascada a través de algún tipo de bus. El PIC elegido fue el 18F4320 de la empresa MicroChip. Algunas características del PIC que se tomaron en cuenta tanto en la elección del microcontrolador como en la programación son: • Velocidad del clock de 40 MHz a través de un cristal de 10 MHz. • 13 conversores A/D de 10 bits • 4 timers • Hasta 32 puertos de E/S • El PIC implementa el protocolo RS232. 5.2 Nodo PC Los requerimientos que determinaron la elección de la estructuración del nodo PC fueron básicamente los siguientes: productividad en el desarrollo, usabilidad y amigabilidad del sistema (ya que este nodo será el punto de entrada para el usuario), mantenibilidad y claridad respecto a la arquitectura. Es por esto que se decidió utilizar un PC para este propósito. El lenguaje que se eligió para la programación fue Java y la 6 ESTRATEGIA MOTRIZ El robot construido no es "inteligente" por si mismo, es decir que el lazo de control no se cierra dentro del robot per se, sino por afuera. Para hacer que el robot camine, se eligió un enfoque de lazo abierto y en principio determinista, en el cual el robot sigue una secuencia de movimientos, sin utilizar la información recabada por los sensores. Estos movimientos conducen a que el robot pase por una cantidad de poses, y mediante la concatenación de estas poses se logra que el robot avance. Esto está inspirado en que la locomoción es un proceso mayoritariamente repetitivo, en el sentido que esto se realiza casi sin pensar, y casi siempre siguiendo las mismas trayectorias. De esta manera, el robot actúa como una marioneta cibernética, donde el marionetista es un programa de control. Si bien entre posición y posición no es posible forzar las articulaciones a seguir otra trayectoria que la que se calcula como se describirá en la subsección Perfil de actuación, intercalando suficientes posiciones intermedias, muy cercanas unas de otras, se puede llevar al robot por una trayectoria arbitraria. • • • 7 ACTUADORES Y SENSORES Debido a la popularidad, facilidad de uso y relativo bajo costo de los motores en aplicaciones de robótica, se decidió usar un motor para implementar cada articulación de un grado de libertad. Las articulaciones de más de un grado de libertad se realizaron uniendo varios motores de alguna manera conveniente (ver la sección 2). Dentro de los tipos de motores disponibles, consideramos que debido a su buena relación peso/par, facilidad de interfacear y relativo bajo costo, los servomotores eran la mejor opción. Los motores elegidos fueron los servomotores Futaba S3003. Estos motores tienen además la ventaja de estar internamente realimentados, es decir que a diferencia de los motores de corriente continua, o los motores paso a paso (steppers), cuentan con un hilo de control, por donde se les indica a qué posición deben ir. 7.1 Perfil de actuación y coordinación Es deseable que los movimientos de todos los motores comiencen y terminen en el mismo momento, ya que de esta manera se obtiene la menor velocidad posible en cada articulación: si una articulación terminara antes que las demás, entonces podría hacerse el mismo movimiento con una velocidad menor para poder terminar al mismo tiempo. Las velocidades más bajas, además de dar movimientos más suaves, redundarán en una aproximación más precisa al enfoque cuasiestático, es decir que cuanto más bajas sean las velocidades que utilicemos, y siempre y cuando la proyección del centro de gravedad (COG) caiga en el polígono de sustentación, el robot permanecerá en equilibrio estable. La mejor manera de hacer que los movimientos de las articulaciones estén sincronizados es imponiéndole una velocidad constante a todos los motores, proporcional al desplazamiento que debe tener cada motor. Cuando a un servomotor se le indica que debe ir a una posición dada, la velocidad con que el motor se mueve no es constante (sigue un comportamiento de segundo orden amortiguado). Es por ello que recurrimos a una técnica que permite obtener una velocidad constante, denominada Ramping [5]. El ramping consiste en ir guiando al motor hacia posiciones consecutivamente cercanas hasta llegar a la posición deseada. 8 DISEÑO MECÁNICO Luego de evaluar varias herramientas de simulación, decidimos utilizar ODE [6], ya que es la más adecuada para ser usada en el proyecto por proveer la funcionalidad necesaria y por existir posibilidad de adaptarla al contarse con el código fuente. También es un punto importante a favor de ODE la existencia de una comunidad activa de usuarios y desarrolladores, que es útil para obtener soporte. ODE es una biblioteca C/C++ que cuenta con tres partes: • Manejo de cuerpos rígidos y articulaciones • Asociación de geometrías a los cuerpos y colisiones • Visualización de la simulación Para diseñar una simulación se debe programar el código que genere: los cuerpos, las articulaciones, las geometrías asociadas a los cuerpos y un ciclo de simulación en el cual se avanza el tiempo mediante pasos discretos y se visualizan los objetos en cada paso. 8.1 Diseño del robot Como se vio en la sección 2, la configuración del robot es de siete segmentos unidos por seis articulaciones. Para poder realizar una simulación más sencilla se modeló cada segmento como un cuerpo simple con masa uniforme. 8.1.1 Datos del Robot Simulado Mediante la experimentación con la simulación se pudo comprender mejor el problema que afrontamos y obtener datos que nos ayudan para enfrentar la construcción del robot. Observamos que si las articulaciones no están correctamente coordinadas el robot se cae. Esto determinó que el controlador de los motores tenga un buen control de velocidad o de otra manera la coordinación del 6 Workshop del CAFR2005 movimiento de las articulaciones no sería posible. Tabla 1. Datos del robot simulado. Dimensiones del pie 50 x 90 x 35 mm Masa del pie 60 g Dimensiones del muslo 8 cm de largo, 2 cm de radio Masa del muslo 90 g Masa del cuerpo 350 g Altura Total 27 cm Masa Total (g): 750 750 g Dimensiones de la canilla 8 cm de largo, 2 cm de radio Masa de la canilla 50 g No existen desarrollos similares que utilicen motores de tan bajo torque. Lamentablemente los servos de mayor torque tienen un costo entre tres y diez veces superior. En la simulación observamos cómo el torque del que disponemos en los motores seleccionados es muy poco, ya que si bien el robot camina, no se cuenta con mucho margen de seguridad. La construcción del robot debe lograr por lo tanto un tamaño y peso mínimos, pero los que simulamos ya constituyen un desafío. En cuanto a la validación de la estrategia propuesta para caminar, el hecho de que las velocidades aplicadas lleven a una secuencia de movimientos que haga caminar al robot dio un buen nivel de seguridad en cuanto a la validez cinemática de la misma. La simulación brindó por lo tanto confianza de que si las velocidades son suficientemente pequeñas un robot puede caminar con esta estrategia. 8.2 Construcción Se debieron diseñar piezas para un prototipo funcional de robot bípedo. Como se vio en la sección 2 es deseable que los ejes de cada DOF de una articulación converjan a un punto (que define la articulación), así como también que estos puntos estén alineados a lo largo de la pierna en la posición natural del robot. La distribución de masa debe ser lo más similar posible a una distribución uniforme. La movilidad de las articulaciones no debe ser menor que el rango que utiliza la simulación para caminar y es deseable que se acerque lo más posible a la de un ser humano. Es deseable construir el robot lo más pequeño y liviano posible para que el mismo pueda funcionar con actuadores de poco torque, por tener estos un costo menor que los de mayor torque. Figura 2. El robot HDP. El tamaño de los servos impone un mínimo al tamaño que es posible lograr. El tamaño que hemos simulado ya constituye un desafío porque apenas deja el lugar necesario para los servos. También el peso supone un desafío ya que de los 750 gramos del robot simulado, 480 corresponden a los motores y sólo 270 gramos quedan disponibles para las piezas. Las piezas deben proveer la posibilidad de fijar a ellas los actuadores con los ejes en posiciones adecuadas, y a su vez tienen que evitar que los servos estén sujetos a fuerzas que los perjudiquen. Es importante también que las piezas mismas se deformen lo menos posible. Adicionalmente, los pies deben brindar el contacto con el piso, así como el cuerpo debe brindar el soporte para la electrónica del robot. Las piezas deben poderse construir con las técnicas a las que tenemos acceso y su costo debe ser bajo. Una vez diseñada una pieza se requiere que la misma pueda ser construida y probada en un corto tiempo y en forma económica para continuar con el trabajo de diseño. 8.2.1 Herramientas Para poder lograr los objetivos planteados en la sección anterior se deben utilizar en la construcción herramientas de fácil acceso y cuya operación no conlleve riesgos de seguridad ni requiera de una pericia de la cual no dispongamos. Por ello nos planteamos la construcción utilizando únicamente: • Morsa portátil • Sierra manual • Taladro de baja velocidad y mechas de medidas estándar • Punta y martillo • Destornillador • Trincheta 8.2.2 Materiales Por sus características de precio, disponibilidad y adecuación para nuestro uso se seleccionaron los siguientes materiales: • Chapa de aluminio • Tornillos y tuercas de medidas estándar • Cemento de soldadura plástica • Precintos • Goma eva Utilizar el eje de los servomotores para articular el DOF es el enfoque más sencillo y fue con lo que se realizaron las primeras pruebas. Sin embargo al intentar completar el robot las limitaciones de esta estructura se hicieron evidentes. Tanto las piezas como los brazos de plástico de los servos y el eje de los mismos cedían, deformando cada articulación lo suficiente para que la suma de estos errores deformara completamente el robot. Además el esfuerzo provocado sobre los ejes de los servos es considerable y es probable que conduzca a roturas. Los servos de mayor precio incluyen rulemanes en los ejes, ejes de metal y también existen brazos de metal que se pueden adquirir por separado. Si se contara con este tipo de servos quedaría aún el problema de la deformación de las piezas que habría que solucionar, cosa que tampoco es fácil con las limitaciones con las que trabajamos en este sentido. El enfoque que finalmente se utilizó en el robot es la utilización de dos puntos de apoyo para articular cada DOF. Uno de los puntos es el eje del servo y el segundo es un rodamiento alineado con este eje y que actúa entre los dos segmentos unidos por el DOF. Si bien este enfoque soluciona el problema, el mismo complica significativamente el diseño, aumenta el peso del robot y trae un nuevo problema a afrontar, que es fabricar el rodamiento. El aluminio se seleccionó por su baja densidad y relativa facilidad en su manipulación. Se experimentó con distintos grosores de chapa de aluminio llegándose a la conclusión de que 1.5 mm era un grosor apropiado para la construcción. Para construir el prototipo se podrían cortar las piezas a partir de su desarrollo plano sobre la chapa, para luego agujerear y doblar. Sin embargo los cortes internos son complicados de realizar con las herramientas con las que contamos, por lo que se optó por fabricar las piezas en partes y se utiliza pegamento de soldadura plástica para unirlas. 9 DISEÑO ELÉCTRICO 9.1 Alimentación Para la alimentación se implementó una fuente regulada cuya entrada viene de una fuente de PC de 12 V, ya que los servomotores deben alimentarse a 6 V para obtener el mejor torque (voltaje que no se encuentra disponible). La solución más fácil hubiese sido un circuito regulador, pero las demandas de corriente de 8 Workshop del CAFR2005 los motores son muy grandes (hasta 600 mA cada uno) por lo que hubo que pensar en una solución que diera hasta 5 A sin caída de potencial. La fuente fue construida en un circuito impreso al igual que la placa controladora, y se le adosaron disipadores en el regulador y en el transistor de potencia, y un ventilador para favorecer la disipación. Esto es muy importante ya que el transistor puede llegar a disipar 115 W, lo que eleva la temperatura del circuito muy rápidamente. La fuente construida alimenta directamente a los motores. El PIC se alimenta en 5 V, pasando esta fuente por un regulador lineal 7805. 9.2 Modificación de los motores Con el fin de obtener un lazo de realimentación de la información de los motores, se les realizó una modificación, que conecta el borne del potenciómetro en el eje del motor con un conversor A/D del PIC. De esta forma, el PIC sensa la posición en la que realmente se encuentra el motor, y esta información se transmite al PC, donde pueden tomarse decisiones más informadas acerca de las acciones a tomar. Esta es la característica crucial y determinante que permite que nuestra estrategia funcione, ya que posibilita la digitalización de las posiciones de los motores. 10 SOFTWARE Por un lado, el PIC debe poder comunicarse con un PC utilizando un protocolo descrito en la siguiente sección, a través del puerto serial. Por otro, el PIC debe poder controlar todos los motores del robot simultáneamente, sin errores perceptibles y con la mayor precisión posible, y manejar las salidas digitales presentes en el sistema. Además, el PIC sensa las posiciones de los motores, escrutinia el estado de los mismos (si han llegado a la posición deseada o no), lee las entradas digitales, y comunica dichos datos al PC a través del puerto serial. 10.1 Protocolo de comunicación En esta sección se describe el protocolo de comunicación que se utiliza para la comunicación entre el PIC y el PC. El protocolo define dos clases de mensajes: los mensajes de comandos, que viajan del PC al PIC y los mensajes de notificaciones, que viajan del PIC al PC. Además, se utilizan las técnicas de stop-and-wait y piggybacking para enviar los ACK. No se incluye ningún tipo de método de detección o corrección de errores, ya que en las condiciones dadas (cables cortos y sin pérdidas), consideramos el cable serial como confiable. 10.2 Software embebido Como se desea tener una buena precisión a la hora de controlar motores y leer sensores, es necesario contar con un módulo que implemente las funciones aritmético-lógicas de 16 bits (alu16), ya que el microcontrolador no las proporciona. Este módulo es utilizado por los demás como infraestructura. Por otro lado, el módulo ramping realiza el ramping lineal de los motores, actualizando los valores de posiciones de los motores según la velocidad asignada a dicho motor. Básicamente, si la diferencia entre la posición calculada en la que se encuentra el motor (que es a la que se comanda que vaya el motor, y que a velocidades bajas coincidirá con la real, que es la leída a través del conversor A/D desde el potenciómetro) y la posición a la que debe ir difieren en un valor mayor a un cierto umbral, la posición calculada se actualiza según la velocidad y sentido de giro necesario. Se define para ello un cierto umbral para evitar el efecto hunting (es decir que el motor no oscile en torno a la posición final). Otro módulo importante es el encargado de calcular las máscaras de bits que se detallan más adelante para la coordinación de motores, y por ende de cómo generar las ondas PWM. El sistema se estructura entonces en una rutina 10.2.2 Clamping El clamping (encepado) es una técnica que desarrollamos que permite optimizar el control de los motores. En esencia es simple: la rutina de control de motores va a tardar unas cuantas instrucciones en realizar su cometido. Esta cantidad se irá acumulando evento a evento. Cuando llega al último motor podemos tener un gran desfasaje con lo que deberíamos tener. Por lo tanto, si dos motores deben bajarse muy próximos uno del otro (menos del tiempo que tarda la rutina de control), es conveniente bajarlos conjuntamente, ya que de otro modo no solamente no se logrará la posición objetivo, sino que se retrasarán todos los motores y el sistema se comportará de forma errática. De esta forma, el sistema está programado para tomar en cuenta sus propias "limitaciones" de tiempo, y es de alguna manera consciente de sí mismo. 10.2.3 Coordinación de los motores Se debe ejecutar el algoritmo que realiza la técnica de Ramping para obtener la velocidad constante deseada (ver sección 7.1). 10.2.4 El programa principal El programa principal analiza las siguientes banderas en un bucle infinito: • Fin de recepción de un paquete a través del puerto serial • Se bajaron todos los motores (es decir, el valor de la onda PWM en este momento es 0 V para todos los motores) • Inicio de transmisión del paquete saliente • Armado del paquete saliente Debido a que la lectura analógica involucra una conversión A/D, se precisa de cierto tiempo de setup de los conversores, y de un cierto tiempo de conversión. Es por eso que se hace un polling sobre una bandera del PIC que indica cuándo termina la conversión. Antes de la transmisión de cada byte se hace polling de atención a interrupción que despacha la interrupción adecuada testeando ciertas banderas, un programa principal que realiza polling de ciertas condiciones y rutinas de atención a las interrupciones. En concreto, existen tres interrupciones: • Recepción de un byte por el puerto serie • Timeout del timer de los motores • Timeout del timer de inicio de transmisión de paquete con información acerca de los sensores y motores 10.2.1 Timeout del timer de los motores Los motores utilizados son servomotores, y precisan recibir una onda PWM cuyo período debe estar entre los 18 y 22 ms. Esta rutina debe generar las ondas PWM de los motores sin atrasarse y con la máxima precisión posible. Para ello, se utilizó un enfoque basado en máscaras de bits. Se define un evento como una dupla <motores, tiempo>, entendiendo que los motores deben bajarse en un cierto tiempo dentro del ciclo de la onda. Como varios motores pueden tener que bajarse en un mismo instante, es preferible utilizar máscaras, ya que con una única escritura a un puerto pueden habilitarse/deshabilitarse varios motores. Al utilizar 12 motores se hace necesario usar dos puertos (ya que cada uno puede direccionar ocho motores). El procesamiento se reparte en dos: por un lado se calculan las máscaras y los tiempos, y por otro lado se comandan los motores con esta información. Para calcular las máscaras, se tiene en cuenta cuáles motores están habilitados. Si dos motores deben bajarse en el mismo momento (es decir deben dirigirse a la misma posición), en la máscara aparecerán los dos bits en estado bajo simultáneamente. Esto se extiende en una técnica que denominamos "Clamping". 10 Workshop del CAFR2005 sobre una bandera del PIC que indica cuándo latch de transmisión se ha vaciado. Una vez que esto ocurre, se avanza la posición del puntero que indica el siguiente byte a transmitir dentro del paquete saliente. 10.3 Software del PC El nodo PC debe manejar los motores a nivel de la posición de cada uno de ellos, así como de encargarse de la coordinación del conjunto y de concatenación de movimientos. El software del PC es el que realiza estas funcionalidades. Las funcionalidades clave que presenta el software se resumen a continuación: • Permite comandar al conjunto de motores hacia una pose (stance) dada con velocidades dadas para cada motor. Una pose consiste del conjunto de las posiciones de todos los motores. • Calibrar el conjunto de motores. Esto es, encontrar parámetros que mapeen los valores de las lecturas de posición con los valores de los comandos que se envían al PIC correspondientes. • Capturar (digitalizar) la pose en la que se encuentra el robot actualmente, y guardarla para su futura utilización. • Definir un andar (gait). Un andar es una secuencia de instrucciones, donde una instrucción puede ser una de las siguientes: • Ir a una pose con una velocidad máxima dada. La articulación que debe recorrer más ángulo irá con esta velocidad, mientras que las demás lo harán con velocidades proporcionales a su recorrido. • Repetir un conjunto de instrucciones un número finito de veces. Esto se especifica con las instrucciones Repeat [n] y EndRepeat. • Ir a un paso determinado dentro del andar. Cada instrucción queda naturalmente numerada por el orden en el que se define dentro del andar. Cuando se ingresa una instrucción Goto [n], se está indicando que al llegar a ese paso dentro del andar, se debe continuar en el paso n -ésimo. Es deseable que el software siga una arquitectura extensible, y que esta arquitectura permita extender el sistema de forma de integrar información que excede el alcance de este Proyecto, como ser por ejemplo tener en cuenta la lectura de los sensores para generar trayectorias en tiempo real, etc. (ver Trabajos a futuro). Notar que debido a esta flexibilidad, es posible por ejemplo definir más instrucciones de ser necesario. 11 CONCLUSIONES Una vez integradas todas las partes del sistema (salvo el simulador, que se utiliza por separado) se cuenta con un robot controlado desde un PC que puede realizar movimientos programados. El proceso de calibración dde los servomotores asocia valores de posición leídos de los motores con los comandos enviados a los mismos. Con los motores calibrados, estando los servomotores desactivados (velocidad 0) se posicionó manualmente al robot en la posición deseada y se digitalizó dicha posición. Luego de comprobar la funcionalidad del sistema, nos dispusimos a hacer que el robot caminara. Para ello se diseñaron posiciones similares a las simuladas. Aparecen varios inconvenientes al intentar cumplir este objetivo. Primero, hubo que cambiar el diseño para constreñir a la estructura doblemente en lugar de tener un solo punto de restricción, ya que de lo contrario el juego que resultaba hacia imposible realizar los movimientos deseados. El torque de los motores no resultó ser suficiente para caminar igual que en el simulador. Para solucionar este problema, se inclina el cuerpo (articulaciones de la cadera) hacia adelante para ayudar al movimiento adecuado del centro de masa, y de esa manera se redujo el torque necesario. Las posiciones con ambos pies en el suelo no presentaron mayores dificultades, el robot se mueve con facilidad entre las mismas. Cuando el robot se agacha, el torque necesario aumenta y también aparece la limitación vista en la sección 2.1 por la falta de movilidad, que lleva a que algunas posiciones de los pies no permitan que el robot se agache sin que choquen sus rodillas. Se diseñó un andar a través del cual el robot puede dar cuatro pasos seguidos, partiendo y terminando en la posición de Erguido. 11.1 Evaluación de resultados Se logró plantear una estrategia original para hacer caminar a un robot bípedo y demostrar que la misma funciona correctamente. Otro aporte original fue la modificación de los servomotores para lograr lecturas de posición de los mismos, que es imprescindible para poder construir a bajo costo un prototipo que permita utilizar eficazmente la estrategia planteada. Esta modificación de los servomotores también permite, eventualmente, el desarrollo de otras estrategias de control más avanzadas sobre un robot de bajo costo, por ejemplo, usando cinemática inversa, u alguna técnica de control. También se considera exitoso el desarrollo de una plaqueta de control embebido basada en un microcontrolador y de la interacción de la misma con un PC. Esta plaqueta nos proveyó de funcionalidades que no encontramos en productos comerciales similares, y constituye un producto en sí mismo que puede ser utilizado en cualquier otro proyecto de robótica que necesite un controlador de servomotores. En cuanto al diseño del prototipo los resultados fueron buenos, más aún si tenemos en cuenta que carecemos de formación en cuanto a diseño mecánico. Si bien la construcción del prototipo de robot funcionó correctamente, el mismo muestra una funcionalidad limitada y es bastante frágil. A continuación se presentan las conclusiones más importantes que aparecen luego de realizado el proyecto: • El trabajo en robótica bípeda, para poder desarrollar un robot desde cero, debe ser necesariamente multidisciplinario, requiriéndose conocimientos muy avanzados en Ingeniería Mecánica, Física, Electrónica, Computación y Biología entre otros. • El presupuesto de los proyectos de esta área debe ser necesariamente elevado. Lamentablemente, no es posible trabajar en robótica bípeda sin materiales altamente especializados, cuyos costos son altos. Los proyectos de investigación que se presentan a eventos como la RoboCup [7] llevan robots con costos oscilando entre los U$S 5.000 y U$S 10.000, aproximadamente. 12 TRABAJOS A FUTURO 12.1 Construcción de un robot más robusto Si bien el prototipo logró demostrar las posibilidades de nuestro enfoque, no es lo suficientemente robusto debido a sus motores de bajo precio y a su construcción mediante técnicas poco avanzadas. Un trabajo interesante a realizar es la construcción de un robot con un diseño mecánico mejorado y adecuado para técnicas de construcción más sofisticadas y de ser necesario materiales más apropiados. Independientemente de contar con las nuevas piezas, sería importante también contar con mejores servomotores. Las metas de este trabajo son bastante concretas y el mismo es acotado de tal forma que creemos 12 Workshop del CAFR2005 que puede ser realizado en relativamente poco tiempo si se cuenta con acceso a la tecnología y presupuesto apropiados. Basándonos en nuestra experiencia, pensamos que con las herramientas disponibles en una carpintería de aluminio y con un presupuesto entre U$S 1.000 y U$S 1.200 se puede lograr una buena construcción. A continuación mencionamos algunos puntos a tener en cuenta como posibles mejoras: • Material de la estructura • Amortiguamiento de las oscilaciones • Protección contra caídas • Motores de mayor potencia • Separación de las señales de la alimentación • Fuente conmutada en lugar de regulada • Protección contra cortocircuitos en la fuente • Mejora de la precisión en la lectura de posiciones 12.2 Construcción de un robot humanoide Un siguiente paso lógico sería construir un robot humanoide, con cuerpo, brazos y cabeza. Para ello sería necesario ampliar la plaqueta de control y realizar un estudio para seleccionar nuevos actuadores para las piernas, ya que el peso sería considerablemente mayor. También sería importante dotar al robot de la posibilidad de incluir los sensores necesarios para otros trabajos propuestos, como el de la siguiente sección. Este es un proyecto multidisciplinario y está muy ligado al propuesto en la siguiente sección. 12.3 Estudios sobre locomoción bípeda Si se dispone de un robot robusto y con sensores apropiados podemos trabajar para entender y mejorar la forma de caminar. Para esto se necesitaría estudiar el problema desde el punto de vista físico-matemático. 12.4 Trabajos a más alto nivel La arquitectura planteada posee varios puntos no implementados que hacen a un sistema más completo. Como primera medida cabe destacar que la arquitectura propone tres capas adicionales: walk, pathPlanning y biped. Es importante notar que el lazo de realimentación de la lectura de los sensores se da en estas capas de más alto nivel, y es ahí donde el robot puede empezar a interactuar con su entorno de forma menos "ciega". También hay que observar que si bien el enfoque de este proyecto fue más bien interdisciplinario, por integrar conocimientos y experiencias de electrónica, mecánica y computación, el proyecto que surja para completar la arquitectura, al disponer de la parte física resuelta, podrá enfocarse en áreas más especializadas. Esto se debe principalmente al enfoque en capas, ya que para este nuevo proyecto, el robot ya existe, y no hay que conocer su estructura interna ni su funcionamiento; basta con conocer cuál es su interfaz de servicios. Otro punto a considerar es la integración del simulador como herramienta de predicción y corrección de la trayectoria del robot. En otras palabras, cerrar el lazo de control a un nivel mucho más alto, utilizando la predicción del simulador (que a su vez utiliza las lecturas de los sensores) para corregir la trayectoria real. Figura 3. El robot HDP. REFERENCIA BIBLIOGRÁFICA [1] Samuel R. Buss, "Introduction to Inverse Kinematics with Jacobian Transpose, Pseudoinverse and Damped Least Square methods", 2004. [2] Lynx Motion, Biped Scout Robot, http://www.lynxmotion.com, visitada mayo de 2005. [3] Simulation and Systems Optimization Group - Technische Universität Darmstadt, DD Robot, http://www.sim.informatik.tudarmstadt.de, visitada mayo de 2005. [4] J. Duysen, "Human gait as a step in evolution", Brain, Vol. 125, No. 12, pp. 25892590, Oxford University Press, 2002. [5] Lezama D. y Alexander Sklar, "Construcción de Robots Bípedos", Proyecto de Grado y Proyecto de Fin de Carrera, Instituto de Computación - Instituto de Ingeniería Eléctrica, Facultad de Ingeniería, Universidad de la República, http://www.fing.edu.uy/~pgrobip/, Mayo, 2005. [6] Russell Smith, Open Dynamics Engine, http://www.ode.org, visitada mayo de 2005. [7] Robocup, http://www.robocup2005.org, visitada mayo de 2005. 14 UNIVERSIDAD DE MORON Facultad de Informática Ciencias de la Comunicación y Técnicas Especiales Un aporte al diseño de Redes Neuronales Artificiales Javier Antonio Martinez [email protected] Resumen. En este trabajo se plantea un método de diseño de redes neuronales centrándose en la simulación por computadora como herramienta de diseño. Dicha simulación se basa en un modelo de circuito electrónico diseñado previamente, en lugar del modelo matemático de la neurona, aunque el circuito se diseña conforme a dicho modelo. Para esto se propone la construcción de un simulador de Redes Neuronales donde los algoritmos genéticos generan una población de las mismas. Estos algoritmos se modelan tal que sean capaces de encontrar las distintas interconexiones posibles, para lo cual este trabajo plantea una estructura que pueda contener todas las Redes Neuronales que se puedan construir a partir de los circuitos planteados. Para utilizar este sistema se requiere de un conjunto de ejemplos de la forma entrada-salida los cuales deben ser provistos por el usuario. Al plantear estos ejemplos como requerimientos, se observa la necesidad de establecer dependencia entre los mismos, de manera que la red pueda presentar un comportamiento en función del tiempo o de sus actuaciones anteriores, así que los ejemplos serán presentados al sistema como distintas secuencias de entrada-salida. Concluyendo se destaca que siempre que se tomen en cuenta todas las variables físicas existentes en los circuitos planteados se logrará, con este método, facilitar el diseño de redes neuronales. Palabras clave: Redes Neuronales Artificiales, Algoritmo Genético, Neurona. 1. Introducción. El artículo, se centra en un método para la obtención de estructuras de Redes Neuronales Artificiales a implementarse en hardware. En el capítulo 2. Conceptos previos., se realiza una introducción a las Redes Neuronales Artificiales haciendo hincapié en los primeros modelos y en el aprendizaje. En el capítulo 3. Hipótesis., se presenta un enunciado del método de diseño de Redes Neuronales Artificiales que este trabajo propone. En el capítulo 4. Unidad de Procesamiento. se exhibe la unidad de procesamiento que compondrá la Red Neuronal a construir. Se presenta las ecuaciones que corresponden al funcionamiento de los circuitos neuronales que compondrán algoritmos fundamentales para el diseño que se plantea. El capítulo 5. Codificación Genética. presenta las estructuras y operaciones que codifican una parte esencial para el método de diseño de Redes Neuronales. 1 En el capítulo 6. Simulador de Redes Neuronales., se presenta un primer prototipo de simulador realizando una prueba con el mismo para obtener una Red Neuronal de ejemplo. 2. Conceptos previos. Constantemente el Hombre ha observado la naturaleza en un esfuerzo por comprenderla y aprovecharla utilizando su capacidad para aprender del entorno que lo rodea y la imaginación que lo caracteriza. Desde el punto de vista de un analista de sistemas, los animales poseen un sistema de procesamiento distribuido, redundante, masivamente paralelo y tolerante a fallos. Se dice que es tolerante a fallos porque un animal puede experimentar la pérdida de alguna de las partes que componen su sistema nervioso y seguir funcionando normalmente, cosa que no pueden lograr las computadoras de hoy, por ejemplo una rata puede perder algunos cientos de neuronas y seguirá desarrollando sus actividades normalmente, en cambio cualquier computadora desde una PC hasta las supercomputadoras mas potentes, se verán muy afectadas por la pérdida de alguno de sus componentes por más pequeño que sea, sobre todo si forma parte de su microprocesador. Esto ocurre debido a que el sistema completo se basa en unidades de procesamiento, llamadas neuronas, las cuales pueden reemplazar a otras neuronas en la mayoría de las funcionalidades del sistema, además este sistema de procesamiento biológico posee muchas más unidades de procesamiento de las requeridas (redundancia), las que procesan información simultáneamente (masivamente paralelo). Es distribuido porque las conexiones entre las unidades de procesamiento mencionadas determinan el almacenamiento de los datos a procesar (recuerdos). Para alcanzar un nivel de procesamiento con capacidades como las mencionadas en el párrafo anterior se desarrollaron las Redes Neuronales Artificiales (RNA). A continuación se realiza una introducción al tema y al concepto de Algoritmos Genéticos (AG). Los Algoritmos Genéticos buscan imitar el concepto de “la supervivencia del más apto” presente en la naturaleza y en la optimización de problemas, cuya solución está basada en prueba y error. Dichos algoritmos, entonces, son una abstracción de los mecanismos de evolución biológica y forman parte de lo que se ha denominado como Computación Evolutiva o Algoritmos Evolutivos. 2.1. Redes Neuronales. La razón de crear redes neuronales artificiales es lograr imitar el comportamiento de las neuronas para obtener un sistema de procesamiento de la información con las capacidades de los sistemas nerviosos, las mismas son de gran utilidad en el reconocimiento de formas, de sonidos, para sistemas de control, y automatizaciones en general. La neurona, como elemento básico y simplificado del sistema nervioso, está compuesta por tres partes fundamentales según su funcionalidad y estructura: las dendritas, el cuerpo y el axon. Las dendritas son unos finos filamentos que rodean el cuerpo de la neurona y reciben estímulos electroquímicos, estos últimos provienen de los axones de otras células nerviosas. El axon, o salida, es el transmisor de la excitación o inhibición de la neurona y posee en su extremo una serie de filamentos que se encuentran cercanos a otras dendritas. A la separación entre axon y dendritas se la conoce con el nombre de sinapsis. El cuerpo de la neurona, o soma, cumple la función de excitar o inhibir el axon. 2 El neurofisiólogo Warren McCulloc y el matemático Walter Pitts, en 1943 plantearon el modelo matemático del funcionamiento de una neurona. El principal aporte de este modelo en el desarrollo de las redes neuronales, es un umbral, o referencia, que forma la base del procesamiento neuronal en todos los modelos que le siguieron. La activación de una unidad yi se calcula mediante la ecuación (1), donde xj es el estado de la entrada j, wij es el peso de la conexión entre la unidad i y la unidad j y µi es el umbral correspondiente a la neurona i. (1) j=N y i = f ∑ wij ⋅ x j − µ i j =1 Frank Rosenblatt (1958), diseñó el Perceptron, basado en el modelo de McCulloc y Pitts, en el cual se tienen un conjunto de entradas conectadas todas con cada una de las neuronas de salida, que no se conectan entre si y producen como resultado la identificación del patrón presentado en la entradas. Pero el Perceptron no es capaz de resolver aquellos problemas que no son linealmente separables, el más conocido es el caso de la operación lógica XOR (Hilera González y Martinez Hernando 2000). Debido a que el Perceptron solo puede resolver problemas linealmente separables, se crea el Perceptron Multicapa (ver Hilera González y Martinez Hernando 2000). Dicho modelo consta de capas de neuronas, donde cada neurona se conecta con todas las de la capa siguiente hasta llegar a la capa de salida, no existiendo conexiones en la misma capa o hacia la entrada (sin realimentación). Otro tipo de Redes Neuronales son las redes recurrentes, las que están formadas por unidades de procesamiento, llamadas neuronas, que siguen el modelo básico del Perceptron. Estas redes de neuronas son de estructura estática pero de comportamiento dinámico, debido a sus conexiones recurrentes, lo que las hace ideales para identificar sistemas no lineales dinámicos. Dichas conexiones permiten el análisis de las entradas actuales y anteriores. Las redes neuronales artificiales solucionan problemas mucho más rápido que los microprocesadores convencionales, a pesar de utilizar elementos de procesamiento más lentos. Esto ocurre porque este proceso, así como el de los animales, es masivamente paralelo. Significa entonces, que todas las unidades de procesamiento, realizan sus operaciones en forma simultánea. Las redes neuronales son muy útiles cuando se las aplican en la resolución de problemas extremadamente complejos o en aquellos procesos en los cuales no es posible vislumbrar una solución, pero sí se pueden obtener ejemplos sobre los requerimientos en la forma de entradas y salidas esperadas. De manera que si se tiene un conjunto de entradas y salidas que representen el funcionamiento de la red neuronal, será posible determinar los valores que tendrán las conexiones sinápticas. Para esto es necesario un mecanismo llamado aprendizaje o entrenamiento. 2.1.1. Aprendizaje. El aprendizaje de las Redes Neuronales Artificiales, puede ser supervisado o no supervisado. Para el primero se utiliza un algoritmo matemático que adapta los pesos de la red en función del error de las salidas que se calcula con el conocimiento del valor de salida deseado, en el segundo, la RNA no recibe información sobre cuales son los valores correctos de las salidas. 3 El aprendizaje supervisado necesita un instructor o profesor externo que mida el funcionamiento del sistema. Este tipo de aprendizaje puede ser por corrección de error, por refuerzo o estocástico. El aprendizaje por corrección de error es OFFLINE, lo que significa que para realizar el entrenamiento la red neuronal debe funcionar en un modo especial que consiste en presentar al sistema un conjunto de pares de datos representando la entrada y la salida deseada para dicha entrada. El aprendizaje por refuerzo es ONLINE, es decir que la RN puede ser entrenada en su funcionamiento normal aunque mucho más lento que el anterior y no se realizan correcciones tan exactas, más bien se trata de indicar a la red si hubo éxito o fracaso y a partir de ello la misma realiza el refuerzo o debilitamiento de la conexión sináptica. El aprendizaje estocástico consiste básicamente en realizar cambios aleatorios en los valores de los pesos y evaluar su efecto a partir del objetivo deseado y de distribuciones de probabilidad. El aprendizaje sin supervisión no necesita un instructor, el sistema debe organizarse por si mismo y no existe nada en su entorno que le indique si las salidas producidas son correctas. 2.1.2. Reglas de Aprendizaje. Uno de los primeros en plantear un mecanismo de aprendizaje para las RNA, fue Donald Hebb (1949) quien plantea un postulado conocido como la Regla de Hebb. Este se basa en el comportamiento de las neuronas para decir: "Cuando un axón de la neurona A está lo suficientemente cerca de excitar a B y repetida o persistentemente toma parte en su activación, se produce algún proceso de crecimiento o de cambio metabólico en una o en ambas células tanto que el rendimiento de A como el de las células activadas B, son aumentadas". En otras palabras si dos neuronas se activan simultáneamente, la sinapsis existente entre estas se refuerza. Una forma matemática de esta regla podría ser la de la ecuación (2), donde α es el incremento al que se sometería la conexión wij cuando se cumpla el postulado de Hebb. (2) wij ( t +1) = wij (t ) + α La ecuación (2) da origen a una regla de aprendizaje supervisado, por corrección de error. El mismo se basa en que existe un conjunto de ejemplos de entradas y salidas deseadas. Estos ejemplos son representativos del funcionamiento requerido por la RNA. Para una función de activación de tipo umbral con valores de salida -1,+1 como la que se muestra en las ecuaciones (3) y (4), se considera una entrada de referencia (j = 0), análoga al umbral µ de la ecuación (1). Las ecuaciones mencionadas se consideran para una Neurona de salida con N entradas. (3) j=N Yi = f ∑ x j ⋅ wij j =0 4 (4) − 1 ; si x > 0 f ( x) = + 1 ; si x ≤ 0 El algoritmo de corrección considera que si la salida obtenida es correcta no se realiza modificación de los pesos. Si la salida deseada es +1 y la obtenida es -1, se procede a cambiar los pesos wij según la ecuación (5). (5) wij (t +1) = wij (t ) + α ⋅ x j Si la salida deseada es -1 y la obtenida es +1, los pesos cambian según (6). (6) wij (t +1) = wij (t ) − α ⋅ x j Tanto en (5) como en (6) puede verse que aparece xj (entrada j) multiplicando a α. Esto se debe a que para una entrada negativa la regla cambia, realizándose el ajuste de wij en sentido contrario. Así que es posible definir ∆wij como la variación para el peso wij según se muestra en la ecuación (7), donde yi es la salida obtenida y di es la salida deseada (7) ∆wij ( t +1) = α ⋅ x j ⋅ (d i − y i ) Esta corrección de error es la utilizada en el Perceptron de Rosenblatt (1958). Dicho algoritmo solo sirve para corregir unidades de salida para las cuales se conoce el valor deseado, pero no es posible corregir neuronas asociativas como las del Perceptron Multicapas. Además el algoritmo no contempla el error global durante el proceso de aprendizaje. Un algoritmo que contempla el error global es el propuesto por Widrow y Hoff (1960) LMS Error (Least-Mean-Squared Error) más conocido como la regla delta o regla del mínimo error cuadrado. El error global definido por estos autores es: (8) Errorglobal = 2 1 p N (k ) ( y j − d (j k ) ) ∑∑ 2 ⋅ P k =1 j =1 donde: P: Número de neuronas de salida. N: Número de ejemplos que debe aprender. Lo que se pretende con este algoritmo es encontrar los pesos que minimicen esta función de error de la ecuación (8). Otro algoritmo por corrección de error es el de retropropagación del error, o backpropagation, consiste en determinar cual debió ser el error de las unidades ocultas de una red multicapa, a partir del error de la salida y de la función de activación. Este algoritmo requiere que la función de activación sea derivable. La retropropagación se produce calculando la derivada de la función de activación de las neuronas. Existen muchos trabajos al respecto, como mencionan Hilera González y Martinez Hernando (2000). 2.2. Algoritmos genéticos. Los Algoritmos Genéticos fueron desarrollados por Holland (1975), quien se inspira en el modelo de evolución biológica. 5 En primera instancia se codifican una serie de individuos de un entorno, que representen el problema a resolver. Las codificaciones de individuos constan de características intercambiables, genes. Luego mediante operaciones llamadas de selección, cruza y mutación se realiza una optimización del problema quedando los individuos más aptos para el entorno definido. En otras palabras para desarrollar un algoritmo genético se debe crear una estructura que pueda codificar todas las posibles soluciones del problema que se quiere abordar, generar aleatoriamente soluciones, datos en dicha estructura. Finalmente valiéndose de operaciones llamadas selección, cruza y mutación se debe encontrar la solución óptima. La estructura que codifica como estará formado el individuo se la llama genotipo y mediante este es posible crear un individuo, o fenotipo. El fenotipo es evaluado para obtener un valor de aptitud que determina cuales son los más aptos de una población dada. De esta manera se seleccionan los genotipos de los individuos más aptos de manera que luego se realiza la operación de cruzamiento y mutación para obtener un nuevo genotipo que codificará un fenotipo el cual será evaluado nuevamente. Esto se repite hasta lograr una población de fenotipos que solucionen el problema en cuestión de la forma más óptima posible. 2.2.1. Selección. Existen diferentes técnicas para seleccionar los individuos más aptos de una población dada. Algunos de estos métodos son mutuamente excluyentes, aunque otros pueden usarse en forma combinada. Entre las diferentes formas de implementar este operador genético, se distinguen la selección proporcional, aptitud proporcional a la del resto de los individuos, y la selección por orden que utiliza una tabla para ordenar los individuos según sus aptitudes. Entre los métodos de selección más comunes se encuentra la selección por rueda de ruleta, en la que se plantea una ruleta en la que los individuos ocupan una sección proporcional a su aptitud. De esta manera los individuos más aptos tienen mayor probabilidad de ser seleccionados. Otra forma de selección es la elitista, que incluye los n mejores individuos en la próxima generación directamente. Además existe el método con control sobre el número esperado donde se determina de ante mano el número esperado de hijos considerando la aptitud proporcional a la población para cada uno. 2.2.2. Cruza. En los AG los individuos de la nueva generación son determinados mediante el operador de cruza. Este recombina dos genotipos para formar uno nuevo. En algunos casos se generan dos o más dependiendo del algoritmo. El cruce de individuos puede ser simple o multipunto. La cruza simple se realiza dividiendo en un punto determinado del cromosoma a cada padre para elegir una mitad de cada individuo de manera que sea posible formar dos hijos distintos. La cruza multipunto selecciona partes de ambos padres en mas puntos de cruce. Otro punto a tomar en cuenta es la cruza uniforme, donde se tiene la misma probabilidad de heredar del padre que de la madre. 2.2.3. Mutación. La mutación es el operador encargado de introducir diversidad en la población, evitando así el riesgo de convergencia prematura. Este operador realiza una variación de cada gen con una 6 probabilidad Pm. Cuando esta probabilidad es muy alta se generan estructuras muy diferentes haciendo imposible la combinación de características, debido a que los hijos cambian tanto que pierden el parecido con los genotipos padres y el algoritmo pierde la habilidad de aprender del pasado. Por lo tanto Pm debe ser un valor bajo. La mutación puede ser simple o adaptativa. La mutación simple mantiene una probabilidad constante con un valor muy bajo. Esto no es muy conveniente cuando la población se torna muy homogénea, en cuyo caso debería aumentar Pm. Algunos tipos de mutación adaptativa son la mutación por convergencia y por temperatura. La mutación adaptativa por convergencia emplea información genética para determinar la probabilidad de mutación. A partir de una medida del grado convergencia se varía proporcionalmente Pm. Es decir que aumenta cuando la población se torna muy homogénea y disminuye cuando se diversifica demasiado. La mutación adaptativa por temperatura (ascendente o descendente) varía en función del tiempo, lo que la hace independiente del problema ya que no requiere conocimiento alguno sobre la información genética. La probabilidad de mutación Pm está acotada entre un máximo PmMAX y un mínimo PmMIN. Para la mutación adaptativa por temperatura ascendente Pm comienza en el valor mínimo y se va incrementando en tanto transcurren las distintas generaciones hasta alcanzar PmMAX. Si en cambio es por temperatura descendente Pm comienza en PmMAX y se decrementa hasta alcanzar a PmMIN. 3. Hipótesis. Si se simula el comportamiento de un circuito que represente el funcionamiento de una neurona y sus conexiones sinápticas, será posible obtener una red neuronal a implementar en hardware. 4. Unidad de Procesamiento. Existe una gran cantidad de circuitos electrónicos que pueden aproximar el funcionamiento de una neurona artificial. Con el fin de probar la hipótesis planteada se optará por el amplificador operacional como sumador-restador y comparador con histéresis como el de la Figura 4-1. En este se representa una unidad de procesamiento con cuatro entradas, dos inhibitorias y dos excitadoras. Las entradas inhibitorias son aquellas que ingresan en la entrada inversora del amplificador operacional y las excitadoras son las que lo hacen por la no inversora. Las conexiones están afectadas por un peso determinado por una resistencia. Esta actúa como conexión entre unidades de procesamiento, o desde una entrada a una unidad de procesamiento. Los pesos, una vez construida la red neuronal, son fijos. No existe aprendizaje relacionado en forma directa con la modificación de los pesos. No obstante este modelo de Neurona tiende a conservar su último estado y cambia entre excitación e inhibición en la medida que las entradas sobrepasen el nivel de histéresis. Este nivel queda determinado por la conexión de realimentación indicada en la Figura 4-1 con la resistencia Rf. Para el análisis de este circuito sabemos que VS = (-VA +VB) ·A, donde A es la ganancia de tensión del Amplificador Operacional. 7 Figura 4-1. Sumador-Restador y comparador con histéresis. Se realiza el análisis para las tensiones VA y VB por separado para luego determinar el valor de VS. Para el cálculo de VA suponemos que V3 = V4 = 0V. De esta suposición surge el circuito de la Figura 4-2. Figura 4-2. Circuito resultante de la suposición V3 = V4 = 0V. Por superposición de las tensiones parciales para V1, se supone V2= 0V y VA resulta como en la ecuación (9). Análogamente se obtiene VA con V1 = 0V en la ecuación (10). Luego aplicando el teorema de superposición de las tensiones parciales se obtiene VA en la ecuación (11). (9) VA1 = (10) V A2 = V1 R' 1+ 1 R1 V2 R' 1+ 2 R2 donde R'1 = R2 // Rb1 donde R' 2 = R1 // Rb1 8 V A = VA1 + VA 2 = (11) V1 V2 + R' R' 1+ 1 1+ 2 R1 R2 Generalizando el circuito, para entradas inversoras numeradas desde 0 a N, es posible determinar el valor de VA según la ecuación (12), donde R’i es el resultado del paralelo de todas las resistencias conectadas a la entrada inversora excepto Ri como se muestra en la ecuación (13). (12) N Vi R' i =0 1+ i Ri VA = ∑ R'i = (13) 1 N 1 1 + ∑ Rb1 j =0 R j i≠ j Análogamente para el punto B y teniendo en cuenta que una de las entradas no inversoras es una proporción de la salida, tenemos la ecuación (14) donde las R’i quedan determinadas según se indica en (15). Otro dato importante para (14) es R’f que se calcula de forma similar a R’i tal como se muestra en (16). (14) (15) Vi VB = ∑ R'i i = N +1 1 + Ri M +N R 'i = (16) + Vs R' f 1+ Rf 1 N +M 1 1 1 + + ∑ Rb 2 R f j = N +1 R j R' f = i≠ j 1 1 1 + ∑ Rb 2 j = N +1 R j N +M Finalmente, sabiendo que Vs = (-VA + VB) · A, que A es un número grande del orden de las 100.000 veces o superior. Una pequeña variación de la tensión de entrada puede llevarlo a su tensión de saturación. Debido a que los amplificadores operacionales reales tienen un error en la diferencia de tensiones de entrada llamado OFFSET de entrada, la ecuación de Vs queda como en (17), donde Verror representa una aproximación al error en la diferencia de las tensiones de entrada. V s = F (− V A + V B ± Verror ) (17) + V SAT ; F ( x) = − V SAT ; si x > 0V si x < 0V 9 Otro punto importante en las ecuaciones presentadas es la realimentación positiva. La misma provoca una respuesta en el circuito conocida como histéresis. Este es un circuito clásico llamado báscula de Schmitt, como lo muestra Malvino (1994). Básicamente se trata de tener una entrada que sea directamente proporcional a la salida (realimentación positiva). De esta manera se tiene un circuito cuyo estado depende del estado anterior. Además debido al OFFSET de entrada y a la alta ganancia del amplificador operacional el estado inicial del mismo es saturado (+VSAT /–VSAT). Como puede verse en la Figura 4-3 la función de transferencia F(x), tiene dos valores posibles. Estos valores pueden ser entendidos como una reafirmación de la excitación o inhibición de la Neurona debido a que cuando se encuentra en +VSAT el umbral que debe cruzar para pasar a –VSAT es -B·VSAT, donde B es la proporción de realimentación positiva, y para cruzar de –VSAT a +VSAT es +B·VSAT. 15 F(x) [V] 10 5 0 -20 -10 0 10 X [V] 20 -5 -10 -15 Figura 4-3. Función de activación del comparador con histéresis (báscula de Schmitt). Si bien estos cambios de estado no siguen la regla de Hebb, realizan una adaptación por refuerzo. Esto significa que si una unidad de procesamiento se encuentra fuertemente excitada tiende a permanecer así solo hasta que sea fuertemente inhibida. 5. Codificación Genética. La tarea más compleja en el diseño de una Red Neuronal es determinar la cantidad de Unidades de Procesamiento requeridas para que la misma interprete los patrones de entrada. Lo que sí es seguro que tendrá al menos tantas unidades como salidas posea la Red. Dado que las unidades de salidas iteractúan con el mundo exterior su número es un requerimiento fundamental. Las entradas, cuyo número también es un requerimiento, no son exactamente unidades de procesamiento, solo tienen como misión transferir el valor de entrada al resto de la RNA. Además de las salidas existen otras Neuronas, llamadas asociativas u ocultas, son aquellas que se conectan a las salidas, a las entradas o a otras asociativas, pero no tienen contacto con el mundo exterior. Entonces el problema es determinar la cantidad de Neuronas ocultas. Por este motivo el Genotipo debe codificar la cantidad de Neuronas. 10 Otra difícil decisión en el diseño es la elección de las conexiones, qué unidad se conecta con cual y qué conexión es redundante o innecesaria. Se llega a la conclusión de que la solución más óptima para encontrar una red neuronal a partir de un conjunto de ejemplos de funcionamiento es la simulación. Como no existe una solución matemática al problema de determinar la cantidad de neuronas que se requieren para la construcción de la RNA se opta por un algoritmo evolutivo, mas precisamente encontrar un algoritmo genético debido a que las redes neuronales poseen características intercambiables. Una buena estructura para codificar de forma directa las conexiones de una RNA es una tabla donde las columnas representan el origen y las filas el destino. Esta estructura cubre todas las conexiones posibles para una cantidad determinada de Unidades de Procesamiento. El tamaño de dicha tabla varía según el tamaño de la RNA. Una tabla de 6 filas y 6 columnas indica las conexiones entre seis Neuronas. En la Tabla 5-1 se presenta un ejemplo de Genotipo con dos entradas, dos salidas y dos unidades asociativas. Se observa que las Unidades de Entrada no son destino de una conexión. Esto no es casualidad, como se mencionó en este capítulo las Unidades de Entrada no procesan información, solo la propagan hacia las otras unidades tal cual como la reciben. Por lo tanto las Entradas no pueden ser destino de conexión alguna. Entradas 0 1 2 3 4 5 0 0 0 0 -1 +1 0 1 0 0 0 0 0 -1 Salidas 2 0 0 0 0 0 +1 3 0 0 0 0 0 0 Asociativas 4 0 0 -1 0 0 +1 5 0 0 0 -1 0 0 Tabla 5-1. Ejemplo de un genotipo de red neuronal A partir de la Tabla 5-1, que representa un Genotipo de RNA es posible construir una estructura como la de la Figura 5-1. La misma constituye el Fenotipo de dicha Red. Los Genes, elementos de la tabla mencionada, pueden tomar tres valores, -1 que se transformará en una conexión inhibidora en dicho fenotipo, 0 que representa la no existencia de conexión y +1 que se decodifica como una conexión excitadora. 0 1 4 5 2 3 Figura 5-1. Fenotipo (Red Neuronal) obtenido a partir del Genotipo de la Tabla 5-1 Ya establecida la codificación de Genotipo a Fenotipo, se determinan los operadores necesarios para el AG, Selección, Cruza y Mutación. La Selección de los individuos es del 11 tipo elitista con un número determinado de sobrevivientes. Se introduce un operador de cruza, del tipo multipunto, que tome una unidad neuronal de cada uno de los padres, es decir una fila de cada uno de sus Genotipos. Finalmente la mutación es simple con una probabilidad fija en todas las generaciones. 6. Simulador de Redes Neuronales. La principal funcionalidad del simulador es generar la estructura de una Red Neuronal a partir de un conjunto de ejemplos dados. Cada uno de estos ejemplos estará compuesto por valores de entradas a los cuales le corresponden valores de salidas que podrán depender de ejemplos anteriores. De manera que los datos de entrada al simulador deben ser secuencias de entradassalidas que representen el funcionamiento requerido por la RNA. El programa se divide en dos clases de objetos principales, como puede verse en la Figura 6-1, el Genotipo, encargado de la codificación genética y de la implementación de los operadores genéticos; y la Clase Red (o Fenotipo) que implementa la RNA decodificada a partir del Genotipo. El Genotipo define de forma común a toda la población la probabilidad de mutación (Pm), la probabilidad de crecimiento (Pcrecer) y la cantidad de entradas y de salidas. De forma individual se definen los Genes y la cantidad de nodos. Pm es un número real entre cero y uno que indica la probabilidad de cada Gen de mutar, entendiéndose por Gen a cada entero contenido en el atributo genes del mismo. La operación mutar realiza un recorrido de la tabla genes cambiándolos con una probabilidad Pm. El atributo Pcrecer, determina la probabilidad de que se agregue un nodo (neurona) luego de la operación de cruza. Este mecanismo permite que la RNA aumente de tamaño valiéndose del método agregarNodo(). Debido a que algunos nodos pueden quedar sin conexión en sus entradas o en sus salidas se crea la operación eliminarNodo(), utilizada por el método limpiar() que elimina completamente los nodos que cumplen esta condición de desconectado. Figura 6-1. Clases principales para la construcción del simulador. 12 La Clase Red, Figura 6-1, define de forma común a toda la población los atributos Vsat, offset, MaxIter, MaxActiv, R y Vej. Vsat es la tensión de saturación del amplificador operacional que se está modelando. offset es la tensión de error en la entrada. MaxIter es el máximo número de iteraciones que pueden realizarse para corregir un error de salida esperada. MaxActiv es el número máximo de activaciones que se permiten calculan en el simulador con el fin de alcanzar un estado estable. R es una lista con lis valores típicos de resistores, existentes en el mercado. Vej es un conjunto de secuencias de entrenamiento compuestas cada una de ellas por un conjunto de entradas y salidas esperadas. El resto de los atributos, distintos para cada objeto Red existente en la simulación, son iR, iRb1, iRb2, Rp, Vs y Vant. iR es un arreglo bidimensional que contiene los índices que corresponden al valor de un resistor en la lista R. Estas resistencias representan las Ri mencionadas en las ecuaciones (12) y (14). iRb1 e iRb2 concuerdan respectivamente con Rb1 y Rb2 mencionadas en las ecuaciones (13) y (15). Vs y Vant son las tensiones actual y anterior de salida respectivamente, de los amplificadores operacionales que integran la RNA a implementar. Las operaciones más destacadas en la clase Red para este modelo de simulador se muestran en la Figura 6-1. Los métodos incR(y,x) y decR(y,x) aumentan o disminuyen, respectivamente, en uno el valor de la iR[y][x]. Esta clase hace uso de una operación entrenar() que realiza el ajuste de las resistencias valiéndose de los métodos mencionados. El ajuste realizado por el método entrenar() se basa en la corrección mencionada en la ecuación (7). La diferencia con esta corrección radica en el gradiente que se utiliza. En este algoritmo el ajuste se hace en variaciones de los índices iR[y][x]. esto garantiza que se estarán utilizando resistores comerciales para la construcción de la RNA y reduce notablemente el tiempo de entrenamiento offline. Esto es de vital importancia ya que, como se observa en las ecuaciones (13) y (15), las R’i, implementadas en Rp requieren de un cálculo significativo. Otro algoritmo importante es el de activación de la Red. El mismo está representado por el método activar() de la clase Red. En el mismo se hace uso de las ecuaciones (12) y (14) más un termino de error que simula la tensión de offset de entrada para finalmente aplicar la función de propagación de la ecuación (17). 6.1. Prototipo de Simulador. A partir de lo expuesto se procede con la construcción de un prototipo de simulador de RNA. La finalidad de dicho simulador es probar la hipótesis planteada en el capítulo 3. El simulador genera redes neuronales a partir de un conjunto de parámetros establecidos por el usuario y basándose en los algoritmos mencionados. El primer paso es establecer el conjunto de secuencias de entrenamiento que representen el funcionamiento de la RNA a construir. Las mismas se escriben en un archivo de texto con la estructura del arreglo de tres dimensiones Vej de la Figura 6-1. La cantidad de entradas y de salidas se establece juntamente con los parámetros del simulador como el máximo de iteraciones, de activaciones, Pm, Pcrecer, Vsat y offset. Luego se procede con la simulación, la cual retorna un arreglo bidimensional que contiene los valores de los resistores que conectan los amplificadores operacionales que actúan como Unidades de Procesamiento (Neuronas). 13 A continuación se presenta el contenido del archivo de entrenamiento que se utilizó para la simulación que se muestra en la Figura 6-2. El contenido del archivo está basado en el supuesto de que la tensión de saturación es 5V. Como puede observarse el primer número indica la cantidad de secuencias. El número siguiente la cantidad de ejemplos (entradassalidas esperadas) de la primera secuencia. Luego siguen las tensiones de las entradas y las salidas esperadas. El siguiente entero indica la cantidad de ejemplos de la segunda secuencia y así sucesivamente hasta completar todas las secuencias que se necesiten para reflejar la funcionalidad requerida. 4 4 5 -5 5 -5 5 -5 5 5 5 5 5 5 -5 -5 -5 -5 -5 -5 5 -5 -5 5 5 -5 4 -5 5 -5 5 -5 5 5 -5 -5 5 -5 5 -5 5 5 -5 5 5 5 -5 -5 5 -5 -5 3 -5 -5 -5 -5 -5 5 5 -5 -5 -5 5 5 5 -5 -5 -5 -5 5 4 5 -5 5 5 -5 5 -5 -5 5 5 -5 -5 -5 5 -5 -5 -5 5 5 -5 -5 -5 -5 -5 5 -5 5 5 5 5 -5 -5 -5 5 -5 -5 -5 5 -5 5 -5 5 5 -5 5 -5 -5 5 5 -5 -5 5 -5 5 5 -5 -5 -5 5 5 -5 5 -5 5 -5 -5 5 -5 -5 El ejemplo que se presenta no tiene una funcionalidad en particular para la RNA que se pretende construir, solo se eligieron valores al azar de entradas salidas para probar el funcionamiento del simulador. Figura 6-2. Ejemplo de simulación de RNA con AG, basada en amplificadores operacionales. 14 En la Figura 6-2 se muestra la interfaz del simulador luego de aplicar el AG y el algoritmo de entrenamiento para los ejemplos presentados. A partir de los resultados obtenidos se construye el circuito neuronal de la Figura 6-3. Este circuito fue probado en el simulador Electronic Workbench 5.0. Figura 6-3. Red Neuronal Artificial implementada con Amplificadores Operacionales. Los tensiones medidas en el circuito de la Figura 6-3 mostraron un acierto total en sus salidas del 53% comparándolas con los ejemplos del archivo de entrenamiento. En las salidas que no se produjeron aciertos totales se obtuvieron dos correctas de las tres salidas que posee. 7. Conclusiones. En el presente trabajo se han planteado algunos puntos importantes tendientes a facilitar el diseño de las RNA en la medida que se tomen todas las variables relevantes del modelo físico. Algunos de estos puntos importantes son: 9 Simulación de una Red Neuronal partiendo de circuitos ya diseñados y probados, en lugar de un modelo teórico. 15 9 El uso de una función de activación con un nivel de histéresis que permite reforzar los estados internos de la RNA dependiendo de lo fuerte que sean sus excitaciones o inhibiciones. Cabe destacar que, en el simulador presentado, se ha tomado en cuenta la tensión de offset de entrada, propia de los amplificadores operacionales. Gracias a esto la simulación ha obtenido el esquema correspondiente a un circuito sin oscilaciones. Este punto es muy relevante a la hora de diseñar circuitos de este tipo, dado que existe un número importante de conexiones recurrentes positivas y negativas. La no consideración de este parámetro podría causar que la red se transforme en un oscilador, con la consiguiente no convergencia de las salidas del circuito hacia un valor estable. Finalmente se puede concluir que el presente trabajo constituye un aporte al enriquecimiento del área de conocimiento con un método que promete facilitar el diseño y evolución de las redes neuronales. 8. Bibliografía. Booch, Rumbaugh y Jacobson (1999). El lenguaje unificado de modelado. Addison Wesley. Hebb Donald (1949). The organization of behavior. John Willey & Sons. Hilera González y Martinez Hernando (2000). Redes Neuronales Artificiales. Alfaomega. Holland John (1975). Adaptation in Natural and Artificial Systems. Universidad de Michigan. Jung, W. G. (1975), IC op-amp cookbook. Howard W. Sams & Co., Inc. The Bobbs-Merril Co., Inc. Malvino, A. P. (1994). Principios de Electrónica. McGraw-Hill. McCulloc y Pits (1943). A Logical Calculus of the Ideas Immanent in Nervous Activity. Rosemblatt F. (1958). The Perceptron: Aprobabilistic model for information storage and organization in the brain. Russell S. J. y Norvig P. Inteligencia Artificial: un enfoque moderno. Prentice Hall. Widrow B. y Hoff M. (1960). Adaptative Switching Circuits. IREWESCON Convention Record. 16 CAFR2005 El equipo morasot Potenza, Aníbal CIENTIC, Universidad de Morón Machado 914 Morón (1708) Pcia. Buenos Aires República Argentina Teléfono: 5627-2000 Interno 735 [email protected] Resumen: El artículo presenta la versión III del software morasot, que es el desarrollo de un equipo de fútbol de robots. Esta versión prioriza el diseño de un framework que permita adaptar el equipo a diferentes simuladores, como el simulador SimuroSot (FIRA) o el simulador de RoboCup. Algunas de las características del equipo son: modos y comportamientos, sensado, predicción y retrospección, navegación, delimitación del campo de juego y comunicación remota. I. Introducción. El equipo morasot para competir en el CAFR 2005 tiene un cambio de visión en el desarrollo del mismo. El primer cambio fue programarlo en la plataforma Java y el segundo cambio fue programar el conjunto de clases pensando en un framework que pueda usarse en otros simuladores de otras competencias. La elección de otra plataforma de desarrollo se debió a independizar el desarrollo del equipo de las dependencias de software que pudieran traer los simuladores. Esto tiene la ventaja de poder desarrollar un framework que pueda ser reutilizado en diferentes tipos de competencias. Una estrategia para competir en el simulador SimuroSot podría aplicarse en un simulador de RoboCup, como así también un simulador de Sumo. En una situación ideal, lo único que debería definirse es el paquete de transmisión del simulador al equipo morasot. En una situación real, los cambios que se tendrían que hacer para adaptar la estrategia a las características propias de cada simulador no deberían modificar el núcleo del programa. La utilización del lenguaje Java fue por que se deseaba ampliar los conocimientos sobre el mismo y por la comunidad que lo respalda. Uno de los primeros pasos fue probar la velocidad de conexión en un entorno Java que utiliza una máquina virtual y en un entorno C++ que debería ser más rápido. A pesar de que no se ha realizado una validación empírica sobre los dos entornos, se ha observador que los retardos en la comunicación son similares o no son perceptibles. La figura 1 muestra un diagrama de cómo sería la comunicación remota. OppDLL TeamDLL morasot (server) Figura 1. Comunicación remota. CAFR2005 Solucionado el problema de la comunicación se decidió implementar un fácil mecanismo para controlar el tiempo de respuesta de cada ambiente por parte del equipo, en este caso, el servidor que acepta las peticiones del simulador, el cliente. Este equipo, a pesar de estar programado desde cero, tiene una maduración de dos equipos anteriores. Por último, se ha diseñado un software que permite capturar los datos de una partida para poder reproducirlos luego con información complementaria. La primera intención fue desarrollar un simulador, pero debido a la falta de físicos que se interesasen en el tema no se ha podido implementar todavía. Aunque cabe destacar la colaboración desinteresada del Ing. Menendez, ex docente de la Universidad de Morón, en cuestiones cómo la navegación del equipo. II. Programación genérica Cómo la aspiración fue desarrollar un framework que sea útil a varios simuladores, se presentó el problema del desarrollo de algorítmos que se puedan compartir, o se podría decir, que sean genéricos. Entra en conflicto las características propias de cada simulador, donde la dificultad se encuentra en construir funciones comunes a todos. Por ejemplo, un simulador de fútbol de robots tiene un campo de juego cuadrado, mientras que un simulador de Sumo tiene un campo redondo, pero ambos coinciden en su sistema de navegación porque los robots poseen dos ruedas. Un simulador de la FIRA tiene dimensiones diferentes de un simulador de RoboCup, pero ambos coinciden en la delimitación del campo en área chica, área penal, círculo central y otros. Para intentar lograr este objetivo se respetaron una serie de condiciones que fueron modelando una metodología de desarrollo. Uno de los puntos de control es que cada función programada debía ser analizada para determinar si se adaptaba en por lo menos dos simuladores diferentes. Un punto de diseño era la utilización de interfaces que deben implementar las clases. Las interfaces declaran métodos que deben implementar las clases que quieran cumplir una funcionalidad determinada. La implementación de estas interfaces permitió programar algoritmos que solo conociesen la declaración de la interfaz y no la implementación. Por ejemplo, un algoritmo que utilice un sistema de navegación no le interesa conocer la clase, solamente le interesa conocer la interfaz. Esto permite cambiar los sistemas de navegación sin modificar el algoritmo. III. Pensar un solo equipo Cuando se desarrolla un equipo de fútbol de robots surge la problemática de los lados del campo de juego. Un robot del lado izquierdo debería ir con una dirección de 0 grados para ir al campo oponente. Por el contrario, un robot del lado derecho debería tener una dirección de 180 grados. La estrategia más eficiente pero menos práctica es crear equipos clones pero variando las variables de ángulo y posicionamiento. La solución implementada en morasot I y II fue cambiar esas variables dentro de los métodos donde hiciera falta. Esto trajo consecuencias a medida que el equipo crecía porque hay ciertos errores que son difíciles de detectar. En la versión III de morasot se implementó una solución para programar el equipo pensando en el campo oponente, el campo propio, el lado izquierdo o el lado derecho. De esta forma se estaría pensando el equipo con una visión local y no global. Ya no interesa si un robot patea la pelota con un ángulo de 0 grados o 180 grados, solamente interesa patear la pelota hacia el campo oponente. CAFR2005 En principio se diseñaron clases que encapsulen las medidas del simulador y la ubicación del equipo dentro del campo de juego. Esto permitió una metodología de trabajo para pensar un solo equipo. También durante el desarrollo se debió ser riguroso para evitar condiciones que determinen de que lado del campo de juego se está, demorando el mismo para rediseñar la falencia presentada. IV. Modelización El equipo morasot III fue pensado en capas. Cada capa fue creada siempre que se necesitó un nivel diferente de abstracción. Lo ideal es lograr que cada capa realice una función bien definida. El equipo a presentar este año tiene tres capas definidas: core, modules y strategy. La capa core tiene como objetivo interpretar el ambiente enviados por otros simuladores y mapearlo a una estructura de ambiente propia. Esto permite independizar la funcionalidad de los módulos y la estrategia de cada simulador en particular. Una consideración aparte es el formato de la trama utilizada para lograr la comunicación que se detalla en la figura 2. Al principio se pensó en diseñar una trama orientada a bits, pero por simplicidad y tiempo se decidió una trama donde la unidad mínima sea el byte. decisión, el paquete de dimensiones, el paquete de límites, el paquete de navegación, el paquete de predicción y el paquete de sensado. En la capa strategy están las clases utilizadas para lograr una estrategia. Algunas particularidades que puede tener este módulo es crear una superclase que contenga la detección de modos de juego para las subclases que representen estrategias del equipo. En la figura 3 puede verse un diagrama de paquetes del proyecto. cientic.mora cientic.mora.core cientic.mora.core.net cientic.mora.modules d GameState d N°Robots d Home 0 Home Position d Rotation d Opp. Position d Rotation Position Vel.Left 0 X d Vel.Right 0 d d Y d Vel.Left N d Home N d Vel.Left Opp 0 d Opp N d Curr.Ball d LastBall cientic.mora.modules.decision cientic.mora.modules.dimension cientic.mora.modules.limits cientic.mora.modules.navigation cientic.mora.modules.sense cientic.mora.strategy cientic.mora.strategy.bounds cientic.mora.strategy.heuristic cientic.mora.strategy.heuristic.behaviour cientic.mora.strategy.heuristic.mode cientic.mora.util Team cientic.mora.core.model cientic.mora.core.util.pattern Figura 3. Diagrama de paquetes. d Vel.Right Z d Vel.Right N Figura 2. Trama de comunicación ida y vuelta. La capa modules tiene las clases que sirven de soporte a la estrategia. Algunos paquetes que contiene esta capa son el paquete de V. Estrategia Uno de los inconvenientes de las versiones anteriores de morasot era que el diseño de la estrategia se volvía inmanejable a medida que crecía sus funcionalidades. La nueva estrategia, pensada originalmente por Germán Viscuso, fue diseñada para que sea fácil su modificación a medida que el equipo fuera creciendo. El concepto es crear comportamientos representados por clases. CAFR2005 Estos comportamientos se activan si las condiciones del robot y su ambiente son propicias. A cada robot se le asigna estos comportamientos para que los desarrolle durante el juego. A mayor cantidad de comportamientos asignados a un robot, mayor inteligencia de juego tendrá. No existe un organizador del juego, cada robot toma sus propias decisiones de acuerdo a las condiciones del juego en un instante dado. Puede ocurrir que dos o más comportamientos puedan ejecutarse en un instante. En ese caso se pueden tomar varias decisiones para saber que comportamiento prevalecerá. Una de ellas es la selección aleatoria, otra es la asignación por prioridades. En un diseño ideal esto trae una ventaja significativa en el desarrollo del equipo, ya que se puede aumentar o no la inteligencia del robot, se puede cambiar comportamientos por otros. Esta forma de programación permite tener un archivo de configuración donde se definen que comportamientos deberían aplicarse o no durante el transcurso de un partido. Esto es una ventaja competitiva debido a que se puede analizar la situación del partido y cambiar comportamientos que puedan perjudicar la estrategia. VI. Sensado El equipo cuenta con un conjunto de funciones que permiten el sensado de objetos en el campo de juego. El concepto es establecer un punto de referencia (en este caso un robot) y aplicar la función de sensado. Hay varias funciones de sensado. En la figura 4 puede verse como un robot detecta un objeto en su trayectoria hacia un punto dado. Esta forma de sensar puede servir para detectar una trayectoria limpia hacia la pelota. Esto es una condición que debe cumplirse para que el robot pueda aplicar un comportamiento. Figura 4. Trayectoria libra hacia la pelota. Otra forma de sensado es creando un área de visión dada por dos rectas y un círculo. La figura 5 muestra un ejemplo de como un robot detecta si un robot oponente tiene marca personal. Esta forma de sensado ayuda para saber si un robot debe aplicar el comportamiento de marca personal. Figura 5. Detectar si un robot tiene marca. Por último existe la función de sensado global que detecta que objetos (robots) se encuentra alrededor de un punto dado (robot). Se puede definir la cantidad de subdivisiones que sean necesarias para conocer la posición de otros robots y en consecuencia poder tomar decisiones. La figura 6 muestra un ejemplo de sensado alrededor del robot. Figura 6. Sensado global de un robot. CAFR2005 VII. Navegación El sistema de navegación de morasot III es el mismo que se ha implementado en la versión II de morasot que fue desarrollado en conjunto con Germán Viscuso. Está basado en el paper presentado por [Bowling/Veloso, 2000]. Este sistema de navegación permite que un robot se dirija a un punto, que se dirija a un punto con en un ángulo dado y puede evadir objetos. Algunas funcionalidades extendidas a este sistema fue la navegación bidiferencial y la suavización del zigzageo. En el framework se declaró las interfaces que todos los sistemas de navegación que se implementen deben respetar. Esto permite que se pueda cambiar la navegación en una estrategia sin afectar las clases que modifican la navegación del robot. Esto se debe a que estos métodos esperan un objeto que ya tenga la implementación de la navegación. Al momento se están estudiando otros dos papers para implementarlos en la versión IV y así obtener otras opciones de navegación ([Webers/Zimmer, 2002], [Han/Ho/Hwan, 2002]) que nuestro equipo obtiene el estado actual, sólo que desfasado en el tiempo (ambientes del pasado o ambientes del futuro). De esta forma obtenemos la capacidad de retrospección y predicción (manejo temporal). Una mejora de la funcionalidad de predicción en esta versión del equipo era predecir la pelota cuando rebotaba en los laterales del campo de juego. Una funcionalidad para versiones posteriores es predecir el rebote de la pelota contra otros robots. La figura 7 muestra una imagen del depurador Simora mostrando la predicción de la pelota en diferentes instantes de tiempo. Figura 7. Predicción de la pelota con rebote. VIII. Predicción y retrospección. IX. Delimitación del campo de juego Las funciones de retrospección se utilizan para que los jugadores puedan tomar decisiones basados en jugadas pasadas. Las de predicción se utilizan para que los jugadores puedan anticiparse a los sucesos del juego y jugar teniendo en cuenta hechos que podrían suceder a corto plazo. Para ofrecer a nuestro equipo más información que la que nos provee el servidor en un momento dado, implementamos dos funcionalidades: la recuperación de estados anteriores de juego (retrospección) y la predicción de estados futuros. En ambos casos la información se provee como ambientes, de la misma forma en La delimitación del campo de juego se programa tanto en el capa modules como en la capa strategy. La capa modules contiene el submódulo limits donde están las clases que resuelven la matemática para los límites. Hasta el momento hay dos tipos de delimitación, uno delimita cuadrados y el otro delimita cuadrados irregulares. Ambos comparten una interfaz común que se utiliza para desarrollar en forma genérica. La figura 8 muestra la delimitación de un cuadrado irregular. CAFR2005 FIELD_TOP GL4 PL4 DL4 MDL4 ML4 OML4 OMDL4 ODL4 OPL4 OGL4 GL3 PL3 DL3 MDL3 ML3 OML3 OMDL3 ODL3 OPL3 OGL3 GL2 PL2 DL2 MDL2 ML2 OML2 OMDL2 ODL2 OPL2 OGL2 GL1 PL1 DL1 MDL1 ML1 OML1 OMDL1 ODL1 OPL1 OGL1 GR1 PR1 DR1 MDR1 MR1 OMR1 OMDR1 ODR1 OPR1 OGR1 FREEBALL_TOP PENALTY_TOP GOAL_TOP MIDDLE_FIELD_Y GOAL_BOT GR2 PR2 DR2 MDR2 MR2 OMR2 OMDR2 ODR2 OPR2 OGR2 GR3 PR3 DR3 MDR3 MR3 OMR3 OMDR3 ODR3 OPR3 OGR3 GR4 PR4 DR4 MDR4 MR4 OMR4 OMDR4 ODR4 OPR4 OGR4 PENALTY_BOT FREEBALL_BOT GOAL_RIGHT Figura 9. Sectores del campo de juego. FIELD_RIGHT FREEBAL_RIGHT FIELD_BOT PENALTY_KICK_RIGHT PENALTY_RIGHT Las líneas cruzadas permiten obtener el punto medio del área que es un método de la interfaz. En caso de querer hacer una delimitación con un círculo se debería definir un método que devuelva el centro del círculo. Otro submódulo de la capa modules es el denominado bounds que es el que realmente esconde el lado donde juega el equipo. Las clases dentro de este submódulo deben implementar los métodos de la interfaz de dimensiones. Esta interfaz tiene métodos como 'devolver límite del área penal oponente', 'devolver límite del costado izquierdo del campo de juego'. Entonces, si se quiere adaptar la estrategia a un simulador de RoboCup hay que crear una clase que implemente esta interfaz y definir los métodos para que devuelva el valor correcto dependiendo el lado donde se encuentra el equipo y las constantes de posición del simulador. Es aquí donde se pregunta por el lado del equipo. Si durante el desarrollo del equipo se pregunta por el lado del equipo fuera de estas clases, entonces algo mal se está haciendo y hay que rediseñar lo que se estaba programando. Esto es uno de los conceptos que hay que respetar para programar dentro de una metodología. Hasta el momento solo se habló de las clases que sirven como soporte a la estrategia MIDDLEDEF_RIGHT Figura 8. Delimitación irregular. MIDDLE_FIELD_X x MIDDLEDEF_LEFT p 3 FREEBAL_LEFT p 2 PENALTY_LEFT PENALTY_KICK_LEFT p 1 GOAL_LEFT p 0 en lo que delimitación se trata. Ahora es momento de decidir como delimitar el campo de juego con estas funcionalidades y que sirva para cualquier simulador. Dentro del módulo strategy hay una clase que contiene los sectores del campo de juego para SimuroSot. Esta clase utiliza un objeto que implementa la interfaz de dimensiones. Si se quiere adaptar esta clase para que también represente los sectores de un simulador de RoboCup, el único cambio es reemplazar el objeto de dimensiones quedando sin modificaciones la implementación de la clase. La figura 6 presenta un ejemplo de esta delimitación. FIELD_LEFT y CAFR2005 X. Simora Uno de los desarrollos paralelos a este equipo fue el software Simora, que nació con la intención de crear un simulador. Las limitaciones de conocimientos sobre el comportamiento físico de los objetos que componen un simulador derivó en un programa que permita depurar partidas de fútbol de robots. Este depurador no solamente permite ver partidas en diferido, sino también partidas en tiempo real, aunque disminuyendo el rendimiento de la partida. Un diseño interesante en el proyecto morasot es la aplicación del patrón Observer. El objeto observado es la conexión y los observadores son los objetos que están interesados en la llegada de nuevos ambientes. Cuando un ambiente nuevo llega, el objeto observado notifica a todos sus observadores. Hasta el momento hay tres observadores: a) la clase History, que tiene la información necesaria para la retrospección, b) la clase Strategy, que contiene la estrategia a ejecutar y c) Simora. El framework del depurador está pensado para que se pueda adaptar a diferentes tipos de simuladores. Se pueden cambiar las dimensiones del campo de juego, se pueden agregar o quitar robots, o se puede agregar áreas. Un ejemplo de esto puede verse en la figura 7 donde se añaden al simulador cinco objetos gráficos que representan la predicción de la pelota en el tiempo. La figura 10 muestra una parte del diseño de Simora con un diagrama de clases donde un objeto visual es el encargado de contener todos los objetos visuales del depurador. Ante la llegada de un nuevo ambiente se actualizan los nuevos valores y un objeto MoraField es el encargado de redibujar todos los objetos añadidos a su colección. MoraField MoraObject moraCollections: ArrayList MoraRobo t rotation : double square : Rectangle2D arrow : Line2D x : double y : double width : double height : double color : Color MoraBall MoraBounds ellipse : Ellipse2D bounds : Rectangle2D MoraTeamRobot velocityLabel : JLabel Figura 10. Diagrama de clases de los objetos visuales mora. Una característica adicional del depurador, es que los objetos visuales pueden dibujarse a una escala arbitraria. La figura 11 presenta el depurador en funcionamiento. Faltan más componentes visuales para lograr que sea más atractivo y útil, pero el tiempo en fútbol de robots es tirano ;) Figura 11. Imagen del depurador Simora. CAFR2005 XI. Conclusiones Referencias A pesar de ser un desarrollo nuevo del equipo, las ideas no lo son. Este es un equipo que fue diseñado en base a las experiencias positivas y negativas de las otras dos versiones. Uno de los errores que he cometido en el desarrollo de la versión II de morasot fue diseñar un equipo para que le gane a otro equipo. A pesar de que era un equipo superior a la versión I, se demostró durante el campeonato las debilidades del mismo ante equipos que planteaban estrategias innovadoras. La versión III de morasot es un intento de programar un equipo que pueda adaptarse y superar diferentes estrategias planteadas por equipos oponentes. Un paso importante en este equipo es la continuidad en la línea de desarrollo para el próximo torneo. Esto supera el inconveniente de las versiones I y II que fueron dejadas de lado por que su diseño no permitía un crecimiento de la estrategia en forma clara. Mi objetivo de participar en esta clase de torneos es poder interactuar con personas dedicadas a la docencia e investigación. Estas vivencias han logrado mejorar mi rendimiento en otras áreas. Mi mayor anhelo es que esta sociedad entienda la importancia de contar con científicos que con sus descubrimientos permiten el desarrollo de un país. [Bowling/Veloso, 2000] Michael Bowling y Manuela Veloso, “Motion Control in Dynamic Multi-Robot Environments”, 2000. [Webers/Zimmer, 2002] Christfried Webers & Uwe R. Zimmer, “Motion Control of Mobile Robots - from static targets to fast drives in moving crowds ”, Autonomous Robots, Vol. 12, No. 3, 2002. [Han/Ho/Hwan, 2002] Dong-Han Kim, Jae-Ho Park y Jong-Hwan Kim, “Limit-cycle Navigation Method for Soccer Robot”, Robotics and Autonomous Systems, 42, 2003, p. 17-30 [FIRA, 2005] Sitio oficial de la FIFA, http://www.fira.net [RoboCup, 2005] Sitio oficial de la RoboCup, http://www.robocup.net Equipo de Fútbol de Robots UTNfrba Maximiliano L. Muzzio* Leandro M. Di Matteo** Andrea C. Mangone *** Universidad Tecnológica Nacional Facultad Regional Buenos Aires Grupo de Inteligencia Artificial Medrano 951, Ciudad Autónoma de Buenos Aires, Argentina. [email protected] * [email protected] ** [email protected] *** Resumen: En este trabajo se describe el funcionamiento del equipo de fútbol de robots UTNfrba. El equipo consta de cinco jugadores y un director técnico virtual, cada uno de ellos es un agente independiente y se comunican entre sí a través de una plataforma en tiempo real, contando la misma con un sistema de mensajería, semáforos, etc. Cada jugador hace uso de diversas habilidades y herramientas, como control de trayectoria, planificación de rutas, predicción de los movimientos del entorno, etc. El director técnico virtual se encarga de dirigir el equipo, indica la realización de tácticas y controla el correcto armado de la formación del equipo a través de un motor de lógica difusa. Palabras Clave: Fútbol de robots, robótica cooperativa, cafr, fira, sistemas multiagente, lógica difusa. Abstract: In this work it is described the features of the UTNfrba robot soccer team. The team have five players and one virtual coach, each one of them is an independent agent and they communicate themselves through a real time platform, that has a message system, semaphores, etc. Each player has different abilities and tools, as trajectory control, route planning, prediction of environment movements, etc. The virtual coach aim is to manage the team tactical strategies and controls the adequate team positioning throught a fuzzy logic engine. Keywords: Robot soccer, cooperative robotics, cafr, fira, multiagent systems, fuzzy logic. RESEÑA [Castelo et. al., 2002] El fútbol de robots provee un campo de testeo para sistemas de múltiples robots autónomos que, a través de una tarea común como el juego de fútbol, estimula la investigación de problemas que involucran robots moviéndose rápidamente y cooperando entre sí para cumplir objetivos específicos en entornos dinámicos y bajo situaciones adversas. En la actualidad existen diversas competencias de fútbol con robots. 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. La formación de un equipo capaz de competir en alguno de los certámenes de fútbol de robots presupone integrar desarrollos sobre distintos comportamientos tales como rastreo de agentes y de la pelota, movilización hacia un objetivo determinado, habilidad para llevar la pelota a través de un recorrido, evitar obstáculos móviles, patear la pelota al arco, realizar un pase a otro compañero, ubicarse dentro del campo de juego, evaluar su posición con respecto a sus compañeros y oponentes, interceptar la pelota en movimiento, compartir una estrategia de equipo y reaccionar ante estímulos externos. También supone trabajar sobre áreas como robótica para diseñar robots capaces de aprender y realizar estos comportamientos, procesamiento de imágenes para poder brindar a los robots un estado actual del escenario, procesamiento en tiempo real para poder responder a los estímulos recibidos, y lenguajes de comunicación entre los robots. [Castelo et. al., 2002]. I. INTRODUCCIÓN El grupo humano está compuesto por un equipo multidisciplinario formado por ingenieros y estudiantes de ingeniería de distintas carreras esponsorizados por la UTN Facultad Regional Buenos Aires. El ser un grupo heterogéneo desde el punto de vista de la formación profesional permitió plantear soluciones a los problemas que fueron surgiendo desde perspectivas distintas y de esta forma encontrar la mejor solución para cada uno. El equipo consta de cinco jugadores robots y un director técnico virtual. Cada jugador hace uso de diferentes habilidades y herramientas para desempeñarse en el campo de juego. Dado que el fútbol de robots se desarrolla en un ambiente altamente dinámico es necesario predecir con antelación la ocurrencia de determinados eventos, es por ello que utilizamos distintos sistemas de predicción. Durante el partido ocurren diferentes situaciones, como faltas por ejemplo, que llevan a determinadas jugadas con pelota detenida, lo cual implica que se deben realizar diversas estrategias de control para cada caso. La función del director técnico virtual es la de manejar el equipo. Éste asigna roles (arquero, defensor o delantero) para cada jugador según su posición en el campo de juego. Además lleva el control de una adecuada formación dependiendo del estado del partido, ayudado por un motor de lógica difusa. A continuación se explica en detalle el funcionamiento de cada subsistema del equipo de fútbol de robots. Para alcanzar un mayor nivel de entendimiento de lo aquí expuesto es importante conocer el reglamento de juego, el cual puede obtenerse de los web sites mencionados en las referencias. II. HABILIDADES Y HERRAMIENTAS Las habilidades y herramientas descriptas a continuación le brindan una correcta motricidad a los robots. a. Control diferencial de motores El sistema de tracción está compuesto por dos ruedas a las cuales se les puede fijar la velocidad en forma independiente. Para calcular la velocidad de las ruedas se pasa del sistema diferencial a uno de tracción y timón y luego se vuelve al sistema diferencial. Para esto se calcula la velocidad de avance deseada, la cual será la misma para cada rueda (VD) y luego se le suma la velocidad diferencial (VG) que nos dará el giro del robot. El resultado de esta “suma” se aplica a las ruedas. El control de velocidad de las ruedas tiene dos modos de funcionamiento: el funcionamiento con posicionamiento y sin posicionamiento. Con posicionamiento: En este modo lo que se busca es que el robot quede en punto determinado con un ángulo de rotación determinado en el mínimo tiempo. Para que el desplazamiento del robot sea lo más rápido posible se intentó aprovechar al máximo la capacidad de “frenado“ que tiene el robot poniendo en contra marcha sus ruedas y de esta forma compensar la inercia del mismo. Para el control de velocidad de traslación se evaluó mediante pruebas la capacidad máxima de frenado que posee el robot haciendo girar sus ruedas al 100% de su velocidad durante un tiempo determinado en el cual el robot alcanza su velocidad de traslación máxima. En ese momento se pusieron ambas ruedas en contramarcha y se midió la distancia que recorrió hasta que comenzara a desplazarse en sentido contrario. De esta forma, se obtuvo la velocidad máxima a la que podía desplazarse el robot en función de la distancia al punto objetivo para que al aplicar los frenos se detenga sobre éste. Finalmente, la velocidad que se le entrega a cada rueda será la necesaria para que el robot alcance la velocidad máxima permitida. Si por algún motivo la velocidad de traslación del robot supera la velocidad máxima, se aplica el frenado de manera proporcional al exceso de velocidad que tenga. Para la velocidad de rotación el principio aplicado es el mismo, la única diferencia es que las velocidades evaluadas son angulares. Sin posicionamiento: Este modo se utiliza básicamente para empujar la pelota, la diferencia con el modo anterior es que la velocidad de traslación es siempre del 100% y el ajuste de ángulo es sólo para corregir la trayectoria del desplazamiento. Para ganar más velocidad en el desplazamiento del robot se modificó el algoritmo para que el robot pueda desplazarse “marcha atrás” y de esta forma el ángulo máximo que gira es de 90°. b. Planificador de rutas Es un algoritmo que le permite al robot desplazarse desde su actual posición hasta una posición destino sorteando los obstáculos presentes en el entorno, en este caso los robots. Esto ayuda a alcanzar la posición deseada sin chocarse contra otros robots ni quedar trabado con ellos, tratando de evitar cometer faltas. Además, permite llegar a la coordenada objetivo con un determinado ángulo de entrada. El funcionamiento de este algoritmo está descrito en detalle en “Route planning for vehicle autonomous navigation, based on geometrical regions. Part I: Single approach point” [Di Matteo et. al. , 2004]. c. Control de trayectoria Esta función le permite al robot ir desde su posición actual hasta la posición destino a través de una trayectoria prefijada, donde la misma se representa por una línea imaginaria que pasa por el punto destino y su pendiente o ángulo es un parámetro de entrada. Por lo general se trata que los delanteros envistan la pelota en una dirección que apunte al centro del arco contrario, y para los defensores, que esta dirección sea 45 grados hacia fuera, con el objetivo de rechazar la pelota. Cuando el robot no se encuentra sobre la trayectoria fijada, se pretende que éste alcance la trayectoria en forma suave y exponencial, Fig. 1. * * alfa * * * * Figura 1. Acercamiento del robot a la pelota empleando el Control de Trayectoria. d. Corrección del entorno Es una herramienta que tiene dos objetivos: - invierte las coordenadas del entorno cuando nuestro equipo juega del lado derecho del campo de juego (campo de juego horizontal) y mantiene las mismas cuando juega del lado izquierdo. Esto nos permite realizar todos los algoritmos pensando en jugar desde el lado izquierdo y simplifica la depuración. La inversión de coordenadas se realiza en forma dinámica y se determina según la posición del arquero en el saque inicial. - además genera un nuevo set de “game state” corrigiendo el que entrega el simulador [Silveira et. al., 2003]. III. SISTEMAS DE PREDICCIÓN Estos sistemas ayudan a la navegación de los robots, optimizando trayectorias y puntos de encuentro con la pelota, previendo choques entre robots. Estos sistemas se describen a continuación. a. Predicción de la pelota 1. La predicción de la posición siguiente de la pelota se obtiene sumando el delta de desplazamiento en x y en y entre el ciclo anterior y el actual a la posición actual de la pelota. Es decir: ∆x = x n − x n −1 ∆y = y n − y n −1 x n +1 = x n + ∆x y n +1 = y n + ∆y b. Predicción de la pelota 2. Esta predicción se utiliza para la rutina del arquero y lo que busca es encontrar la coordenada y en la que la pelota deberá ser interceptada por el arquero para que éste anticipe su desplazamiento. La obtención de esta coordenada es similar a la explicada en el punto anterior. La diferencia es que el ∆y se suma varias veces. La cantidad de veces que se suma el ∆y es variable para que el arquero quede descolocado ante un cambio de trayectoria, depende de por ejemplo el sentido de desplazamiento de la pelota, la distancia de la misma al arco, el tiempo que va a tardar en llegar al arco, etc. c. Predicción de intersección de la pelota Esta rutina consiste básicamente obtener el punto de intersección entre pelota y el jugador, las variables que se utilizan para ello son la trayectoria de la pelota y su velocidad y la velocidad de desplazamiento del jugador. Para ello lo que se hace es buscar la intersección ente un punto que se desplaza por una recta a una velocidad dada (desplazamiento de la pelota) y un círculo cuyo radio crece con otra velocidad (desplazamiento del jugador) en un mismo tiempo. Punto de intersección t=3 Pelota pos actual Jugador pos actual Figura 2. Esquema de cálculo de la intersección con la pelota Se utilizan las siguientes ecuaciones paramétricas x = a ⋅ t + x0 r: (1) y = b ⋅ t + y0 { Robot : ( x − xr ) 2 + ( y − yr ) 2 = ( vRobot ⋅ t ) 2 (2) d. Predicción del entorno Se realiza una predicción lineal de las próximas posiciones de los robots. A esto hay que agregar que cuanto mas lejos está el obstáculo se predice con mayor antelación. e. Límites del terreno de juego La rutina de límites no sólo contempla los límites del terreno de juego sino que también limita el ingreso de los jugadores a las áreas o los hace salir dependiendo de la cantidad que ya hay dentro de las mismas y de la cercanía del jugador a la pelota, es decir, si el jugador defensor que está más cerca de la pelota debe entrar por ejemplo al área grande y en ésta ya hay dos jugadores defensores y el arquero, se le ordena al jugador más lejano a la pelota que salga. IV. JUGADAS CON PELOTA PARADA Para las jugadas que contemplan situaciones con pelota parada, establecimos las siguientes estrategias: a. Saque de arco El arquero sale jugando con la pelota y es relevado por un compañero. b. Pique El jugador más cercano a la pelota se dirige directamente a ella, y tres jugadores más se posicionan cerca del área de juego, formando una línea en diagonal donde el jugador del medio se encuentra en la misma línea vertical que el jugador principal. Notar que en las figuras donde se muestran estrategias de juego, los cuadrados grises representan los robots de nuestro equipo y los cuadros grises oscuros y rayados representan los robots del equipo contrario, y el punto más notorio representa a la pelota. * * * * x x x * Figura 3. Reacción de los jugadores ante un pique c. Tiro libre En contra: Los jugadores se posicionan como se muestra en la Fig. 4 y cuando se ejecuta el comienzo de la jugada, los dos jugadores más cercanos se aproximan delante de la pelota, y los dos jugadores más alejados retroceden en línea horizontal acercándose a la línea de fondo. * * x x x * * x * * Figura 4. Reacción de los jugadores ante un tiro libre en contra A favor: Los jugadores se posicionan como se muestra en la Fig. 5 y una vez que comienza la jugada, los tres jugadores posicionados detrás del jugador que ejecuta el tiro libre se aproximan a él. * * x x * * x * * Figura 5. Reacción de los jugadores ante un tiro libre a favor d. Penal En contra: Para el caso de un penal a favor del equipo contrario, los jugadores se posicionan según Fig. 6 y una vez que comienza la jugada, avanzan hacia las posiciones marcadas en la figura mencionada. * * x x * * x * * Figura 6. Reacción de los jugadores ante un penal en contra A favor: Para ejecutar un penal, los jugadores se posicionan según Fig. 7 y una vez que comienza la jugada, el jugador que se encuentra frente a la pelota, avanza hacia el arco mientras que los tres jugadores que se encuentran detrás de él, se acercan al mismo. * * x x * * x * * Figura 7. Reacción de los jugadores ante un penal a favor El jugador pateador realiza la siguiente secuencia de desplazamiento: Figura 8. Reacción de los jugadores al ejecutar un penal o tiro libre. e. Saque del medio Se posiciona un jugador detrás de la pelota apuntando hacia nuestro campo de juego y al comenzar la jugada arrastra la pelota hacia el jugador más cercano. * * * * * * Figura 9. Reacción de los jugadores al sacar del medio V. PLATAFORMA EN TIEMPO REAL Y SISTEMA DE MENSAJERÍA Se desarrolló una plataforma diseñada para trabajar con “threads” donde los robots y rutinas auxiliares son tareas independientes que corren en forma paralela y se comunican entre sí por medio de mensajes, semáforos, etc. Actualmente la ejecución de las rutinas es secuencial, la funcionalidad multitarea será incorporada más adelante. Se puede disponer de funciones como “inicializarSistemaDeMensajería”, “EnviarMensaje”, “LeerBuzónDeMensajes”, etc. La topología de comunicación puede observarse en la Fig. 10. J1 J2 . . . MAILBOX JN DT ANALIZADOR DE PRIORIDADES Figura 10. Representación esquemática del sistema de mensajería VI. ROLES a. Arquero El objetivo principal del arquero es evitar que la pelota ingrese al arco. Para esto, evalúa la situación y toma distintas actitudes, como por ejemplo: • ir al “y” de intersección pero manteniendo el “x” actual • ir a la pelota • salir jugando • girar en el lugar • alejarse de la pelota e ingresar al arco para tratar de sacarla (en el caso de que la pelota lo haya superado). Como algunas situaciones pueden generar varias respuestas, éstas están priorizadas de manera tal que sólo se obtiene una respuesta por parte del arquero. b. Defensor El jugador cuando tiene asignado el rol de defensor toma distintas actitudes de acuerdo a la cercanía que tiene a la pelota con respecto a los demás jugadores, la posición de la misma en el campo de juego y con respecto a él. Estas actitudes se pueden dividir en dos grandes grupos: Actitudes de defensa activas: En las que el jugador va directamente a la pelota o con planificador Actitudes de defensa pasiva: En las que el jugador no va a la pelota sino que lo que hace es cubrir posiciones estratégicas como por ejemplo posicionarse en la línea que une la pelota con el centro del arco para interceptarla en el caso de que ésta tome una trayectoria que pudiera terminar en gol. c. Delantero Al igual que el defensor, su comportamiento se determinará por la cercanía del mismo a la pelota con respecto a los demás integrantes del equipo. También en este caso podemos dividir las actitudes en dos grupos: Activas: En las que el jugador empuja la pelota o la “golpea” tratando de introducirla en el arco contrario. Pasivas: En las que el jugador acompaña al que lleva la pelota o se ubica en puntos estratégicos para aumentar la efectividad del ataque. VII. DIRECTOR TÉCNICO VIRTUAL Se encarga de manejar el funcionamiento global del equipo y generar un trabajo cooperativo entre robots. Para ello se cuenta con una asignación dinámica de los roles y un conjunto de directivas para mantener la formación de juego. Además, dispara órdenes a los jugadores para lograr trabajos cooperativos. a. Asignación dinámica de roles Hemos dividido el campo de juego en tres partes, Fig. 11. La asignación dinámica de roles sigue la siguiente lógica: - primero se inicializan a todos los jugadores como defensores. - luego se asigna a los dos jugadores más adelantados el rol de delantero. - posteriormente se aplican reglas imperativas, donde si el jugador se encuentra en la zona A es defensor, sin importar lo indicado anteriormente. - paralelamente si el jugador se encuentra en la zona C, se le asigna el rol de delantero. * * * * A B C * * Figura 11. Zonas utilizadas para la asignación dinámica de roles b. Control de la formación Se dispone de cinco formaciones de juego, Fig. 12 a 16. Además, cada formación posee tres formas de posicionarse en el campo de juego, atrasada, media o adelantada, conformado entonces un total de 15 posibles modos de posicionamiento. La formación a utilizar en cada instante la determina el director técnico ayudado por el motor de lógica difusa, el cual se explica más adelante. Para mantener la formación, cuando hay jugadores alejados de un determinado radio de jugada que no están cumpliendo ninguna función, el director técnico virtual les envía comandos para que cubran las posiciones libres. * * * * * * Figura 12. Formación 0x4 * * * * * * Figura 13. Formación 1x3 * * * * * * Figura 14. Formación 2x2 * * * * * * Figura 15. Formación 3x1 * * * * * * Figura 16. Formación 4x0 c. Disparo de órdenes a los jugadores Existen distintos comandos que viajan a través del sistema de mensajería, que pueden ir desde el director técnico a los jugadores y viceversa o entre jugadores. En la actualidad poseemos los siguientes comandos: - Ir a determinada posición - Ir a la jugada - Ayudar a quien está trabado con la pelota - Ir a esperar un posible centro - Cambio de arquero - Mensajes relacionados a las jugadas con pelota detenida VIII. ESTADÍSTICAS DE JUEGO El módulo de estadísticas calcula porcentajes de ocupación de campo según la posición de la pelota, dividiendo el campo en tres zonas (Fig. 17). También calcula el tiempo de juego total en segundos y el resultado del partido. Para conocer el resultado del partido, se observa la posición en “x” de la pelota, para saber si entró o no a alguno de los arcos. Luego, esta situación se valida siempre y cuando posteriormente se realice un saque desde el medio. * Campo * Local * Campo Central * Campo * Visitante * Figura 17. Zonas del campo de juego tomadas para el cálculo de ocupación de campo IX. MOTOR DE LÓGICA DIFUSA PARA CONTROL DE FORMACIÓN El módulo de lógica difusa le permite al director técnico tomar la decisión sobre la formación conveniente a utilizar. La lógica difusa es un sistema basado en reglas heurísticas. En nuestro caso, el resultado de estas reglas se basan en la experiencia humana. Un algoritmo de lógica difusa se basa principalmente en tres módulos: módulo de fuzzificación, módulo de análisis de reglas y módulo de desfuzzificación. Para el módulo de fuzzificación se necesita una serie de conjuntos de entrada a evaluar. Como conjunto de entrada utilizamos el tiempo de juego, la diferencia de goles del partido y el porcentaje de ocupación de campo en el último minuto de juego (Fig. 18, 19 y 20). Tiempo de juego Muy Poco 0 Poco 150 180 Intermedio 210 240 Alto 330 360 Muy Alto 390 420 600 seg Figura 18. Lógica difusa. Conjunto de entrada “Tiempo de juego” Diferencia de goles Muy Malo Malo -4 -3 Normal -1 0 Bueno 1 2 Muy Bueno 3 4 Figura 19. Lógica difusa. Conjunto de entrada “Diferencia de goles” Porcentaje ocupación de cancha Nuestro Campo En el medio Campo Contrario Figura 20. Lógica difusa. Conjunto de entrada “Porcentaje de ocupación de campo” El módulo de análisis de reglas consta de un set de 75 reglas basadas en la experiencia de un ser humano. Los sets de 75 reglas pueden ampliarse indefinidamente para volcar al director técnico la experiencia de varias personas a la vez. Estas reglas pueden ser: Si (Diferencia de Goles = MuyMalo) Y (Tiempo = MuyPoco) Y (Porcentaje Ocupación = NuestroCampo) ENTONCES Formación = 3x1; Posición = Adelantado; Si (Diferencia de Goles = Malo) Y (Tiempo = MuyPoco) Y (Porcentaje Ocupación = NuestroCampo) ENTONCES Formación = 2x2; Posición = Adelantado; Como los conjuntos de entrada poseen zonas de intersección, pueden darse una o varias reglas a la vez. Por lo tanto, se pueden activar varios conjuntos de salida a la vez (Fig. 20 y 21). El resultado final para evaluar la formación y posición lo hacemos calculando el centro de masa entre los resultados de las distintas reglas disparadas, lo que se conoce como proceso de desfuzzificación. Formaciones 4x0 3x1 2x2 1x3 0x4 Figura 20. Lógica difusa. Conjunto de salida “Formaciones” Posición Atrás En el medio Adelantado Figura 21. Lógica difusa. Conjunto de salida “Posicionamiento” X. FUTUROS DESARROLLOS A las actuales características del equipo se le adicionarán en forma paulatina los siguientes módulos: - Jugadas preparadas ordenadas por el director técnico virtual y luego coordinadas en forma cooperativa entre los jugadores empleando el sistema de tiempo real y de mensajería. - Red neuronal para poder interpretar la posibilidad de realizar diversas jugadas preparadas. - Se adicionará al control motriz, correcciones por lógica difusa optimizada con algoritmos genéticos. - Se analizará la implementación de técnicas alternativas para la planificación de rutas, como por ejemplo, potenciales de campo. XI. APLICACIONES DE LA TECNOLOGÍA EMPLEADA EN FÚTBOL DE ROBOTS Si bien el fútbol de robots atrae a las masas debido a su atractivo y su relación con uno de los deportes más reconocido en el mundo, no es sólo un juego. Esta actividad, incentivada por los diversos torneos y workshops, genera una tecnología con aplicaciones tangibles en el campo de la robótica y tecnologías vehiculares. De aquí se desprenden nuevos modelos de control para accionamiento de motores de corriente continua, también impulsa el diseño de técnicas innovadoras para la navegación autónoma de vehículos no tripulados, tanto en ambientes estructurados o dinámicos. En el caso de ambientes altamente dinámicos, se aplican diversas técnicas de predicción del entorno, como predictores de Kalman por ejemplo, y se fomenta la generación de nuevas técnicas de predicción basadas en heurística. Además de los importantes aportes mencionados, falta resaltar el más importante, el cual es un tema donde actualmente se centra la atención en el ámbito mundial, “la robótica cooperativa”. En los sistemas cooperativos de robots, no sólo se deben comandar los robots en forma aislada, sino que por el contrario, se debe coordinar el accionar de múltiples robots con un objetivo común. De allí resultan aplicaciones como el control de formaciones de vehículos no tripulados, almacenes inteligentes los cuales son muy útiles en la industria, transporte de cargas de gran dimensión, etc. XII. AGRADECIMIENTOS Contamos con la especial colaboración y el apoyo del director del Grupo de Investigación de Inteligencia Artificial de UTN FRBA, Ing. Claudio Verrastro, agradecemos profundamente sus importantes opiniones, aportes y revisiones del proyecto. Agradecemos también al Grupo de Inteligencia Artificial de UTN FRBA por brindar sus computadoras para el testeo de equipos. XIII. CONCLUSIONES Esta fue nuestra primera experiencia en el desarrollo de equipos de fútbol de robots, si bien cada uno de los integrantes del equipo se desenvuelve en tareas de robótica y/o desarrollo de software, esta actividad nos permitió implementar técnicas de control para sistemas de robots en tiempo real. REFERENCIAS [Alberino et. al., 2003] Alberino S., Folino P. and Verrastro C. “Variante en el algoritmo PID para evitar el uso de un generador de trayectoria trapezoidal ” X RPIC Proceedings, San Nicolás, Bs. As., 659-663 (2003). [Castelo et. al., 2002] Castelo, Claudia; Fassi, Hector; Scarpettini Flavio. “Fútbol de Robots: Revisión del Estado del Arte y Desarrollo del Equipo UBASot de Simulación”. Tesis de Licenciatura. Facultad de Ciencias Exactas y Naturales, Universidad de Bs. As. 2002. [Claro et. al., 2003] Claro, Martín; Gazolli, Andrés, Potenza, Aníbal; Viscuso, Germán; Ierache, Jorge. “El equipo MoraSot”. Campeonato Argentino de Fútbol de Robots CAFR2003, Bs. As., Argentina, 2003. [Di Matteo et. al., 2004] Di Matteo, Leandro; Mangone, Andrea; Muzzio, Maximiliano; Verrastro, Claudio. “Route Planning for vehicle autonomous navigation, based on geometrical regions. Part I: Single approach point”. VII Congreso Latinoamericano de Robótica. Santa Cruz de la Sierra, Bolivia. 2004. [Fernández et. al., 2003] Fernández, Julio; Greszenswit, Fernando; González, Sergio; Milanese, Ezequiel; Tleye, Sebastián. “Equipo Simul-ARLT: El fútbol de robots como Entorno Educativo”. Campeonato Argentino de Fútbol de Robots CAFR2003, Bs. As., Argentina, 2003. [Fernández León et. al., 2003] Fernández León J.A. y H. N. Acosta, “The INCAsoT Simulated Robot Soccer Team”. Campeonato Argentino de Fútbol de Robots CAFR2003, Bs. As., Argentina, 2003. [Han et. al., 2002] Han, Kuk-Hyun; Lee, Kang-Hee; Moon, Con-Kyoung, Lee, Hoon-Bong; Kim, Joung-Hwan. “Robot Soccer System of SOTY 5 for Middle League MiroSot”. Korea Advanced Institute of Science and Technology (KAIST). Korea. FIRA Robot Congress 2002. [Khatib,1985] Khatib, O. “Real-time obstacle avoidance for manipulators and mobile robots” Proceedings IEEE-ICRA, St. Louis MO, 500-505 (1985). [Latombe , 1991] Latombe, J. C. “Robot Motion Planning”, Kluwer Academic Pub. Boston (1991) [Matsubara et. al.,1996] Matsubara, Hitoshi; Noda, Itsuki; Hiraki, Kazuo. “Learning of Cooperative actions in multi-agent systems: a case study of pass play in soccer”. Electrotechnical Laboratory. AAAI-96 Spring Symposium on Adaptation, Coevolution and Learning in multiagent systems. [Pereiro et. al., 2003] Pereiro F. y Verrastro C. “Sistema de Comando y Navegación para Robot Móvil con Arquitectura Distribuida” X RPIC Proceedings, San Nicolás, Bs. As., 565-569 (2003). [Silveira et. al., 2003] Silveira, Rodrigo; Aguirre, Facundo; Silveira, Javier; Zabala, Gonzalo. “Equipo Schönthal del CAFR 2003”. Campeonato Argentino de Fútbol de Robots CAFR2003, Bs. As., Argentina, 2003. [Veloso et. al., 1998] Veloso, Manuela; Bowling Michel; Achim, sorin; Han, Kwun; Stone Peter. “The CMUnited-98 Champion Small-Robot Team”. Carnegie Mellon University, Pittsburg, PA 15213. 1998. En Web: www.cafr.com.ar www.fira.net www.dc.uba.ar/people/cafr2003 Proxies para la comunicación con el 3D Robot Soccer Simulator Alvaro Castroman1, Ernesto Copello2, Gonzalo Tejera3 1 Instituto de Computación, Facultad de Ingeniería, Universidad de la República, J. Herrera y Reissig 565, Montevideo, Uruguay [email protected] http://www.fing.edu.uy/~pgfutrob 2 Instituto de Computación, Facultad de Ingeniería, Universidad de la República, J. Herrera y Reissig 565, Montevideo, Uruguay [email protected] http://www.fing.edu.uy/~ecopello 3 Instituto de Computación, Facultad de Ingeniería, Universidad de la República, J. Herrera y Reissig 565, Montevideo, Uruguay [email protected] http://www.fing.edu.uy/~gtejera Resumen. En este artículo se presenta se presenta el desarrollo de proxies para el simulador 3D Robot Soccer Simulator v1.4 y v1.5ª, simuladores oficiales de FIRA para la categoría Middle League Simurosot. Estos permiten desarrollar estrategias distribuidas, independizándose de la arquitectura, el sistema operativo y el lenguaje de programación. Por otro lado, permite desarrollar estrategias de tiempo real, lo cual es muy complejo de realizar utilizando las dll y casi nunca tenido en cuenta. 1 Introducción Este documento describe los proxies desarrollados para la comunicación con el 3D Robot Soccer Simulator v1.4 y v1.5a (simuladores oficiales de FIRA para la categoría Middle League Simurosot) [1], equipo amarillo y equipo azul. Así, el principal objetivo es hacer transparente la comunicación con dicho simulador de manera de facilitar la integración del mismo con equipos desarrollados en cualquier otro lenguaje de programación. Si bien no fue el objetivo que enmarco el desarrollo de los proxies, utilizarlos permiten trabajar en tiempo real, algo que con el simulador actual es imposible atacar. 1.1 Trabajos Relacionados Según nuestro conocimiento, no hay trabajos en la bibliografía revisada que brinden los proxies abiertamente como en este trabajo Si existen varios equipos que disponen de sus propios proxies. Al brindar estos proxies se logra estandarización y se elimina la necesidad de desarrollo por parte de otros equipos. También permite discutir sobres las bondades y desventajas de los mismos, y del uso de proxies en general. 1.2 Guía de capítulos En el capítulo 2 se presenta el protocolo, la unidad de datos intercambiada entre los proxies y la configuración por defecto de los equipos. En el capítulo 3 se presenta el formato del archivo de configuración y en el capítulo 4 se describen los archivos desarrollados. En el capítulo 5 se presentan las conclusiones y trabajos futuros. 2 Especificaciones técnicas Protocolo Fig. 1. Especificación del protocolo. En la figura 1 se puede apreciar el protocolo de comunicación (SDL[2]) y en la figura 2 el formato de paquetes que intercambian los proxies. Fig. 2. Estructura de los mensajes. Las señales env y cmds representan el ambiente (Environment) y los comandos (velocidad izquierda y velocidad derecha de cada robot) respectivamente. El primero, por su parte, es enviado por el proxy del lado del simulador que luego, se queda bloqueado esperando recibir los siguientes comandos a setearle a los robots. Esto se hace en cada invocación del simulador al método Strategy(Environment env). Por otro lado, el proxy del lado de la estrategia permanece bloqueado en espera de la recepción del ambiente. Cuando este llega, se calculan los comandos a transmitirles a cada robot (método calcCmds() en la figura anterior) para luego sí enviarlos hacia el otro proxy. El detalle de los campos de los paquetes intercambiados se muestra en las tablas 1 y 2. Tabla 1. Detalle del paquete enviado al ProxyStrategy. Method State whosBall currentBall.x currentBall.y lastBall.x lastBall.y homei.x homei.y homei.r opnti.x opnti.y opnti.r Número de método invocado: 0 es create(...), 1 es destroy(...), y 2 es strategy(...). En la implementación actual siempre va el valor 2, y por lo tanto, no se sabe cuando se invocan los dos primeros métodos Número de estado tal cual se pasa desde el simulador: 1 es FREE_BALL, 2 es PLACE_KICK, 3 es PENALTY_KICK, 4 es FREE_KICK, y 5 es GOAL_KICK Número que indica quién tiene posesión de la pelota (tal cual se pasa desde el simulador): 0 es que nadie posee la pelota, 1 es que el equipo azul posee la pelota, y 2 es que el equipo amarillo posee la pelota Coordenada x de la posición actual de la pelota Coordenada y de la posición actual de la pelota Coordenada x de la posición anterior de la pelota Coordenada y de la posición anterior de la pelota Coordenada x de la posición del robot i Coordenada y de la posición del robot i Rotación del robot i Coordenada x de la posición del robot oponente i Coordenada y de la posición del robot oponente i Rotación del robot oponente i Tabla 2. Detalle del paquete enviado al ProxySimulator. homei.vl homei.vr Velocidad de la rueda izquierda del robot i Velocidad de la rueda derecha del robot i Es importante destacar que los campos de los mensajes no son de largo fijo. En la implementación se utilizó el carácter ‘:’ (dos puntos) como separador. Esta decisión fue tomada simplemente porque resultaba programaticamente más fácil el parseado de los distintos campos. En las tablas anteriores se describen en detalle cada uno de estos. Esta secuencia se repite en cada invocación a la función void Strategy(Environment env) implementada en ProxyStrategy. Importante Actualmente en el campo method siempre va el valor 2, esto es, solo se envía información hacia el ProxyStrategy de la estrategia en la invocación al método void Strategy(Environment env). Equipo Amarillo Los proxies correspondientes al control del equipo amarillo se implementan en los archivos ProxyY14.dll y ProxyY15.dll para las versiones 1.4 y 1.5a del 3D Robot Soccer Simulator respectivamente. Estos, se comunican por defecto a través del puerto local UDP 4040 con el puerto local UDP 5050 (que debe ser abierto por el otro proxy con el cual se establecerá la comunicación). Es posible cambiar esta configuración mediante el archivo yellow\proxy.config (ver abajo). Equipo Azul Los proxies correspondientes al control del equipo azul se implementan en los archivos ProxyB14.dll y ProxyB15.dll para las versiones 1.4 y 1.5a del 3D Robot Soccer Simulator respectivamente. Estos, se comunican por defecto a través del puerto local UDP 4141 con el puerto local UDP 5151 (que debe ser abierto por el otro proxy con el cual se establecerá la comunicación). Es posible cambiar esta configuración mediante el archivo blue\proxy.config (ver abajo). 3 Archivo de configuración El archivo proxy.config (que se encuentra en el directorio yellow y en el directorio blue) es el archivo de configuración de los proxies. Dicho archivo consta de solamente tres líneas: remote hostl remote port local port Nombre de la máquina en la cual correrá el otro proxy Puerto UDP del host remoto que será abierto por el otro proxy Puerto UDP local que será abierto por el ProxyXXX.dll De esta forma, el funcionamiento de los proxies es el siguiente: cuando se carga la dll en el simulador (por ejemplo ProxyY14.dll), el simulador invoca a la función void Create(Environment env) de dicha dll. Precisamente en esa función, el proxy intenta leer el archivo proxy.config para así abrir el socket UDP correspondiente con la configuración indicada en el archivo. Si este archivo no puede ser leído (por ejemplo porque no se encuentra), el proxy abrirá el socket con la configuración por defecto. 4 Contenido del .zip proxy.pdf: este archivo bin/yellow/proxy.config: archivo de configuración para el proxy del equipo amarillo bin/yellow/ProxyY14.dll: proxy del equipo amarillo para la versión 1.4 del simulador bin/yellow/ProxyY15.dll: proxy del equipo amarillo para la versión 1.5a del simulador bin/blue/proxy.config: archivo de configuración para el proxy del equipo amarillo bin/blue/ProxyB14.dll: proxy del equipo azul para la versión 1.4 del simulador bin/blue/ProxyB15.dll: proxy del equipo azul para la versión 1.5a del simulador src/ProxyY14: directorio con los fuentes C++ del proxy del equipo amarillo (v1.4) src/ProxyB14: directorio con los fuentes C++ del proxy del equipo azul (v1.4) src/ProxyY15: directorio con los fuentes C++ del proxy del equipo amarillo (v1.5a) src/ProxyB15: directorio con los fuentes C++ del proxy del equipo azul (v1.5a) 5 Conclusiones Se desarrollo un par de componentes capaces de encapsular la comunicación intercambiada entre el simulador de FIRA y una estrategia. Esta separación permite desarrollar componentes distribuidos, y permite desarrollar estrategias independientes de la arquitectura, sistema operativo y lenguaje sobre el cual fue desarrollado el simulador. Estos proxies fueron testeados exitosamente en el Campeonato Argentino de Fútbol de Robots en su edición 2004 [4] y serán utilizados en la edición de este año [5]. Como trabajos futuros se está trabajando en definir nuevos mecanismos de sincronización. En este sentido la primer mejora a introducir es que el ProxySimulator no se bloquee a la espera de un mensaje del ProxyStrategy. El siguiente paso es proporcionar varios esqueletos de ProxyStrategy para diferente lenguajes de programación. Referencias 1. 2. 3. 4. 5. FIRA Federation of International Robot-soccer Association, www.fira.net, visitada mayo de 2005. CCITT, Lenguaje de especificación y descripción funcional, recomendación Z.100, IX Asamblea Plenaria, Noviembre 1988. Castroman A. y E. Copello, “Fútbol de Robots”, Tesis de Grado, Instituto de Computación - Facultad de Ingeniería – Universidad de la República, Mayo 2004. CAFR 2004, Campeonato Argentino de Fútbol de Robots, http://www.exa.unicen.edu.ar/cafr2004/ , Facultad de Ciencias Exactas, Universidad Nacional del Centro de la Provincia de Buenos Aires, Tandil, Argentina, visitada mayo 2005. CAFR 2005, Campeonato Argentino de Fútbol de Robots, www.unimoron.edu.ar/cafr2005/, Universidad de Morón, Buenos Aires, Argentina, visitada mayo 2005. NAVEGACIÓN DE ROBOTS UN CASO PRACTICO MARCOS LAMBOLAY EZEQUIEL LAZAGA [email protected] [email protected] UNIVERSIDAD DE MORÓN FACULTAD DE INFORMÁTICA CAFR 2005 – JUNIO 2005 Resumen La navegación es un desafío mayor para los robots autónomos móviles. El problema puede se dividido básicamente en posicionamiento y planeamiento de la ruta. En esta disertación se presenta un enfoque al cual se le llama navegación por grilla. Este enfoque usa una mínima infraestructura de ambiente y solo dos sensores de luz en el robot. Comenzando desde un cuadro predefinido y una orientación predefinida, el robot puede dirigirse autónomamente a cualquier cuadro en la grilla. En su camino hacia los objetivos el robot determina su localización actual en la grilla basado en el tiempo que tarda de ir de cuadro a cuadro. 1.Introducción Una habilidad clave necesitada por un robot autónomo es la posibilidad de navegar a través del espacio. El problema puede ser descompuesto en posicionamiento y planeamiento de la ruta. Sin embargo se propone un procedimiento para el planeamiento donde este trabajo se concentra en la detección de la posición actual, monitoreando con un sensor el tiempo que se tarda en recorrer la mitad de un cuadro de la grilla, y, luego de calibrar el tiempo que se tarda en recorrer un cuadro completo, por convención de tiempo, se averigua la posición actual. Especialmente si el robot está severamente restringido de recursos, los esquemas y procedimientos simples le son favorables a los elaborados algoritmos usados. Además, una plataforma limitada como lo es Lego MindStorms, con sus sensores y motores, requiere técnicas robustas y simples debido a la imprecisión y falta de recursos. Estructura del trabajo En la sección 2 se proporciona un resumen del ambiente que el robot, descripto en la sección 3, necesita para navegar. En la sección 4 se describen las decisiones de software tomadas para hacer este trabajo. En la sección 5 se presenta el algoritmo de navegación y se discuten sus detalles. El trabajo concluye en su final y se presentan otros enfoques para navegar en la grilla. 2. Ambiente El robot navega sobre una grilla que regularmente divide una superficie en cuadros. Dichos cuadros se identifican de manera muy parecida a las coordenadas cartesianas, sólo que varían de éstas debido a que las coordenadas tienen su origen en el extremo superior izquierda del plano. Como se mencionó antes, el robot comienza en una posición predefinida (la posición inicial que sirve para calibrar la distancia de los cuadros) y en una orientación predeterminada (punto cardinal Este). Es suficiente que la grilla en su totalidad sea completamente cuadrada o rectangular y que todos los cuadros siempre sean del mismo tamaño. El robot no requiere conocer las dimensiones de la grilla, sólo necesita saber la posición inicial de arranque, luego de la calibración de la longitud de los cuadros, y la orientación actual. Dirigiéndose de cuadro a cuadro, el robot distingue 4 direcciones de rumbo: Este, Norte, Oeste y Sur. Dependiendo del tamaño del robot y la sensitividad de los sensores de luz, es posible disponer de diferentes tamaños de cuadros y diferentes contrastes entre el plano y las líneas de la grilla. Para las pruebas se utilizó un piso gris con una grilla de cinta adhesiva negra de 2 cm. de ancho y cuadros de 25 centímetros. Durante la demostración se pretende usar papel afiche blanco como fondo del plano y líneas impresas negras para la grilla, aunque también se podría usar en la demostración una grilla de cinta adhesiva. En ambos casos la longitud de los cuadros puede ser variable. Figura 1: Grilla experimental 3. Robot El robot requiere simplemente capacidades sensitivas y de actuación muy básicas. Todo lo que se necesita son dos sensores de luz que observen el suelo, encastrados al robot perpendicularmente a la dirección de avance de éste, y ambos sensores delante del robot, lo que permite una mayor resolución de sensitividad y corrección en el rumbo del robot. También se necesitan 4 ruedas controlables de a pares mediante 2 motores. Los sensores están delante del robot en una distancia de aproximadamente 10 cm. lo que permite que ante el menor movimiento de desviación del robot se produzcan más posibilidades de poder volverlo a su camino. La distancia entre los dos sensores de luz debe ser apenas un poco mayor que el grosor de la cinta adhesiva o línea negra. Figura 2: Diseño del robot Se eligió el Kit Lego MindStorms 2.0 para desarrollar el robot debido a su disponibilidad y bajo costo, pero no solamente por eso, sino porque permitió probar diferentes tipo de robots sin demasiado esfuerzo en la construcción mecánica y pudiendo enfocarse en los aspectos de programación y algoritmos. El código de navegación y posicionamiento se ejecuta en la unidad de microcontrolador RCX amarilla, encima de todo el robot. Sin embargo, el Kit Robotics Invention Systems 2.0 de Lego MindStorms arroja algunas desventajas. El RCX está seriamente restringido de recursos. Sólo oferece 32 kB de memoria para el firmware, el código del programa y los datos. En adición, los sensores y motores son bastante imprecisos, siendo que la velocidad del robot depende mucho de la capacidad de la batería. A modo de comentario, el programa que será expuesto a continuación sufrió de sobrepasar la capacidad de memoria varias veces antes de ser optimizado finalmente. 4. Software Llegado el momento de elegir un software con el cual trabajar, se tenían 3 opciones: (1) BrickOS y codificación C++; (2) Lejos y programación Java y (3) programación en Nqc. Se detallan los aspectos más sobresalientes de cada uno que pudiesen influenciar en la implementación de nuestro trabajo: (1) BrickOS y codificación C++: esta alternativa presentaba un elaborado firmware, codificación en C/C++, multithreading con semáforos, punto flotante y rutinas de comunicación IR. No se eligió esta alternativa por ser la menos sencilla de las tres (2) Lejos y programación Java: esta era una alternativa muy tentadora, ya que contábamos con casi todas las capacidades que necesitábamos, una curva de aprendizaje relativamente fácil y la vedette que se trataba de un clase Java llamada TimingNavigator, la cual, dados los tiempos que el robot tardaba en hacer un giro y en recorrer un cierto trayecto, calculaba el sistemas de coordenadas y permitía dirigir el robot hacia cualquier punto determinado en su ambiente. Esta alternativa, si bien tentadora, quitaba al trabajo el espíritu de su realización, el cual era implementar un sistema de navegación coordinado. (3) Programación en NQC: esta fue la elegida debido a su fácil curva de aprendizaje y porque, a pesar de tener restricciones, permitió llegar a un buen resultado a corto plazo. 5. Algoritmo A continuación se muestra un diagrama de actividad UML para describir el algoritmo en forma genérica. El gráfico mostrado se aplica para un objetivo, pero de haber otros sólo requiere repetir el algoritmo para poder satisfacer ese requerimiento. La rutina “Calcular desplazamiento” se compone de: “calcular recorrido”, “desplazar en x”, y “desplazar en y”. Aquí, para su mejor observación, se han desglosado las rutinas “Calcular desplazamiento” y “Desplazar en x”. Esta última se compone, al igual que “Desplazar en y” de: “Girar hacia derecha o izquierda”, “Determinar nueva orientación”, “Corregir giro”, “Avanzar recorrido” y “Fijar nueva posición”. Cada vez que se ejecuta “Avanzar recorrido”, se hace una corrección de trayectoria, la cual no fue mostrada en el gráfico para mantener la simplicidad. Tabla 1: Detalle de Funciones y Tareas principales Tipo de Rutina Nombre Función Configurar Función Girar Derecha Función Girar Izquierda Función Corregir Giro Función Avanzar Tarea Corregir Trayectoria Descripción Configura sensores y motores. Calibra automáticamente el umbral de luz para detectar guías de recorrido. Calibra automáticamente el tiempo requerido para desplazarse durante un cuadro. Determina el posicionamiento inicial del Robot Realiza un giro del Robot hacia la derecha y se calibra sobre la guía de recorrido. Realiza un giro del Robot hacia la izquierda y se calibra sobre la guía de recorrido. Realiza la corrección de giros del Robot cuando no se posicionan sobre la guía de recorrido o detecta un error. Realiza el desplazamiento del Robot sobre las guías de recorrido Realiza la corrección de trayectoria mientras el Robot avanza sobre la guías de recorrido. Función Función Función Tarea Desplazar en X Determina la orientación y realiza los giros necesarios para el desplazamiento del robot. Determina la necesidad de corrección de los giros. Establece el avance del Robot en el eje X. Desplazar en Y Ídem anterior sobre el eje Y. Calcular Calcula y determinar la necesidad de movimiento en el eje Desplazamiento X e Y. Mostrar Muestra las coordenadas de los objetivos en la pantalla Coordenadas LCD del Robot. 6. Conclusión y trabajo futuro En esta disertación se presentó un enfoque para la navegación y posicionamiento de un robot móvil y autónomo, llamado navegación por grilla. El cual utiliza una infraestructura ambiental mínima y dos sensores de luz en el robot. Comenzando desde una localización predefinida y una orientación predefinida en la grilla, el robot puede dirigirse de forma autónoma a los objetivos prefijados. En su camino determina la posición actual por convención de tiempo, es decir, sabiendo cuanto tiempo tarda en atravesar un cuadro. También se demostró como se implementó el algoritmo en software y hardware, que puede adaptarse a diferentes tipos de grilla, variando los cuadros en su longitud. El algoritmo de planeamiento de ruta puede optimizarse, lo cual da pie a un trabajo futuro donde el robot realice el recorrido óptimo, fundamentalmente en cuanto la decisión de giros y avances sobre los ejes X e Y. También se espera en un futuro disponer de un algoritmo que desplace al robot en diagonal así como actualmente lo hace en forma recta. También se podrían agregar obstáculos en el camino, lo que haría más interesante el algoritmo de navegación y más complejo. Otro futuro trabajo se define con el uso de lejos o legOS, los cuales con mayor disponibilidad de tiempo pueden ser aprendidos para obtener mejores resultados (como por ejemplo mediante el uso de aritmética de punto flotante) y desarrollar algoritmos más complejos. Referencias: [1] Website de Lego Mindstorms Robotics Inventions System 2.0: http://mindstorms.lego.com/eng/default.asp [2] Where am I?Sensors and Methods forMobile Robot Positioning byJ. Borenstein , H. R. Everett , and L. Feng 1 2 3 Contributing authors: S. W. Lee and R. H. Byrne,Abril 1996, University of Michigan ftp://ftp.eecs.umich.edu/people/johannb/pos96rep.pdf [3] Website del proyecto BrickOS: http://brickos.sourceforge.net [4] Website del proyecto lejos: http://lejos.sourceforge.net Experimentación de una conducta basada en Subsumición sobre QuiBot V1.0 Oscar Enrique Goñi Universidad Nacional del Centro de la Provincia de Buenos Aires Facultad de Ciencias Exactas [email protected] Resumen: Siguiendo las pautas descriptas en el artículo QuiBot V1.0 [Goñi2005], el presente trabajo explica los pasos seguidos para adaptar una arquitectura de comportamiento de robots a esta plataforma. Para esto se explican brevemente la subdivisión propuesta por Everett [Everett1998], en reactivos, dinámicos e híbridos. Dadas las limitaciones de computacionales del robot con el que se trabaja, se explica con más profundidad el diseño por capas de una arquitectura de Subsumición [Brooks86]. El experimento aquí presentado, consiste en simular un animal siguiendo un rastro. Se explican cada uno de los comportamientos que forman la conducta del robot, y como dichos comportamientos son arbitrados. Finalmente se explica cómo implementar la conducta obtenida sobre el procesador del QuiBot, concluyendo que el cálculo requerido por la arquitectura adoptada es soportado por la plataforma del robot. Palabras clave: navegación robótica, Subsumición, robots autónomos, comportamientos robóticos operativo de un robot. El control reactivo se ajusta bien en los I. Introducción ambientes dinámicamente cambiantes. Por naturaleza, los seres vivos • Sistemas Deliberativos: Involucran el están dotados de la habilidad para acoplamiento de sensores para la navegar en su ambiente. Sin embargo, detección de objetos con algún tipo de pocos robots móviles pueden alcanzar capacidad absoluta para modelar el todos sus objetivos sin necesidad de mundo. Se emplean distintos marcas de referencia artificiales en el paradigmas para la planificación de la ambiente. Por tal motivo, la navegación trayectoria deseada. La principal robótica se ha considerado [Jones y ventaja de estos sistemas sobre el Flynn, 93] como un problema aún no control. resuelto en Inteligencia Artificial. Reactivo es que, de existir, se De acuerdo con Everett [Everett, 95] los garantiza determinación de un camino métodos de navegación artificial franco a la meta. actualmente utilizados se pueden • Enfoques Híbridos Reactivo / clasificar en tres grandes grupos: Deliberativo. Combinan ambas • Control Reactivo: Estrategia basada metodologías para lograr una en conductas que acopla información operación más robusta en ambientes sensorial en tiempo real con acciones dinámicos. motrices, sin la intervención de Los sistemas reactivos pueden usarse representaciones simbólicas para el como una forma de navegación restrictiva modelado parcial o total del ambiente que se ajusta bien en tareas y conductas específicas. El objetivo de este artículo es plantear una arquitectura de comportamientos, acorde al hardware del robot con el que se está trabajando. Debido a que un enfoque deliberativo involucraría buena cantidad de capacidad de almacenamiento y cálculo para realizar el modelo del mundo, se optó por una arquitectura con un enfoque reactivo. En la próxima sección se describe brevemente como se compone la arquitectura de Subsumición. En la sección III, se plantea dicha arquitectura simulando el comportamiento de un animal. Se explica como implementar dicha conducta en la sección IV. Finalmente se exponen las conclusiones y trabajos futuros en la sección V. II. Subsumición: Una Arquitectura Basada en el Comportamiento La arquitectura de Subsumción [Brooks1986] ofrece una manera de combinar el control distribuido en tiempo real con conductas disparadas por sensores. Esta arquitectura, usa una estrategia con la cual se trata a los sensores como disparadores de conductas (en vez de establecer juicios explícitos acerca de la validez del sensor). Para simplificar el funcionamiento de esta arquitectura se puede imaginar como varios comportamientos corriendo en paralelo. Cada uno de estos es una capa. A medida de que las capas se encuentran en un nivel superior, poseen menor prioridad. Todas las capas emiten su mensaje al árbitro. El mensaje es la acción que se debiera tomar si el robot tuviese ese solo comportamiento. El árbitro es el encargado de pasarle el mensaje de mayor prioridad a los actuadores, posponiendo o anulando los de menor prioridad Nótese que en ninguna parte de este esquema existe la idea de que una conducta llame a otra como subrutina. Sin embargo, cuando las conductas de más alto nivel ya no están activas por una condición de un sensor dado, éstas cesan la supresión de las conductas de niveles inferiores para que éstas últimas tomen el control de las acciones. Así, la arquitectura es inherentemente paralela y los sensores interaccionan a través de todas las capas de conductas. No hay una estructura de datos unificada o modelo geométrico del mundo. Un espectro de habilidades constituye una especificación informal de la clase de comportamiento que se desea que el robot exhiba en los ambientes que enfrente. Se puede observar que cada espectro de habilidades de un robot puede hacer algo por sí mismo. La idea central es que se puede construir espectros de habilidades, de tal forma que el comportamiento pueda mejorarse agregando un nuevo espectro de habilidad a los ya existentes, sin que estos deban ser modificados, es decir, subsumiéndolos. En la arquitectura de Subsumción, el diseñador debe establecer una a una las relaciones entre las conductas (salidas, entradas, supresión e inhibición) para obtener el comportamiento deseado del robot. Las metas del robot en estos mecanismos de selección de acción están implícitas en la estructura del mismo y pueden ser de muy diversa naturaleza. Los datos de percepción son ilimitados de igual forma. El arbitraje entre conductas se realiza por medio de los mecanismos de inhibición y supresión. Estos mecanismos no contemplan la fusión de comandos, lo que significa que no es posible que dos conductas se activen de manera simultánea. En la próxima sección y a manera de ejemplo se muestra cómo cada uno de los diferentes comportamientos envían sus mensajes al árbitro, y cómo éste prioriza la atención de estos. III. Aplicando QuiBot V1.0 Subsumición en Entre los robots investigados que funcionan bajo una arquitectura de Subsumición, uno de los más importantes es Herbert [MIT IA lab 1980], basado en 23 procesadores, los cuales colaboraban para lograr la siguiente conducta: Buscar latas de gaseosa, si está llena dejarla, si está vacía, estrujarla y llevarla. Considerando que los avances tecnológicos permiten reducir la cantidad de procesadores, se planteará la arquitectura para el procesador sencillo del QuiBot. El objetivo del experimento es imitar el comportamiento de un sistema biológico. Además, se demuestra que con una cantidad limitada de sensores y del mismo tipo se pueden conjugar tres comportamientos sencillos y concurrentes. Los perros de caza o bien aquellos abocados a la búsqueda de personas en medio de catástrofes tienen un comportamiento que su entrenador le ha enseñado. Por ejemplo, un perro de caza anda por el campo buscando el rastro de algún animal, hasta que encuentra uno, lo sigue, y una vez avistada la presa, le marca a su amo la presencia de esta, quedándose inmóvil en el lugar, precisamente este comportamiento es el que se intentará imitar. En el experimento propuesto, el robot se encontrará haciendo wandering (buscando algún rastro) y evitando obstáculos hasta que encuentre una línea negra (rastro). Éste la seguirá hasta que encuentre un objeto magnético (presa) quedándose inmóvil. El entorno del experimento se compone por: - Obstáculos: Preferentemente objetos blancos que indican imposibilidad de continuar. - Piso: Es por donde se mueve el robot. Preferentemente de color uniforme y sin fuertes ondulaciones (para no dañar los sensores en la parte inferior). - Ambiente: Habitación despejada con paredes. - Rastro Consiste en una línea negra pegada sobre una superficie de goma blanca. En esta se plantean caminos cíclicos, caminos con objetos y caminos con presa. Una vez presentado el ambiente del robot, se planta la habilidad del robot. Esta se puede descomponer en las siguientes capas: Tarea_Andar → Prioridad Baja Tarea_ Andar comando_andar=comando_adelante Tarea_seguir_linea →Prioridad Media Tarea_ Seguir_Linea Repetir [ Si fuera_de_linea_izquierda comando_linea=comando_corregir_derecha Si fuera_de_linea_derecha comando_linea=comando_corregir_izquierda Esperar comando_linea=comando_ninguno ] Hasta Siempre Tarea_Evitar_obstaculo → Prioridad Alta Tarea_ Evitar_Obstaculo Repetir [ Si Obstaculo_Izquierda comando_evitar=comando_evitar_por_derecha Si obstaculo_izquierda comando_evitar=comando_evitar_porderecha Esperar comando_evitar=comando_ninguno ] Hasta Siempre Por último, el árbitro es quien decide qué mensaje enviar a los actuadores Tarea_ Arbitrar Repetir [ Si comando_andar ≠comando_ninguno comando_motor=comando_andar Si comando_linea ≠comando_ninguno comando_motor=comando_linea Si comando_evitar ≠comando_ninguno comando_motor=comando_evitar mover_robot ] Hasta Siempre Este esquema tiene una adaptación directa en sistema multiprocesador (por ejemplo una conducta por procesador). La implementación en el limitado procesador del QuiBot es presentada en la siguiente sección. IV. Implementación Se puede plantear la posibilidad de programar todos las conductas que corran concurrentemente o bien que cada una de las conductas sea ejecutada iterativamente (una tras otra) para dar ilusión de multitarea. Cada una de dichas conductas tiene asignado un espacio para alojar el mensaje al árbitro. Éste debe analizar cada uno de los mensajes en orden de prioridad, para suprimirlos o inhibirlos. Luego toma una decisión y comunica solo un mensaje a los actuadores. Así el árbitro es quien controla la posición de cada comportamiento en el esquema por capas. Una incorrecta disposición de las capas pueden causar conductas indeseables. Por ejemplo, si en este caso sencillo seguir la línea es de mayor prioridad que evitar un obstáculo, al encontrarse un bloqueo sobre la pista, lo chocará. V. Conclusiones y trabajo futuro El estilo de arquitecturas reactivas, demuestra ser el indicado para esta plataforma específica debido a su sencillez, robustez y desempeño ante ambientes dinámicos. Así como los seres humanos en ciertas situaciones, pueden llevar adelante un número limitado de conductas concurrentemente, la arquitectura programada efectuó tres conductas simultáneas. Esta situación otorga gran importancia a una conducta de Subsumición. El crecimiento vertical de la arquitectura brinda gran flexibilidad para agregar comportamientos al sistema. Para eso hay que programar dicha conducta e instruir al árbitro. Este será quien tome la decisión final a comunicar a los actuadores. Por otra parte, en las experimentaciones de las conductas por separado, se obtuvieron mejores resultados que con una arquitectura Braittenberg. El experimento consistía en colocar objetos, uno de cada lado del robot. El robot detectaba obstáculos, pero no calculaba si tenía espacio suficiente para pasar entre medio. Esto se debe a en esta arquitectura hay fusión de sensores, provocando dos acciones simultáneas. Sería interesante, debido a que la arquitectura del robot QuiBot fue concebida para tener un crecimiento por capas, experimentar nuevas arquitecturas de comportamientos, especialmente aquellas que requieran más poder de cálculo. VI. Referencias V. Braitenberg 1986 “Vehicles – Experiment in Synthetic Psycology”, MIT Press. Arkin, A. 1998. Behavior-Based Robotics. MIT Press, Cambridge, MA. Brooks, R. 1986. “A Robust Layered Control System for a Mobile Robot,” IEEE Journal of Robotics and Automation, Vol. RA-2, No. 1, pp. 14-23. Goñi Oscar E. "QuiBot V1.0: Diseño de un robot experimental" UNCPBA 2005. Everett H. R. Sensors for Mobile robots: Theory and Application. Naval Command, Control and Ocean Surveillance Center San Diego, California. A. K. Peters, ltd. Wellesley, Massachussets, 1995. Gunther, J.A. (1994), "Dante's Inferno", Popular Science, November. Jones, J.L. and Flynn (1993), A.M., Mobile Robots-Inspiration to Implementation, QuiBot V1.0 Diseño de un Robot Experimental Autónomo Oscar Enrique Goñi Universidad Nacional del Centro de la Provincia de Buenos Aires Facultad de Ciencias Exactas [email protected] Resumen: El presente artículo describe brevemente el análisis, construcción y programación de un robot físico, prototipo de robot experimental. El principal desafío que se plantea para el desarrollo es encontrar el punto de equilibrio entre versatilidad y costo. Dada su característica de plataforma de prueba de prototipos, el diseño fue enfocado a permitir la incorporación de distintas arquitecturas de control (Por ejemplo Subsumición [Brooks86]). En las diferentes secciones del trabajo, se explican las decisiones de diseño y como fueron construidas las partes electrónicas y mecánicas del robot. Por último se describe como mejorar el desempeño del robot mediante la incorporación de módulos o a través del reemplazo de existentes. Además se describen las mejoras y los puntos a tener en cuenta para su desarrollo en el futuro. Palabras clave: microbótica, microcontroladores. I. robot Introducción La robótica móvil ha crecido en los últimos años debido al creciente desempeño de los robots y microbots actuales. Entre los ejemplos destacados se encuentra el caso del Mars Lander [Nasa99], un robot desarrollado por la NASA y abocado a la tarea de la exploración del suelo marciano. Aunque las aplicaciones del área de la robótica móvil no se limitan a tareas que no pueden realizar los seres humanos. La robótica con fines educativos y de ocio han alimentado también al crecimiento. El Khepera [Kteam2002] es un microbot comercial usado para investigación y desarrollo de esquemas de control robótico. Dado el elevado costo de estas unidades, se hace inviables su uso en experimentación de forma masiva. experimental, de robot, una plataforma robótica con un bajo costo de desarrollo. En la sección II se analizan las sub partes que componen un robot y se detallan cuales son aquellas que causan los altos costos de desarrollo. En la sección III, se explican los factores tenidos en cuenta al momento de diseñar las estructura física y mecánica del robot. La sección IV plantea las diferentes opciones para el diseño de la parte electrónica. Luego se explica las decisiones tomadas en ese aspecto. En la sección V se mencionan demás consideraciones no tenidas en cuenta en secciones previas. Por último en la sección VI se describe el trabajo a realizarse en el futuro con la plataforma construida y sus modificaciones. II. El objetivo de este artículo es describir los pasos seguidos para la construcción de arquitectura Definición natural de las componentes del robot Evaluando los costos de construcción de un robot, se obtuvo que las partes que encarecen su diseño son: El procesador y el diseño ad hoc de componentes a pequeña escala. Para lograr los objetivos anteriormente mencionados se utilizaron procesadores más sencillos y se realizó un robot de volumen mediano (unos 15 lts.). Dentro de ese volumen se encuentra la plataforma aquí presentada. Esta está dividida en dos grandes grupos: QuiBot V1.0 Componentes Físicas Componentes Computacionales esta información se determinan las acciones a llevar a cabo. -Actuar: Lleva a cabo acciones que modifican en cierto sentido el ambiente. Con la separación propuesta, cada responsabilidad tiene un módulo electrónico asociado. Los módulos construidos son: Controlador: Se basa en un microcontrolador PIC16F84 de Microchip, montado sobre una placa con electrónica necesaria para la programación del PIC sin tener, necesariamente, que removerlo. En el caso de tener que sustituirlo, este cuenta con un zócalo instalado para tal fin. Software Hardware Estructura Corporal Mecánica Módulo de Sensores: Se encarga de recibir las señales provenientes de los sensores analógicos y discretiza la señal a una digital TTL 1 Las componentes computacionales se encargan del funcionamiento electrónico del robot, mientras que las físicas son aquellas que tienen intervención en el ambiente. Por tratarse de una máquina automática, el robot sigue el esquema de control clásico. Esto implica que las partes electrónicas pueden ser separadas de acuerdo a sus responsabilidades: -Sensar: Se encarga de percibir los datos provenientes del mundo físico y convertirlos en señales eléctricas. - Procesar: Asimila y evalúa los datos provenientes de los sensores. Con 1 Temas alcanzados por el presente artículo. Módulo de Potencia: Construido para activar motores Stepper de cuatro bobinas. Se permite además el uso de motores con menos inductores. Cada uno de los módulos fue diseñado con la intención de que sea totalmente compatible con otros de mayor o menor capacidad. Por ejemplo, debe ser posible quitar el módulo Trigger estándar de cinco sensores y colocar uno Multiplexado de 16. Por otra parte se encuentran las componentes físicas. Estas involucran la forma de locomoción del robot y su estructura corporal. En la próxima sección se explican brevemente lo referido a dichas componentes. Se describe como fueron construidas la parte mecánica y el cuerpo del robot, argumentando las decisiones tomadas. III. Factores determinantes del diseño de las componentes físicas La parte mecánica así como el chasis y cuerpo del robot, fueron variables a considerar al momento de diseñar el robot. Debido a que se consideró la posibilidad de que la arquitectura del robot crezca, se tuvo en cuenta el espacio suficiente para albergarla. Se utilizará aproximadamente el 40% del volumen útil en el diseño propuesto. En lo referente a la forma, se eligió cilíndrica, para permitir una navegación libre y permitir el cambio de dirección sin perturbar el entorno (Esto se logra girando sobre el mismo eje). La locomoción se realiza por medio de dos ruedas de ∅12 cm. Estas proporcionan dirección y tracción. Están montadas sobre bancadas con bolilleros. Esta configuración permite un desplazamiento suave y sin fricción. El sustento es realizado por una rueda trasera que se encuentra colocada justo debajo de la parte más pesada, la batería. Esta tercer rueda logra el equilibrio del robot y permite la colocación de sensores en la parte inferior delantera. Por ejemplo para la exploración del terreno La energía cinética es provocada por dos motores paso a paso, que incrementan su torque gracias a un engranaje colocado en su eje, y otro de mayor tamaño en las ruedas. La parte superior (la cabeza) se realizó con un recipiente acrílico trasparente. Esta decisión se debe a que el robot puede ser ampliado en su futuro, y permite la colocación de sensores de luz o cámaras de video digital permitiendo imágenes en 360 grados. IV. Diseño electrónicas de las componentes Los módulos electrónicos fueron diseñados siguiendo el esquema propuesto en la sección II. Como todo sistema de control consta de tres partes fundamentales: • • • Entrada Procesamiento Salida La etapa de sensado se ocupa de convertir las señales del exterior en señales puramente digitales. La primera versión construida se trata de un circuito integrado Schmith Trigger. Este discretiza las señales analógicas de los sensores y las convierte en pulsos lógicos. TTL La opción de utilizar transistores correctamente polarizados no es viable debido a que el tamaño que ocupa este tipo de electrónica es mayor. El circuito integrado elegido fue el CD40106 que posee seis canales inversores.2 La conexión a la placa controladora se realiza vía un cable plano (7 hilos) con conectores en sus extremos. Los pines de los extremos del conector, transportan la alimentación, mientras que los internos transportan las señales digitales. Con esta disposición se puede optar por cambiar el módulo y allí colocar un módulo de ampliación ya sea para ser usado para sensores, comunicación o ambos. Otro módulo que allí se puede conectar es un multiplexor. Este es construido utilizando un circuito Integrado CD 4051 de Texas Instrument. Este posee 16 patas, cuya salida única es seleccionada de entre 8 entradas. La elección de este integrado 2 Esta situación debe ser tenida en cuenta al momento de programar ya que se trabaja con lógica negativa. se debe a que soporta entradas analógicas, lo que permitiría el cambiar el tipo se señales soportadas por el procesador sin alterar este módulo Para hacerlo funcionar, se deben utilizar 3 bits de datos provenientes del µP, y uno en sentido contrario, que transporta el dato solicitado. El bit restante en el conector, es usado para transmisión de datos por infrarrojos. Los dos motores paso a paso (actuadores) se encuentran conectados a la etapa de potencia. Su funcionamiento se basa en un transistor que permite interrumpir la circulación de corriente por cada bobina, en un momento determinado. Se utilizaron transistores BC337, son del tipo NPN, interrumpiendo la alimentación negativa de la bobina. Cada uno de estos son alimentados vía resistencias de 470Ω para limitar la corriente en la base, y ocho diodos para absorber los pulsos de alta tensión provocados por la bobina cuando esta deja de conducir. Dichos picos podrían dañar al transistor y la controladora. La elección de usar transistores y no Circuitos Integrados en esta etapa, se basa en que se desea poder trabajar con tensiones mayores a 12 volts. Además la opción de usar motores de menos cantidad de bobinas, esta previsto en esta opción. También se obtiene mayor disipación del calor. Ocho circuitos idénticos separan a la controladora de los motores. Cada paso a paso es movido gracias a la correcta secuencia de ocho bits que provienen de la controladora. Para mover los motores, es necesario escribir en el puerto los siguientes datos: 10001000 (2)≡88 (16)≡136 (10) 00100010 (2) ≡ 22 (16)≡34 (10) 01000100 (2) ≡ 44(16)≡68 (10) 00010001 (2) ≡11 (16)≡17 (10) Nótese que cada palabra consta de dos grupos de 4 bits idénticos, un grupo por motor. Esto logra mover ambos motores en el mismo sentido, provocando un movimiento en línea recta. Si los movimientos son giros sobre el mismo eje, las palabras deben ser palíndromas. Esto causa giros en direcciones diferentes opuestas en los motores. Cada motor ocupa doscientos pasos en dar un giro completo, lo que permite un ángulo de 1,8 grados por paso. Esta precisión sumada a la reducción, permite que el robot se mueva a una velocidad aceptable, como así también lograr que sus movimientos pasen desapercibidos. Por último y como punto más importante se encuentra la controladora, que se basa en un circuito electrónico que alberga un procesador PIC16F84 de Microchip [Microchip]. La opción de este procesador, se debe ya que se trata de un intermedio entre sus hermanos3, el PIC12C508 y PIC16F877, menor y mayor respectivamente. Además las opciones de utilizar procesadores con memoria borradas mediante la incidencia de luz ultravioleta fue descartadas ya que no facilitan al desarrollo de aplicaciones en el robot. Entre las características del procesador utilizado se encuentran: • Solo 35 Instrucciones • Todas las instrucciones involucran un solo ciclo, excepto las de salto que involucran 2 • Velocidad de operación de reloj de 20MHZ (200 ns por instrucción) • 1024 palabras de memoria de programa • 68 bytes de RAM • 64 bytes de datos EEPROM • Pila de 8 niveles 3 Se evaluaron solo estos tres procesadores debido a su bajo costo. Lo que interesa básicamente para implementar el lazo de control es que posee dos puertos, PORTA de 5 Bits, que se encargará de introducir en el µP los datos provenientes del módulo de sensores. El PORTB de 8 bits, se encarga de controlar los circuitos de potencia de los motores. Por otra parte, a la controladora se le agregó la electrónica necesaria para la programación del PIC. Todos los procesadores de esta familia siguen la misma metodología de programación, por lo que, si en un futuro se desea ampliar (¿o reducir?) el procesamiento de cálculo, bastan pocas modificaciones en el esquema electrónico original al igual en las rutinas que este corra. V. Otras consideraciones Por último resta describir que se utilizó una batería de 12V, 4.5 ah, las que energiza al robot por más de una hora de experimentación, sus dimensiones son 90mm x 90mm x 70mm y le aportan al robot el peso de 1500gs, que representan el 30 % del peso total del robot. Los sensores usados fueron del tipo infrarrojos reflectivos (que logran detectar obstáculos antes de entrar en contacto con el robot) en su parte anterior e inferior del robot para su funcionamiento como Sniffer. En el caso que se necesitase conectar más de un sensor a un canal, se puede improvisar una puerta lógica OR utilizando diodos correctamente polarizados. VI. Conclusiones y trabajo futuro Las experimentaciones realizadas con el robot [Goñi2005], han demostrado que la plataforma soporta arquitecturas de comportamiento reactivo sin inconvenientes. Queda pendiente la experimentación con arquitecturas deliberativas e híbridas. Para esto se tiene previsto realizar un cambio de procesador para implementar arquitecturas de Software para Robots que requieran procesamiento de señales analógicas (Braittenberg, por ejemplo). La ampliación consiste en dejar al procesador original que se encargue de las tareas de más bajo nivel, como son la de actuar y sensar y dejar que un procesador más potente se encargue del tratamiento de señales más complejas como el procesamiento de una imagen, sonido u otro sentido que se le pueda agregar al robot. El objetivo de armar un robot a bajo costo fue cumplido, ya que no se acercó ni a una décima parte del precio de un robot experimental, con las mismas características. VII. Agradecimientos Juan Santos y Diego Benderski por el excelente curso de Robótica que dictaron e incentivaron a realizar el proyecto. José León por su dedicación continua en revisar el articulo una y otra vez. A mi familia por su invalorable paciencia y apoyo a lo largo de todo el proyecto. Carolina Tommasi y Guillermo Acuña por la revisión y críticas del árticulo. VIII. Referencias Goñi Oscar E.: Experimentación de una conducta basada en Subsumición sobre QuiBot V1.0. UNCPBA 2005 Microchip, www.microchip.com Atmel, www.atmel.com Circuitos www.pablin.com.ar electrónicos, Texas Instrument, www.ti.com NASA: Autonomous Rovers for Mars Exploration www.tc.arc.nasa.gov/publications/pdf/19 99-0078.pdf I.b Otros Artículos Investigación en Sistemas Multi-agente y Robótica Cognitiva aplicada a la Robótica Móvil en el dominio de Fútbol de Robots Alejandro J. Garcı́a Telma Delladio Mariano Tucat Nicolás D. Rotstein Diego R. Garcı́a Grupo de Robótica Cognitiva Laboratorio de Investigación y Desarrollo en Inteligencia Artificial (lidia) Departamento de Ciencias e Ingenierı́a de la Computación Universidad Nacional del Sur. Av. Alem 1253, (8000) Bahı́a Blanca, Argentina Tel: ++54 291 459 5135 - Fax: ++54 291 459 5136 {ajg,td,mt,ndr,drg}@cs.uns.edu.ar Resumen El objetivo principal de este trabajo es presentar las diferentes lı́neas de investigación que nuestro grupo está desarrollando en inteligencia artificial aplicada a la robótica móvil. En particular, en este trabajo se describen las lı́neas de investigación que están asociadas al desarrollo de un equipo de fútbol de robots. Con el desarrollo de estas lı́neas de investigación el objetivo es doble. En primer lugar se desea aportar nuevas soluciones para los problemas que se presentan en robótica móvil. En segundo lugar se desea utilizar un dominio de aplicación concreto de robots móviles para obtener retro-alimentación y desarrollar mejores formalismos en el área de agentes inteligentes, sistemas multi-agente y robótica cognitiva. 1. Robótica Móvil, Robótica Cognitiva y Sistemas Multi-agente Disponer de robots móviles con algún grado de inteligencia requiere integrar facilidades de bajo nivel (manejo de sensores, movimientos básicos, evasión de obstáculos, navegación, etc) con habilidades de alto nivel como razonamiento, representación de creencias, planificación, comunicación con otros agentes, interacción, coordinación, etc. El desarrollo de dichas facilidades y habilidades debe tener en cuenta que si el robot móvil opera en un ambiente dinámico, donde además pueden existir otros agentes que interactúan con él, entonces el robot deberı́a ser capaz de razonar con cierto grado de incertidumbre y poder planear sus acciones con la suficiente flexibilidad como para modificar sus planes en ejecución. Estas habilidades de alto nivel se encuentran actualmente en estudio en dos áreas de inteligencia artificial que han tenido un gran impulso en los últimos años: Robótica Cognitiva y Sistemas Multi-agente (SMA). La investigación en Robótica Cognitiva [16, 12, 8, 5, 3] involucra problemas relacionados con funciones cognitivas de alto nivel, las cuales permiten que robots fı́sicos sean capaces de razonar y desenvolverse en el entorno que los alberga. Algunas de las problemáticas abordadas por el área de Robótica Cognitiva incluyen: la necesidad de desenvolverse en dominios dinámicos con conocimiento incompleto acerca de los objetos en el mundo, las acciones disponibles, sus precondiciones, y sus efectos; la necesidad de representar grandes espacios de estados y razonar sobre ellos; la actualización y revisión del conocimiento disponible en forma eficiente y semánticamente correcta; el diseño de arquitecturas de agentes adecuadas que soporten las soluciones a todos esos problemas. Por esta razón, los trabajos en robótica cognitiva son muy variados y abordan temáticas complejas como: representación de conocimiento y razonamiento; definición de lenguajes de control de algo nivel para el desarrollo de razonadores; la definición y desarrollo de planificadores; la definición de formalismos de razonamiento acerca de acciones y cambio; revisión de conocimiento y aprendizaje; arquitecturas de agentes inteligentes. Además, si los robots móviles deben desenvolverse en un entorno donde pueden existir otros robots con los cuales tienen que interactuar, entonces surgen otro tipo de problemas. Las soluciones a estos problemas, requieren que estos robots cuenten, no sólo con habilidades cognitivas, sino también con habilidades sociales tales como: cooperación, coordinación, y comunicación entre agentes. Estas habilidades sociales se encuentran actualmente en estudio dentro del área de Sistemas Multi-agente. Como fue dicho anteriormente, nuestro interés en robótica móvil es doble. Por un lado, uno de lo objetivos centrales es la aplicación de formalismos que han sido desarrollados por nuestro grupo en diferentes áreas de inteligencia artificial, los cuales permitirán obtener las habilidades de alto nivel (cognitivas y sociales) antes mencionadas. Por otro lado, se está utilizando un grupo de robots en un dominio de aplicación especı́fico como lo es un partido de fútbol de robots, con el objetivo de obtener retro-alimentación en temas fundamentales de SMA como coordinación, interacción, colaboración y comunicación; ası́ como también en temas centrales de Robótica Cognitiva como representación de conocimiento, razonamiento, planificación y aprendizaje. En la sección 3 se describirán en detalle las lı́neas de investigación que se están llevando a cabo en nuestro grupo. Estas lı́neas involucran desarrollos teóricos y prácticos en robótica cognitiva y SMA, y están siendo aplicadas en el desarrollo de un equipo de fútbol de robots el cual se describe en la sección siguiente. 2. El dominio de aplicación En esta sección se describe brevemente cual es el dominio de aplicación sobre el cual se están aplicando las lı́neas de investigación que describiremos en la sección siguiente. Se trata de un equipo de fútbol de robots de la modalidad E-league [1], formado por cuatro robots Lego Mindstorm [2]. Para su funcionamiento, se han diseñado e implementado un sistema multiagente donde cada agente lógico controla un jugador del equipo de robots. A continuación incluimos un resumen del diseño de este sistema, los detalles pueden verse en [10] y [9]. Figura 1: Diseño del Sistema Multi-agente que controla a los robots [9] El sistema fue desarrollado siguiendo un diseño por capas (Figura 1). El SMA fue diseñado como muestra la Figura 1 donde cada capa de servicio está asociada a un diferente nivel de abstracción. Cada capa resuelve un conjunto diferente de problemas por medio de los servicios que ofrece. Dichos servicios quedan disponibles a las capas superiores. Por ejemplo, la capa mas baja (low level communication layer) provee los servicios básicos provistos por el hardware de visión y comunicación con los robots. La capa siguiente (logical communication layer) está implementada en C y utiliza los servicios de la anterior y provee dos primitivas básicas: la función de percepción y la primitiva de comunicación con los robots. La siguiente (sensorial/effectorial) está implementada en Prolog y provee las primitivas básicas para implementar el comportamiento de los robots. La más alta es la que implementa las habilidades cognitivas y sociales. Como cada capa es modular, modificando las capas inferiores permite adaptar los desarrollo de alto nivel a otros dominios u otros robots. Además, nuevos desarrollos a nivel cognitivo pueden ponerse a prueba simplemente a través de la reformulación de los servicios de la capa cognitiva. 3. Lı́neas de investigación en curso En esta sección se describen las siguientes lı́neas de investigación aplicadas a problemáticas relacionadas con robótica móvil: Representación de conocimiento y razonamiento con argumentación rebatible. Arquitecturas de Agentes. Aprendizaje. Interacción y comunicación en Sistemas Multi-agente. Planificación. Estas lı́neas de investigación se encuentran actualmente en desarrollo en nuestro laboratorio. 3.1. Representación de conocimiento y razonamiento con argumentación rebatible Como ya se dijo, un robot móvil deberı́a poder desenvolverse en dominios dinámicos con conocimiento incompleto acerca de su entorno. Esto incluye información incompleta acerca de los objetos en el mundo y cierto grado de incertidumbre en los efectos de sus acciones. Por lo tanto, debe proveerse a los robots de un formalismo que les permita razonar sobre información incompleta y cambiante. En nuestro laboratorio se ha desarrollado un formalismo de razonamiento con argumentación rebatible que permite realizar inferencias sobre conocimiento incompleto y potencialmente contradictorio. Este formalismo, denominado Defeasible Logic Programming (DeLP) o Programación en Lógica Rebatible [11], permite representar conocimiento con reglas rebatibles y estrictas. En DeLP las conclusiones de un agente son sustentadas con argumentos. Una conclusión se dice garantizada cuando el argumento que la sustenta no posee derrotadores (contraargumentos que lo derrotan) o todos sus derrotadores son a su vez derrotados. Dado un argumento que sustenta una conclusión este podrı́a ser atacado por otros argumentos derrotadores que lo contradigan. Dichos derrotadores podrán a su vez ser atacados, y ası́ sucesivamente, generando una secuencia de argumentos llamada lı́nea de argumentación. En DeLP el proceso completo considera para cada argumento todos sus posibles derrotadores, lo cual, en lugar de una única lı́nea de argumentación, genera un conjunto de lı́neas representadas a través de un árbol de dialéctica. Un proceso de análisis dialéctico determina, a partir del conocimiento del agente, si la conclusión en cuestión está garantizada o no. La utilización de DeLP para implementar el proceso de razonamiento de un robot nos permite poseer un sistema de razonamiento con las caracterı́sticas deseadas y además analizar cómo se comporta DeLP en un dominio de aplicación de robots móviles. En nuestro caso, cada robot representa, como parte de su conocimiento, las acciones de alto nivel que pueden ser ejecutadas, y las razones para creer en el éxito o fracaso de las mismas. Estas razones se apoyan en la información que posee cada agente acerca de las posiciones del resto de los jugadores y la pelota, dentro del campo de juego. Un análisis argumentativo sobre la garantı́a de la ejecución de las acciones disponibles conforma la base para la etapa final del proceso de razonamiento. Este proceso, enmarcado en una arquitectura BDI (ver Sección 3.2), finaliza con la determinación de una intención que se materializará en una acción fı́sica por parte del robot. 3.2. Arquitecturas de Agentes El objetivo principal de esta lı́nea de investigación es analizar cómo se adecúa al dominio de fútbol de robots una combinación entre una arquitectura de agentes BDI (Belief-DesireIntention) y un sistema de razonamiento con argumentación rebatible (DeLP). El dominio de aplicación ofrece el desafı́o de ser altamente dinámico y determina una cierta variedad de acciones, las cuales, de alguna manera, compiten entre sı́ para determinar cuál será la próxima a ser ejecutada. La arquitectura BDI que describe la implementación de los agentes de software que controlan a los robots fı́sicos (Figura 2) está conformada por los conjuntos de creencias (B), deseos (D) e intenciones (I) que se detallan a continuación: Creencias (Beliefs): El conjunto de creencias reúne toda la información que obtiene el agente únicamente a través de su percepción del mundo. A partir de este conjunto el agente puede actuar en consecuencia, ya que tiene su propia representación del entorno que lo rodea. La calidad y el detalle de la información obtenida depende de sus sensores y de la forma en que internaliza el estado del mundo. Deseos (Desires): Los deseos, como conjunto, representan las actitudes que determinarán el comportamiento del agente. Demuestran la tendencia del agente hacia una forma de actuar determinada y, de alguna manera, las metas que tiene fijadas y que intenta cumplir. Dependiendo de la situación actual, habrá deseos que no podrán cumplirse y deberán ser reprimidos. Esto es imprescindible para que el agente pueda cumplir con la misión que le fue encomendada. Figura 2: Ciclo BDI utilizando DeLP como módulo de razonamiento Intenciones (Intentions): Se generan a partir de los deseos y expresan lo que el agente es capaz y quiere hacer en el instante actual. Representan la materialización de los deseos, habiéndolos contrastado previamente con el estado del mundo y del agente en sı́. En esta implementación, el conjunto de intenciones será un único elemento del conjunto de deseos y representará la acción de alto nivel que prevalece en ese instante. Por ejemplo, los conjuntos de Creencias, Deseos e Intenciones de un agente (jugador) podrı́an ser los siguientes: B = { { { { arqueroFuera(E), posesión(E) : E ∈ {our,their} } ∪ alguienEntre(X,Y) : X, Y ∈ {me,t1,t2,t3,o1,o2,o3,o4} } ∪ ganando, empatando, perdiendo } ∪ ladoContrario(J), nadieAdelante(J), marcado(J), tienePelota(J) : J ∈ {me,t1,t2,t3,o1,o2,o3,o4} } D = { patearAlArco(me), puedeLlevarla(me), alinearse } ∪ { hacerPase(me,T) : T ∈ {t1,t2,t3} } ∪ { marcarA(O) : O ∈ {o1,o2,o3,o4} } I ⊆ D, tal que |I| = 1 3.3. Aprendizaje El aprendizaje es una habilidad que está relacionada con la autonomı́a. Por esa razón, la importancia del estudio de mecanismos de aprendizaje en el desarrollo de agentes autónomos. Dentro del área de Machine Learning, la Programación en Lógica Inductiva se presenta como una propuesta interesante al momento de resolver el problema de aprendizaje de conceptos a partir de ejemplos. Las propuestas de Programación en Lógica Inductiva utilizan formalismos de Programación en Lógica como herramienta de representación de conocimiento y razonamiento, junto con mecanismos de inducción para sintetizar, a partir de ejemplos, programas lógicos que sirven como definición de los conceptos que se desean aprender. La obtención de estas definiciones es una tarea muy costosa y es necesario estudiar mecanismos que permitan resolver esta tarea en forma eficiente. Muchas veces, afrontar una tarea compleja en forma cooperativa puede dar buenos resultados. Se han realizado estudios considerando la definición de un esquema de aprendizaje grupal [6] como un primer paso para el planteo de soluciones cooperativas al problema del aprendizaje de conceptos a partir de ejemplos dentro del marco de la Programación en Lógica Inductiva. Además, considerando la flexibilidad necesaria para llevar adelante una tarea cooperativa tan compleja, se ha estudiado la utilización de otros paradigmas de programación en lógica como la Programación en Lógica Rebatible [7] como herramienta de representación de conocimiento y razonamiento no monótono a partir de la cual desarrollar aprendizaje inductivo de conceptos. La Programación en Lógica Rebatible como herramienta de razonamiento no monótono, ofrece una mayor flexibilidad al momento de sintetizar definiciones que modelen los conceptos que son objeto de aprendizaje. En el domino considerado, la habilidad de aprendizaje puede ayudar al mejoramiento del comportamiento individual y grupal de los integrantes del equipo. Cada jugador puede aprender, por ejemplo, nociones de posición y acción las cuales pueden ser modeladas a través de conceptos representados por términos lógicos. La valoración de la correctitud de los conceptos aprendidos puede ser determinada en la dinámica del juego considerando los resultados obtenidos en el transcurso del mismo. A más alto nivel, se pueden plantear tareas de aprendizaje grupal, en donde el conjunto de agentes pueda aprender (aproximar) la estrategia de comportamiento del equipo contrario. 3.4. Interacción y comunicación en Sistemas Multi-agente La interacción es una caracterı́stica esencial de un Sistema Multi-Agente. Dicha interacción puede ser llevada a cabo a través del intercambio de mensajes de acuerdo a una polı́tica de conversación determinada, o a la ejecución de servicios de acuerdo a los requerimientos de otros agentes. Es por esto que la habilidad de comunicarse y responder a estos requerimientos es una caracterı́stica que deberı́an poseer los agentes que forman parte de un SMA. Un partido de fútbol de robots puede considerarse un SMA donde existe cooperación entre los agentes del mismo equipo y competencia entre agentes de equipos contrarios. En este dominio de aplicación los agentes (jugadores) necesitan interactuar y comunicarse. Por ejemplo, en casos donde la visión de los robots es parcial, éstos podrı́an comunicarse para intercambiar la información del entorno que cada uno posee, como ser la ubicación de los demás jugadores. También podrı́an interactuar para planificar y coordinar jugadas, o simplemente para informar sobre alguna decisión tomada que pudiera afectar el comportamiento del resto del equipo. Nuestro objetivo es proveer una extensión de la Programación en Lógica que permita implementar comunicación entre agentes sin necesidad de programar elementos de conexión de bajo nivel. En esta lı́nea de trabajo se ha desarrollado una extensión de Prolog [18] que provee un conjunto de primitivas de interacción con las siguientes caracterı́sticas: 1. Permite la creación de distintos SMA independientes. 2. Un agente que se une a un SMA, puede comunicarse con los demás integrantes del sistema simplemente conociendo sus nombres. No es necesario especificar información de conexión de bajo nivel como, por ejemplo, el identificador de la máquina y el puerto en el que se encuentra cada agente. 3. Los agentes pueden obtener la lista de los agentes presentes en el SMA. 4. Cada agente puede asociar la llegada de un mensaje de otro agente, a la ejecución de un predicado determinado. Esto permite una programación orientada a eventos. 5. Además, es posible realizar una asociación diferente para cada agente. Es decir, dependiendo de quien envı́e el mensaje, se ejecutará el predicado asociado previamente. 3.5. Planificación En un ambiente dinámico y complejo como un partido de fútbol, resulta muy difı́cil considerar todas las posibles situaciones que un robot puede enfrentar. Una tarea mas difı́cil aún es programar su comportamiento para que reaccione adecuadamente a cada una de esas situaciones. Si bien es posible programar un robot de forma general, sus habilidades quedan restringidas a las situaciones previstas por su diseñador, lo cual conspira contra su autonomı́a. Dotar al robot con la habilidad de construir y ejecutar planes permite que el mismo pueda enfrentar una variedad de situaciones más amplia y aumentar su autonomı́a. Más aún, si se desea agregar habilidades al robot, no es necesario volver a programarlo, alcanza con agregar las acciones adecuadas para que sean consideradas al momento de construir un plan. Por otra parte, la tecnologı́a de planificación actual resulta inadecuada para resolver los tipos de problemas que enfrenta un robot de este tipo. Esto se debe a que los métodos tradicionales de planificación asumen simplificaciones sobre los problemas planificación, que resultan adecuadas para otros dominios y disminuyen la complejidad de los problemas. Las simplificaciones más importantes son: El planificador tiene todo el conocimiento relevante que necesita en el momento que comienza a planificar. Nada importante ocurre en el mundo, excepto como resultado de sus acciones. Se ve al planificador como un módulo separado, en lugar de estar integrado a la arquitectura cognitiva del robot. En un ambiente dinámico como un partido de fútbol estas suposiciones pueden fallar debido a que: El conocimiento del robot acerca del mundo, por más preciso que sea, será incompleto. Las creencias del robot son falibles y a medida que adquiere más información sus creencias pueden cambiar. A medida que el mundo cambia, las creencias del robot deben actualizarse. El robot interactúa con otros robots que pueden cambiar el estado del mundo. El propósito de esta lı́nea de investigación es la incorporación y adaptación de técnicas de planificación a la arquitectura de los robots, con el objetivo facilitar el diseño e implementación de su comportamiento y aumentar su autonomı́a. 3.6. Facilidades de bajo nivel Además de investigar sobre estos aspectos cognitivos y sociales de alto nivel, en nuestro grupo se han desarrollado algunas facilidades de bajo nivel relacionados con la percepción y acción. Por ejemplo, una tarea elemental que debe realizar un robot al desenvolverse en un medio fı́sico es la de trasladarse desde su posición actual hacia una ubicación deseada. Para lograrlo, debe tener la capacidad de evadir posibles obstáculos, tanto estáticos como dinámicos. Para ello se ha desarrollado un algoritmo de evasión de obstáculos con bajo costo computacional basado en campos de potencial [17]. Otro ejemplo es la minimización de errores que ocurren en la etapa de sensado y en la ejecución de acciones (el resultado real de su ejecución difiere del resultado esperado). Para resolver estos problemas se han propuesto diversas soluciones [13]. 4. Conclusiones En este trabajo se han descripto las diferentes lı́neas de investigación que se están desarrollando actualmente en nuestro laboratorio en las áreas de robótica cognitiva y SMA, con el objetivo de proveer soluciones a problemas en robótica móvil. Referencias [1] http://agents.cs.columbia.edu/eleague/. Official E-League webpage. [2] http://www.legomindstorms.com. Lego Mindstorms robots and RCX controllers. [3] Amir, E., and Doyle, P. Adventure games: A challenge for cognitive robotics. Proceedings of the 3rd International Cognitive Robotics Workshop (2002). [4] Bratman, M. E., Israel, D., and Pollack, M. Plans and resource-bounded practical reasoning. In Philosophy and AI: Essays at the Interface, R. Cummins and J. L. Pollock, Eds. The MIT Press, Cambridge, Massachusetts, 1991, pp. 1–22. [5] Castelpietra, C., Iocchi, L., Nardi, D., and Rosati, R. Coordination in multiagent autonomous cognitive robotic systems. Proceedings of the 2nd International Cognitive Robotics Workshop, Berlin, Germany (2000). [6] Delladio, T. Ilp en aprendizaje grupal. IV Workshop de Investigadores en Ciencias de la Computación (WICC 2002) (2002). [7] Delladio, T. Aprendizaje de conocimiento rebatible. Anales del IX Congreso Argentino de Ciencias de la Computación (CACiC 2003) (2003), 566–576. [8] Dylla, F., Ferrein, A., and Lakemeyer, G. Acting and deliberating using golog in robotic soccer: A hybrid approach. Proceedings of the 3rd International Cognitive Robotics Workshop (2002). [9] Garcı́a, A. J., Simari, G. I., and Delladio, T. Designing an agent system for controlling a robotic soccer team. In Proceedings of X Argentine Congress of Computer Science (2004), p. 227. http://cs.uns.edu.ar/∼ajg/papers/index.htm. [10] Garcı́a, A. J., Simari, G. I., Delladio, T., Garcı́a, D. R., Tucat, M., Rotstein, N. D., Martı́n, F. A., and Gottifredi, S. Cognitive robotics in a soccer game domain: A proposal for the e-league competition. In 6to Workshop de Investigadores en Ciencias de la Computación (WICC), Universidad Nacional del Comahue (2004), pp. 289–293. http://cs.uns.edu.ar/∼ajg/papers/index.htm. [11] Garcı́a, A. J., and Simari, G. R. Defeasible logic programming: An argumentative approach. Theory and Practice of Logic Programming 4, 1 (2004), 95–138. [12] Lesperance, Y., and Ng, H.-K. Integrating planning into reactive high-level robot programs. Proceedings of the 2nd International Cognitive Robotics Workshop, Berlin, Germany (2000). [13] Martı́n, F., Tucat, M., and Garcı́a, A. J. Soluciones a problemas de percepción y acción en el dominio de un equipo de fútbol de robots. Anales del X Congreso Argentino de Ciencias de la Computación (CACiC 2004) (2004). [14] Rao, A. S. AgentSpeak(L): BDI agents speak out in a logical computable language. In Seventh European Workshop on Modelling Autonomous Agents in a Multi-Agent World (Eindhoven, The Netherlands, 1996), R. van Hoe, Ed. [15] Rao, A. S., and Georgeff, M. P. BDI-agents: from theory to practice. In Proceedings of the First International Conference on Multiagent Systems (San Francisco, 1995). [16] Reiter, R. Knowledge in Action Logical Foundations for Specifying and Implementing Dynamical Systems. The MIT Press, 2001. [17] Rotstein, N., and Garcı́a, A. J. Evasión de obstáculos con bajo costo computacional para un equipo de fútbol de robots. Anales del X Congreso Argentino de Ciencias de la Computación (CACiC 2004) (2004). [18] Tucat, M. Primitivas de Interacción para el Desarrollo de Sistemas Multi-agente. Proyecto Final de Ingenierı́a en Sistemas de Computación. Departamento de Ciencias e Ingenierı́a de la Computación, Universidad Nacional del Sur, Bahı́a Blanca, Argentina, http://cs.uns.edu.ar/∼ajg/interaction primitives/, mar 2005. Investigación en Sistemas Multi-agente y Robótica Cognitiva aplicada a la Robótica Móvil en el dominio de Fútbol de Robots Alejandro J. Garcı́a Telma Delladio Mariano Tucat Nicolás D. Rotstein Diego R. Garcı́a Grupo de Robótica Cognitiva Laboratorio de Investigación y Desarrollo en Inteligencia Artificial (lidia) Departamento de Ciencias e Ingenierı́a de la Computación Universidad Nacional del Sur. Av. Alem 1253, (8000) Bahı́a Blanca, Argentina Tel: ++54 291 459 5135 - Fax: ++54 291 459 5136 {ajg,td,mt,ndr,drg}@cs.uns.edu.ar Resumen El objetivo principal de este trabajo es presentar las diferentes lı́neas de investigación que nuestro grupo está desarrollando en inteligencia artificial aplicada a la robótica móvil. En particular, en este trabajo se describen las lı́neas de investigación que están asociadas al desarrollo de un equipo de fútbol de robots. Con el desarrollo de estas lı́neas de investigación el objetivo es doble. En primer lugar se desea aportar nuevas soluciones para los problemas que se presentan en robótica móvil. En segundo lugar se desea utilizar un dominio de aplicación concreto de robots móviles para obtener retro-alimentación y desarrollar mejores formalismos en el área de agentes inteligentes, sistemas multi-agente y robótica cognitiva. 1. Robótica Móvil, Robótica Cognitiva y Sistemas Multi-agente Disponer de robots móviles con algún grado de inteligencia requiere integrar facilidades de bajo nivel (manejo de sensores, movimientos básicos, evasión de obstáculos, navegación, etc) con habilidades de alto nivel como razonamiento, representación de creencias, planificación, comunicación con otros agentes, interacción, coordinación, etc. El desarrollo de dichas facilidades y habilidades debe tener en cuenta que si el robot móvil opera en un ambiente dinámico, donde además pueden existir otros agentes que interactúan con él, entonces el robot deberı́a ser capaz de razonar con cierto grado de incertidumbre y poder planear sus acciones con la suficiente flexibilidad como para modificar sus planes en ejecución. Estas habilidades de alto nivel se encuentran actualmente en estudio en dos áreas de inteligencia artificial que han tenido un gran impulso en los últimos años: Robótica Cognitiva y Sistemas Multi-agente (SMA). La investigación en Robótica Cognitiva [16, 12, 8, 5, 3] involucra problemas relacionados con funciones cognitivas de alto nivel, las cuales permiten que robots fı́sicos sean capaces de razonar y desenvolverse en el entorno que los alberga. Algunas de las problemáticas abordadas por el área de Robótica Cognitiva incluyen: la necesidad de desenvolverse en dominios dinámicos con conocimiento incompleto acerca de los objetos en el mundo, las acciones disponibles, sus precondiciones, y sus efectos; la necesidad de representar grandes espacios de estados y razonar sobre ellos; la actualización y revisión del conocimiento disponible en forma eficiente y semánticamente correcta; el diseño de arquitecturas de agentes adecuadas que soporten las soluciones a todos esos problemas. Por esta razón, los trabajos en robótica cognitiva son muy variados y abordan temáticas complejas como: representación de conocimiento y razonamiento; definición de lenguajes de control de algo nivel para el desarrollo de razonadores; la definición y desarrollo de planificadores; la definición de formalismos de razonamiento acerca de acciones y cambio; revisión de conocimiento y aprendizaje; arquitecturas de agentes inteligentes. Además, si los robots móviles deben desenvolverse en un entorno donde pueden existir otros robots con los cuales tienen que interactuar, entonces surgen otro tipo de problemas. Las soluciones a estos problemas, requieren que estos robots cuenten, no sólo con habilidades cognitivas, sino también con habilidades sociales tales como: cooperación, coordinación, y comunicación entre agentes. Estas habilidades sociales se encuentran actualmente en estudio dentro del área de Sistemas Multi-agente. Como fue dicho anteriormente, nuestro interés en robótica móvil es doble. Por un lado, uno de lo objetivos centrales es la aplicación de formalismos que han sido desarrollados por nuestro grupo en diferentes áreas de inteligencia artificial, los cuales permitirán obtener las habilidades de alto nivel (cognitivas y sociales) antes mencionadas. Por otro lado, se está utilizando un grupo de robots en un dominio de aplicación especı́fico como lo es un partido de fútbol de robots, con el objetivo de obtener retro-alimentación en temas fundamentales de SMA como coordinación, interacción, colaboración y comunicación; ası́ como también en temas centrales de Robótica Cognitiva como representación de conocimiento, razonamiento, planificación y aprendizaje. En la sección 3 se describirán en detalle las lı́neas de investigación que se están llevando a cabo en nuestro grupo. Estas lı́neas involucran desarrollos teóricos y prácticos en robótica cognitiva y SMA, y están siendo aplicadas en el desarrollo de un equipo de fútbol de robots el cual se describe en la sección siguiente. 2. El dominio de aplicación En esta sección se describe brevemente cual es el dominio de aplicación sobre el cual se están aplicando las lı́neas de investigación que describiremos en la sección siguiente. Se trata de un equipo de fútbol de robots de la modalidad E-league [1], formado por cuatro robots Lego Mindstorm [2]. Para su funcionamiento, se han diseñado e implementado un sistema multiagente donde cada agente lógico controla un jugador del equipo de robots. A continuación incluimos un resumen del diseño de este sistema, los detalles pueden verse en [10] y [9]. Figura 1: Diseño del Sistema Multi-agente que controla a los robots [9] El sistema fue desarrollado siguiendo un diseño por capas (Figura 1). El SMA fue diseñado como muestra la Figura 1 donde cada capa de servicio está asociada a un diferente nivel de abstracción. Cada capa resuelve un conjunto diferente de problemas por medio de los servicios que ofrece. Dichos servicios quedan disponibles a las capas superiores. Por ejemplo, la capa mas baja (low level communication layer) provee los servicios básicos provistos por el hardware de visión y comunicación con los robots. La capa siguiente (logical communication layer) está implementada en C y utiliza los servicios de la anterior y provee dos primitivas básicas: la función de percepción y la primitiva de comunicación con los robots. La siguiente (sensorial/effectorial) está implementada en Prolog y provee las primitivas básicas para implementar el comportamiento de los robots. La más alta es la que implementa las habilidades cognitivas y sociales. Como cada capa es modular, modificando las capas inferiores permite adaptar los desarrollo de alto nivel a otros dominios u otros robots. Además, nuevos desarrollos a nivel cognitivo pueden ponerse a prueba simplemente a través de la reformulación de los servicios de la capa cognitiva. 3. Lı́neas de investigación en curso En esta sección se describen las siguientes lı́neas de investigación aplicadas a problemáticas relacionadas con robótica móvil: Representación de conocimiento y razonamiento con argumentación rebatible. Arquitecturas de Agentes. Aprendizaje. Interacción y comunicación en Sistemas Multi-agente. Planificación. Estas lı́neas de investigación se encuentran actualmente en desarrollo en nuestro laboratorio. 3.1. Representación de conocimiento y razonamiento con argumentación rebatible Como ya se dijo, un robot móvil deberı́a poder desenvolverse en dominios dinámicos con conocimiento incompleto acerca de su entorno. Esto incluye información incompleta acerca de los objetos en el mundo y cierto grado de incertidumbre en los efectos de sus acciones. Por lo tanto, debe proveerse a los robots de un formalismo que les permita razonar sobre información incompleta y cambiante. En nuestro laboratorio se ha desarrollado un formalismo de razonamiento con argumentación rebatible que permite realizar inferencias sobre conocimiento incompleto y potencialmente contradictorio. Este formalismo, denominado Defeasible Logic Programming (DeLP) o Programación en Lógica Rebatible [11], permite representar conocimiento con reglas rebatibles y estrictas. En DeLP las conclusiones de un agente son sustentadas con argumentos. Una conclusión se dice garantizada cuando el argumento que la sustenta no posee derrotadores (contraargumentos que lo derrotan) o todos sus derrotadores son a su vez derrotados. Dado un argumento que sustenta una conclusión este podrı́a ser atacado por otros argumentos derrotadores que lo contradigan. Dichos derrotadores podrán a su vez ser atacados, y ası́ sucesivamente, generando una secuencia de argumentos llamada lı́nea de argumentación. En DeLP el proceso completo considera para cada argumento todos sus posibles derrotadores, lo cual, en lugar de una única lı́nea de argumentación, genera un conjunto de lı́neas representadas a través de un árbol de dialéctica. Un proceso de análisis dialéctico determina, a partir del conocimiento del agente, si la conclusión en cuestión está garantizada o no. La utilización de DeLP para implementar el proceso de razonamiento de un robot nos permite poseer un sistema de razonamiento con las caracterı́sticas deseadas y además analizar cómo se comporta DeLP en un dominio de aplicación de robots móviles. En nuestro caso, cada robot representa, como parte de su conocimiento, las acciones de alto nivel que pueden ser ejecutadas, y las razones para creer en el éxito o fracaso de las mismas. Estas razones se apoyan en la información que posee cada agente acerca de las posiciones del resto de los jugadores y la pelota, dentro del campo de juego. Un análisis argumentativo sobre la garantı́a de la ejecución de las acciones disponibles conforma la base para la etapa final del proceso de razonamiento. Este proceso, enmarcado en una arquitectura BDI (ver Sección 3.2), finaliza con la determinación de una intención que se materializará en una acción fı́sica por parte del robot. 3.2. Arquitecturas de Agentes El objetivo principal de esta lı́nea de investigación es analizar cómo se adecúa al dominio de fútbol de robots una combinación entre una arquitectura de agentes BDI (Belief-DesireIntention) y un sistema de razonamiento con argumentación rebatible (DeLP). El dominio de aplicación ofrece el desafı́o de ser altamente dinámico y determina una cierta variedad de acciones, las cuales, de alguna manera, compiten entre sı́ para determinar cuál será la próxima a ser ejecutada. La arquitectura BDI que describe la implementación de los agentes de software que controlan a los robots fı́sicos (Figura 2) está conformada por los conjuntos de creencias (B), deseos (D) e intenciones (I) que se detallan a continuación: Creencias (Beliefs): El conjunto de creencias reúne toda la información que obtiene el agente únicamente a través de su percepción del mundo. A partir de este conjunto el agente puede actuar en consecuencia, ya que tiene su propia representación del entorno que lo rodea. La calidad y el detalle de la información obtenida depende de sus sensores y de la forma en que internaliza el estado del mundo. Deseos (Desires): Los deseos, como conjunto, representan las actitudes que determinarán el comportamiento del agente. Demuestran la tendencia del agente hacia una forma de actuar determinada y, de alguna manera, las metas que tiene fijadas y que intenta cumplir. Dependiendo de la situación actual, habrá deseos que no podrán cumplirse y deberán ser reprimidos. Esto es imprescindible para que el agente pueda cumplir con la misión que le fue encomendada. Figura 2: Ciclo BDI utilizando DeLP como módulo de razonamiento Intenciones (Intentions): Se generan a partir de los deseos y expresan lo que el agente es capaz y quiere hacer en el instante actual. Representan la materialización de los deseos, habiéndolos contrastado previamente con el estado del mundo y del agente en sı́. En esta implementación, el conjunto de intenciones será un único elemento del conjunto de deseos y representará la acción de alto nivel que prevalece en ese instante. Por ejemplo, los conjuntos de Creencias, Deseos e Intenciones de un agente (jugador) podrı́an ser los siguientes: B = { { { { arqueroFuera(E), posesión(E) : E ∈ {our,their} } ∪ alguienEntre(X,Y) : X, Y ∈ {me,t1,t2,t3,o1,o2,o3,o4} } ∪ ganando, empatando, perdiendo } ∪ ladoContrario(J), nadieAdelante(J), marcado(J), tienePelota(J) : J ∈ {me,t1,t2,t3,o1,o2,o3,o4} } D = { patearAlArco(me), puedeLlevarla(me), alinearse } ∪ { hacerPase(me,T) : T ∈ {t1,t2,t3} } ∪ { marcarA(O) : O ∈ {o1,o2,o3,o4} } I ⊆ D, tal que |I| = 1 3.3. Aprendizaje El aprendizaje es una habilidad que está relacionada con la autonomı́a. Por esa razón, la importancia del estudio de mecanismos de aprendizaje en el desarrollo de agentes autónomos. Dentro del área de Machine Learning, la Programación en Lógica Inductiva se presenta como una propuesta interesante al momento de resolver el problema de aprendizaje de conceptos a partir de ejemplos. Las propuestas de Programación en Lógica Inductiva utilizan formalismos de Programación en Lógica como herramienta de representación de conocimiento y razonamiento, junto con mecanismos de inducción para sintetizar, a partir de ejemplos, programas lógicos que sirven como definición de los conceptos que se desean aprender. La obtención de estas definiciones es una tarea muy costosa y es necesario estudiar mecanismos que permitan resolver esta tarea en forma eficiente. Muchas veces, afrontar una tarea compleja en forma cooperativa puede dar buenos resultados. Se han realizado estudios considerando la definición de un esquema de aprendizaje grupal [6] como un primer paso para el planteo de soluciones cooperativas al problema del aprendizaje de conceptos a partir de ejemplos dentro del marco de la Programación en Lógica Inductiva. Además, considerando la flexibilidad necesaria para llevar adelante una tarea cooperativa tan compleja, se ha estudiado la utilización de otros paradigmas de programación en lógica como la Programación en Lógica Rebatible [7] como herramienta de representación de conocimiento y razonamiento no monótono a partir de la cual desarrollar aprendizaje inductivo de conceptos. La Programación en Lógica Rebatible como herramienta de razonamiento no monótono, ofrece una mayor flexibilidad al momento de sintetizar definiciones que modelen los conceptos que son objeto de aprendizaje. En el domino considerado, la habilidad de aprendizaje puede ayudar al mejoramiento del comportamiento individual y grupal de los integrantes del equipo. Cada jugador puede aprender, por ejemplo, nociones de posición y acción las cuales pueden ser modeladas a través de conceptos representados por términos lógicos. La valoración de la correctitud de los conceptos aprendidos puede ser determinada en la dinámica del juego considerando los resultados obtenidos en el transcurso del mismo. A más alto nivel, se pueden plantear tareas de aprendizaje grupal, en donde el conjunto de agentes pueda aprender (aproximar) la estrategia de comportamiento del equipo contrario. 3.4. Interacción y comunicación en Sistemas Multi-agente La interacción es una caracterı́stica esencial de un Sistema Multi-Agente. Dicha interacción puede ser llevada a cabo a través del intercambio de mensajes de acuerdo a una polı́tica de conversación determinada, o a la ejecución de servicios de acuerdo a los requerimientos de otros agentes. Es por esto que la habilidad de comunicarse y responder a estos requerimientos es una caracterı́stica que deberı́an poseer los agentes que forman parte de un SMA. Un partido de fútbol de robots puede considerarse un SMA donde existe cooperación entre los agentes del mismo equipo y competencia entre agentes de equipos contrarios. En este dominio de aplicación los agentes (jugadores) necesitan interactuar y comunicarse. Por ejemplo, en casos donde la visión de los robots es parcial, éstos podrı́an comunicarse para intercambiar la información del entorno que cada uno posee, como ser la ubicación de los demás jugadores. También podrı́an interactuar para planificar y coordinar jugadas, o simplemente para informar sobre alguna decisión tomada que pudiera afectar el comportamiento del resto del equipo. Nuestro objetivo es proveer una extensión de la Programación en Lógica que permita implementar comunicación entre agentes sin necesidad de programar elementos de conexión de bajo nivel. En esta lı́nea de trabajo se ha desarrollado una extensión de Prolog [18] que provee un conjunto de primitivas de interacción con las siguientes caracterı́sticas: 1. Permite la creación de distintos SMA independientes. 2. Un agente que se une a un SMA, puede comunicarse con los demás integrantes del sistema simplemente conociendo sus nombres. No es necesario especificar información de conexión de bajo nivel como, por ejemplo, el identificador de la máquina y el puerto en el que se encuentra cada agente. 3. Los agentes pueden obtener la lista de los agentes presentes en el SMA. 4. Cada agente puede asociar la llegada de un mensaje de otro agente, a la ejecución de un predicado determinado. Esto permite una programación orientada a eventos. 5. Además, es posible realizar una asociación diferente para cada agente. Es decir, dependiendo de quien envı́e el mensaje, se ejecutará el predicado asociado previamente. 3.5. Planificación En un ambiente dinámico y complejo como un partido de fútbol, resulta muy difı́cil considerar todas las posibles situaciones que un robot puede enfrentar. Una tarea mas difı́cil aún es programar su comportamiento para que reaccione adecuadamente a cada una de esas situaciones. Si bien es posible programar un robot de forma general, sus habilidades quedan restringidas a las situaciones previstas por su diseñador, lo cual conspira contra su autonomı́a. Dotar al robot con la habilidad de construir y ejecutar planes permite que el mismo pueda enfrentar una variedad de situaciones más amplia y aumentar su autonomı́a. Más aún, si se desea agregar habilidades al robot, no es necesario volver a programarlo, alcanza con agregar las acciones adecuadas para que sean consideradas al momento de construir un plan. Por otra parte, la tecnologı́a de planificación actual resulta inadecuada para resolver los tipos de problemas que enfrenta un robot de este tipo. Esto se debe a que los métodos tradicionales de planificación asumen simplificaciones sobre los problemas planificación, que resultan adecuadas para otros dominios y disminuyen la complejidad de los problemas. Las simplificaciones más importantes son: El planificador tiene todo el conocimiento relevante que necesita en el momento que comienza a planificar. Nada importante ocurre en el mundo, excepto como resultado de sus acciones. Se ve al planificador como un módulo separado, en lugar de estar integrado a la arquitectura cognitiva del robot. En un ambiente dinámico como un partido de fútbol estas suposiciones pueden fallar debido a que: El conocimiento del robot acerca del mundo, por más preciso que sea, será incompleto. Las creencias del robot son falibles y a medida que adquiere más información sus creencias pueden cambiar. A medida que el mundo cambia, las creencias del robot deben actualizarse. El robot interactúa con otros robots que pueden cambiar el estado del mundo. El propósito de esta lı́nea de investigación es la incorporación y adaptación de técnicas de planificación a la arquitectura de los robots, con el objetivo facilitar el diseño e implementación de su comportamiento y aumentar su autonomı́a. 3.6. Facilidades de bajo nivel Además de investigar sobre estos aspectos cognitivos y sociales de alto nivel, en nuestro grupo se han desarrollado algunas facilidades de bajo nivel relacionados con la percepción y acción. Por ejemplo, una tarea elemental que debe realizar un robot al desenvolverse en un medio fı́sico es la de trasladarse desde su posición actual hacia una ubicación deseada. Para lograrlo, debe tener la capacidad de evadir posibles obstáculos, tanto estáticos como dinámicos. Para ello se ha desarrollado un algoritmo de evasión de obstáculos con bajo costo computacional basado en campos de potencial [17]. Otro ejemplo es la minimización de errores que ocurren en la etapa de sensado y en la ejecución de acciones (el resultado real de su ejecución difiere del resultado esperado). Para resolver estos problemas se han propuesto diversas soluciones [13]. 4. Conclusiones En este trabajo se han descripto las diferentes lı́neas de investigación que se están desarrollando actualmente en nuestro laboratorio en las áreas de robótica cognitiva y SMA, con el objetivo de proveer soluciones a problemas en robótica móvil. Referencias [1] http://agents.cs.columbia.edu/eleague/. Official E-League webpage. [2] http://www.legomindstorms.com. Lego Mindstorms robots and RCX controllers. [3] Amir, E., and Doyle, P. Adventure games: A challenge for cognitive robotics. Proceedings of the 3rd International Cognitive Robotics Workshop (2002). [4] Bratman, M. E., Israel, D., and Pollack, M. Plans and resource-bounded practical reasoning. In Philosophy and AI: Essays at the Interface, R. Cummins and J. L. Pollock, Eds. The MIT Press, Cambridge, Massachusetts, 1991, pp. 1–22. [5] Castelpietra, C., Iocchi, L., Nardi, D., and Rosati, R. Coordination in multiagent autonomous cognitive robotic systems. Proceedings of the 2nd International Cognitive Robotics Workshop, Berlin, Germany (2000). [6] Delladio, T. Ilp en aprendizaje grupal. IV Workshop de Investigadores en Ciencias de la Computación (WICC 2002) (2002). [7] Delladio, T. Aprendizaje de conocimiento rebatible. Anales del IX Congreso Argentino de Ciencias de la Computación (CACiC 2003) (2003), 566–576. [8] Dylla, F., Ferrein, A., and Lakemeyer, G. Acting and deliberating using golog in robotic soccer: A hybrid approach. Proceedings of the 3rd International Cognitive Robotics Workshop (2002). [9] Garcı́a, A. J., Simari, G. I., and Delladio, T. Designing an agent system for controlling a robotic soccer team. In Proceedings of X Argentine Congress of Computer Science (2004), p. 227. http://cs.uns.edu.ar/∼ajg/papers/index.htm. [10] Garcı́a, A. J., Simari, G. I., Delladio, T., Garcı́a, D. R., Tucat, M., Rotstein, N. D., Martı́n, F. A., and Gottifredi, S. Cognitive robotics in a soccer game domain: A proposal for the e-league competition. In 6to Workshop de Investigadores en Ciencias de la Computación (WICC), Universidad Nacional del Comahue (2004), pp. 289–293. http://cs.uns.edu.ar/∼ajg/papers/index.htm. [11] Garcı́a, A. J., and Simari, G. R. Defeasible logic programming: An argumentative approach. Theory and Practice of Logic Programming 4, 1 (2004), 95–138. [12] Lesperance, Y., and Ng, H.-K. Integrating planning into reactive high-level robot programs. Proceedings of the 2nd International Cognitive Robotics Workshop, Berlin, Germany (2000). [13] Martı́n, F., Tucat, M., and Garcı́a, A. J. Soluciones a problemas de percepción y acción en el dominio de un equipo de fútbol de robots. Anales del X Congreso Argentino de Ciencias de la Computación (CACiC 2004) (2004). [14] Rao, A. S. AgentSpeak(L): BDI agents speak out in a logical computable language. In Seventh European Workshop on Modelling Autonomous Agents in a Multi-Agent World (Eindhoven, The Netherlands, 1996), R. van Hoe, Ed. [15] Rao, A. S., and Georgeff, M. P. BDI-agents: from theory to practice. In Proceedings of the First International Conference on Multiagent Systems (San Francisco, 1995). [16] Reiter, R. Knowledge in Action Logical Foundations for Specifying and Implementing Dynamical Systems. The MIT Press, 2001. [17] Rotstein, N., and Garcı́a, A. J. Evasión de obstáculos con bajo costo computacional para un equipo de fútbol de robots. Anales del X Congreso Argentino de Ciencias de la Computación (CACiC 2004) (2004). [18] Tucat, M. Primitivas de Interacción para el Desarrollo de Sistemas Multi-agente. Proyecto Final de Ingenierı́a en Sistemas de Computación. Departamento de Ciencias e Ingenierı́a de la Computación, Universidad Nacional del Sur, Bahı́a Blanca, Argentina, http://cs.uns.edu.ar/∼ajg/interaction primitives/, mar 2005. Workshop del CAFR2005 Robot Físico Autónomo Colaborativo MSL Ing. Balich, Néstor Adrián [e-mails:[email protected]] Investigador del Centro de Altos Estudios en Tecnología Informática Universidad Abierta Interamericana Montes de Oca 740 Buenos Aires – Argentina Junio, 2005 Abstract El presente trabajo tiene por objetivo analizar los principales aspectos necesarios en la construcción de un conjunto de robots autónomos que cumpla con las especificaciones de la categoría Middle Size League para fútbol de robot de la Robocup, además de dar información experimental obtenida de la construcción de los mismos. Se analizan las principales características de varios robots presentados en diferentes certámenes, buscando una alternativa a nivel nacional, tanto en materiales como en costo. Por último se pretende brindar una plataforma de programación de fácil acceso a nivel computacional al mismo tiempo que permita una escalabilidad en cuanto hardware y software, permitiendo el uso de los mismos como base para el desarrollo e investigación de diferentes configuraciones de robot, predominando el reconocimiento del entorno por visión y la comunicación por red cableada o WIFI. Keywords: robot, middle-size-league, fútbol-robot, construcción, especificaciones-diseño. I. Introducción Este trabajo parte del conocimiento previo sobre características y ventajas del entorno de fútbol de robot como marco para experimentación en robótica (Balich, CAFR 2004), en este trabajo se describen las principales ventajas de uso de robots colaborativos dentro de este entorno y de un modelo de software basado en agentes propuesto para diseñar un equipo básico de MiroSot. La categoría MSL (Midlle Size League) de la Robocup y MiroSot de la Fira, si bien no son similares en todo sentido, tienen muchos puntos de coincidencia. No es nuestra intención realizar una comparación entre ambas categorías, por ello se destacan solo los más relevantes, que son: • • • Entorno físico similar de trabajo. Sistema de reconocimiento de imágenes. Características del juego (Problema). En cuanto a las diferencias MSL con respecto de MiroSot, se puede citar: • El incremento en el tamaño de los robots y del campo de juego. • Cada robot debe ser autónomo y poseer un sistema de visión local. • Se permite utilizar un computador estándar del tipo PC como sistema de control y de hecho el tamaño de los robots lo hacen también posible. • Se utiliza un sistema de comunicación WIFI 802.11 a / b. La principal ventaja de usar computador estándar, es que permite desarrollar íntegramente el sistema de control en lenguajes de alto nivel, pero también se cuenta con la posibilidad de utilizar lenguajes de bajo nivel. Brinda un marco habitual de trabajo para estudiantes de sistemas, haciéndolo mas accesible. II. El Entorno El campo de juego debe ser de color verde con un tamaño entre 8 a 16 mts de largo y de 6 a 12 metros de ancho aproximadamente (Robocup, Reglamento). La disposición es similar a la de un campo de fútbol tradicional. Consta de dos arcos uno para el equipo azul y otro para el equipo amarillo, con un área de zona, delimitada por una línea blanca. En los cuatro extremos del campo de juego existen postes con tres franjas de color identificadas con dos secuencias (amarillo/azul/amarillo o azul/amarillo/azul) de acuerdo al equipo que corresponda. La pelota es de color naranja número 5, de acuerdo a las especificaciones de la Federación Internacional de Fútbol Asociados. Los equipos pueden estar formados desde 2 hasta 5 robots incluido el arquero. especificaciones de diseño son muy abiertas y de hecho se evidencia en los diferentes tipos de robots presentados. Principalmente se deben cumplir con los siguientes requisitos. • Su tamaño debe estar comprendido en un cuadrado de 30cm x 30cm hasta un máximo es 50cm x 50 cm. La altura debe estar entre 30cm y 80cm. En el caso de utilizar actuadores (dispositivo de pateado, etc.), con estos desplegados no se debe superar un rectángulo de 60cm x 60 cm. • Su peso puede llegar hasta 40 Kg. • Debe ser pintado de color negro mate. • Poseer distintivos de identificación visuales (número, color, etc.) según las especificaciones (Robocup, Reglamento). RobSoc (Moreira, 2004) 1. Transmisión No existe limitación con respecto a la cantidad de motores, pero frecuentemente se usan dos tipos de transmisión: • Diferencial con dos ruedas de empuje (VolksBot) Campo de juego III El Robot Las regulaciones con respecto a las Workshop del CAFR2005 Plataforma (VolksBot) Visión 360° (Buchheim, 2004) • Omnidireccional con tres o más ruedas (EIGEN, Team) No esta limitada la cantidad de cámaras y hay equipos que cuentan con tres o mas cámaras, una para cada flanco del robot (Maeda, 2005) Omnidireccional (EIGEN, Team) 2. Visión La mayoría de lo equipos utilizan dos cámaras de video, una montada sobre el frente del robot para visualizar el camino a recorrer, la pelota y obstáculos próximos a baja altura. La restante montada en la parte superior para visión global a mayor distancia. Con respecto a la segunda cámara existen dos formas comunes de utilizarla: • • Con visión directa Visión global de 360º (Buchheim, 2004) Los mejores resultados se han obtenido con visión global de 360º, esto se logra usando un cono reflextivo ( enfocado desde la parte inferior por una única cámara, logrando una visión periférica de 360° (Petrov, 2004). . Team “FC-Soromons” (Maeda, 2005) 3. Sensores Hasta el momento no se limita la utilización de sensores especiales (velocímetro, brújula, GPS, odómetro, sonares, etc.) ni tampoco la cantidad de baterías. 4. Actuadores Principalmente se utilizan dos tipos: • Estáticos: su función es mantener la pelota junto al robot, en una posición conocida con el fin de impulsarla en línea recta con la fuerza de desplazamiento del robot. • Dinámicos: comúnmente llamados pateadores, que permiten golpear la pelota. Los más utilizados son los electromecánicos y los neumáticos. (revoluciones por minuto) de la rueda. La única restricción presente tanto para los actuadores como para la forma del robot, es que no debe dañar a otro robot de ninguna manera. 5. Computador El computador esta restringido únicamente, por el tamaño y peso máximo, dando la posibilidad de utilizar una palm, nootebook, PC, CPU industriales, micros, etc. Un modelo muy usado es Pentium III de 1 Ghz con 512 de memoria, HD 8 GB (Lima, 2004) 6. Comunicación El método de comunicación inalámbricos permitido, es WIFI 802.11b, no existiendo restricciones con respecto a la comunicación entre robots del mismo equipo. La comunicación con un computador central esta solo permitida para tareas de monitoreo, pudiéndose solicitar la desconexión del mismo en cualquier momento. IV. Construcción del robot 1. Elección de los motores: Esta es una guía rápida para el calculo de los motores, con valores en vacio, con el fin de darnos una aproximación a los valores reales. El primer dato evaluado a la hora de definir los motores, es la velocidad máxima que debíamos alcanzar, generalmente los robots van de 1,5 a 3 metros/segundo lo que nos da con una velocidad de 90 a 180 metros/minuto y 5,4. a 10,8 kilómetros/hora. RPM-r = 90 mts/minuto * 100 / long circ = 286,62 rpm Finalmente la rpm de la rueda deberán oscilar entre un valor de 286 y 574 rpm. Para calcular las RPM del motor, se debe multiplicar por el factor de multiplicación del motor, que generalmente se recomienda osciles entre 3 y 5. RPM-M = 286 RPM * 3 = 859 Finalmente las RPM del motor deberán oscilar entre 859 y 2870 RPM. Por último es necesario calcular la potencia del motor que esta directamente relacionada por la carga (masa) que debe transportar y el factor de aceleración que se desee obtener. Generalmente estos valores están expresados en Newton por centímetro N-cm, Newton por metro N-m o en Kg-cm.. Para tener una idea 1 Nm = 0,09807 Kg-cm. Se decidió hacer un cálculo en base a valores experimentales. Dado un robot con dos motores que proporcionan una potencia final al conjunto de 19,61 N-cm se comprobó que podía transportar hasta 3,5 Kg (incluyendo su propio peso). Entonces con 2 motores de 26 N-cm y una relación de multiplicación 7 a 1 se calculó que aproximadamente podía transportar hasta 64 kg. Velocidad = 90 a 180 metros/minuto Carga = 52 N-cm * 3,5 Kg / 19,61 N-cm = 9,8 Kg Con una rueda de 10 cm. de diámetro se calcula la longitud de circunferencia: Con una relación de multiplicación de 7 Long Circ = 2 * pi * radio = 31,4 cm. Carga Final = 9,8 Kg * 7 = 64 Kg Con esta longitud se calcula las rpm Experimentalmente se comprobó que con la mitad de la tensión es posible transportar hasta Workshop del CAFR2005 60 Kg sin problema, variando solamente el factor de aceleración. 1.2 Otros factores a considerar La tensión de alimentación que esta relacionada con el consumo de corriente de los motores y el peso de las baterías necesarias. En base a esto se opto por motores de 24V dado que permiten un menor consumo de corriente con una potencia igual que uno de 12V en las mismas condiciones. Sumado al consumo medido de una CPU estándar y dado su bajo costo, se eligió usar dos baterías de gel de 12Volt x 7 Amperes libre de mantenimiento. 2. Transmisión y multiplicación Un factor importante es definir un método para trasmitir la potencia del motor a las ruedas, al mismo tiempo que se multiplica y se reduce la velocidad de salida del eje del motor. Se evaluaron tres métodos alternativos: • Reductores fijos • Correa dentada • Cadena 2.1. Reductores fijos: Existe gran variedad en el mercado, se logra multiplicar y reducir la velocidad en función de engranajes y usualmente tienen reducción por sinfín y corona o engranajes satelitales. Los primeros permiten transmitir mayor potencia pero con un alto costo de reducción de la velocidad de salida. Los segundos logran una mejor respuesta en velocidad pero su rendimiento disminuye con la velocidad al mismo tiempo que se encarecen. 2.2. Correa dentada: Se obtuvo un muy buen rendimiento con este sistema siendo sus principales ventajas: un bajo nivel de ruido, tamaño reducido de los engranajes, muy buena transferencia de potencia, y no requiere de mantenimiento. La principal desventaja es el elevado costo del mecanizado (fabricación) de los engranajes. Se evaluó también el uso de olring y correas en V, el primero tiene problemas en cuanto a la resistencia del material con que es fabricado, lo que ocasiona un estiramiento del mismo y un posterior resbalamiento sobre las poleas, para los encontrados en el mercado. En el segundo caso no se consiguió un tamaño adecuado de correa, al limitar el tamaño mínimo de la polea. 2.3. Cadena: Es el método más económico y utilizado en el en el segundo prototipo. Ventajas buena transferencia de potencia, bajo costo, engranajes disponibles en el mercado, regulación de distancia entre ejes. Desventajas: necesidad de mantenimiento, nivel de ruido medio, tamaño mínimo de engranajes según paso de la cadena. V. Interfase de potencia: El objetivo es mantenerla los mas sencilla posible y al menor costo. Se opto por controlar los motores directamente con un Driver-H (o H-bridge) aislados por opto acopladores y comandados directamente por medio del puerto paralelo del computador. El Driver-H esta compuesto por transistores comunes con la idea de mantener un bajo costo y un alto manejo de corriente y tensión (hasta 30V). Con transistores del tipo Tip31 se puede manejar corrientes de hasta 1,5amp. Con el mismo circuito, utilizando transistores de tipo Darlington (Tip127 y Tp122) se llego hasta una corriente de hasta 5Amp. en 30V. Y para corrientes de mas de 5Amp y hasta 20Amp esta previsto el diseño de una interfase con transistores Mosfet del tipo IRF4905 e IRFZ44 basados en un articulo publicado en siliconchip (Crivelli, 2004) Universidad de Morón Facultad de Informática, Cs. de la Comunicación y Técnicas Especiales Reconocimiento de imágenes, aplicado a agentes robóticos Norberto Carlos Mazza ([email protected]) RESUMEN Durante los últimos años hemos visto como las ciencias del campo de las tecnologías de la información fueron avanzando a un ritmo más que vertiginoso. Actualmente nos encontramos en un punto donde los avances más significativos desde el punto de vista social están dados por las aplicaciones de la inteligencia artificial a diversos sistemas. La visión puede ser considerada como uno de los sentidos más importantes que tienen los seres vivientes, ya que otorga un panorama del entorno que lo rodea. Si trasladamos razonamiento al campo de la robótica podríamos pensar en dotar a un agente robótico de la capacidad de ver su entorno, o desde un espectro más amplio, obtener datos de un entorno para facilitar el entrenamiento de un agente en un mundo virtual. El objetivo de este trabajo es presentar nociones básicas de visión artificial, robótica e inteligencia artificial, para luego si plantear un modelo teórico para el desarrollo de un sistema de reconocimiento de imágenes, para ser aplicado a agentes robóticos. Palabras clave: Reconocimiento de imágenes, inteligencia artificial, visión por computadora, robótica. 1. Introducción La cátedra de Robótica , de la Facultad de Informática Ciencias de la Comunicación y técnicas especiales, de la Universidad de Morón, está llevando a cabo un proyecto de investigación científica que tiene como objetivo la creación de un equipo de Fútbol Robot (robots jugadores de fútbol) para la liga de pequeña escala bajo los lineamientos establecidos en Robocup [1]. La presente tesis pretende desarrollar un sistema de visión que pueda ser aplicado al proyecto antes mencionado Para ello se desarrollara un Sistema de visión global y on-board, el cual deberá adquirir en tiempo real y de manera continua las imágenes del ambiente de trabajo de los robots, transformar las imágenes de la cámara en formatos que puedan ser procesados digitalmente, identificar, segmentar y posicionar los diferentes objetos presentes en el ambiente de trabajo, y transformar los datos obtenidos de las imágenes en información capaz de ser procesadas el equipo de fútbol. En el Módulo de Visión Global se realizan las actividades de segmentación y clasificación por coloración de objetos. Actualmente en este proceso se utiliza una técnica de umbral donde a cada color a identificar se le asigna por el usuario valores mínimos y máximos en cada componente RGB, con el fin de poder determinar si las componentes de un píxel dado se encuentra entre los componentes de umbral de un determinado color, si esto ocurre se dice que el píxel es de ese color. De esta manera es posible identificar los distintos objetos dentro de la cancha de juego del robot: píxeles anaranjados delimitan la pelota, píxeles blancos delimitan las líneas de las distintas zonas de la cancha, etc. 1 Debido a la naturaleza de la luminosidad del ambiente, los objetos dentro de la cancha presentan leves variaciones en sus tonalidades a través del tiempo, como por acción de leves cambios del ambiente producidos dentro y fuera de la cancha: Los objetos se mueven y proyectan sombras sobre otros, o dejan de proyectarla [4]. El cerebro humano, en el proceso de producción de la imagen, hace ajustes extraordinariamente rápidos para permitirnos reconocer, por ejemplo, un objeto de color azul a pesar de que en algunas zonas presente variaciones de luz y sombra. En el módulo de Visión de los robots se modelará este ajuste haciendo variaciones manuales en los valores de umbral de los distintos colores presentes en la cancha de juego. Figura 1 2 2. La Robótica Este término procede de la palabra robot1. La robótica es, por lo tanto, la rama del conocimiento que se ocupa del estudio, desarrollo y aplicaciones de los robots. Los robots son dispositivos compuestos de sensores que reciben datos de entrada y que pueden estar conectados a la computadora. Esta, al recibir la información de entrada, ordena al robot que efectúe una determinada acción. Puede ser que los propios robots dispongan de microprocesadores que reciben el input de los sensores y que estos microprocesadores ordenen al robot la ejecución de las acciones para las cuales está concebido. En este último caso, el propio robot es a su vez una computadora [2]. En la actualidad, los avances tecnológicos y científicos no han permitido todavía construir un robot realmente inteligente, aunque es posible que esto se logre algún día. Hoy por hoy, una de las finalidades de la construcción de robots es su intervención en los procesos de fabricación. Estos robots, que no tienen forma humana en absoluto, son los encargados de realizar trabajos repetitivos en las cadenas de proceso de fabricación, como por ejemplo: pintar al spray, moldear a inyección, soldar carrocerías de automóvil, trasladar materiales, etc. En una fábrica sin robots, los trabajos antes mencionados los realizan técnicos especialistas en cadenas de producción. Con los robots, el técnico puede librarse de la rutina y el riesgo que sus labores comportan, con lo que la empresa gana en rapidez, calidad y precisión [5]. 3. El Color Dentro del rango de la luz visible se presentan una serie de diferentes sensaciones que la luz produce en el ojo, que se denominan colores. Los colores son una propiedad de la luz. Estos pueden medirse de acuerdo a la frecuencia y a la longitud de onda. La sensibilidad del ojo humano a los colores depende de la longitud de onda de la luz [3], para la persona promedio esta es máxima dentro del color verde-amarillento. El color posee las siguientes propiedades: • Tonalidad: Consiste en los distintos matices que puede presentar un tono determinado cuando se descompone la luz blanca en sus distintos componentes. • Pureza: Esta propiedad se refiere a la proporción de blanco que posee un determinado color espectral. • Saturación: Un color saturado tiene un aspecto oscuro. Los colores rojo, verde y azul pueden presentar alta saturación y los mismos se aclaran cuando la saturación se reduce. El color amarillo más puro por el contrario, tiene una saturación baja. • Brillo: Se refiere a la intensidad del color y al cambiar este, afecta a la tonalidad, pareciendo más amarillentas, azuladas o verdosas. El número de colores posibles es infinito y se estima que el ojo puede distinguir unos 10 millones de tonalidades diferentes. 1 El término robot procede de la palabra checa robota, que significa 'trabajo obligatorio'; fue empleado por primera vez en la obra teatral de 1921 R.U.R. (Robots Universales de Rossum) por el novelista y dramaturgo checo Karel Èapek. 3 En función de las cualidades cromáticas definidas, se han establecido numerosas escalas de clasificación del color, diferentes de la primera elaborada por Newton. Así el físico británico James Clerk Maxwell, que analizó pormenorizadamente distintos aspectos de las radiaciones electromagnéticas, realizó en el siglo XIX la primera diferenciación cromática, según métodos de síntesis aditiva y sustractiva. Por su parte, el estadounidense Albert Munsell estableció a principios del siglo XX un catálogo de colores en el que se disponía de veinte tonos diferentes ordenados en un círculo. Los modelos de colores proveen una manera estándar para especificar un color particular, definiendo un sistema de coordenadas en 3D, y un sub-espacio que contiene todos los colores que se pueden construir con un modelo particular. Cualquier color que puede ser especificado usando un modelo corresponderá a un punto dentro del subespacio definido. Cada modelo de color está orientado bien sea a un hardware específico (RGB, CMY, YIQ) o a una aplicación de procesamiento de imágenes (HSI) 4. RoboCup RoboCup [6] es una iniciativa internacional de investigación y educación, nace como un intento para fomentar la investigación de la Inteligencia Artificial y Robótica. Este proyecto ha adoptado el juego de Fútbol como un problema estándar a resolver, para el cual es necesario integrar una amplia gama de tecnologías como: principios de diseño de agentes autónomos, colaboración de multi-agentes, adquisición de estrategias, razonamiento en tiempo real, y robótica entre otros. El objetivo final de RoboCup se estableció como: “A mediados del siglo 21, un equipo de jugadores robots humanoides totalmente autónomos ganará un juego de fútbol, de acuerdo a las reglas oficiales de la FIFA, contra el ganador de la Copa del Mundo más reciente.” Esta meta será uno de los grandes retos compartidos entre la Robótica y la Inteligencia Artificial para los próximos 50 años. Esta meta puede sonar ambiciosa dado el estado del arte de la tecnología actualmente, sin embargo, gracias a iniciativas de este tipo se fomenta la investigación de nuevas tecnologías para conseguir una serie de objetivos secundarios que están más al alcance. 5. Investigaciones Actuales Actualmente se están desarrollando investigaciones similares a esta, y ya se encuentran algunos prototipos. La cátedra de la Universidad de Lleida, España, ha desarrollado un robot el cuál incorpora un sistema de visión propio, que le permite jugar al fútbol, ya que diferencia balón, arcos y contrincantes. En la Universidad de las Américas-Puebla, México, se ha desarrollado un sistema de reconocimiento de rostros, el cuál es aplicable a sistemas de seguridad. En la Universidad Nacional del Centro de la provincia de Buenos Aires, se han realizado investigaciones sobre el software Doraemon, aplicando el reconocimiento de imágenes a la categoría Robocup e-League. 4 6. Objetivos Con el marco teórico referencial planteado en esta comunicación, se propone el siguiente objetivo general: ahondar en los aspectos específicos del reconocimiento imágenes y visión artificial, para así poder dejar planteado un marco teórico sobre el cual se pueda realizar el diseño y construcción de un sistema de reconocimiento de imágenes capaz de obtener las coordenadas de un objeto. 6. Hipótesis La hipótesis a contrastar se puede enunciar del siguiente modo: Se pueden construir robots capaces de reconocer imágenes mediante la utilización de camaras que emulen el comportamiento del ojo humano. 7. Metodología Para llevar a cabo esta investigación se efectuó una búsqueda documental a través de diferentes fuentes documentales a fin de elaborar las bases teóricas referenciales. Se indagó a través de libros, revistas especializadas y centros de investigación accesibles a través de Internet. Esta investigación es de tipo exploratoria, ya que pretende evaluar el estado del arte, mediante el uso de bibliografía y el contacto con personas que están desarrollando investigaciones similares actualmente. A su vez, se efectuará el desarrollo de un sistema de visión, el cual deberá poder detectar las coordenadas de un objeto. 8. Conclusiones En esta tesis se plantea desarrollar un sistema de reconocimiento de imágenes por medio de detección de umbral de colores. Al utilizar este metodo el sistema es tolerante a las variaciones que puedan llegar a ocurrir tanto en el ambiente de trabajo, como en los objetos observados (tales como las variaciones de luz del ambiente, color o tamaño). Existen múltiples tipos de aplicaciones para el campo de la visión artificial, en el caso de este trabajo se seleccionó la aplicación hacia un área especifica, lo cual no quiere decir que no pueda adaptarse el desarrollo a otro ámbito. 9. Futuras Líneas de Investigación A partir de los resultados obtenidos, se dejan planteadas las siguientes líneas de investigación: • Mejoras sobre el sistema desarrollado, y ampliación de la investigación. • Construcción de un robot sobre el cual se aplique el sistema de visión desarrollado. • Adaptación del sistema de visión al equipo de Fútbol Robot . 5 10. Referencias [1] Winston, Patrick H., (1994). Inteligencia Artificial. New York: AddisonWesley Iberoamericana, 3ª ed. [2] Mark Spong F.L. Lewis C.T. Abdallah (1993). Robot Control. Dynamic, Motion Planning and Analysis. New York: IEEE [3] Jullier Laurent. La Imagen Digital. Madrid: La Marca Editora. [4] D. Marravall Gomez-Allende, (1993). Reconocimiento de Formas y Visión Artificial. Madrid: Addison-Wesley Iberoamericana. [5] Carrobles Maeso, M. Manual de mecánica industrial, tomo V. Ed. Cultural S.A. Madrid. [6] www.robocup.org. Visitado en Septiembre de 2004. 6 Robótica (77) - 2004 El equipo SimpSot Norberto Mazza ( [email protected] ) Leandro Rodríguez ( [email protected] ) Facultad de Informática Universidad de Morón Cabildo 134 Morón (1708) Pcia. Buenos Aires República Argentina RESUMEN El equipo SimpSot se encuadra dentro de la categoría Large League Simurosot (FIRA), cuenta con un equipo que realizo una investigación para llegar a conseguir el material necesario para comenzar a incursionar en esta categoría. En la actualidad, el equipo no se encuentra preparado para competencias ya que está en una fase de desarrollo. Palabras clave: Robótica, simurosot, large league, cafr. 1. Introducción El equipo SimpSot surge como un frente de trabajo de la cátedra de Robótica de la Universidad de Morón, razón por la cual los integrantes del equipo tienen conocimientos mínimos en el área de fútbol de robots. Este equipo nació con la idea de ser el puntapié inicial para que la Universidad comenzar a competir en la categoría Large League Simurosot, además de competir en la Middle League Simurosot [1] en la que actualmente participa. Uno de los primeros pasos que tomó el equipo de trabajo, fue el de contactarse con personas y sitios que se encuentran trabajando en el ámbito, con el fin de conocer mejor el área de trabajo, para luego comenzar a realizar la investigación necesaria para llevar a cabo el trabajo. Nuestro primer gran desafío se baso en poner en funcionamiento el simulador. Este era de características diferentes a la de su par de la Middle League, ya que se basa en una arquitectura cliente/servidor (fig. 1). A partir de ese momento pusimos empeño en conseguir el cliente y un equipo base, factores que se hicieron posibles gracias a la colaboración del equipo Microsot de la República de Korea, quienes nos facilitaron dicho material. 1 Robótica (77) - 2004 fig. 1 De la misma forma en que fue nuestro primer desafío, se convirtió en nuestro primer logro: el simulador y el equipo base (equipo derecho) funcionaban. Esto nos planteo la necesidad de conseguir que el equipo contrincante funcione de manera equivalente. Esto ultimo se consiguió luego de realizar un análisis del código fuente del equipo. Este es el estado del arte del equipo. En el resto del documento trataremos de introducir al lector en cuestiones concernientes al servidor, cliente y equipo base de Large League Simurosot. 2. Servidor El servidor utilizado es un simulador útil para el desarrollo de estrategias de juego y algoritmos básicos para fútbol de robots. Este simulador es provisto por la FIRA [2] y fue desarrollado por el Harbin Institute of Technology. El simulador actualmente se encuentra en la versión 1.0 de su desarrollo. El campo de juego se encuentra dividido en diferentes zonas, tal como se indica en la fig 2. En esta figura se indican las posiciones de cada uno de los puntos fundamentales del juego. 2 Robótica (77) - 2004 fig. 2 El servidor además cuenta con un módulo de inteligencia artificial, el cual permite determinar las infracciones y el curso de las acciones a seguir [3]. 3. Cliente El cliente nos fue facilitado por el equipo Microsot (tal como se indica en la Introducción del presente documento). Este debe ser fusionado con el código del equipo, ya que trabajan en forma contigua. En una primera instancia la interfaz del módulo cliente nos pareció algo difícil de comprender, razón por la cual basándonos en esta hemos desarrollado una versión propia, la cual a nuestro parecer, resulta de mejor comprensión que su antecesora. La funcionalidad del cliente en sí no es demasiado amplia, lo cual no quiere decir que no sea importante, solo cumple el servicio de permitir que el equipo se comunique con el servidor. 4. Equipo El equipo base, al igual que el cliente nos fue cedido por la gente de Microsot. En una primera instancia, el equipo recibido solo funcionaba para el lado derecho. Esto fue motivo para que se comience a trabajar en conseguir un equipo base para el sector izquierdo. La estrategia actual de los equipos es la misma, los arqueros realizan movimientos transversales al campo de juego dependiendo de la ubicación de la pelota, y dos jugadores circulan detrás del balón (fig. 3). Debido a la escasez de tiempo para realizar la investigación no fue posible desarrollar una estrategia propia para uno de los dos equipos, lo cual quedará planteado como una futura línea de investigación. Tanto el equipo base, como el cliente se encuentran desarrollados bajo el paradigma de la programación orientada a objetos. fig. 3 3 Robótica (77) - 2004 5. Conclusiones Si bien el equipo de trabajo no cuenta con experiencia en el campo del fútbol de robots, ha conseguido adquirir conocimientos básicos del tema gracias a las personas que colaboraron en este trabajo de investigación. Consideramos que el objetivo que nos planteamos fue logrado, hemos conseguido la información necesaria para lograr un equipo base que sirva como cimientos para desarrollos futuros. Las líneas de investigación que proponemos a corto plazo son: • Enriquecer la información adquirida; • Investigar estrategias para aplicar al equipo base; • Desarrollo de un cliente propio; • Análisis y desarrollo de un equipo propio. 6. Referencias [1] El equipo Morasot. 2003. http://www.dc.uba.ar/people/cafr2003/ visitado en Septiembre de 2004 [2] FIRA Federation of Internatinal Robot-Soccer Association. http://www.fira.net visitado en Septiembre de 2004 [3] SimuroSot (11 vs. 11) RULE. 2003. http://www.fira.net/soccer/simurosot/overview.html visitado en septiembre de 2004. 4 LogViewer Javier Silveira – Lic. Gonzalo Zabala Centro de Altos Estudios en Tecnología Informática Facultad de Tecnología Informática Universidad Abierta Interamericana Introducción El LogViewer surgió como la respuesta a la necesidad de contar con una herramienta para poder analizar, utilizar y visualizar toda la información recolectada durante los partidos y también durante las pruebas hechas con nuestros equipos. Era muy importante desarrollar una aplicación que nos permitiera ordenar todos los comentarios enviados por el equipo a un archivo de salida y vincular cada comentario a un momento temporal preciso, o sea, al “cuadro” del partido en el cual se emitió cada comentario. Dado que cada comentario sólo tiene sentido en un contexto particular, que es cómo se está desarrollando el juego en un preciso momento (posición y rotación de todos los jugadores más la pelota en la cancha), decidimos que lo ideal seria registrar todos esos datos, junto con los comentarios, en un “log” para poder luego levantarlos desde el LogViewer. Una vez cargado el log por la aplicación, esta debía organizarlos en “cuadros” (instantes de juego) y permitir navegar por ellos cómodamente para analizar cuidadosamente qué ocurrió en cada instante y porqué. Dentro del proyecto inic ial también consideramos importante representar gráficamente la situación del partido en cada cuadro para poder seguir con mayor claridad el desarrollo del juego y entender qué originó cierto comportamiento o comentario. A medida que comenzamos a desarrollar el LogViewer y una vez cumplidos los objetivos iniciales, fue inevitable vislumbrar nuevas funciones para mejorar esta herramienta y extender su utilidad. Así es que actualmente es un programa mucho más complejo y completo que la mera respuesta a estos objetivos iniciales. Cómo se usa Lo primero que hay que hacer para poder utilizar el LogViewer es agregar al equipo el código necesario para que en cada cuadro imprima la siguiente información con este formato (r=Robot Propio, O=Robot Oponente y tener en cuenta que cada valor debe estar separado por un sólo espacio) : # R1.X R1.Y R1.rotation . . . R5.X R5.Y R5.rotation O1.X O1.Y O1.rotation . . . O5.X O5.Y O5.rotation Ball.X Ball.Y Ball.rotation # COMENTARIOS: La salida debe tener necesariamente estas líneas de código para poder ser interpretadas por el LogViewer como un log de un partido. A partir de ella obtendrá la información de los jugadores y la pelota, e interpretará todo lo que quede entre “# COMENTARIOS:” y el próximo “#” como comentarios que en el LogViewer se mostrarán en el cuadro correspondientes (y que quedarán asociados al cuadro en el cual se emitieron). Una vez hecho esto, sólo resta poner a jugar el equipo y asegurarse que todos los comentarios y salidas vallan a parar a un archivo de texto. Cargar un Log: Una vez en el LogViewer, usando el botón “Abrir Log...” aparece una ventana para seleccionar el archivo. Elija el archivo de salida de su equipo y el LogViewer lo cargará, procesará su contenido y además detectará los goles. Con el botón “Reload Log” se carga nuevamente el último log cargado. Esto es muy útil cuando se está trabajando simultáneamente con el simulador y se quiere recargar el log debido a que este ha cambiado. Reproducir y navegar por los cuadros: Para “navegar” durante el juego utilice los botones que se encuentran debajo de la cancha. Con “Rew” va al primer cuadro. Con “Slow” reproduce a una velocidad limitada. Con “>>” reproducirá el partido a la mayor velocidad que le permitan las características de su computadora (esto puede ser tanto a 30 fps en algunas computadoras como 100 fps en otras). Con “2x >>” salta de a dos cuadros, alcanzando el doble de velocidad (pero obviamente salteando cuadros). Con “4x >>” salta de cuatro cuadros, alcanzando el cuádruple de velocidad. Estos últimos dos modos de reproducir son especialmente útiles si se trata de computadoras no muy potentes y se desee mirar rápidamente un partido. Finalmente con “Stop” deja de animarse el partido y queda en un cuadro fijo. Para avanzar o retroceder de a un cuadro use la barra de desplazamiento o las flechas izquierda y derecha del teclado. Detección de goles y de faltas: Los goles se detectan automáticamente al cargarse cada log. Son representados en color rojo en la barra verde que se encuentra debajo de la cancha. Esta barra representa todos los cuadros del partido, y el color de cada cuadro tienen un significado. Los cuadros rojos representan cuadros en los cuales la pelota está dentro del arco de cualquiera de los dos equipos, los verdes representan juego normal y los azules cuadros que no se pudieron cargar o procesar correctamente (seguramente debido a una incorrecta definición de los datos necesarios en todo log o por que aparecen en los comentarios caracteres reservados del LogViewer como el “#”. Se puede navegar por los distintos goles con las teclas “Insert” y “Supr”. El LogViewer actualmente detecta las faltas causadas por tener una cantidad de jugadores en las áreas chicas y grandes mayor a la permitida. Éstas son representadas con un cartel rojo que aparece (cuando se produce la falta) debajo del número de frame. Hacer zoom sobre la cancha : Se puede hacer un “zoom” en un área particular de la cancha manteniendo presionada la tecla “SHIFT” y haciendo click en el punto en el cual se quiere hacer zoom y luego (con el botón apretado) moviendo el mouse hacia arriba (para acercar) o hacia abajo (para alejar). Una vez hecho el zoom, se puede “arrastrar” la cancha hacia cualquier dirección para ver áreas fuera de la vista. Buscar palabras en los comentarios: Puede buscar una cadena de texto en los comentarios de todo el partido escribiendo la cadena en el cuadro de texto que dice “Ingrese texto” y presionando el botón a la derecha. Una ventana aparecerá con la lista de cuadros o “Frames” en los que se ha encontrado esa cadena y haciendo doble click sobre los cuadros se saltará directamente a ese momento del partido. Medir distancia entre dos puntos: Otra herramienta muy útil es la de medir manualmente una distancia entre dos puntos del campo de juego. Para esto presione el botón que dice “Medir Distancia” y luego marque el primer punto. Moviendo el cursor aparecerá la distancia al punto sobre el que éste se encuentre posicionado. Hacer marcas en la cancha : En el campo de juego se pueden marcar rectas tanto horizontales como verticales, puntos y áreas rectangulares. Para esto utilice el menú contextual que aparece al hacer click con el botón derecho sobre la cancha (caso en el cual las marcas estarán posicionadas en el punto donde usted hizo click derecho) o sino puedo presionar el botón “Agregar / eliminar marcas” y aparecerá una ventana con la lista de marcas existentes donde podrá eliminar marcas o agregar nuevas marcas definiendo numéricamente la posición de las mismas. También se puede elegir un nombre y un color para cada marca. Proyección de la pelota: Tanto del menú contextual de la cancha como de las preferencias, se puede activar o desactivar la opción de que el LogViewer dibuje una recta con la proyección lineal de la trayectoria de la pelota. Esto es útil si se está trabajando con “jugadores” que tienen en cuenta esta trayectoria en su comportamiento. Marcas temporales en la cancha : Una de las funciones más potentes del LogViewer es que provee una suerte de “código” o sintaxis mediante la cual si se imprimen en el archivo de salida comentarios que responden a una forma específica, estos serán interpretados por el LogViewer como elementos especiales con distintas representaciones. Actualmente existen dos marcas de este tipo y son temporales ya que se representan en la pantalla únicamente en el cuadro en el cual fueron enviadas. Estas son: Puntos: Con lo indica su nombre, son puntos que se marcan en la cancha. Para ser interpretados como tales, el comentario debe tener la siguiente forma o sintaxis (si NRODEJUGADOR es igual a –1 el color del punto será rosa) : VEC$ [ PUNTO.X , PUNTO.Y ] NRODEJUGADOR [ Texto: Permite mostrar texto directamente en el campo de juego y de forma flotante asociadas a un robot en particular, con su color y al lado de los mismos. Para ser interpretados como tales, el comentario debe tener la siguiente sintaxis: TXT$[ TEXTO ] NRODEJUGADOR [ Por defecto todo lo que es detectado como marcas temporales no son mostradas como comentarios, a menos que se desactive la opción “Eliminar marcas temporales de los comentarios” en las preferencias. Especificaciones técnicas Algunas características técnicas que posee son: • Desarrollado en java • Internamentente, cuando se carga el log la información se levanta a un modelo de objetos en el cual están modelados los robots y un objeto que denominamos “disposición”, que contiene los diez robots y la pelota. Cada partido entonces se almacena en un vector de “disposiciones”. • Lo más destacable de la parte gráfica es que para evitar toda clase de parpadeo o refresco visible de la pantalla, se utiliza la técnica del doble buffer, utilizada para animaciones en java y que consiste en dibujar todo en memoria y recién al final mostrar la imagen terminada en pantalla. Además se redefinen los métodos que refrescan la pantalla en java, como por ejemplo el método “update”. Posibles futuras mejoras y nuevas funciones • Poder definir formatos personalizados para cada log, o sea, poder definir cómo interpretar cada log y poder cargar toda clase de logs (aún cuando quizás estos no fueron creados con el objetivo de ser cargados con el LogViewer). • Ampliar la comunicación directa entre comentarios y LogViewer (como es el caso de las marcas temporales) mediante un conjunto de nuevas palabras claves o sintaxis especiales que sean detectadas en los comentarios e interpretadas por el LogViewer. • Agregar a la información fija de cada cuadro la velocidad de las ruedas izquierda y derecha de cada robot y representar a estas gráficamente como un vector cuyo módulo esté dado por la velocidad. • Hacer la detección de faltas (por ejemplo el penal) más flexible y parametrizable. Referencias Balich, Néstor Adrián “Aspectos básicos de Robots Autónomos y Lineamientos para la Construcción” CAFR2004 – INICEN – TANDIL- Buenos Aires – Argentina. Reglamento, ROBOCUP proyecto internacional para promover el desarrollo de la robótica e IA http://www.robocup.org EIGEN, Team Descripción Hikari Fuji, Yusuke Ohde, Masayuki Kato, Fumitaka Otsuka, Naoko Sema http://www.yoshida.sd.keio.ac.jp Marie Kawashima, Eisuke Sugiyama, Suichi Nizuma, and Kazuo Yoshida Departamento of System Designe Engineering, Keio University – Japón VolksBot Plataforma comercial diferencial www.volksbot.de con transmisión Petrov, 2004 vorgelegt von Slav Petrov [email protected] - Computer Vision, Sensorfusion und verhaktenssteuerung für fussball-roboter – am Fachbereich Mathematik und Informatik der Freien Unversität Berlin. 17 Mai 2004 Lima, 2004 Pedro Lima, Luis Custódio, Pedro Pinheiro, Hugo Costelha, Goncalo Neto, Vasco Pires, Miguel Arroz, Bob Vecht -ISocRob 2004: Team Description Paper – Instituto de Sistemas e Robótica, Instituto Superior Técnico, Lisboa, Portugal http://socrob.isr.ist.utl.pt/indexMSL.php Crivelli, 2004 Frank Crivelli – Motor speed controller – Siliconchip - December 2004 http://www.siliconchip.com.au/cms/A_103246/article.ht ml Buchheim, 2004 Team Description Paper 2004 CoPS Stuttgart – IPVS, University of Stuttgart, Germany [email protected] Maeda, 2005 Yoichiro Maeda, Wataru Shimizuahira, Satoshi Hanaka and Kensuku Mizutani - “FCSoromons” Team Description – Robocup 2005 - Dept. of Human and Artifical Intelligent Systems, Faculty of Engineering, University of Fuki , Japan http://www.ir.his.fukui-u.ac.jp/robocup/index-e.html Moreira, 2004 – António Paulo Moreira ¹ ² , Paulo Costa ¹ ² , Armando Sousa ¹ ² , Luís Paulo Reis ¹ ³ 5dpo-2000 Team Description for Year 2003 – ¹ FEUP – Faculdade de Engenhaia da Universidade do Porto - ² ISR – Instituto de Sistemas e Robótica – Porto - ³ LIACC – Laboratorio de Inteligencia Artificial e Ciencia de Computadores da Univ. Porto II. Descripción Técnica de Equipos II.a Nivel de enseñanza Universitaria y Particulares Workshop del CAFR2005 El Equipo Futbol Robots GallitoSoT Corlevich, María Lorena – Escobar, Daniel Pascal – Guerrero, Alejandro – Montenegro, Victor Facultad de Informática Universidad de Morón Cabildo 134 Morón (1708) Pcia. Buenos Aires República Argentina Resumen: El equipo de GallitoSoT de la Universidad de Morón compite por segundo año consecutivo en la categoría Simurosot del Campeonato Argentino de Fútbol de Robots 2005. La arquitectura del equipo ha evolucionado hacia la modelización del ambiente basándose en el paradigma orientado a objetos. La base del equipo se sustenta sobre la división de roles entre los diferentes jugadores, adoptando el criterio de acuerdo a su ubicación en la cancha y el estado del juego en ese momento, obteniendo de esta forma roles bien definidos en tres campos: arquero, defensor y delantero. Esta división permite a cada grupo trabajar de forma coordinada, para lograr alcanzar el objetivo común de todo el equipo. Palabras clave: CAFR, Simurosot, División-de-Roles, Navegación-de-Robots. I. Introducción El equipo GallitoSoT de la Universidad de Morón se formo a fines del mes de abril del 2004, por medio de una convocatoria educativa impulsada por el Sr. Anibal Potenza, integrante del equipo MORASOT de nuestra universidad. La demostración del trabajo y el desarrollo alcanzado del equipo MORASOT en el campeonato organizado por la FIRA del año 2003, logro despertar la iniciativa para formar un nuevo equipo que siguiera los pasos de su inspirador. Así pues el equipo GallitoSoT hizo su debut durante el Campeonato Argentino de Fútbol de Robots del 2004, en la categoría Simurosot, obteniendo resultados realmente muy satisfactorios, pese a su corta experiencia. Frente a la realización del nuevo campeonato que nos convoca nos encontramos con un equipo que ha migrado su arquitectura hacia la modelización del ambiente basándose en el paradigma orientado a objetos, lo que nos ha beneficiado enormemente en materia de simplicidad y claridad en la programación. La base de nuestro equipo continua sustentándose en la división de roles entre los diferentes jugadores, adoptando el criterio de acuerdo a su ubicación en la cancha y el estado del juego en ese momento. Esta división permite a cada grupo trabajar de forma coordinada, para lograr alcanzar el objetivo común de todo el equipo. La evolución de nuestra arquitectura se vio acompañada por una fuerte investigación en materia de navegación de robots, lo que nos permitió desarrollar una nueva navegación a la hemos denominado Navegación Híbrida, ya que posee aportes de la navegación diferencial, la navegación difusa, la navegación autónoma diferencial, y navegación directVG. Permitiendo de esta manera un desplazamiento más preciso y veloz de nuestros jugadores en el ámbito del juego. En los puntos siguientes desarrollaremos la nueva arquitectura del equipo, el punto de partida de nuestra investigación sobre navegación de robots, el enfoque con que se distribuyo el mismo en el ámbito de juego y la implementación de ellos en la dinámica del juego; como a su vez la respuesta a necesidades que se nos han ido planteando. La clase Jugador hereda todas las variables y métodos de la clase Navegación y establece una superclase de lo que son las clases Arquero, Defensor y Delantero que incluyen la estrategia de juego de cada jugador de acuerdo a su rol específico. A su vez la gran revelación lo constituyen los métodos que se encargan de Transponer la Cancha. Estos métodos son comunes a las clases Cancha y Navegación. Su función es la transposición de las líneas de la cancha y de volver transparente para los robots la pertenencia a los equipos azul o amarillo, brindándoles la inteligencia necesaria para decidir por que equipo se encuentran jugando en cada momento, respectivamente. II. Arquitectura del equipo. Nuestro equipo ha migrado su arquitectura hacia la modelización del ambiente basándose en el paradigma orientado a objetos, lo que nos ha beneficiado enormemente en materia de simplicidad y claridad en la programación. En nuestro equipo cada elemento del juego se define mediante una clase, a saber: Cancha, Navegación, Jugador y Faltas. A su vez la clase Jugador hereda los métodos de la clase Navegación; y dependen de la clase Jugador los diferentes roles de juego que son las clases: Arquero, Defensor y Delantero. La clase Cancha contiene todas las variables que definen al campo de juego que son utilizadas por nuestros jugadores al momento de plantar la estrategia. Sus métodos se basan en la definición y obtención de las líneas imaginarias que delimitan los diferentes sectores críticos del campo de juego. La clase Navegación involucra los métodos que le brindan movilidad al equipo, como por ejemplo: NavDirecVG, NavDiferencial, NavAutonoma y VisiónCircular. II. Navegación de Robots. La evolución de nuestra arquitectura se vio acompañada por una fuerte investigación en materia de navegación de robots, lo que nos permitió desarrollar una nueva navegación a la hemos denominado Navegación Híbrida. La Navegación Híbrida toma conceptos definidos por la navegación diferencial, la navegación difusa, la navegación autónoma diferencial, y navegación directVG. Posee la velocidad que le brinda una navegación diferencial, la independencia y decisión fundada por una navegación autónoma diferencial, la predicción y visión base de la navegación difusa, y una visión difusa de la distancia en grados aportada por la navegación directVG. De esta forma se permite un desplazamiento más preciso y veloz de nuestros jugadores en el ámbito del juego. La navegación se centra en que cada jugador crea su propio eje de coordenadas, donde el cero del robot se convierte en su nuevo cero absoluto y a partil de él traza los ejes mencionados. Imagen 1 – Visión Circular. 2 Workshop del CAFR2005 Imagen 2 – Navegación Híbrida. III. Roles del equipo. La idea de la identificación de roles definidos es poder mantener la independencia entre los jugadores de acuerdo a su desempeño en la cancha y su obligación que cumplen en la misma. Nos encontramos con tres tipos de roles fuertemente definidos: arquero, defensores y delanteros, cada uno de los cuales se ve representado en nuestro modelo de clases y contienen implementada su estrategia de juego propia. A su vez existe un rol de “director técnico”, correspondiente a la clase jugador, el cual se encarga, como su nombre lo indica, de la dirección general del equipo para lograr el objetivo común del mismo durante el desempeño del juego. IV. División del campo de juego. Las líneas imaginarias que dividen el medio ambiente con el fin de poder recalcular de forma mas precisa la ubicación de los objetos entregados por el simulador, se mantuvieron constantes en nuestro equipo debido al beneficio que ha producido su implementación en el desarrollo de las estrategias del mismo. Para el trazado de las líneas se contemplan aquellas divisiones que sean reutilizables para la mayoría de los roles y que tengan como fin ayudar y no confundir o complicar. Estas divisiones dan a lugar la posibilidad de establecer la ubicación de nuestros jugadores, los oponentes y la pelota. Por medio de los métodos implementados en nuestras clases se evalúan los datos entregados por el ambiente y se obtiene como consecuente el tipo de caso en que se encuentra el juego, para próximamente posicionar, direccionar o preparar a los jugadores de forma tal de que estos reaccionen según los datos obtenidos, fomentando continuamente el cambio de roles entre ellos de acuerdo a los diferentes estados por los que se posiciona el juego. Imagen 3 – División de la cancha. En todo momento se intenta mantener la independencia entre los sectores obtenidos, pero la misma se ve amenazada por cortos intervalos de tiempo que es cuando se salta de un sector a otro. No todos los roles llegan a participar en todos los casos ni en todos los sectores del juego, si no que algunos se concentran y especifican sus funciones en regiones del juego limitadas. El cambio de roles permite darle diversidad y una mayor funcionalidad a cada situación de juego con respecto a nuestros jugadores, los oponentes, el estado actual de la pelota y la predicción de la próxima jugada a ejecutarse. la defensa, los jugadores se encuentran desfasados entre ellos, de tal forma se intenta conseguir que los jugadores no tengan la misma ubicación horizontal. A su diferencia con la defensa de líneas cruzadas, con esta se logra una reacción mas rápida ante la pelota y cubre mayor área de juego. Imagen 4 – División de la cancha. V. Formación del Equipo La formación del equipo esta, como se menciono anteriormente, compuesta por un arquero, dos defensores y dos delanteros, cuyos roles en el ámbito de juego están definidos de acuerdo a la ubicación que ocupan, pero los mismos se intercambian de acuerdo a la ubicación del jugador en la cancha y la evaluación de los factores anteriormente mencionados. El rol del arquero describe un movimiento de un semicírculo que abarca el área chica, con esto se intenta obtener una mayor reacción en situaciones que el arquero se vea desplazado del área chica, también se adquirió una mejor ubicación en situaciones de ataque por los laterales. El arquero además contiene las funciones normales que destacan al comportamiento de un arquero, que son las de bloqueo de pelota y su reincorporación lo más inmediatamente posible al área chica. Los defensores se posiciona de acuerdo a la situación de la chancha de juego, podemos destacar dos comportamientos principales: una defensa vertical y una defensa en forma de cruz. La defensa lateral esta compuesta por múltiples niveles de líneas, que de acuerdo a la cercanía de la pelota con respecto a nuestro arco van cambiando la disposición de Imagen 5 – Traza del arquero. Imagen 6 – Defensa lateral. 4 Workshop del CAFR2005 El inconveniente con que nos tropezamos es que existe una región en donde las dos líneas convergen y es la zona donde el cambio de rol se ve mas intensificado de acuerdo a la sincronización entre los jugadores, ya que cualquier inconveniente que se obtenga en esta área dará por consecuencia un decremento considerable de la eficiencia de esta estrategia. delanteros en su rol de juego ha ocasionado que en el conjunto de todo el equipo, el rendimiento de los mismos se vea muy favorecido por la cooperación de los defensores y la fuerte disposición del arquero frente al equipo rival. VI. Conclusiones. La evolución de nuestro equipo ha sido uno de los mayores logros que obtuvimos con base en el esfuerzo y la dedicación. El poder desarrollar y explorar nuestra ideas ha conseguido satisfacer nuestras expectativas y llenarnos de nuevas ideas a implementar en un futuro no tan lejano. Sabemos que mucho es el camino que le queda a GallitoSot por recorrer pero con una base sólida y confiable, una dedicación y un equipo de trabajo unido y robusto las ideas se podrán plasmar en nuevas visiones y estrategias que innoven en la simulación de fútbol de robots. Imagen 7 – Defensa Cruzada. La función básica de los delanteros se ve íntimamente relacionada con la posición actual de la pelota de juego y con la predicción de los próximos movimientos tanto del equipo contrario como de la pelota. Los jugadores tienen una trayectoria base que recorren con el fin de anotar un gol y a su vez deben contener con sus movimientos el ataque del equipo contrario. Cuando se sitúa en el área critica, frente al arquero rival, la finalidad del jugador es convertir el gol sin cometer faltas en contra del juego. De acuerdo al ángulo en el cual se encuentre posicionado y en dónde se situe la pelota, busca la mejor forma de llegar a su cometido o si se encuentra un integrante del equipo con mejor posicionamiento que el mismo procede a realizar el pase de la pelota. La finalidad de la implementación de los Referencias [1] Ramirez, Gustavo. Método de aprendizaje simple para navegación de Minirobots móviles rodantes. [2] Cañas Plaza, Jose M. Navegación global de un robot usando el método del gradiente. SPIRITUAL MACHINE TEAM Freedman, Hernán G. – Mon, Gonzalo 3368 Fco. Beiró Av. - Floor 12º Apt. D Capital, Buenos Aires, 1419, Argentina ABSTRACT The Spiritual Machine Team was developed in a non – academical environment motivated by the challenge of solving a simple comprehension problem and complex resolution. In every moment, we tried to raise the problem on simple, modular concepts and great adaptability to a high dynamical environment. Spiritual machine is a team that looks forward to create a game philosophy and mobility far from the physical environment, dimensions and field shape, from the capacity and time given, in a way that could be easily extrapolated to other application environments (either real or virtual ones). We dispose of several ways of playing that the team may choose during the match, so as to all players may be part in the defence, attack or steady positions to get a defendant and more accurate behavior. These possibilities give to the team a great flexibility and adaptability to the opponent. Its first participation was in CAFR2004 (Argentine Championship of RoboSoccer 2004) where it won the Second Prize in the Simurosot category. 1. INTRODUCTION The general development concept was to achieve that the robots move quickly, in a precise way and with the minor quantity of possible corrections in its path. This tries to reserve execution time to process the strategy. On this base, we prefer that the players are in continual movement instead of being quiet or spinning in itself. We define two navigation methods, one that guaranties an angle of destination reach and another that not. By means of these two movements we get the navigation of all players. The result of this is a team that moves quickly and kicks the ball in the right direction, to achieve this; we should work a lot with a very dynamical navigation which describes the curves to avoid the robot stops when changes the path and a good manage of the inertia provoked by the continual change of directions. This navigation is divided into two great groups of routines, ones are applied to large distances to the ball (macro- environment) and others are in charge of short distances navigation (microenvironment), this experience showed us that in cases applied to the first group, they did not work well being next to the ball, because of a simple movement in it provoked a sudden change of situation that in a macro environment do not occur easily. Another main tool to be able to work with this so dynamical plan was the development of a good routine of predicting the ball which gets to transform all this dynamism in a situation of ecstatic analysis of the ball to future letting to the robots carry out the navigation to an affective target and so be able to create plays. This prediction takes into account rebounds and changes of path provoked by own players as opponent ones. 2. TEAM DEVELOPMENT STRUCTURE We define the team structure through the following modules: Environment: check data that would be used for the rest of the modules. Some of these data are the position of the contrary team, statistics about ball possession, past, present & future ball positions and the robots. Prediction: Evaluate the future position of the ball and robots taking into account their paths. This calculation is made to each robot in particular according to its velocity and distance to the ball, giving as a result the future position respect to the ball in the field, and a t value that represents the time that the robot will need to reach the ball. As the ball is a mobile object, which has velocity, acceleration and direction, this value is calculated by means of an iterative algorithm which pretends to get a coincidence between the ball position and the robot one, taking into account their paths, in a certain time. The iteration not always reaches an exact result and is stopped when it achieves the accuracy you want. Strategy: gives roles to the players and orders their movements. The roles are not static, these go interchanging in order to the position of the robots (either own ones or contrary ones) and to the ball. Navigation: is responsible for the transfer of that robot to the specifical destination by the strategy. It uses two basic functions that coordinated ensures the final reach with an accurate angle at a maximum velocity. Kicking: Define a play when the ball is in the microenvironment of the robot. There are three kinds of kicking depending on the angle of the robot to the objective, this could be straight, gyratory or by the side, thus we may get to optimize the chances of kicking at an objective in case of reaching the ball with a no-ever ideal orientation. Log: A very important module, who is in charge of the LOG, made possible the well development and the constant improvement of the team. The function of this module is registering the development of the match. As a result of this, we get the following possibilities: - Have a Backup of the played matches for a posterior analysis, in which, in general, we may get improvements. -Evaluate how our own team works, detecting development mistakes. This module give us as a result a file that in a posterior step is analysed by a soft developed by us which let us watch the replay, watch and analyse the paths, real objectives and predicted ones. Besides, let you make numerical velocities analysis, accelerations and distances to the robots and to the ball. 3. ROLES We define as role to the different behaviors that may take a player in the development of the play. As follows, The goalkeeper: It develops a circular path which results very effective to reduce the projection field of contrary shoots to our goal. Besides, it results very good to clear away balls which come from the lateral sides, clearing away the ball to the centre of the field, as avoids too and resolves the problems caused by contraries who intend to make goals using the brute force by the lateral sides by the bottom line of the field. This technique has its roots in the philosophy used in any martial arts, especially AIKIDO, in which you try to make use of the rival strength to become it in a favourable factor for you and so you win. The goalkeeper, taking into account this concept, does not try to restrain the opponents which are trying to make goals using the add up of the strength of many of them, because it would be impossible to him just doing it by physical matters, but he make use of it and with a simple revolving movement he move them to the centre of the field, making fail their targets. The defender: It develops too a circular path with a major radio than the goalkeeper, but with a minor passive attitude in certain occasions, but with riskier kicking and clearing away features. Middle field player: It develops its game in the middle field line and its main function is catching all balls which try to return to our field and send them to the contrary field. Thus, he achieve to get a great quantity of attacks of the opponent, keeping the play the contrary field which increases the chances to get more goals from the forward players and the others. The forward player: It tries to focus its radio of action in the third offensive part of the field. He counts on a feature of receiving the passes very well and executes shoots to the goal with many objectives in order to the position of the contrary team. This evaluates time by time the ball path, and it sets close, so it tries to be always good positioned to receive a pass or a clearing of the opposite team, increasing its possibilities of achieving a goal. The whole field player: It presents the more complex features and tries to give dynamism to the play contributing with the whole roles and making circulate the ball to the contrary goal. Clearing player: This role is taken when, after evaluating that the conditions are appropriated and secure, the player abandon its position and risk itself, searching the shorter path to the ball and trying to touch the ball to clear it. This role is used mainly in the defence, although in many situations is used too in the middle field. To ensure that a situation is secure to clear the ball, we evaluate the time that all the players take to reach the ball (either own or opposite ones) and if the one who has the minor time is own and there is a certain margin with the minor time of the contrary, so it takes that role. The result is the creation of situations in which the team pass of an unfavourable situation to a very favourable one, with great possibilities to escape alone to the opposite goal. Ball waiter: With this role we try to distribute the team position in a more accurate way in the field. This role is taken in those occasions in which many own players go to the ball, so one or many of them (depending on the quantity) is chosen to be positioned in a place more behind the ball, between it and the own goal. This is made for the following reason: to avoid that everyone run behind the ball and give a major security, having the chance to recover the ball supposing that who go to catch it do not reach it, either because an opposite player have stolen it or because there was a mistake in the calculation of the prediction. Perimeter Line Player: This player presents the necessary features to be able to develop the game against the field edges. Its unique function is to push the ball or an own player, with the objective of restrain an attack and make goals in the bottom line of the opposite goal. 4. STRATEGY We have decided to give non-static, interchanging roles to the players, this allows, sometimes, to resolve a situation, in minor time, when distribute the roles, as better as could, in order to times & distances, mainly in those critical situations when it is necessary to clear away a ball or define a play. Neither the kinds of roles are not distributed in a uniform way nor are given depending on the defensive or attack attitude that the team may take. This means that, for instance, that in a certain situation the team may defend with 3 players, or perhaps attack with all of them. The strategic module feeds constantly from the information generated by the environment which may provoke the sudden change of a defensive attitude to a very aggressive in order to the time, result or making use of any weakness detected by the contrary team. 5. CONCLUSIONS The participation in the CAFR2004 enriched us thanks to the contact with other teams; let us measure our concepts and the way in which we have applied it. We think that be part in a worldwide championship has helped us to test our concepts in a more demanding level and so we could see our weakness and strongness, which will help that our team keep growing. Our target to future is that some of the concepts of our team be applied in the real robots category. 6. BIBLIOGRAPHY [1] Castelo Claudia, Fassi Hector, Scarpettini Flavio. “Fútbol de Robots: Revisión Workshop del CAFR2003 del Estado del Arte y Desarrollo del Equipo UBASot de Simulación. Tesis de Licenciatura. “, Buenos Aires, December 2002. Campeonato Argentino de Fútbol Robot 2005 EvoluSOT JSI Claro, Martín - D´Alessandro, Gabriel – Gazolli, Andrés - Lorusso, Emiliano – Pereira, Gustavo Robótica Facultad de Informática Universidad de Morón Cabildo 134 Morón (1708) Pcia. Buenos Aires República Argentina Resumen: El equipo EvoluSOT JSI de la Universidad de Morón modeliza el ambiente de juego utilizando una arquitectura orientada a objetos. Cada elemento del ambiente está visto como una clase generando en el caso de los jugadores a Rol a desarrollar y las estrategias que deberá seguir durante el transcurso del juego. Palabras clave: CAFR, Simurosot, Universidad_de_Morón I. Introducción III. Comportamiento de los roles El equipo EvoluSOT JSI nace como parte de la motivación brindada por la Universidad de Morón en el desarrollo de equipos de fútbol de robots simulados. Cabe aclarar que la Universidad ya ha participado en los últimos dos campeonatos obteniendo en el CAFR 2003 el tercer puesto con el equipo Morasot. Y en el CAFR 2004 participando con dos equipos, Morasot 2 y GallitoSot. II. Modelización del Equipo Todo elemento del juego, jugadores, campo, pelota, son definidos por una clase C++. Las clases son instanciadas al comenzar y cada vez que el simulador entrega los datos del juego se procede a entregar esos datos para el desarrollo de la estrategia del equipo. Cada jugador es independiente del resto, solamente son relacionados por medio de un método que determina las condiciones del juego y determina la estrategia con la que debe desenvolverse el equipo. 1- Rol Arquero El arquero posee tres situaciones distintas de juego: en primera instancia, debe verificar si la pelota se aproxima por su derecha, de ser así el arquero procederá a acercarse hacia la línea que define el limite del arco de su derecha para proteger el arco y así evitar un posible gol. El arquero realiza un procedimiento análogo en el caso de que la pelota se acerque hacia el arco por el costado izquierdo. En cambio si la jugada oponente se efectuara frente al arco, el arquero deberá determinar de acuerdo a la predicción de la pelota cual será su próxima posición para poder adelantarse y así poder frenar el posible gol. En caso de tener la pelota muy cercana a el, el arquero procederá despejarla para cortar la jugada contraria y quitar al equipo del riesgo de gol. la pelota hacia la mitad de cancha oponente. Si consigue el control de la pelota procederá a llevarla hacia el arco intentando evitar que tanto los defensores como el arquero eviten la jugada y se pueda convertir el gol. Si la pelota se encuentra en la media cancha de su propio equipo, el delantero procederá a dar apoyo a los defensores esperando un despeje cerca de la mitad de cancha. Fig 1 Comportamiento del Arquero 2- Rol Defensor Al bajar la pelota de la media cancha el defensor buscará frenar el ataque contrario, dos jugadores tomarán este rol y buscarán la embestir la pelota para desviarla de su dirección con la intención de despejarla. En el caso de que la pelota no esté en el área del equipo, los defensores actuarán como apoyo al ataque, evitando en lo posible no pasar de la mitad de la cancha. Fig 2 Comportamiento del Defensor 3-Rol Delantero El delantero básicamente busca un despeje de Fig 3 Comportamiento del Delantero IV. Estrategias de Juego A pesar de estar bien definida la cantidad de jugadores por rol, dependiendo del estado del juego, los robots pueden asumir cualquier rol, Permitiendo así el comportamiento del robot dependiendo del estado en que se encuentre el juego, ya sea: estado de riesgo alto, estado de riesgo medio y estado de riesgo bajo. El estado de riesgo alto permitirá una estrategia mucho mas defensiva, dando prioridad a la asignación de los roles del aquero y de los defensores. El estado de riesgo medio, será una posición mas neutra, donde se buscará un despeje de la pelota para así conseguir una situación de ataque contra el arco del equipo contrario. En el estado de riesgo bajo, el equipo no se encuentra en peligro, sino que se encuentra jugando sobre la mitad de cancha oponente e Campeonato Argentino de Fútbol Robot 2005 intentará concretar el gol. En este estado se dará mayor prioridad a la asignación de los roles de los delanteros. V. Zonas de la cancha Se han definido diversas zonas por las cuales los robots procederán a moverse y donde asumirán los diversos roles. 3-Zona de apoyo Esta zona será en donde esperarán tanto los defensores, en caso de que se esté en una situación de ataque, como donde esperarán los delanteros el despeje en una situación de defensa del arco. 1-Lineas de defensa Los robots que tomen el rol de Defensor se moverán entre las tres líneas que se muestran en la figura. Fig 6 Zona Apoyo Fig 4 Lineas de defensa 2- Zona de ataque Los delanteros realizarán ataques contra el arco contrario solo cuando la pelota se encuentre en el área marcada Fig 5 Zona de ataque VI. Conclusiones EvoluSOT JSI aprovecha la experiencia obtenida en años anteriores para conseguir un equipo en estado de armonía. El manejo de los roles mediante objetos ha permitido una modelización mucho más sencilla y ha llevado a una comprensión mas alta de las posibilidades que puede brindar un equipo simulado de fútbol de robots para quizás luego volcar todos los experimentos realizados en el ambiente simulado a la robótica física. Workshop del CAFR2005 Presentación del equipo Caeti – UAI Silveira, Javier – Aguirre, Facundo - Lic. Zabala, Gonzalo Centro de Altos Estudios en Tecnología Informática Facultad de Tecnología Informática Universidad Abierta Interamericana Resumen: en el presente artículo se desarrolla una breve descripción del equipo presentado por Caeti – UAI en 2005. Basados en el equipo desarrollado para el Cafr 2004, pero cambiando completamente el sistema de navegación y de manejo de estrategias, el equipo Caeti – UAI ha rediseñado su modelo de objetos con el objetivo de: a) b) c) Obtener una estructura lo más modular posible que permita modificaciones de estrategias y roles sin afectar el funcionamiento general del equipo. Permitir la incorporación sencilla de nuevos miembros al grupo de trabajo. Permitir el trabajo en forma paralela de los diferentes miembros del equipo. Se presenta a continuación el modelo de objetos diseñado, el estudio realizado sobre el modelo del simulador y la nueva navegación implementada. Palabras clave: fútbol-de-robots, robots-autónomos, navegación-autónoma, comportamientosemergentes. I. Introducción El equipo presentado en esta oportunidad es un rediseño completo del presentado el año pasado en el Cafr 2004, esencialmente en el modelo de objetos y en el sistema de navegación. Para llegar a este punto desarrollamos una herramienta que nos permitió seguir paso a paso el comportamiento del simulador en los partidos, y realizamos un estudio detenido del modelo del simulador. perdido la posibilidad de trabajar en forma modular. Nuestros primeros intentos en este terreno nos habían llevado a tener código especial, sólo entendible y utilizable por su creador, y con diversas rutinas que muchas veces hacían la misma tarea, pero que no eran reutilizadas por la falta de modularidad. Por lo tanto, resolvemos rediseñar el modelo de objetos que habíamos implementado hace un año, determinando las siguientes clases: II. Modelo de Objetos Después de casi dos años de desarrollo del equipo, el mismo había llegado a un punto en el cual gran parte del comportamiento estaba definido por constantes arbitrarias, lo que en la jerga informática se llama “hardcodeado”. De esta manera, habíamos podido definir minuciosamente el comportamiento del equipo (en algunos momentos, casi cuadro a cuadro) pero hacía imposible la modificación de la implementación por parte de alguien ajeno al desarrollo primario, y por otra parte, habíamos a) Equipo: es el objeto que mantiene la información del environment, analiza el estado del juego, y elige una estrategia a ser implementada. También es responsable de evitar oscilaciones en las estrategias. b) Estrategia: es el objeto que designa los roles para cada robot y le pide a cada uno de ellos que ejecuten dicho rol. Ejemplos de estrategia son: JuegoCanino, AtaquePorBorde, CentroInminente, DefensaCanina. la pelota decide la estrategia a poner en marcha. Entre ellas están: a) estPenal b)estTiroDelArco c) estSaqueDelMedio d)estPique e) estCanina f) estAtVerticalFueraAC g) estDeEnAC c) Rol: es el objeto que determinará el comportamiento del robot. Envía al robot mensajes de acciones atómicas, como irAPelota, irAZona, irAPunto, girarGrados. Ejemplos de roles son: ArqueroConservador, Acompañador, Empujador, Asediador. Estas son las clases esenciales que definen el comportamiento. Luego se desarrollaron otras que permitían trabajar con estas clases en forma más sencilla, o definir otros comportamientos atómicos, como Zona, Segmento, Predictor, etc. Los roles representan la programación de un conjunto de acciones primitivas. Es decir, el rol, sobre datos del entorno, decide qué acciones atómicas debe hacer el robot correspondiente. Ejemplos de roles: Para tener un claro ejemplo del uso de estos objetos, presentamos un diagrama de secuencias en la Ilustración 0. a) rolArqueroConservador b)rolArqueroVolante c) rolEmpujador d)rolAcompañante e) rolEsperadorCentro f) rolCortadorCentros La selección de la estrategia está basada en un análisis de estados. El mismo primero hace foco en el estado de juego (normal, penal, tiro del arco, etc) y luego, según ubicación de la pelota, ubicación de jugadores y dirección de Con laEstrategia Canina elEquipo esta organización, robot1 juga tuRolEs(this) juga queHago(this) irAPelota 2 podido rolCanino decideEstrategia Ilustración 1 hemos Workshop del CAFR2005 incorporar nueva gente al equipo de trabajo sin demasiada dificultad. Por otro lado, el desarrollo se ha podido llevar a cabo en forma paralela con poca interactividad entre los participantes. II. Estudio del Modelo del Simulador El otro tema que encontramos fundamental para la evolución del equipo fue la navegación del mismo. Hasta ahora, esta era la parte del código que teníamos desarrollada más intuitivamente. Es por eso que decidimos un estudio profundo del simulador, que se presenta en otro paper. Para poder realizar este estudio, desarrollamos una herramienta que nos permitió realizar un log del juego para luego depurarlo cuadro a cuadro, obteniendo información del entorno con precisión. Además, encontramos algunas presentaciones de los desarrolladores del simulador donde comentaban el uso de la librería Havoc que fue utilizada en Director para la construcción del software de simulación. Con esta herramienta y la información conseguida estudiamos los siguientes elementos del simulador: a) Velocidad real de los robots ante diferentes velocidades asignadas. b)Comportamiento ante choques del robot. c) Velocidad aplicada a la pelota ante un encuentro con un robot. d)Desaceleración de la pelota por rozamiento. e) Desaceleración y ángulo final de la pelota ante rebote. f) Timeslicing del simulador. g) Comportamiento del giro ante diferentes velocidades asignadas a la ruedas. De esta manera pudimos desarrollar un algoritmo de navegación altamente preciso, característica que poseen los equipos más desarrollados de la Fira. A continuación describimos el mecanismo de navegación. III. Navegación La navegación funciona de una forma muy simple pero que es a la vez muy efectiva. Básicamente lo que hacen los robots se puede resumir en avanzar hacia delante procurando estar orientados hacia su destino. Esto significa que se desplazan hacia adelante si se encuentran mirando a su objetivo, y en caso contrario hacen los ajustes necesarios para simultáneamente rotar con una mínima disminución de la velocidad de las ruedas. Aunque esto pueda sonar trivial o exageradamente abreviado, esta simplicidad conlleva consigo un concepto fundamental: los robots reducen su velocidad en una cantidad mínima, sólo la estrictamente necesaria como para corregir su rumbo. De esta forma, la navegación se centra en un objetivo: desperdiciar en la menor medida que sea posible el impulso proporcionado por las “ruedas” y así obtener una máxima velocidad promedio. Una vez definido este sencillo enfoque para la navegación, el problema se reduce a uno: cómo determinar en qué cantidad disminuir la velocidad de la rueda izquierda o derecha para rotar una cantidad de grados específica. Para responder a esto último la única alternativa es realizar un estudio minucioso de la física del simulador y plantear un modelo matemático que relacione las variables que nos interesan con la velocidad de las ruedas. Pero notemos que dado que lo único que nos interesa es estar orientados o no hacia el punto de destino, podemos dejar de lado la parte más compleja de la navegación, que es estudiar el movimiento cómo una trayectoria en el plano. Fue así que llevamos a cabo una serie de detalladas pruebas en las cuales nos concentramos en determinar la velocidad y aceleración de los robots desde el punto de vista de la rotación, o sea, su velocidad y aceleración angular. Con aproximaciones lineales y cuadráticas de las curvas obtenidas, finalmente logramos encontrar una función que determine la velocidad necesaria para las ruedas en función de sólo dos variables: el ángulo a rotar, y la cantidad de grados rotados en el último cuadro. La necesidad del primer parámetro es evidente, no así la del segundo. La cantidad de grados rotados en el último cuadro lo que nos permite es conocer con qué “envión” ya viene girando el robot, y por lo tanto tener en cuenta que con ese impulso rotacional, arrastrado de cuadros anteriores, se producirá en el futuro una cierta rotación. Estimando cuánto se rotará en los futuros cuadros gracias a ese impulso, lo único que resta hacer es calcular la cantidad de rotación “extra” necesaria para terminar de apuntar al destino, cálculo que se hace en base del estudio del simulador. Cabe aclarar que todo esto último es necesario porque la física no se comporta de forma aislada en cada instante, sino que cada velocidad asignada a las ruedas afecta la simulación por muchos cuadros posteriores, y por lo tanto hay que mirar todo el historial del robot para poder predecir sus movimientos futuros. IV. Conclusiones Con respecto a la navegación, nos falta analizar e implementar dos aspectos. En primer lugar, queremos ver si es posible la navegación evitando obstáculos, y si realmente nos brinda mejoras considerables sin perder velocidad y precisión. Por otra parte, queremos desarrollar un algoritmo que nos permita ir a un punto, llegando al mismo con una rotación determinada. Con respecto al comportamiento del equipo tenemos diversos frentes por encarar. Por un lado, queremos implementar algún mecanismo de aprendizaje que nos permita de alguna manera autónoma, mejorar la performance del equipo. Y por otro, desarrollar más estrategias y roles que proporcionen mayor versatilidad en el juego según un conjunto de estados más complejo. Por otra parte, estudiamos profundamente el comportamiento de la pelota para poder predecir el destino de la misma en una cantidad de cuadros a futuro, y considerando rebotes posibles. De esta manera, cuando el robot se dirige a la pelota, siempre está yendo hacia el lugar donde más le convenga de aquí a un conjunto de cuadros. En nuestras navegaciones anteriores, teníamos un nivel de predicción de un cuadro. Ahora, al tener mayores niveles de predicción (y con mayor precisión) podemos definir a cuál de los puntos futuros de la pelota deseamos ir. 4 Chinchulín 2005 Resumen y visión general Este artículo explica la estrategia del equipo Chinchulín. Formado por alumnos de Ingeniería Informática que se introducen al mundo de la robótica, se decidió dividir en 3 capas lógicas: 1. 2. 3. Movimientos básicos Planes de Movimientos Estrategia Además, se intentó separar todos los problemas geométricos en funciones separadas a las de estrategia y movimiento. Desarrollo Movimiento básicos La capa de movimiento no tiene "memoria" y asigna velocidades a las ruedas de acuerdo a objetivos como "ir a punto" o "ir a punto en línea recta". Esta capa también es llamada "de navegación". Se investigó en este aspecto y la conclusión que se llega es que todas las rutinas se basan en obtener una velocidad tangencial y una velocidad angular. Se transforma la velocidad tangencial y la angular a velocidades en las ruedas y se asigna al robot. Planes de Movimientos Esta capa tiene memoria y guarda un plan para cada robot. Un plan consiste en objetivos a cumplir de la capa inferior, precondiciones y detectar que el objetivo ha sido cumplido. Esta capa se encarga de implementar la rutina de llegar a un punto con un ángulo y patear pelota. Las dos cosas consisten en hacer una recta y un semicírculo para girar y patear la pelota en un ángulo determinado (Gregor Novak). La trayectoria se ve en el siguiente gráfico: Como ya se ha dicho se evalúan distintos parámetros para saber si un objetivo ha sido cumplido, y si las precondiciones del plan fallan (velocidad de pelota para los casos en que se sigue a la pelota, por ejemplo), en ambos casos el plan se deshecha y hay que generar uno nuevo. Estrategia En la tercer capa, lo que se desea es clasificar el estado actual del juego (defensivo o ataque) y planear alguna jugada y/o acción de cada jugador. Para ello se ideó el siguiente esquema: Primero dividimos la cancha en 9 secciones. Donde la primer letra es D=Defensa M=Medio A=Ataque y la segunda es I=Izquierda M=Medio D=Derecha. Entonces por ejemplo DI es Defensa-Izquierda, etc. etc La estrategia de ataque se define por un conjunto de reglas, cada una lleva cinco valores: • 1 valor para la sección actual donde se encuentra el robot nuestro que tiene la pelota • 1 valor para la sección objetivo donde queremos que llegue el robot nuestro con la pelota • 3 valores para las secciones donde queremos ubicar a los otros tres robots (el arquero no cuenta porque siempre se queda en el area Entonces, la regla MM Æ [AM, MD, MI, DM] significa que si nuestro jugador tiene la pelota en la mitad de la cancha, tiene que intentar llevarla hacia la zona media de ataque y los otros jugadores tienen que ponerse uno a cada lado y el otro detrás. Con este planteo, podemos tener las estrategias totalmente separadas de la lógica de ejecución (guardando las distintas formaciones en archivos de texto por ejemplo). Con la simpleza del planteo podría implementarse un aprendizaje sobre cuáles jugadas son más efectivas. Funciones de Geometría Se hicieron perfiles de velocidades del robot, con el objeto de predecir encuentros con la pelota o demás objetos. Se obtuvo una curva con las distancias recorridas con el robot a máxima velocidad. A partir de esta curva, se modelizó una función (con interpolación lineal) para calcular el tiempo necesario para una distancia o viceversa. De esta manera, es posible calcular un encuentro con un móvil a velocidad constante de manera muy sencilla. En el aspecto de la mejor trayectoria recta, se estudió que es mejor “frenar” las ruedas que poner “marcha atrás”. Con este conocimiento se implementó una función que va en línea recta a un punto a máxima velocidad y cuando la distancia es tanto, se ponen las ruedas con velocidad 0. Velocidad por iteración cuando ponemos “marcha atrás”: velocidad v e lo c id a d p o r it e r a c io n 2 1 .8 1 .6 1 .4 1 .2 1 0 .8 0 .6 0 .4 0 .2 0 0 10 20 30 tie m p o 40 50 60 Velocidad por iteración cuando ponemos velocidad 0: Velocidad por iteracion velocidad 2 1.5 1 0.5 0 0 10 20 30 40 50 60 iteracion También se perfiló el tiempo de algunas funciones de nivel 1, para poder predecir el encuentro con el balón, así como el tiempo que tarda en girar sobre un círculo con un radio de 4, y cuando tarda el robot en girar sobre si mísmo (para apuntar un objetivo). En las funciones de geometría también hay funciones que detectan colisiones, que obtienen el punto de encuentro de una recta y un círculo (para las trayectorias de pateo). Conclusión El ambiente de desarrollo de robots parece emocionante y esperamos poder seguir compitiendo demás años. Creemos que para crear un buen equipo se necesita dedicación y tiempo, y que la investigación en el área es muy amplia y rica. En las capa superior de la estrategia parece ser mas indicada para aplicar técnicas de IA (técnicas como RRNN, aprendizaje automático, etc) , y por otra parte las capas bajas tienen distintas complicaciones por la naturaleza todos detalles que se tienen en cuenta en el simulador (como la resistencia del aire). Agradecemos a todos los que nos ayudaron a formar el equipo SimpleSot III CAMPEONATO ARGENTINO DE FÚTBOL DE RO BOTS CAFR 2005 Agustín Rafael Martínez – Germán Viscuso Pablo Andres Diaz Mazzaro – Gabriel Diaz Mazzaro – Nicolás Navarro – Martín Roslán RESUMEN SimpleSot es una implementación en Smalltalk de un controlador de equipo de fútbol para la categoría SimuroSot Middle League. Busca explotar el mínimo Gap Semántico que propone la programación orientada a objetos entre el controlador de los robots y los conceptos, en primer término, del dominio de la robótica autónoma en equipo, luego del fútbol de robots y finalmente, del fútbol de robots simulado de cinco jugadores. Intenta contribuir a mostrar la fuerza de la tecnología de objetos, aportar al desarrollo de la robótica autónoma, en especial en equipo, y al desarrollo académico en fútbol de robots. INTRODUCCIÓN UNA HISTÓRIA DEL FÚTBOL DE ROBOTS La idea del fútbol jugado por robots fue mencionada por primera vez por el profesor Alan Mackworth (Universidad de Columbia Británica, Canadá) en una publicación titulada "On Seeing Robots" [Mackworth, 1992] presentada en la Conferencia VI-92 en el año 1992 la que luego formó parte del libro "Computer Vision: System, Theory, and Applications". El grupo de investigadores del profesor Mackworth publicó luego una serie de trabajos que en su conjunto se convirtieron en el proyecto de fútbol robótico Dynamo. Independientemente, un grupo de investigadores japoneses organizó un Workshop de Grandes Desafíos de la Inteligencia Artificial en Octubre de 1992, discutiendo posibles problemas que constituyeran retos en la materia. Este evento generó serias discusiones sobre el uso del juego de fútbol para promover la ciencia y la tecnología. Se llevaron a cabo una serie de estudios y como resultado los investigadores concluyeron que el proyecto era factible y deseable. En Junio de 1993 un grupo de investigadores, incluyendo a Minoru Asada, Yasuo Kuniyoshi, y Hiroaki Kitano, decidieron lanzar una competencia de fútbol robótico, cuyo nombre tentativo fue Robot J-League. En el lapso del primer mes hubo un fuerte interés por parte de investigadores fuera de Japón que requerían que la iniciativa fuera extendida como proyecto internacional conjunto. Debido a ello se renombró al proyecto Robot World Cup Initiative, o ‘RoboCup’ abreviado. En paralelo, varios investigadores ya estaban utilizando el juego de fútbol como dominio de estudio. Por ejemplo, Itsuki Noda, en el Electro Technical Laboratory (ETL), un centro de investigación gubernamental en Japón, conducía estudios de sistemas multi-agente utilizando el fútbol y había comenzado a desarrollar un simulador dedicado al juego de fútbol. Independientemente el profesor Minoru Asada y colaboradores en la Universidad de Osaka por un lado y la Profesora Manuela Veloso y su estudiante Peter Stone en la Universidad Carnegie Mellon por el otro, habían estado trabajando en robots que jugaban al fútbol. Sin la participación de estos pioneros la liga de fútbol robótico no hubiera podido despegar. En Septiembre de 1993 se hizo el primer anuncio público de la iniciativa y se definieron regulaciones específicas, lo que marcó el despegue del fútbol de robots como área de investigación e interés común a nivel internacional. En 1997 se realiza la primera ‘RoboCup’ oficial conformando efímeramente el centro internacional por excelencia del fútbol robótico con más de 40 equipos participando –incluyendo relaes y simulados. La ‘RoboCup’ esperaba para 1998 más de 100 equipos. Ya desde setiembre de 1995 se venía gestando un Comité de Organización internacional para disputar una copa mundial de fútbol para una categoría real llamada entonces ‘Micro-Robot’. Este emprendimiento internacional estaba liderado por el profesor Jong-Hwan Kim del Korean Advance Institute of Science and Technology (KAIST), situado en Taejon, Corea del Sur. Para agosto de 1996 la categoría tomaba el nombre de MiroSot y sus regulaciones tomaban clara forma. El 9 de noviembre, en el KAIST, tiene lugar la primera copa con 23 equipos representando 10 países. Para 1997 el emprendimiento no creció en número de equipos (22 representando 9 países) pero formó oficialmente la FIRA (Federation of Internacional RobotSoccer Association) bajo el objetivo de coordinar la competencia internacional y su investigación asociada. LA ROBÓTICA SIMULADA Es claro que la simulación en robots constituye una alternativa para la investigación de aquellos que no ostentan fuertes recursos económicos. Pero no existen robots sin un cuerpo y un ambiente para desenvolverse. La simulación es entonces un paso previo para el desarrollo de la ordinariamente denominada robótica ‘física’: la robótica real. Es cierto también que un ambiente simulado presenta una ventaja con respecto a uno 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. EL SIMUROSOT MIDDLE LEAGUE El simulador de fútbol de mayor prestigio, mejor mantenido y más utilizado es el que constituye la categoría SimuroSot Middle League de la FIRA que lleva el nombre de ‘3D Robot Soccer Simulator’. Este proyecto se dirige desde Corea por el Dr. Jun Jo y colaboran en su desarrollo cuatro personas más de diferentes países. La versión actual es la 1.5a. El ‘3D Robot Soccer Simulator’ esta arquitectónicamente constituido por un servidor y tres clientes. Dos de los clientes son los equipos que se conectan y un tercero es un Visor desarrollado en Shockwave de MacroMedia, que viene incluido en la distribución del simulador (acompañan también dos equipos de test). Vista del simulador La disputa es entre dos estrategias donde cada una comanda un equipo. Los equipos están distinguidos por su color, una estrategia comandará el Amarillo y otra el Azul. Uno selecciona la opción ubicada arriba en el menú de la izquierda –Strategies– que permite especificar las estrategias que tendrán lugar a enfrentarse al comienzo del juego. Debe especificarse también el leguaje en que se ha desarrollado. Las opciones permitidas por el servidor para la estrategia son: programarla en ‘C++’ y compilarla como una dll, o bien desarrollarla en un leguaje de Scripts llamado ‘Lingo’. Gracias a Germán Viscuso contamos en Smalltalking –una web argentina– con un puente mediante una dll –que el sevidor reconoce como una estrategia C++– hacia el ambiente Visual Smalltalk de Cincom, versión 3.1 o superior. La dll o el texto del script debe estar en el directorio raíz, bajo una carpeta de nombre Strategy y luego bajo una carpeta nombre blue, si es la estrategia para el equipo azul o yellow si es la estrategia para el equipo amarillo. Todos estos directorios se crean automáticamente al instalar el ‘3D Soccer Simulator’ con los equipos de test, que al correr el simulador son los que están listos para jugar. El SimuroSot en cuestión enfrenta equipos de cinco jugadores en un campo que simula tener un ancho de 180 cm por un largo de 220, rodeado por paredes de 2.5 cm de alto. Los arcos tienen 25 cm de longitud y 5 de profundidad. La pelota es una esfera de de 42.7 milímetros de diámetro y 46 gramos de peso. LOS ROBOTS DEL SIMUROSOT Ya dijimos que un robot debe tener un cuerpo, pero no cualquier cuerpo conforma un robot. Ya que un robot debe desenvolverse en un ambiente, debe tener la capacidad de algún tipo de movimiento en él y mecanismos que le permitan interactuar con él. Por consiguiente debe poder sensar y actuar en su entorno. Los robots del SimuroSot, un cubo de 7,5 cm de lado, tienen como actuadotes dos ruedas a sus laterales que se mueven independientemente. Con ellas se desplazarán en el campo de juego e intentarán toparse con la pelota para llevarla al arco contrario y evitar que se meta en el propio. No hay un mecanismo individual de sensado por parte de los robots sino uno global para todo el equipo. Cada estrategia recibe 60 veces por segundo la posición actual de la pelota y de cada robot, en este último caso junto con su orientación, hacia donde mira su cara delantera. A la vez que entrega información, 60 veces por segundo, el servidor del simulador demanda a las estrategias la nueva dirección y velocidad de ambas ruedas de cada uno de los robots que ella controla. La dirección y velocidad de la ruedas están definidas en un rango de 251 valores que van desde el -125 al 125. Donde el signo representa la dirección –negativo, hacia atrás– y el número la velocidad –0, la rueda no se mueve, 125, toma la máxima velocidad. ALGUNAS REGLAS DE FÚLTBOL ROBÓTICO Un partido consta de dos períodos de 5 minutos cada uno, con un intervalo entre ambos de 10 minutos. Un referee, una persona determinado por la organización convocante regimentará el partido, ya que para el simulador todo vale mientras respete sus leyes físicas. Cuando el estado de juego cambia, el simulador debe ser notado de esto por el referee, el árbitro, para que las estrategias sean informadas y actúen en consecuencia. Los posibles estados de juego son: En juego, Pique, Saque del medio, Penal, Tiro libre y Saque de arco. Los jugadores tienen restricciones respecto a qué áreas se pueden situar al inicio de jugada en los diferentes estados, que serán controladas por el árbitro. Por ejemplo en el comienzo del partido, con el estado En juego, el equipo que tiene el saque puede posicionar libremente sus robots en su propio campo y dentro del círculo central y otro equipo puede ubicar sus robots dentro de su campo sin considerar el círculo central. Un gol se marca cuando la pelota ingresa en el arco pasando en forma completa la línea. El ganador de un partido se determina en base a la cantidad de goles marcados. En caso de haber finalizado el partido empatado, el ganador se decide por muerte súbita, luego penales. Atacar con más de un robot en el área chica oponente es penalizado con un saque de arco a favor del equipo defensor. Defender con más de un robot en el área chica propia es penalizado con un tiro penal a favor del equipo atacante. Defender con más de tres robots en el área penal se sanciona con un tiro penal a favor del equipo atacante. Un robot se considera dentro del área penal si está dentro de ella en más de un 50 %, a juzgar por el referee. SimpleSot EL PLAN TRAZADO LINEAMIENTOS n n n n La simpleza y naturalidad de los conceptos modelados es el pilar fundamental del proyecto. Este precepto bautiza nuestro equipo de fútbol como SimpleSot. El trabajo no debe focalizarse en el dominio que propone el SimuroSot Middle League, sino en el dominio de la robótica autónoma en equipo. Buscando culminar en su estado ideal en un completo modelo smalltalk para el desarrollo de equipos de robots. El trabajo debe poder ser extendido por cualquier persona ajena a su realización con conocimientos de la tecnología de objetos. Y debe poder ser entendido por personas ajenas a la robótica y a la programación. Lo modelado debe contribuir probada y satisfactoriamente a la actividad emergente de los robots. CONCEPTOS EQUIPO Un grupo no es en esencia un equipo. Un equipo tiene un objetivo, una misión, un reto que engloba a sus integrantes en un acuerdo común, donde idealmente el éxito individual es el éxito grupal y viceversa. Detrás de todo equipo existe una estrategia para llevar a cabo el objetivo común. En la marcha de la estrategia surgen tácticas que definen como el equipo debe operar para sacar el mejor provecho en el transcurso de una situación determinada. La táctica puede entenderse como un conjunto organizado de acciones individuales; acciones con un objetivo simple detrás. Para llevar a cabo estas acciones simples, existen innumerables alternativas; la habilidad para elegir estás alternativas de ejecución, es lo que diferencia a cada individuo y ella depende de su técnica. En síntesis, el reto mismo nos plantea el punto de vista estratégico, al s vicisitudes en el transcurso nos plantea el punto de vista táctico. EQUIPO DE FÚTBOL “La mejor defensa es la que puede organizarse conjuntamente con un ataque propio (defensa activa, contraataque). (...) El jugador que conduce una defensa activamente, debiera por lo tanto llevar siempre en la mente la posibilidad de un contraataque en un momento adecuado”. Táctica y Estrategia Moderna en Ajedrez. Ludeck Pachman. El objetivo de un equipo de fútbol es obtener el mejor resultado posible en cada partido que juegue; o mejor dicho, alcanzar el mayor éxito posible en los diversos campeonatos en los que participe. Esa es la misión de un equipo de fútbol que se precie. La esencia y gracia del fútbol como juego consiste en transformar el ataque colectivo, realizado por varios compañeros que se pasan la pelota, en ataque individual; apartar del ataque a todos los atacantes sin balón; limpiarle el camino al rematador. La teoría del fútbol investiga ese marcaje estratégico, ese control del avance de los atacantes sin balón y demuestra que en todas las épocas, el juego ha planteado los mismos retos de estrategia: n En defensa, marcar a cada atacante contrario. n En ataque, desmarcar al rematador y entregarle la pelota. “Dos equipos se enfrentan. Cada uno con sus virtudes y defectos, y con su estado de forma del día. ¿Con qué calidad ejecutarán las jugadas los unos y los otros? Nadie lo sabe de antemano con certeza. Durante el partido, los equipos deberán tomar continuamente decisiones tácticas, de sentido común, según se desarrolle el juego…” Teoría del Fútbol. Ricardo Olivos Arroyo. “El que quiere atacar con éxito debe primeramente observar las debilidades del adversario, porque la dirección del ataque está determinado siempre por las flaquezas de las posiciones del adversario” El ataque y la defensa. Hans Müller. Ya dijimos que una táctica es definida para un determinado estado de las cosas en el transcurso de la misión, del juego en nuestro caso. Ejemplos de tácticas que podrán surgir son: • Si tenemos la pelota, vamos ganando por un gol y falta un minuto para que termine el partido, hacerla circular manteniendo el dominio de ella sin avanzar mucho. • Si el equipo contrario está atacando con muchos jugadores, defender con muchos y jugar al contraataque. Una táctica tiene asociadas acciones de equipo que implican acciones individuales de sus integrantes. Para el caso de tener la pelota, la acción pude ser conjunta, pase entre compañeros, o bien unitaria, uno la cubre. JUGADOR DE FÚTBOL Cada jugador es dueño del modo en que ejecuta sus acciones, más allá que sean producto de un acuerdo táctico con sus compañeros de equipo. Distinguiremos dos grandes grupos de acciones a realizar por un jugador: 1. Acciones que se realizan cuando el jugador tiene la pelota: n Patear al arco. n Pasarla a un compañero. n Llevarla a algún lugar –normalmente avanzar. n Colgarla o dividirla en una zona más favorable para la estrategia. n Provocar un Foul contrario –cubriéndola o como de lugar. 2. Acciones que se realizan cuando el jugador no tiene la pelota: n Marcar un contrario. n Anticipar un contrario en la recepción de la pelota. n Buscar la pelota. n n Ir a buscar un pase –un pique con previo acuerdo con los compañeros que pronto se la pasarán. Esperara por un pase, colocándose y manteniéndose en línea con el compañero que tiene la pelota, abriéndole a este una opción más de juego. n Cortar una jugada contraria con Foul. n Cubrir un área –una acción pasiva, de espera. Una acción individual, como dijimos, tiene diferentes modos de llevarse a cabo, de ejecutarse. Un ejemplo, colgarla en fútbol de robots cúbicos puede ser moverse hacia la pelota a toda velocidad y arrastrarla en la propia dirección; o bien, moverse como una perinola sobre sí mismo –con una rueda hacia un lado y otra hacia el otro– pegándole un coletazo para que tome una dirección poco predecible. La acción es la misma, su ejecución no. Otro ejemplo es tener que avanzar la pelota con el campo libre, donde un jugador puede simplemente arrastrarla o, por tener un jugador delante, hacer alguna pared, gambeta, algo, o resignarse a chocar. En la técnica del jugador radica la elección y perfeccionamiento del modo de ejecución de sus acciones. Un jugador nace con aptitudes físicas y mentales pero no con técnica, la que irá depurando con el jugar. ARQUITECTURA EQUIPO Está determinada por un subsistema autónomo por cada individuo en el ambiente que pertenezca al equipo, donde cualquier integrante podrá comunicarse con cualquiera. La eficacia y riqueza de la comunicación entre estos subsistemas cobrará, entonces, un valor fundamental para el éxito del equipo en su misión. Particularmente, los subsistemas que tendremos en nuestro equipo serán uno por cada robot en el campo de juego –cinco para el caso del Middle League. Cada actor podrá comunicarse con todos sus compañeros con un mensaje grupal. Un grito de ¡Mía! ¡La perdí! [4] son ejemplos de este tipo de mensaje. También podrá comunicarse con mensajes a compañeros puntuales como ¡Pasala! ¡Pico por la punta! ¡Estoy!, etc. INDIVIDUO Todo robot deberá conocer las reglas que impone el ambiente, su posición y la última conocida del resto de los agentes. También deberá tener la capacidad de moverse a un punto fijo o hacia un objeto móvil lo más rápido posible. El robot debe aprender de los sucesos ocurridos, para ir sacando provecho de los defectos tácticos del oponente y minimizar los propios, y poder evaluar cual es su mejor rol a la hora de desplegar una táctica con sus compañeros. Sus acciones y ejecuciones quedarán libradas a su elección, a su técnica, a su habilidad ganada en la experiencia. Elegirá la que le sale mejor o la que le viene saliendo mejor en ese partido o una que quiere probar como funciona. Aquí es donde un jugador comenzará a diferenciarse de otros. No habrá habilidosos de ante mano, ni fouleros, ni rápidos, ni lentos, ni sordos, ni locos, ni malos, ni buenos… Serán todos cubitos con un nivel de procesamiento hasta que entren en la cancha y se hagan en el día a día… Únicos, quizás irremplazables, amados u odiados… …jugadores de fútbol. SimpleSot LA PUESTA EN MARCHA R E Q U E R I M I E N T O S E I N S TALACIÓN Se debe contar con una máquina de alrededor de 1 Ghz de procesamiento, 256 Mb de memoria, placa de video con procesamiento 3D y sistema operativo Windows 98 o superior. Se debe instalar el simulador de la FIRA: Robot Soccer Simulator 15a. Se debe contar con el Visual Smalltalk (VS) versión 3.1 con el paquete ARSLLs y la goodie Smallsot que se obtienen en las siguientes url respectivamente: http://www.smalltalking.net/Goodies/VisualSmalltalk/Files/ARSlls.zip http://www.smalltalking.net/Goodies/VisualSmalltalk/Files/SmallsotGoodie.zip A esto debe agregarse la implementación del equipo SmallSot. Se deben setear las siguientes variables de entorno: dlls PATH VSW310 C:\VSW310\LIB %dlls%;%VSW310%;%Path% C:\VSW310\LIB;C:\ VSW310\SYSTEM;C:\ VSW310;C:\VSW310\Help La Smallsot goodie provee un archivo dll –smallsot.dll– que deberá ser copiado en el directorio ‘C:\Strategy\blue’ –automáticamente creado en la instalación del simulador. P U E S T A E N M A R C HA Con todo instalado: arrancar el simulador, cliquear en ‘STRATEGIES’; donde diga ‘Lingo’ se debe decir ‘C++’; en el campo de texto del equipo, por ejemplo, azul se debe escribir la palabra ‘smallsot’ –en ambos casos sin la extensión dll. Luego de esto apretar ‘SEND’ y automáticamente el controlador smalltalk será el que adopte el simulador. Luego hay que arrancar el VS con todo instalado –ejecutando el archivo ‘VDEVW.EXE’– y evaluar la expresión ‘SmallsotMonitor open’. Cliquear sobre el checkbox para desactivar un viewer del juego y luego clickear ‘START’. Con todo listo podemos comenzar el partido oprimiendo el ‘START’ del simulador. Dento del VS tenemos la opción de inspeccionar con el botón ‘INSPECT’ los objetos en cuestión. Y por supuesto con el Class Browser conocer las definiciones de los comportamientos de nuestros objetos. EL SIMULADOR Y LA DL L En cada ciclo el simulador provee el estado del ambiente a la dll y espera que ella la modifique con los nuevos valores de velocidad de rueda de sus jugadores (que van desde -125 a 125). Esta modificación es delegada al programa SimpleSot corriendo en VS. LA SMALLSOT GOODIE El paquete proveído por Germán Viscuso a través de smalltalking.net levanta la smallsot dll como un objeto, al que accedemos con la expresión ‘SmallsotDll current’ y al que podemos demandarle datos del ambiente y proveerle nuevos. Se detallan abajo los mensajes más importantes que una ‘SmallsotDll’ puede recibir. ‘SmallsotDll’ es una ‘DynamicLinkLibrary’. A través de este objeto es que el programa se comunica con el simulador. SimpleSot LO MODELADO EQUIPO Nuestra clase más importante es la clase ‘TeamRobot’, que define el comportamiento de un robot del equipo y cuyo método central es ‘act’ que desencadena las siguientes colaboraciones: El rol, según la perspectiva actual del robot, es el que determina la acción que este va a realizar, la que luego, también según la perspectiva, elige su ejecución que brinda el movimiento para realizarse. Aquí un detalle de los mensajes que un ‘TeamRobot’ puede recibir: Aquí las clases ‘Roll’, ‘Action’, ‘Execution’ y ‘Movement’, que al igual que ‘TeamRobot’ heredan de ‘Object’: EQUIPO DE FUTBOL Algunos roles implementados hasta ahora han sido arquero, defensores laterales izquierdo y derecho, volante central y delantero. Cada uno con una clase que define su comportamiento: Cada rol debe elegir entre sus acciones posibles la indicada para la perspectiva de su robot. Algunas acciones implementadas son: Para que estas acciones puedan llevarse a cabo, ejecuciones necesarias son: NAVEGACIÓN E N E L S I M U R O S O T Los movimientos, clases que heredan de ‘Movement’, son los directos encargados de modificar el valor de los actuadores del robot. Algunos de ellos han sido ‘Calm’, ‘GoPisition’, ‘GoPositionOriented’, ‘HitPosition’, ‘HitPositionOriented’ y ‘Spin’. HIT POSITION Cuando un robot quiere llegar a un punto, por ejemplo al centro de la pelota o del área que corresponde a su rol, existen una cantidad de variables que se desprenden de su situación respecto del ambiente. El robot se encuentra mirando hacia un lugar, lo que se denomina rotación, y es proveído como dato por el simulador en cada ciclo junto con su posición en la cancha. Sólo con estos dos datos y el punto donde se desea ir es que el movimiento Hit Position opera. La implementación es la de [5] con pequeñas modificaciones. HIT POSITION ORIENTED Un robot no quiere solamente necesita llegar a determinado punto, sino que muchas veces quiere hacerlo en una determinada dirección, por ejemplo para patear la pelota al arco. Esto se calcula corrigiendo el punto al que el robot debe dirigirse, haciendo que primero vaya detrás de la pelota. COMENTARIOS FINALES SimpleSot es un trabajo en proceso. En este documento se han detallado las cuestiones base que refieren al modelo construido y muchas otras quedan pendientes para posteriores versiones, seguramente producto de la motivación por futuros desafíos. Ejemplo de elementos pendientes de ser documentados, por estar aún inmaduros en su desarrollo, son mensajería entre agentes o modo de elección de roles, acciones, ejecuciones en cada momento. Este trabajo busca ser punto de partida a un estudio de la colaboración entre agentes en un equipo, maximizando las capacidades de cada individuo en función del objetivo común. Intentamos que sea un proyecto abierto a la contribución de quienes compartan el marco propuesto. En función de ello, tenemos previsto publicar la implementación de un modelo que consideremos cerrando, quizás bajo la dirección, actualmente en trámite, www.simplesot.com.ar SimpleSot APÉNDICE GLOSARIO • Actividad Emergente: resultado de la observación de los comportamientos simultáneos de un robot. • Actuadores: mecanismos con los que consta un robot para modificar su ambiente. Por ejemplo: ruedas que cambian su ubicación. • Ambiente: lugar donde los robots se desenvuelven. Escena de los actores. • CAFR: Campeonato Argentino de Fútbol de Robots. • Estrategia: Conjunto de decisiones tomadas sobre la manera de accionar, antes de empezar a hacerlo. • FIRA: Federation of International Robot-Soccer Association. • Gap Semántico: distancia entre un dominio y su modelo construido. • Programa: conjunto de objetos que colaboran enviándose mensajes. • Robot (una definición entre tantas): agente que puede considerarse que percibe su ambiente mediante sensores y que responde o actúa en tal ambiente por medio de efectores. • Táctica: Conjunto de decisiones temporales, supeditadas a una estrategia, sobre la manera de accionar, tomadas en un período de acción. • Técnica: Habilidad para ejecutar o conseguir algo REFERENCIAS 1. Reglamento de Juego para CAFR 2004. 2. Neuroevolución de Topologías Aumentativas aplicada al dominio de Fútbol de Robots [Germás Viscuso, CAFR 2004] 3. Revisión del Estado del Arte y Desarrollo del Equipo UBASot de Simulación [Diciembre de 2002, Claudia C. Castelo, Héctor R. Fassi, Flavio E. Scarpettini] 4. Patito Fútbol Club [Daniel Bistman, CAFR 2004] 5. Motion Control in Dynamic Multi-Robot Environments [Michael Bowling, Manuela Veloso, Computer Science Department, Carnegie Mellon University] LINKS • FIRA: www.fira.net • RoboCup: www.robocup.org • CAFR2005: www.unimoron.edu.ar/cafr2005/ • CAFR2004: www.exa.unicen.edu.ar/cafr2004/ • CAFR2003: www.dc.uba.ar/people/cafr2003/ • UBASot: www.dc.uba.ar/people/proyinv/robotica/spa/pg_index.php • Teoría de Fútbol: www.soccertheory.com/spanish/strategy.htm • Smalltalking: www.smalltalking.net II.a Nivel de enseñanza Secundaria Ladiani, Damián – Sisi, Lucas – Escobar, Adrián – Morel, Emmanuel – Cardozo, Roberto - Barrios, Pamela Sierra, Mayra - Prof. García Mónica. Colaboradores: Pereira Gustavo, Brizzi Teresa E.EM Nº 5 Navier y Bailen Ing. Pablo Nogués www.pollitofive.netfirms.com Resumen: El equipo PollitoFive, experimenta por primera vez la inserción al Campeonato Argentino de Fútbol de Robot. Con conocimientos básicos en programación, de acuerdo al nivel Polimodal en el que se desenvuelven. El trabajo se dividió en dos grupos: programadores (en otros dos subgrupos amarillo y azul) y documentación. El grupo programadores se encargó de buscar la manera de desarrollar las estrategias de juego y el otro grupo de describir las actividades desarrolladas para su posterior documentación. I - Introducción El equipo Pollitofive de la E.E.M N°5 de Ing. Pablo Nogués, esta integrado por alumnos de 2° y 3° año de polimodal. Estos alumnos pertenecen a la modalidad Producción Bienes y Servicios con conocimientos básicos de los lenguajes Clipper y Visual Basic. Dada la complejidad del entorno de programación para fútbol de robot fue conveniente aprender en primera instancia la estructura básica del lenguaje C++, con el cual trabaja el simulador. Circunstancia que llevo aproximadamente cinco meses, en total se lleva trabajando un año aproximadamente. Paralelo a esto se trataron temas matemáticos propios para el movimiento adecuado de los jugadores en la cancha. II- Enfoque del trabajo El equipo se desarrollo íntegramente en lenguaje Visual C++. No se implemento clases, pero si se utilizo ampliamente funciones. Como resultante se obtuvo los .Dll del equipo. carrera. En la última etapa los alumnos estando cursando el 3º año, se organizo en horario extraescolar, para no afectar el contenido curricular obligatorio. Sin abandonar en ningún caso la continuidad del trabajo. III. Estrategias utilizadas Comportamiento del Arquero Función básica: el arquero se mantiene dentro del área chica siguiendo la pelota sin salir de dicha área. Se mueve con respecto al eje Y del arquero es muy importante mantener pegado a los límites de la cancha garantizando que no quede un espacio entre el arquero y la pared por donde pueda pasar la pelota. Cuando el arquero sale o es empujado fuera del rango permitido sobre su eje Y, el jugador más cercano (excepto el Líbero jugador Nº 4) tomará la posición del arquero efectuando el cambio de roles.. Para su mayor desarrollo se dividió en tres partes: 1°) Equipo Amarillo; 2°) equipo Azul 3°) documentación para elaborar el Work Shop. Al comienzo el soporte tecnológico era escaso para las necesidades que requería el simulador. La cooperadora de la escuela con gran esfuerzo adquirió el equipamiento necesario para el buen funcionamiento del mismo. Con las nuevas máquinas se organizo una nueva de metodología de trabajo, ya que al principio se elaboran estrategias en lápiz, papel y pizarrón. Ocupando horas asignadas al horario escolar, ya que no afectaba el contenido curricular de la Si la pelota pasa la posición del área chica, el robot se posesiona dependiendo de donde se encuentre la pelota siempre de arriba hacia abajo, mientras el arquero no abandone el arco. Si está cerca de un rango de dos se pone a girar para rechazar la pelota. En caso de quedar el arquero en una posición no alineada se rectifica la posición original. La acción descripta se desarrolla en la función Cercade (). 1 Comportamiento de Defensores El trabajo que realizan los defensores es simple: Cuando la pelota no pasa de la mitad de la cancha Automáticamente el jugador Líbero y dos jugadores más pasan a ser defensores. Se posicionan sobre el eje “x”, buscando estar delante de la pelota si esto se cumple se posiciona en el eje ”y” de la pelota, si esta paso al defensor el robot busca la posición para ponerse delante de la pelota y rechazarla. Comportamiento del jugador Líbero Lo que se busca con esta jugada, es que el jugador siempre llegue al cruce del delantero oponente y que el equipo ataque, el mayor tiempo posible Como estrategia se tiene en cuenta que si pelota pasa la mitad de la cancha juega de Líbero caso contrario de Defensor. La función Líbero: cuando la pelota pasa la mitad de la cancha se posesiona sobre el eje X justo en la mitad, siguiendo el eje Y de la pelota; cuando la pelota está en un rango de cuatro se pone a girar para efectuar el rechazo. Como se describió anteriormente, este jugador queda como un soporte para no descuidar el área y ser de ayuda para el arquero, mientras que los demás jugadores siguen sus jugadas. El libero queda en la línea del medio de la cancha, libre para cubrir las pelotas que puedan venir de los oponentes. De este modo ayudaría al arquero a defender mientras que los demás jugadores salen a atacar para lograr el gol. Las acciones del defensor depende de la posición de la pelota se tuvo en cuenta tres momentos posibles: 1) Sigue el movimiento de la pelota respecto del eje X, utilizando la predicción para adelantarse al desplazamiento de ésta. 2) Cuando la pelota esta en un rango de cuatro pulgadas a la redonda entonces gira para rechazar teniendo en cuenta que no toque el arco. 3) Cuando la pelota no supera al Robot se la va llevando hacia abajo. Siempre sacándola. 2 Los delanteros Cambio de Roles El cambio de roles se produce cuando un jugador (con excepción el jugador Líbero que por defecto es el Nº 4) esta posicionado más cerca del arco que el mismo arquero. Las acciones previstas se desarrollan en la función Arrelevo (), que saca la distancia de los cuatro jugadores más cercanos para determinar cual será el que cambiará de rol. Los delanteros esperan el despeje del arquero o de los defensores para luego llevar la pelota al campo contrario intentando llegar al arco oponente y luego concretar el gol. Si el robot se encuentra enfrentado al arco, y la pelota se encuentra en un radio de cuatro pulgadas de éste, el robot girará para intentar golpear la pelota hacia el arco. Paso 1: (Arquero en su área y tres jugadores cercanos) IV. Conclusión: Paso 2: Se rescata del presente trabajo dos hechos importantes: El primero tiene que ver con el aprendizaje de nuevas herramientas de programación y resolución de problemas. El segundo con la vivencias de cada uno de los integrantes del grupo que descubrieron la importancia de la responsabilidad individual y el aprendizaje compartido. La perseverancia hacia el objetivo planificado, venciendo las distintas dificultades presentadas a nivel pedagógico y circunstancial. (Cambio de roles entre el jugador 2 y el arquero) 3 Workshop del CAFR 2005 Mukeniosot Presentación del Equipo Mukeniosot Avila, Diego; Hughes, Tomás; Lorusso, Emiliano; Puchetta, Fernando; Shrewsbury, Lucas; Shrewsbury, Tomás; Solotum, Gerardo; Solotum, Roberto. Resumen: En el presente trabajo se explicará brevemente la manera de jugar del equipo de fútbol de robots Mukeniosot, del Instituto José Manuel Estrada, Don Torcuato, Pcia. de Buenos Aires. La organización del equipo se dividió en: Delanteros, Defensores y Arquero, y la programación del equipo fue desarrollada en Visual C++. El equipo es la continuación de Mukeniosot, que participó en el CAFR 2004, con algunas modificaciones de navegación y jugadores. Palabras Claves: Programación, Simurosot, Fútbol de robots. I. Introducción: El equipo presentado en esta oportunidad contiene algunas modificaciones con respecto al anterior. Estas reformas no modifican esencialmente el juego, pero hacen una mejora con respecto al del año pasado; Si bien este fue programado entre todos los integrantes del grupo, el NUEVO MUKENIO surgió de la organización de un torneo entre los integrantes. Del ganador de este torneo se tomaron algunas ideas que se le aplicaron al primer equipo. II. Delanteros: La navegación de los delanteros de nuestro equipo fue desarrollada por un integrante del grupo durante el campeonato interno realizado a fines del año pasado. Los delanteros lo único que hacen es ir hacia la pelota y no apuntan al arco por el momento. III. Defensores: Los defensores se los modificó desde cero. Los nuevos son similares a los del primer equipo, con la diferencia de que la línea en Y por donde se movían, ahora son líneas que cambian dependiendo de donde esté la pelota (figura 1). Figura 1 Los dos defensores no pasan la mitad de la cancha, y hacen como una especie de mediocampistas que intentan frenar las pelotas que se están yendo a nuestro arco (figura 2). Figura 2 Los defensores también están provistos de un despeje hacia fuera (figura 3). Workshop del CAFR 2005 Mukeniosot Figura 3 IV. Arquero: El arquero se mueve igual que los defensores, con la diferencia de que su línea en Y es constante. El arquero fue modificado solo en la parte del despeje, que en el equipo anterior se salía mucho del área y era motivo de muchos goles en nuestra contra. Ahora el arquero solo sale en situaciones extremas y no demasiado (figura 4). Figura 4 V. Pelotas Paradas: las jugadas de pelota parada casi no se modificaron. Las jugadas son: • Free Ball: El robot intenta impactar a la pelota a máxima velocidad. • Place Kick: El jugador va hacia la pelota normalmente. • Penalty: El robot va hacia la pelota y cuando está por tocarla gira, con el objetivo de colocar la pelota en la esquina opuesta al arquero del equipo contrario (figura 5). Figura 5 CAFR 2005 SimulArlt III www.expotortuguitas.com.ar Equipo SimulARLT III: El Fútbol de Robots Como Entorno Educativo Coordinador: Profesor Julio Fernández. Alumnos Integrantes: Alderete Mauro, Báez Matías, Fuentes Carolina, García Maria de los Ángeles, Milanese Elías Colaboradores: Barreto Ariel, Campos Nicolás, Colman Mauricio, Corbacio David, Coronel Ezequiel, Fortunato Lucas, Fretes Héctor, Lobo Ezequiel, Rodas Sebastián, Urih Ariel, Zarate Facundo, Corso Sabrina, Fuentealba Yésica, González Mercedes, Maldonado Pamela, Molina Patricia, Montenegro Vanesa, Valdez Maria Sol, Villaverde Estefanía. Escuela de Educación Media Nº 7 “Roberto Arlt” Tortuguitas - Buenos Aires – Argentina [email protected] http://www.esctortuguitas.com.ar Palabras clave: Educación, Polimodal, Robótica, Simulación, Fútbol, Cooperación, Simurosot, Inteligencia Artificial, Programación, Estrategia. Resumen En el presente artículo se describe el proyecto “Equipo SimulArlt III”, en el cual se ha utilizado al fútbol de robots como un entorno educativo para alumnos de la especialidad de Producción de Bienes y Servicios, con orientación en Desarrollo y Programación de Aplicaciones Nivel Polimodal de la Provincia de Buenos Aires. El equipo de fútbol de robots simulado desarrollado, está destinado a competir en el III Campeonato Argentino de Fútbol de Robots Simulado 2005, organizado por la Universidad de Morón (U.M). En este artículo se muestra como los alumnos a lo largo del proyecto, aplicaron técnicas y conocimientos adquiridos en los distintos espacios curriculares; y además fueron intuitivamente reconociendo y dominando conceptos sobre robótica, problemas de tiempo real y sistemas multiagentes. Uno de los equipos antecesores, Simularlt I, obtuvo el primer puesto en el Campeonato Nacional de Fútbol Simulado (CAFR 2003) que los llevo al Campeonato Mundial que se efectúo en Austria y Simularlt II, obtuvo el tercer puesto en el segundo respectivo Campeonato (CAFR 2004). La posibilidad de formar un equipo de robot soccer surgió a principio del año lectivo 2004 cuando tomamos conocimiento de la participación de alumnos de nuestra escuela en campeonatos anteriores. Fue entonces cuando comenzamos a investigar el lenguaje C++, el simulador y la demo que provee el mismo. Con el tiempo desarrollamos un prototipo basado en la estructura de Simularlt II, que utilizamos para realizar distintos encuentros amistosos con otros equipos. Los resultados, a pesar de ser buenos, no llenaron nuestras expectativas. Ya en el año 2005 con las experiencias obtenidas debimos realizar un nuevo equipo con una estructura completamente distinta a Simularlt I y Simularlt II para poder construir un equipo superior. 1 CAFR 2005 SimulArlt III I. Introducción www.expotortuguitas.com.ar BASICAS COMPLEJAS A mediados del 2004 comenzamos a analizar la estructura del programa que provenía del equipo anterior, con esta estructura tuvimos la oportunidad de participar en un Torneo amistoso en la Universidad de Morón. Fue nuestra primera experiencia, los resultados fueron buenos pero no alcanzaron con nuestros objetivos. Después de esto y con el logro de los equipos anteriores tomamos la decisión de crear una nueva estructura ya que los anteriores poseían falencias lógicas. Las cuales hacían imposible la mejora del rendimiento. El nuevo emprendimiento lo afrontamos mediante los conocimientos adquiridos en estos tres años de aprendizaje en los que vimos nacer a SIMULARLT I y SIMULARLT II. Realizando una nueva estructura para formar el equipo. 2 HABILIDADES JUGADORES DEFENSORES Mensaje ARQUERO II. Estructura del equipo. Mensaje Comenzamos creando Habilidades Básicas y luego Complejas, que son las acciones que utilizan los Jugadores para desempeñarse en diferentes situaciones del juego. Los Jugadores en conjunto forman el Equipo, que junto con las Estrategias de Juego, las cuales utilizan Jugadas especiales, Cambio de Roles, y datos del entorno, logran realizar un juego cooperativo y dinámico donde los cinco robot tienen como Objetivo meter la pelota en el arco oponente impidiendo que el equipo contrario cumpla su objetivo. Esto podremos visualizarlo en el siguiente cuadro: DELANTERO Mensaje ESCLAVO EQUIPO Cambio de roles Entorno Jugadas especiales ESTRATEGIAS OBJETIVO CAFR 2005 SimulArlt III 1. Habilidades: www.expotortuguitas.com.ar 3 Arquero_Empujar. Aquí se realizan los movimientos de los robots. Es así como con diferentes funciones de movimiento, se pueden crear las habilidades, estas se dividen en dos: 1.1. Básicas: Estos son procesos que efectúan los movimientos simples del robot. Por ejemplo: Avanzar, retroceder, girar y mirar un punto, etc. 1.2. Complejas: Es donde usamos los procesos que se crearon con las habilidades básicas para realizar los movimientos más complejos del robot. Por ejemplo: recuperar pelota, ir a un punto, y las que se mostraran a continuación. Arquero_Empujar: Si pelota > (al fondo izq. + robot ½ ) y el robot < (fondo izq. + robots ½ ) entonces Si (pelota > robot) y (pelota > centro de la cancha en Y) entonces. Arquero_Empujar:= verdadero Sino Si (pelota < robot) y (pelota< centro de la pelota en Y) entonces Arquero_Empujar:= verdadero Sino Arquero_Empujar:= falso Finsi Finsi Finsi Fig.1 Muestra como el jugador, cuando la pelota esta cerca del arco, avanza hacia ella para empujarla utilizando la función Arquero_Empujar. Levantar_Pelota: Si (el robot > al lateral superior) entonces Si (pelota < a robot) entonces Gira a la izq. Sino Gira a la der. Finsi Finsi Sino Si (robot < al lateral) entonces Si (pelota < robot) entonces Gira a la der. Sino Gira a la izq. Finsi. Finsi. Cuando la pelota esta en los bordes se utiliza la función: Levantar_P. Fig.2 Muestra como el jugador se acomoda para recuperar la pelota utiliza la función Levantar _P. Ir a punto: Ang = obtener ángulo(robot, punto) Angulo frente:=Ang-rotación robot Angulo espalda:= Ang-(rotación robot-180) CAFR 2005 SimulArlt III Si (Angulo frente<Angulo espalda) entonces Si (Angulo frente>1.5) entonces VR= (Angulo frente*max. velocidad)/180 Rueda izq.= -VR Rueda der.=VR Sino Avanzar Finsi Sino Si(Angulo espalda>1.5) entonces VR= (Angulo espalda* max. Velocidad)/180 Rueda izq.= -VR Rueda der.= VR Sino Retroceder Finsi Finsi www.expotortuguitas.com.ar 4 2.1. Mensajes: Según las situaciones de la cancha, los robots se envían mensajes entre si usando la función Bot mail. Un robot puede enviar un mensaje a todo el equipo a la vez utilizando la función Team mail. 2.2. Esclavo: Es un conjunto de habilidades que le son asignadas a cualquier jugador dependiendo del juego mediante un mensaje emitido por un robot compañero. Por ejemplo: Empujar al Compañero: Esta función envía al robot más cercano en ayuda de un compañero para empujar la pelota. Cuando el arquero va a tapar se llama a la función: ir a punto Fig.4 Muestra como un robot ayuda a empujar a un compañero, utilizando la función Empujar _ compañero. Fig.3 Muestra como el jugador va hacia la pelota dirigiéndose al su punto x,y. III. Funcionamiento del equipo 1. Entorno: 2. Jugadores: Las uniones de las habilidades forman un jugador, con un buen desempeño en el campo de juego dependiendo en la situación en que se encuentre. Por ejemplo: Estas tres habilidades forman parte del jugador arquero, Acomodar_Arquero, Arquero_Tapar y Arquero_Empujar, etc. Son todas las funciones que analizan el estado de la cancha guardando los datos que toma del enviroment en el registro cancha. Se divide en dos tiempos, pasado, contienen los datos de los ciclos anteriores y presente, contienen las posiciones actuales de los objetos en la cancha. CAFR 2005 SimulArlt III www.expotortuguitas.com.ar Registro cancha 5 CAFR 2005 SimulArlt III 2. Jugadas Especiales: Para poder hacer que el equipo funcione cooperativamente creamos estrategias de juego cuyo eje principal es el cambio de roles. Dentro de las estrategias también contamos con un conjunto de algoritmos para las ocasiones especiales como el Penal, Tiro Libre, Saque de Arco, Saque de Centro, Pique, etc. Por ejemplo: En el Saque de centro nuestro robot recupera la pelota del centro de la cancha y se la pasan a cualquier compañero para comenzar el juego. En el Pique el ejecutor del pique tira la pelota hacia arriba, para que el jugador arquero la saque del área defensiva. En caso de que el pique se efectúe en el área oponente el ejecutor tira la pelota al centro de la cancha. En el Tiro Libre el jugador ejecuta un tiro hacia el arco oponente. En el Saque de arco Nuestro arquero se encarga de sacar la pelota cuando se sanciona las faltas que pueden existir en éste. En el Tiro penal hemos construido variantes dependiendo de la situación en que se encuentran los robots Oponentes. Estos pueden ejecutarse en forma directa, por medio de una “patada” o en dos toques para lograr cambiar la trayectoria de la pelota y así desorientar al robot arquero que busca la predicción de la misma. 3. Cambio de roles: Cuando el jugador lleva la pelota y se va de su zona buscamos el robot más cercano y hacemos un cambio de rol esto posibilita tener siempre un arquero, dos defensores y dos delanteros. www.expotortuguitas.com.ar 6 Cuando el Jugador Estrella no esta cerca de la pelota, buscamos al jugador más cercano a la misma y cambiamos su rol por éste. Esto hace que siempre nuestro jugador estrella este en contacto con la pelota para llevarla hacia el arco contrario. IV. Herramientas para llegar al objetivo: Desarrollamos también programas Debugger en el Lenguaje Pascal y en Visual Basic para ver datos que el simulador no entrega por si solo. Primero guardamos las posiciones de los objetos en la cancha, la velocidad de las ruedas, rol, etc., durante el juego. Luego pasamos con el Debugger, la información a una base de datos, la cual es interpretada dibujando en pantalla la cancha, los robots y la pelota, con esto reproducimos el partido. Uno de los programas hace la repetición completa del juego y muestra la posición, la rotación y velocidad de los robots. El otro muestra el rol de cada robot en su parte superior y el número del mismo. V. Conclusión: Con los conocimientos adquiridos en robótica, matemáticas, lógica, que son componentes que se derivan de la programación, logramos el beneficio de resolver problemas lógicos en poco tiempo, implementarlos en otras materias y también en lo cotidiano. Poder desarrollar este proyecto en nuestra institución E.E.M.N°7 "Roberto Arlt", nos ha dado una gran satisfacción y anhelamos que Simularlt III, pueda concretar buenos resultados en el campo de juego, en el Campeonato Nacional de Fútbol Robot CAFR 2005 SimulArlt III www.expotortuguitas.com.ar simulado (CAFR 2005). Con esta experiencia obtendremos conocimientos de los otros equipos. Y esperamos aportar ideas para desarrollar futuros equipos de Fútbol Robots Simulado. Referencias Workshop de Simularlt I , Creado por: Milanese Ezequiel, Tleye Sebastián, González Sergio, Gerszenwit Fernando, de la Institución “Roberto Arlt” Workshop de Simularlt II, Creado por: Sánchez Elena, Fretes Alfredo, Schneider Juan, González Pablo, Míguez Gabriel, Cuellar German y Hernández Leandro, de la Institución “Roberto Arlt” Workshop de Patito Fútbol Club, Creado por: Daniel Bitsman., particular. Microsoft Visual C++, Autor: Chuck Sohar, Editorial: Mc Graw-Hill. Curso de programación C++, Autor: Fco. Javier Ceballos, Editorial: Ra-ma. Programación en Turbo/Borland Pascal 7, Autor: Luis Joyanes Aguilar, Editorial: Mc Graw-Hill. Aprendiendo C en 24 horas, Autor: Tony Zhang, Editorial: Prentice Hall. SIMULARLT III 7