CAFR 2005 - F:I:C:C:T:E:

Transcripción

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,
Juan Miguel Santos (Departamento de Computación,
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 fútbol implementado como un
sistema heterogéneo de múltiples agentes lógicos
Mauro J. Gómez José H. Moyano
Nicolás D. Rotstein Telma Delladio Alejandro J.Garcı́a
Grupo de Robótica Cognitiva
Laboratorio de Investigación y Desarrollo en Inteligencia Artificial (LIDIA)
Departamento de Ciencias e Ingenierı́a de la Computació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 fútbol simulado con el objetivo de participar en el CAFR 2005 en la categorı́a Simurosot. El equipo fue concebido
y diseñado como un sistema multi-agente heterogéneo. Cada jugador está modelado como
una entidad computacional autónoma que tiene un rol determinado dentro del equipo y
coopera con sus compañeros para enfrentar al equipo contrario. El sistema fue desarrollado utilizando el lenguaje de programació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 dinámico, como lo es un partido de fútbol,
para poder realizar investigación básica en temas centrales en el área de Sistemas Multiagente: coordinación, protocolos de interacción, comunicación, arquitecturas de agentes,
etc. El planteo del equipo como un sistema multi-agente presenta numerosas ventajas: la
ejecución de los agentes puede realizarse en forma distribuida en una o varias máquinas,
en forma transparente. Los agentes que componen el equipo pueden reemplazarse de la
misma manera que en el fútbol real. De esta manera, puede sustituirse un agente por otro
con diferentes caracterı́sticas, roles o habilidades, sin modificar el resto de la lógica del
sistema o los demás agentes.
El diseño del equipo está planteado en dos módulos principales: el módulo de interfaz
y el módulo de comportamiento. El mó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 módulo de interfaz obtiene la información del entorno
provista por el simulador, la cual, luego de ser pre-procesada, queda disponible a los
agentes Prolog (pertenecientes al módulo de comportamiento) para que éstos analicen
y decidan las acciones a realizar. Estas acciones son comunicadas al simulador a través
del mismo módulo de interfaz.
1.
Introducción
El presente trabajo describe consideraciones de diseño e implementación en el desarrollo de
un equipo de fútbol de robots simulado. La principal motivación para desarrollo de este trabajo
está asociada a la posibilidad que ofrece un dominio dinámico como el fútbol para realizar
investigación básica en al área de sistemas multi-agentes [3, 7, 2, 4, 5].
El equipo presentado se diseña siguiendo un modelo de sistema multi-agente y este diseño
se plantea en forma modular, separando los aspectos de interfaz relacionados al entorno de simulación en particular (categorı́a Simurosot en este caso), de aquellos aspectos relacionados al
comportamiento del sistema de agentes. Esta separación permite que el entorno de simulación
considerado sea transparente al sistema de agentes propiamente dicho, el cual es implementado en Prolog debido a su utilidad como herramienta de representación de conocimiento y
razonamiento [6, 1].
El trabajo se organiza de la siguiente manera: en la sección 2 se describen los módulos principales del sistema; en la sección 3 se describen las consideraciones de diseño de la arquitectura
de los agentes desarrollados; finalmente, en la sección 4, se exponen las conclusiones del trabajo
realizado.
2.
Los módulos principales del sistema: interfaz y comportamiento
El sistema implementado consta de dos módulos. El primer módulo, o módulo de interfaz,
implementa la dll del equipo, necesaria para la interacción con el simulador. El segundo, o
módulo de comportamiento, implementa el comportamiento de los cinco agentes lógicos que
conforman el equipo, siguiendo el paradigma de programación en lógica usando el lenguaje
Prolog. La dll descrita es la que requiere el simulador, y su única función es actuar como
interfaz entre éste y el módulo de comportamiento, donde se implementa el equipo propiamente
dicho.
En la inicialización del módulo de interfaz (dll) se crea e inicializa un intérprete Prolog
sobre el cual se ejecutará el código de los agentes lógicos implementados en el módulo de comportamiento. En cada ciclo de la simulación, el módulo de interfaz realiza una transformación de
los datos contenidos en la variable de entorno provista por el simulador, generando, a partir de
éstos, un término Prolog que será manipulado por los agentes del módulo de comportamiento.
Este término representa para cada agente su percepción actual del entorno.
A partir de esos datos, cada uno de los agentes lógicos evalúa la situación actual, establece
un objetivo y decide la acción a realizar en ese instante de tiempo. Las acciones decididas por
cada agente, las cuales son representadas también por términos Prolog, son procesadas por
el módulo de interfaz para actualizar la estructura de entorno que será retornada al simulador
en cada ciclo de la simulación (Figura 1).
Figura 1: Arquitectura del Sistema
3.
El Sistema de Agentes: módulo de comportamiento
El sistema fue desarrollado utilizando el lenguaje de programación Prolog para implementar las componentes de alto nivel de los agentes, representación de conocimiento y razonamiento. El mó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 lógicos fueron desarrollados utilizando Prolog debido a las ventajas que este lenguaje ofrece al
ser una herramienta de representación altamente declarativa. Por lo tanto, la mayorı́a de los
aspectos relacionados al diseño del comportamiento del equipo de agentes y a los procesos de
decisión que estos agentes realizan son implementados a alto nivel.
Entre otras cosas, esta herramienta permite la definición de estructuras de datos complejas
a través de términos que pueden manipularse uniformemente. La simplicidad en el manejo
de estos términos, combinada con el mecanismo implı́cito de backtracking y la unificación,
posibilita la clara definición de rutinas de comportamiento y de acceso a las estructuras de
información definidas. Eso permite, entre otras cosas, diseñar rápidamente agentes funcionales
cuyo comportamiento básico puede refinarse incrementalmente, a medida que se avanza sobre
el diseño del sistema multi-agente; esto es, el equipo.
3.1.
Perfil de los agentes: comportamiento básico
En esta sección se describe brevemente el diseñ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 determinación de sus metas inmediatas o de corto plazo. Cada agente jugador posee un
estado interno, en el cual se almacena información acerca del estado actual del mundo: posición,
orientació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 percepción y retorna una acción. Cuando
el agente recibe una percepció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 qué 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 té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 posición y orientación del jugador, y la velocidad a la que se desea ir durante
el trayecto.
3.2.
Primitivas de Movimiento
La única forma de controlar el movimiento de los jugadores simulados es determinando
una velocidad a cada una de sus ruedas. Fácilmente se pueden modelar movimientos primitivos
bá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 diseño de los procesos de razonamiento y toma de decisiones requieren contar
con primitivas de movimiento de más alto nivel. Por esta razón, se desarrollaron primitivas
Prolog de movimiento que permiten llevar a cabo movimientos má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 direcció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
posición (Pos_jugador) y tiene una determinada orientació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 posición (Pos_jugador) y tiene una determinada orientación (Or_jugador).
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 posición (Pos_jugador)
y tiene una determinada orientación (Or_jugador). También recibe como argumento la
velocidad a la que se desea ir durante el trayecto. Si el jugador está muy desenfocado con respecto al punto Destino, irA invocará a mirar, en caso contrario invocará a
irAConArco.
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 dirección a otro punto (Objetivo),
dado que se encuentra en una determinada posición (Pos_jugador) y tiene una determinada orientación (Or_jugador).
irAPerfilado(+Or jugador,+Pos jugador,+Destino,+Objetivo,-Accion)
Es importante notar que, para lograr un comportamiento más preciso, es necesario tener
un buen control de la velocidad. Por esta razón, el diseño de las primitivas de movimiento
consideran parámetros de velocidad, los cuales son determinados previamente a la ejecución de
los movimientos, luego de un análisis de la situació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 ejecución de la acción.
Durante el proceso de decisió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 última instancia antes de la ejecución efectiva de cada acción. Se entiende que,
en este entorno simulado, la ejecución de las acciones seleccionadas por cada agente, en cada
instante de tiempo, se traducen finalmente en la determinación de dos valores que representarán
las velocidades de las ruedas que deben asignarse a cada robot en cada ciclo de la simulación.
3.3.
Razonamiento: Á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 cómo debe refinarse una meta de acuerdo al conocimiento acerca
del mundo, es utilizar un árbol de refinamiento de metas.
Los nodos del árbol se etiquetan con metas y los arcos con expresiones ló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 expresión booleana asociada a un arco de un nodo padre a un nodo hijo representa la
condició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 á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 sólo una de las condiciones que etiquetan los arcos salientes
será verdadera. De esta manera, dado el conocimiento actual acerca del mundo, el camino a
seguir dado por el árbol de refinamiento está unı́vocamente determinado.
El algoritmo para razonar usando estos árboles consiste en partir de la raı́z e ir moviéndose
hacia abajo siguiendo los arcos cuya expresió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 implementación del razonamiento usando estos á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 árbol. Este predicado tendrá 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 árbol de refinamiento
árbol. Por ejemplo, para el caso del árbol de la figura 3 deberı́a escribirse el siguiente código
Prolog:
refinarMeta(atacar, Meta inmediata) ←−
soy el más cercano a la pelota,
refinarMeta(dominar pelota, Meta inmediata).
refinarMeta(atacar, Meta inmediata) ←−
NO soy el má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 situació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 ejecución consigue dicha meta. Por ejemplo, la meta llegar a perfilado(pelota,arco)
está asociada a la primitiva ir a perfilado/5.
4.
Conclusiones
Como se mencionó al comienzo, una de las motivaciones para el desarrollo de este trabajo
es la realización de investigación básica en sistemas multi-agentes. En el caso particular de
este trabajo, el énfasis está 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 lógicos. Una ventaja
de esto es que posibilitarı́a la definición de agentes lógicos con la habilidad de adaptarse a
cambios del entorno. Estos cambios podrı́an verse reflejados en la decisión de cambiar la forma
de refinar las metas. Dicho de otra forma, un agente podrı́a variar dinámicamente su polı́tica
de comportamiento a través de la reestructuración del arbol de refinamiento lo cual puede
realizarse actualizando dinámicamente su base de conocimiento. Al estar representados estos
árboles a través de programas lógicos Prolog la reestructuración se lograrı́a directamente con
la actualización dinámica del có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.Ñ., 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
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
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
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
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
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.
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
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
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
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
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
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
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
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
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
[email protected]
http://www.fing.edu.uy/~ecopello
3
[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
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
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
Investigación en Sistemas Multi-agente y
Robótica Cognitiva aplicada a la Robótica
Móvil en el dominio de Fútbol de Robots
Alejandro J. Garcı́a
Telma Delladio
Mariano Tucat
Nicolás D. Rotstein
Diego R. Garcı́a
Laboratorio de Investigación y Desarrollo en Inteligencia Artificial (lidia)
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 investigación
que nuestro grupo está desarrollando en inteligencia artificial aplicada a la robótica móvil.
En particular, en este trabajo se describen las lı́neas de investigación que están asociadas
al desarrollo de un equipo de fútbol de robots.
Con el desarrollo de estas lı́neas de investigación el objetivo es doble. En primer lugar
se desea aportar nuevas soluciones para los problemas que se presentan en robótica móvil.
En segundo lugar se desea utilizar un dominio de aplicación concreto de robots móviles
para obtener retro-alimentación y desarrollar mejores formalismos en el área de agentes
inteligentes, sistemas multi-agente y robótica cognitiva.
1.
Robótica Móvil, Robótica Cognitiva y Sistemas Multi-agente
Disponer de robots móviles con algún grado de inteligencia requiere integrar facilidades de
bajo nivel (manejo de sensores, movimientos básicos, evasión de obstáculos, navegación, etc)
con habilidades de alto nivel como razonamiento, representación de creencias, planificación, comunicación con otros agentes, interacción, coordinación, etc. El desarrollo de dichas facilidades
y habilidades debe tener en cuenta que si el robot móvil opera en un ambiente dinámico, donde
además pueden existir otros agentes que interactúan con é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 ejecución.
Estas habilidades de alto nivel se encuentran actualmente en estudio en dos áreas de inteligencia artificial que han tenido un gran impulso en los últimos años: Robótica Cognitiva y
Sistemas Multi-agente (SMA). La investigación en Robó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
problemáticas abordadas por el área de Robótica Cognitiva incluyen:
la necesidad de desenvolverse en dominios diná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 actualización y revisión del conocimiento disponible en forma eficiente y semánticamente correcta;
el diseño de arquitecturas de agentes adecuadas que soporten las soluciones a todos esos
problemas.
Por esta razón, los trabajos en robótica cognitiva son muy variados y abordan temáticas complejas como:
representación de conocimiento y razonamiento;
definición de lenguajes de control de algo nivel para el desarrollo de razonadores;
la definición y desarrollo de planificadores;
la definición de formalismos de razonamiento acerca de acciones y cambio;
revisión de conocimiento y aprendizaje;
arquitecturas de agentes inteligentes.
Además, si los robots mó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 sólo con habilidades cognitivas,
sino también con habilidades sociales tales como: cooperación, coordinación, y comunicación
entre agentes. Estas habilidades sociales se encuentran actualmente en estudio dentro del área
de Sistemas Multi-agente.
Como fue dicho anteriormente, nuestro interés en robótica móvil es doble. Por un lado, uno
de lo objetivos centrales es la aplicación de formalismos que han sido desarrollados por nuestro
grupo en diferentes áreas de inteligencia artificial, los cuales permitirán obtener las habilidades
de alto nivel (cognitivas y sociales) antes mencionadas. Por otro lado, se está utilizando un grupo
de robots en un dominio de aplicación especı́fico como lo es un partido de fútbol de robots, con
el objetivo de obtener retro-alimentación en temas fundamentales de SMA como coordinación,
interacción, colaboración y comunicación; ası́ como también en temas centrales de Robótica
Cognitiva como representación de conocimiento, razonamiento, planificación y aprendizaje.
En la sección 3 se describirán en detalle las lı́neas de investigación que se están llevando
a cabo en nuestro grupo. Estas lı́neas involucran desarrollos teóricos y prácticos en robótica
cognitiva y SMA, y están siendo aplicadas en el desarrollo de un equipo de fútbol de robots el
cual se describe en la sección siguiente.
2.
El dominio de aplicación
En esta sección se describe brevemente cual es el dominio de aplicación sobre el cual se
están aplicando las lı́neas de investigación que describiremos en la sección siguiente. Se trata
de un equipo de fútbol de robots de la modalidad E-league [1], formado por cuatro robots Lego
Mindstorm [2]. Para su funcionamiento, se han diseñado e implementado un sistema multiagente donde cada agente lógico controla un jugador del equipo de robots. A continuación
incluimos un resumen del diseño de este sistema, los detalles pueden verse en [10] y [9].
Figura 1: Diseño del Sistema Multi-agente que controla a los robots [9]
El sistema fue desarrollado siguiendo un diseño por capas (Figura 1).
El SMA fue diseñado como muestra la Figura 1 donde cada capa de servicio está asociada
a un diferente nivel de abstracció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 básicos
provistos por el hardware de visión y comunicación con los robots. La capa siguiente (logical
communication layer) está implementada en C y utiliza los servicios de la anterior y provee
dos primitivas básicas: la función de percepción y la primitiva de comunicación con los robots.
La siguiente (sensorial/effectorial) está implementada en Prolog y provee las primitivas básicas
para implementar el comportamiento de los robots. La má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. Además, nuevos desarrollos a nivel cognitivo
pueden ponerse a prueba simplemente a través de la reformulación de los servicios de la capa
cognitiva.
3.
Lı́neas de investigación en curso
En esta sección se describen las siguientes lı́neas de investigación aplicadas a problemáticas
relacionadas con robótica móvil:
Representación de conocimiento y razonamiento con argumentación rebatible.
Arquitecturas de Agentes.
Aprendizaje.
Interacción y comunicación en Sistemas Multi-agente.
Planificación.
Estas lı́neas de investigación se encuentran actualmente en desarrollo en nuestro laboratorio.
3.1.
Representación de conocimiento y razonamiento con argumentación rebatible
Como ya se dijo, un robot móvil deberı́a poder desenvolverse en dominios dinámicos con
conocimiento incompleto acerca de su entorno. Esto incluye informació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 información
incompleta y cambiante.
En nuestro laboratorio se ha desarrollado un formalismo de razonamiento con argumentación
rebatible que permite realizar inferencias sobre conocimiento incompleto y potencialmente contradictorio. Este formalismo, denominado Defeasible Logic Programming (DeLP) o Programación en Lógica Rebatible [11], permite representar conocimiento con reglas rebatibles y
estrictas. En DeLP las conclusiones de un agente son sustentadas con argumentos. Una conclusió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 conclusión este podrı́a ser atacado por otros argumentos derrotadores
que lo contradigan. Dichos derrotadores podrán a su vez ser atacados, y ası́ sucesivamente,
generando una secuencia de argumentos llamada lı́nea de argumentación. En DeLP el proceso
completo considera para cada argumento todos sus posibles derrotadores, lo cual, en lugar de
una única lı́nea de argumentación, genera un conjunto de lı́neas representadas a través de un
árbol de dialéctica. Un proceso de análisis dialéctico determina, a partir del conocimiento del
agente, si la conclusión en cuestión está garantizada o no.
La utilizació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 además analizar
cómo se comporta DeLP en un dominio de aplicación de robots mó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 éxito o fracaso de las mismas. Estas razones
se apoyan en la información que posee cada agente acerca de las posiciones del resto de los
jugadores y la pelota, dentro del campo de juego. Un análisis argumentativo sobre la garantı́a
de la ejecución de las acciones disponibles conforma la base para la etapa final del proceso de
razonamiento. Este proceso, enmarcado en una arquitectura BDI (ver Sección 3.2), finaliza con
la determinación de una intención que se materializará en una acción fı́sica por parte del robot.
3.2.
Arquitecturas de Agentes
El objetivo principal de esta lı́nea de investigación es analizar cómo se adecúa al dominio
de fútbol de robots una combinación entre una arquitectura de agentes BDI (Belief-DesireIntention) y un sistema de razonamiento con argumentación rebatible (DeLP). El dominio
de aplicación ofrece el desafı́o de ser altamente dinámico y determina una cierta variedad de
acciones, las cuales, de alguna manera, compiten entre sı́ para determinar cuál será la próxima
a ser ejecutada.
La arquitectura BDI que describe la implementación de los agentes de software que controlan
a los robots fı́sicos (Figura 2) está conformada por los conjuntos de creencias (B), deseos (D) e
intenciones (I) que se detallan a continuación:
Creencias (Beliefs): El conjunto de creencias reúne toda la información que obtiene el
agente únicamente a través de su percepción del mundo. A partir de este conjunto el
agente puede actuar en consecuencia, ya que tiene su propia representación del entorno
que lo rodea. La calidad y el detalle de la informació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 determinará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 situación actual, habrá deseos que no podrán cumplirse y deberán ser
reprimidos. Esto es imprescindible para que el agente pueda cumplir con la misión que le
fue encomendada.
Figura 2: Ciclo BDI utilizando DeLP como mó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 materialización de los deseos,
habiéndolos contrastado previamente con el estado del mundo y del agente en sı́. En esta
implementación, el conjunto de intenciones será un único elemento del conjunto de deseos
y representará la acció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), posesió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 está relacionada con la autonomı́a. Por esa razón, la
importancia del estudio de mecanismos de aprendizaje en el desarrollo de agentes autónomos.
Dentro del área de Machine Learning, la Programación en Ló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 Programación en Lógica Inductiva utilizan formalismos de
Programación en Lógica como herramienta de representación de conocimiento y razonamiento,
junto con mecanismos de inducción para sintetizar, a partir de ejemplos, programas lógicos
que sirven como definición de los conceptos que se desean aprender. La obtenció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 definició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 Programación en Lógica Inductiva.
Además, considerando la flexibilidad necesaria para llevar adelante una tarea cooperativa tan
compleja, se ha estudiado la utilización de otros paradigmas de programación en lógica como la
Programación en Lógica Rebatible [7] como herramienta de representación de conocimiento y
razonamiento no monótono a partir de la cual desarrollar aprendizaje inductivo de conceptos.
La Programación en Lógica Rebatible como herramienta de razonamiento no monó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 posición y acción las cuales pueden ser modeladas a través de conceptos
representados por términos lógicos. La valoración de la correctitud de los conceptos aprendidos
puede ser determinada en la dinámica del juego considerando los resultados obtenidos en el
transcurso del mismo. A má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.
Interacción y comunicación en Sistemas Multi-agente
La interacción es una caracterı́stica esencial de un Sistema Multi-Agente. Dicha interacción
puede ser llevada a cabo a través del intercambio de mensajes de acuerdo a una polı́tica de
conversación determinada, o a la ejecució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 fútbol de robots puede considerarse un SMA donde existe cooperación entre
los agentes del mismo equipo y competencia entre agentes de equipos contrarios. En este dominio
de aplicación los agentes (jugadores) necesitan interactuar y comunicarse. Por ejemplo, en
casos donde la visión de los robots es parcial, éstos podrı́an comunicarse para intercambiar la
información del entorno que cada uno posee, como ser la ubicación de los demás jugadores.
También podrı́an interactuar para planificar y coordinar jugadas, o simplemente para informar
sobre alguna decisión tomada que pudiera afectar el comportamiento del resto del equipo.
Nuestro objetivo es proveer una extensión de la Programación en Lógica que permita implementar comunicación entre agentes sin necesidad de programar elementos de conexión de
bajo nivel. En esta lı́nea de trabajo se ha desarrollado una extensión de Prolog [18] que provee
un conjunto de primitivas de interacción con las siguientes caracterı́sticas:
1. Permite la creación de distintos SMA independientes.
2. Un agente que se une a un SMA, puede comunicarse con los demás integrantes del sistema
simplemente conociendo sus nombres. No es necesario especificar información de conexión
de bajo nivel como, por ejemplo, el identificador de la má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 ejecución de un
predicado determinado. Esto permite una programación orientada a eventos.
5. Además, es posible realizar una asociación diferente para cada agente. Es decir, dependiendo de quien envı́e el mensaje, se ejecutará el predicado asociado previamente.
3.5.
Planificación
En un ambiente dinámico y complejo como un partido de fútbol, resulta muy difı́cil considerar todas las posibles situaciones que un robot puede enfrentar. Una tarea mas difı́cil aú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 diseñ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 más amplia y aumentar su autonomı́a. Más aú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 planificación actual resulta inadecuada para resolver los tipos
de problemas que enfrenta un robot de este tipo. Esto se debe a que los métodos tradicionales de
planificación asumen simplificaciones sobre los problemas planificación, que resultan adecuadas
para otros dominios y disminuyen la complejidad de los problemas. Las simplificaciones má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 módulo separado, en lugar de estar integrado a la arquitectura
cognitiva del robot.
En un ambiente dinámico como un partido de fútbol estas suposiciones pueden fallar debido
a que:
El conocimiento del robot acerca del mundo, por más preciso que sea, será incompleto.
Las creencias del robot son falibles y a medida que adquiere más información sus creencias
pueden cambiar.
A medida que el mundo cambia, las creencias del robot deben actualizarse.
El robot interactúa con otros robots que pueden cambiar el estado del mundo.
El propósito de esta lı́nea de investigación es la incorporación y adaptación de técnicas de
planificación a la arquitectura de los robots, con el objetivo facilitar el diseño e implementación
de su comportamiento y aumentar su autonomı́a.
3.6.
Facilidades de bajo nivel
Ademá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 percepción y
acción. Por ejemplo, una tarea elemental que debe realizar un robot al desenvolverse en un
medio fı́sico es la de trasladarse desde su posición actual hacia una ubicación deseada. Para
lograrlo, debe tener la capacidad de evadir posibles obstáculos, tanto estáticos como dinámicos.
Para ello se ha desarrollado un algoritmo de evasión de obstáculos con bajo costo computacional
basado en campos de potencial [17]. Otro ejemplo es la minimización de errores que ocurren en
la etapa de sensado y en la ejecución de acciones (el resultado real de su ejecució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 investigación que se están desarrollando actualmente en nuestro laboratorio en las áreas de robótica cognitiva y SMA, con el
objetivo de proveer soluciones a problemas en robótica mó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 Computación (WICC 2002) (2002).
[7] Delladio, T. Aprendizaje de conocimiento rebatible. Anales del IX Congreso Argentino
de Ciencias de la Computació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 Computació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 percepción y
acción en el dominio de un equipo de fútbol de robots. Anales del X Congreso Argentino
de Ciencias de la Computació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. Evasión de obstáculos con bajo costo computacional
para un equipo de fútbol de robots. Anales del X Congreso Argentino de Ciencias de la
Computación (CACiC 2004) (2004).
[18] Tucat, M. Primitivas de Interacción para el Desarrollo de Sistemas Multi-agente.
Proyecto Final de Ingenierı́a en Sistemas de Computación. Departamento de Ciencias
e Ingenierı́a de la Computación, Universidad Nacional del Sur, Bahı́a Blanca, Argentina,
http://cs.uns.edu.ar/∼ajg/interaction primitives/, mar 2005.
Investigación en Sistemas Multi-agente y
Robótica Cognitiva aplicada a la Robótica
Móvil en el dominio de Fútbol de Robots
Alejandro J. Garcı́a
Telma Delladio
Mariano Tucat
Nicolás D. Rotstein
Diego R. Garcı́a
Laboratorio de Investigación y Desarrollo en Inteligencia Artificial (lidia)
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 investigación
que nuestro grupo está desarrollando en inteligencia artificial aplicada a la robótica móvil.
En particular, en este trabajo se describen las lı́neas de investigación que están asociadas
al desarrollo de un equipo de fútbol de robots.
Con el desarrollo de estas lı́neas de investigación el objetivo es doble. En primer lugar
se desea aportar nuevas soluciones para los problemas que se presentan en robótica móvil.
En segundo lugar se desea utilizar un dominio de aplicación concreto de robots móviles
para obtener retro-alimentación y desarrollar mejores formalismos en el área de agentes
inteligentes, sistemas multi-agente y robótica cognitiva.
1.
Robótica Móvil, Robótica Cognitiva y Sistemas Multi-agente
Disponer de robots móviles con algún grado de inteligencia requiere integrar facilidades de
bajo nivel (manejo de sensores, movimientos básicos, evasión de obstáculos, navegación, etc)
con habilidades de alto nivel como razonamiento, representación de creencias, planificación, comunicación con otros agentes, interacción, coordinación, etc. El desarrollo de dichas facilidades
y habilidades debe tener en cuenta que si el robot móvil opera en un ambiente dinámico, donde
además pueden existir otros agentes que interactúan con é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 ejecución.
Estas habilidades de alto nivel se encuentran actualmente en estudio en dos áreas de inteligencia artificial que han tenido un gran impulso en los últimos años: Robótica Cognitiva y
Sistemas Multi-agente (SMA). La investigación en Robó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
problemáticas abordadas por el área de Robótica Cognitiva incluyen:
la necesidad de desenvolverse en dominios diná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 actualización y revisión del conocimiento disponible en forma eficiente y semánticamente correcta;
el diseño de arquitecturas de agentes adecuadas que soporten las soluciones a todos esos
problemas.
Por esta razón, los trabajos en robótica cognitiva son muy variados y abordan temáticas complejas como:
representación de conocimiento y razonamiento;
definición de lenguajes de control de algo nivel para el desarrollo de razonadores;
la definición y desarrollo de planificadores;
la definición de formalismos de razonamiento acerca de acciones y cambio;
revisión de conocimiento y aprendizaje;
arquitecturas de agentes inteligentes.
Además, si los robots mó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 sólo con habilidades cognitivas,
sino también con habilidades sociales tales como: cooperación, coordinación, y comunicación
entre agentes. Estas habilidades sociales se encuentran actualmente en estudio dentro del área
de Sistemas Multi-agente.
Como fue dicho anteriormente, nuestro interés en robótica móvil es doble. Por un lado, uno
de lo objetivos centrales es la aplicación de formalismos que han sido desarrollados por nuestro
grupo en diferentes áreas de inteligencia artificial, los cuales permitirán obtener las habilidades
de alto nivel (cognitivas y sociales) antes mencionadas. Por otro lado, se está utilizando un grupo
de robots en un dominio de aplicación especı́fico como lo es un partido de fútbol de robots, con
el objetivo de obtener retro-alimentación en temas fundamentales de SMA como coordinación,
interacción, colaboración y comunicación; ası́ como también en temas centrales de Robótica
Cognitiva como representación de conocimiento, razonamiento, planificación y aprendizaje.
En la sección 3 se describirán en detalle las lı́neas de investigación que se están llevando
a cabo en nuestro grupo. Estas lı́neas involucran desarrollos teóricos y prácticos en robótica
cognitiva y SMA, y están siendo aplicadas en el desarrollo de un equipo de fútbol de robots el
cual se describe en la sección siguiente.
2.
El dominio de aplicación
En esta sección se describe brevemente cual es el dominio de aplicación sobre el cual se
están aplicando las lı́neas de investigación que describiremos en la sección siguiente. Se trata
de un equipo de fútbol de robots de la modalidad E-league [1], formado por cuatro robots Lego
Mindstorm [2]. Para su funcionamiento, se han diseñado e implementado un sistema multiagente donde cada agente lógico controla un jugador del equipo de robots. A continuación
incluimos un resumen del diseño de este sistema, los detalles pueden verse en [10] y [9].
Figura 1: Diseño del Sistema Multi-agente que controla a los robots [9]
El sistema fue desarrollado siguiendo un diseño por capas (Figura 1).
El SMA fue diseñado como muestra la Figura 1 donde cada capa de servicio está asociada
a un diferente nivel de abstracció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 básicos
provistos por el hardware de visión y comunicación con los robots. La capa siguiente (logical
communication layer) está implementada en C y utiliza los servicios de la anterior y provee
dos primitivas básicas: la función de percepción y la primitiva de comunicación con los robots.
La siguiente (sensorial/effectorial) está implementada en Prolog y provee las primitivas básicas
para implementar el comportamiento de los robots. La má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. Además, nuevos desarrollos a nivel cognitivo
pueden ponerse a prueba simplemente a través de la reformulación de los servicios de la capa
cognitiva.
3.
Lı́neas de investigación en curso
En esta sección se describen las siguientes lı́neas de investigación aplicadas a problemáticas
relacionadas con robótica móvil:
Representación de conocimiento y razonamiento con argumentación rebatible.
Arquitecturas de Agentes.
Aprendizaje.
Interacción y comunicación en Sistemas Multi-agente.
Planificación.
Estas lı́neas de investigación se encuentran actualmente en desarrollo en nuestro laboratorio.
3.1.
Representación de conocimiento y razonamiento con argumentación rebatible
Como ya se dijo, un robot móvil deberı́a poder desenvolverse en dominios dinámicos con
conocimiento incompleto acerca de su entorno. Esto incluye informació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 información
incompleta y cambiante.
En nuestro laboratorio se ha desarrollado un formalismo de razonamiento con argumentación
rebatible que permite realizar inferencias sobre conocimiento incompleto y potencialmente contradictorio. Este formalismo, denominado Defeasible Logic Programming (DeLP) o Programación en Lógica Rebatible [11], permite representar conocimiento con reglas rebatibles y
estrictas. En DeLP las conclusiones de un agente son sustentadas con argumentos. Una conclusió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 conclusión este podrı́a ser atacado por otros argumentos derrotadores
que lo contradigan. Dichos derrotadores podrán a su vez ser atacados, y ası́ sucesivamente,
generando una secuencia de argumentos llamada lı́nea de argumentación. En DeLP el proceso
completo considera para cada argumento todos sus posibles derrotadores, lo cual, en lugar de
una única lı́nea de argumentación, genera un conjunto de lı́neas representadas a través de un
árbol de dialéctica. Un proceso de análisis dialéctico determina, a partir del conocimiento del
agente, si la conclusión en cuestión está garantizada o no.
La utilizació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 además analizar
cómo se comporta DeLP en un dominio de aplicación de robots mó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 éxito o fracaso de las mismas. Estas razones
se apoyan en la información que posee cada agente acerca de las posiciones del resto de los
jugadores y la pelota, dentro del campo de juego. Un análisis argumentativo sobre la garantı́a
de la ejecución de las acciones disponibles conforma la base para la etapa final del proceso de
razonamiento. Este proceso, enmarcado en una arquitectura BDI (ver Sección 3.2), finaliza con
la determinación de una intención que se materializará en una acción fı́sica por parte del robot.
3.2.
Arquitecturas de Agentes
El objetivo principal de esta lı́nea de investigación es analizar cómo se adecúa al dominio
de fútbol de robots una combinación entre una arquitectura de agentes BDI (Belief-DesireIntention) y un sistema de razonamiento con argumentación rebatible (DeLP). El dominio
de aplicación ofrece el desafı́o de ser altamente dinámico y determina una cierta variedad de
acciones, las cuales, de alguna manera, compiten entre sı́ para determinar cuál será la próxima
a ser ejecutada.
La arquitectura BDI que describe la implementación de los agentes de software que controlan
a los robots fı́sicos (Figura 2) está conformada por los conjuntos de creencias (B), deseos (D) e
intenciones (I) que se detallan a continuación:
Creencias (Beliefs): El conjunto de creencias reúne toda la información que obtiene el
agente únicamente a través de su percepción del mundo. A partir de este conjunto el
agente puede actuar en consecuencia, ya que tiene su propia representación del entorno
que lo rodea. La calidad y el detalle de la informació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 determinará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 situación actual, habrá deseos que no podrán cumplirse y deberán ser
reprimidos. Esto es imprescindible para que el agente pueda cumplir con la misión que le
fue encomendada.
Figura 2: Ciclo BDI utilizando DeLP como mó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 materialización de los deseos,
habiéndolos contrastado previamente con el estado del mundo y del agente en sı́. En esta
implementación, el conjunto de intenciones será un único elemento del conjunto de deseos
y representará la acció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), posesió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 está relacionada con la autonomı́a. Por esa razón, la
importancia del estudio de mecanismos de aprendizaje en el desarrollo de agentes autónomos.
Dentro del área de Machine Learning, la Programación en Ló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 Programación en Lógica Inductiva utilizan formalismos de
Programación en Lógica como herramienta de representación de conocimiento y razonamiento,
junto con mecanismos de inducción para sintetizar, a partir de ejemplos, programas lógicos
que sirven como definición de los conceptos que se desean aprender. La obtenció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 definició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 Programación en Lógica Inductiva.
Además, considerando la flexibilidad necesaria para llevar adelante una tarea cooperativa tan
compleja, se ha estudiado la utilización de otros paradigmas de programación en lógica como la
Programación en Lógica Rebatible [7] como herramienta de representación de conocimiento y
razonamiento no monótono a partir de la cual desarrollar aprendizaje inductivo de conceptos.
La Programación en Lógica Rebatible como herramienta de razonamiento no monó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 posición y acción las cuales pueden ser modeladas a través de conceptos
representados por términos lógicos. La valoración de la correctitud de los conceptos aprendidos
puede ser determinada en la dinámica del juego considerando los resultados obtenidos en el
transcurso del mismo. A má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.
Interacción y comunicación en Sistemas Multi-agente
La interacción es una caracterı́stica esencial de un Sistema Multi-Agente. Dicha interacción
puede ser llevada a cabo a través del intercambio de mensajes de acuerdo a una polı́tica de
conversación determinada, o a la ejecució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 fútbol de robots puede considerarse un SMA donde existe cooperación entre
los agentes del mismo equipo y competencia entre agentes de equipos contrarios. En este dominio
de aplicación los agentes (jugadores) necesitan interactuar y comunicarse. Por ejemplo, en
casos donde la visión de los robots es parcial, éstos podrı́an comunicarse para intercambiar la
información del entorno que cada uno posee, como ser la ubicación de los demás jugadores.
También podrı́an interactuar para planificar y coordinar jugadas, o simplemente para informar
sobre alguna decisión tomada que pudiera afectar el comportamiento del resto del equipo.
Nuestro objetivo es proveer una extensión de la Programación en Lógica que permita implementar comunicación entre agentes sin necesidad de programar elementos de conexión de
bajo nivel. En esta lı́nea de trabajo se ha desarrollado una extensión de Prolog [18] que provee
un conjunto de primitivas de interacción con las siguientes caracterı́sticas:
1. Permite la creación de distintos SMA independientes.
2. Un agente que se une a un SMA, puede comunicarse con los demás integrantes del sistema
simplemente conociendo sus nombres. No es necesario especificar información de conexión
de bajo nivel como, por ejemplo, el identificador de la má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 ejecución de un
predicado determinado. Esto permite una programación orientada a eventos.
5. Además, es posible realizar una asociación diferente para cada agente. Es decir, dependiendo de quien envı́e el mensaje, se ejecutará el predicado asociado previamente.
3.5.
Planificación
En un ambiente dinámico y complejo como un partido de fútbol, resulta muy difı́cil considerar todas las posibles situaciones que un robot puede enfrentar. Una tarea mas difı́cil aú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 diseñ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 más amplia y aumentar su autonomı́a. Más aú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 planificación actual resulta inadecuada para resolver los tipos
de problemas que enfrenta un robot de este tipo. Esto se debe a que los métodos tradicionales de
planificación asumen simplificaciones sobre los problemas planificación, que resultan adecuadas
para otros dominios y disminuyen la complejidad de los problemas. Las simplificaciones má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 módulo separado, en lugar de estar integrado a la arquitectura
cognitiva del robot.
En un ambiente dinámico como un partido de fútbol estas suposiciones pueden fallar debido
a que:
El conocimiento del robot acerca del mundo, por más preciso que sea, será incompleto.
Las creencias del robot son falibles y a medida que adquiere más información sus creencias
pueden cambiar.
A medida que el mundo cambia, las creencias del robot deben actualizarse.
El robot interactúa con otros robots que pueden cambiar el estado del mundo.
El propósito de esta lı́nea de investigación es la incorporación y adaptación de técnicas de
planificación a la arquitectura de los robots, con el objetivo facilitar el diseño e implementación
de su comportamiento y aumentar su autonomı́a.
3.6.
Facilidades de bajo nivel
Ademá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 percepción y
acción. Por ejemplo, una tarea elemental que debe realizar un robot al desenvolverse en un
medio fı́sico es la de trasladarse desde su posición actual hacia una ubicación deseada. Para
lograrlo, debe tener la capacidad de evadir posibles obstáculos, tanto estáticos como dinámicos.
Para ello se ha desarrollado un algoritmo de evasión de obstáculos con bajo costo computacional
basado en campos de potencial [17]. Otro ejemplo es la minimización de errores que ocurren en
la etapa de sensado y en la ejecución de acciones (el resultado real de su ejecució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 investigación que se están desarrollando actualmente en nuestro laboratorio en las áreas de robótica cognitiva y SMA, con el
objetivo de proveer soluciones a problemas en robótica mó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 Computación (WICC 2002) (2002).
[7] Delladio, T. Aprendizaje de conocimiento rebatible. Anales del IX Congreso Argentino
de Ciencias de la Computació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 Computació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 percepción y
acción en el dominio de un equipo de fútbol de robots. Anales del X Congreso Argentino
de Ciencias de la Computació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. Evasión de obstáculos con bajo costo computacional
para un equipo de fútbol de robots. Anales del X Congreso Argentino de Ciencias de la
Computación (CACiC 2004) (2004).
[18] Tucat, M. Primitivas de Interacción para el Desarrollo de Sistemas Multi-agente.
Proyecto Final de Ingenierı́a en Sistemas de Computación. Departamento de Ciencias
e Ingenierı́a de la Computación, Universidad Nacional del Sur, Bahı́a Blanca, Argentina,
http://cs.uns.edu.ar/∼ajg/interaction primitives/, mar 2005.
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
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
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)
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
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
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
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
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
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
El Equipo Futbol Robots GallitoSoT
Corlevich, María Lorena – Escobar, Daniel Pascal – Guerrero, Alejandro – Montenegro, Victor
Facultad de Informática Universidad de Morón
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
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
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
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.
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
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
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
I.
Introducción
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
1. Habilidades:
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)
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
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.
Registro cancha
5
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.
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
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

CAFR 2005 - F:I:C:C:T:E:

Transcripción

Documentos relacionados

Número 4 - La canica

CAMP 2010 FLYER-spanish

ErgoPakPal - Combi Packaging Systems