Maceri Tesisingenieriainformatica

APRENDIZAJE AUTOMATICO BASADO EN INTERCAMBIO DE OPERADORES EN SISTEMAS INTELIGENTES AUTONOMOS TESIS DE GRADO EN INGENIERIA INFORMATICA FACULTAD DE INGENIERIA UNIVERSIDAD
DE BUENOS AIRES
TESISTA: Sr. Pablo MACERI DIRECTOR: Prof. Dr. Ramn GARCIA-MARTINEZ Laboratorio de Sistemas Inteligentes JUNIO 2001
Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos
Resumen
Los sistemas inteligentes que actan de forma autnoma en un ambiente tienen que ser capaces de integrar tres comportamientos bsicos: aprendizaje, planificacin y ejecucin. Esta integracin es imprescindible cuando se requiere del sistema un desempeo satisfactorio en ausencia de conocimiento sobre cmo sus acciones pueden afectar el ambiente en el cual funciona o cmo reacciona ste a sus acciones. En este contexto, los sistemas inteligentes autnomos (SIA) deben ser capaces de aprender el comportamiento de su ambiente y estructurar este aprendizaje mediante la formulacin de teoras de su funcionamiento (operadores). Por otra parte, deben ser capaces de autoproponerse objetivos y construir planes (a partir de la teora de funcionamiento del ambiente que han aprendido) para alcanzarlos. En este trabajo, se estudia de qu manera la interaccin entre sistemas inteligentes autnomos, que intercambian los operadores aprendidos en un mismo ambiente, mejora el comportamiento individual acelerando la convergencia del aprendizaje y el rendimiento general para alcanzar los objetivos autopropuestos por el SIA.
Palabras claves: Planificacin, aprendizaje no supervisado, sistemas inteligentes autnomos, formacin y revisin de teoras, cooperacin entre agentes.
Abstract
Intelligent systems that act autonomously in an environment have to be able to integrate three basic behaviors: learning, planning and execution. This integration is mandatory when the system must have a satisfactory performance without any knowledge about how its actions can affect the environment in which it runs or how the environment reacts to its actions. In this context, autonomous intelligent systems (AIS) have to be able to learn the enviroments behavior and to structure this learning by the formulation of theories about his permormace (operators). Moreover, they have to be able to self-propose goals and setup plans for achieving them.
Resumen Pablo M. Maceri i
This work studies how the interaction between autonomous intelligent systems, that share the operators learnt in the same environment, improves the individual performance increasing the learning convergence speed and the general performance to achieve the AIS self-proposed goals. Keywords: Planning, unsupervised machine learning, autonomous intelligent systems, theory formation and revision, cooperation between agents.
ii
Pablo M. Maceri
Resumen
Indice
Captulo 1 - Introduccin Captulo 2 - Estado de la Cuestin 2.1. GINKO: Una arquitectura integrada para aprendizaje y planificacin en robtica 2.2. PRODIGY: una arquitectura integrada para planificacin y aprendizaje 2.3. Un Anlisis de Soar como una Arquitectura Integrada 2.4. LIVE: una arquitectura para aprendizaje del entorno 2.5. Dyna, una Arquitectura Integrada para Aprendizaje, Planificacin 2.6. Sistema de Christiansen 2.7. Sistema de Hayes-Roth 2.8. Sistema Inteligente Autnomo Captulo 3 - Descripcin del Problema 3.1. Introduccin 3.2. Integracin SIA-Khepera 3.3. El problema de la extensin del modelo del SIA 3.4. Interaccin entre intercambio de operadores y otras estrategias 3.5. Lugar de las soluciones Captulo 4 - Solucin Propuesta 4.1. Introduccin 4.2. Representacin del modelo de teora 4.3. Descripcin General del Sistema 4.4. Arquitectura del Sistema 4.5. Entorno del Sistema 4.6 Sistema Sensor 4.7. Mdulo de Aprendizaje 4.8. Mdulo Planificador 4.9. Mdulo Ponderador de Planes 4.10. Mdulo Controlador de Planes en Ejecucin 4.11. Mdulo de Intercambio de Teoras 4.12. Ejemplo Integrador Captulo 5 - Experimentos 5.1. Introduccin 5.2. Diseo Experimental 5.3. Grficas y su Interpretacin Captulo 6 - Conclusiones Referencias Anexo A - Simulador Khepera versin 2.0 1 5 5 7 10 13 15 18 20 22 25 25 26 26 26 27 29 29 31 32 34 35 36 37 38 42 45 45 50 71 71 71 73 83 87 95
A.1. Acuerdo de Licencia A.2. Introduccin A.3. Programacin A.4. Reconocimientos A.5. Referencias A.6. Apndice: Librera de funciones A.7. Apndice: Estructura de directorios A.8 Apndice: Comandos seriales Khepera A.9. Apndice: multirobots.h A.10. Preguntas ms frecuentes del Simulador Khepera Anexo B - Escenarios Anexo C - Datos Experimentales Anexo D - Documentacin del Sistema D.1. Introduccin D.3. Instalacin de los archivos fuente del SIA D.4. Integracin del SIA al Khepera D.5. Descripcin de los archivos fuente D.6. Esquema de interaccin de los mdulos D.7. Diagramas de estructura D.8. Comandos implementados D.9. Estructuras de datos D.10. Formato de los archivos de estadsticas Anexo E - Cdigo Fuente
95 95 99 105 106 107 111 112 113 115 121 129 135 135 136 140 141 145 146 149 150 153 155
Captulo 1
Introduccin
El Aprendizaje Automtico es una disciplina dentro de los Sistemas Inteligentes cuya importancia ha quedado establecida desde hace dos dcadas [Anderson y Kline, 1979]. De las variadas formas que se han explorado, la que mejor modeliza el aprendizaje humano es la que toma en los sistemas con aprendizaje por observacin y descubrimiento. Bock [1985] sostiene que no se puede hablar de Sistemas Inteligentes sino hay Aprendizaje Automtico. En apoyo de la postulacin de Bock sobre aprendizaje, RauchHindin [1985] sostiene que los sistemas que pueden observar y aprender a manejar cambios incesantes en los entornos de funcionamiento son el sueo de las organizaciones e industrias. Sostiene tambin el principio de que los programas de aprendizaje permiten comprobar teoras de aprendizaje [Moravec, 1988] y define los sistemas de produccin adaptativos como sistemas que aprenden nuevas reglas basadas en lo que han observado [Carbonell, 1983; Eiter y Gotlob, 1992; Falkenhaimer, 1990; Christiansen, 1992], agregando estas nuevas reglas al sistema de produccin existente. Un sistema inteligente autnomo ha sido definido [Fritz y otros, 1989; 1990; Garca Martnez y Borrajo, 1996] como aqul que puede descubrir y registrar si una accin hecha en una situacin dada fue favorable. Entra dentro de los sistemas que aprenden por observacin y descubrimiento por experimentacin activa [Wang, 1994; 1995]. Los sistemas inteligentes autnomos formulan operadores que en conjunto constituyen un modelo de como el entorno que los circunda funciona [Garca Martnez, 1992a]. Tal modelo es parcial pero tiene la consistencia suficiente [Garca Martnez, 1993a; 1993b; 1995] como para ser utilizado por su carcter predictivo en procesos de planificacin suficiente [Garca Martnez, 1996; 1997a; Garca Martnez et al., 1998a; 1998b; Garca Martnez et al., 1999a; 1999b]. En este contexto, el propsito de este proyecto es estudiar de que manera la interaccin entre sistemas inteligentes autnomos mejora el modelo de funcionamiento del entorno que cada sistema va formando y cmo se integran en dicha interaccin los modelos de refuerzo [Sutton, 1984].
Introduccin
Pablo M. Maceri
En este trabajo se parte del modelo de sistema que integra planificacin, aprendizaje, y ejecucin en un ciclo cerrado, mostrando un comportamiento inteligente autnomo. El sistema obtiene operadores de aprendizaje y planificacin mediante la observacin de las consecuencias de ejecutar acciones planeados en el ambiente. Para acelerar la convergencia, se utilizan heursticas de generalizacin de las observaciones. Se usan estimadores de probabilidad para manejar las contradicciones que presentan los operadores de planificacin generados. El mecanismo de aprendizaje no solo permite adquirir descripciones de los operadores, sino tambin adaptar dichas descripciones a los cambios del ambiente. En este trabajo se presenta una extensin del mecanismo de aprendizaje que permite compartir el conocimiento entre varios agentes. El resultado de usar una arquitectura multiagente muestra cmo la interaccin con otros sistemas de aprendizaje mejora la convergencia del aprendizaje y el comportamiento exitoso. El objetivo del sistema es planificar de una manera autnoma para alcanzar objetivos auto propuestos, ejecutar los planes, encontrar divergencias en los planes o corregir el comportamiento, y aprender operadores (modelos) que predicen los efectos de las acciones en el ambiento, observando las consecuencias de dichas acciones. Varios agentes pueden intercambiar el conocimiento bajo un mismo entorno de manera de mejorar su rendimiento y acelerar la convergencia del aprendizaje. En el captulo 2 se establece el estado del dominio de conocimiento sobre arquitecturas inteligentes describiendo la arquitectura del sistema GINKO (seccin 2.1), la arquitectura del sistema PRODIGY (seccin 2.2), la arquitectura del sistema SOAR (seccin 2.3), la arquitectura LIVE (seccin 2.4), la arquitectura DYNA (seccin 2.5), el sistema de Christiansen (seccin 2.6), el sistema de Hayes-Roth (seccin 2.7) y por ltimo el sistema inteligente autnomo (seccin 2.8). En el captulo 3 se presenta el entorno en el cual se plantea el problema a abordar en la tesis (seccin 3.1), se sealan cuestiones relativas a la integracin de la arquitectura elegida con una plataforma estandar (seccin 3.2), surgen las cuestiones relativas a la extensin de la arquitectura elegida (seccin 3.3), se sealan aspectos a explorar como resultado de la interaccin como estrategia de aprendizaje (seccin 3.4), y se identifican otras partes de la tesis donde se abordan las cuestiones precedentemente tratadas (seccin 3.5).
Pablo M. Maceri
Introduccin
En el captulo 4 se presenta una introduccin al sistema implementado y la plataforma utilizada (seccin 4.1), la representacin del modelo de teora (seccin 4.2), se da la descripcin general del sistema (seccin 4.3), se explica su arquitectura (seccin 4.4), se describe el entorno del sistema (seccin 4.5), se describe el sistema sensor (seccin 4.6), se explica el mdulo de aprendizaje (seccin 4.7), se da una descripcin del mdulo planificador (seccin 4.8), se explica el mdulo ponderador de planes (seccin 4.9), se presenta el mdulo controlador de planes en ejecucin (seccin 4.10) y se explica el mdulo de intercambio de teoras (seccin 4.11). Por ltimo, se detalla un ejemplo integrador de la funcionalidad del sistema (seccin 4.12). En el captulo 5 se presentan los resultados experimentales del comportamiento del sistema inteligente autnomo implementado en la plataforma Khepera. Se da una introduccin (seccin 5.1), luego se da una visin del diseo experimental (seccin 5.2) y por ltimo, se muestran grficamente los resultados obtenidos y su interpretacin (seccin 5.3). En el captulo 6 se toman las cuestiones abordadas en el captulo 3 y se sumarizan las respuestas a las mismas que aparecen a lo largo de la tesis. En el anexo A se presenta una adaptacin del documento de dominio pblico preparado por Oliver Michel (E-mail: Olivier.Michel@epfl.ch) sobre el manual del usuario del Simulador Khepera versin 2.0 y la preguntas ms frecuentes sobre el mismo. Se da el acuerdo de licencia (seccin A.1), una introduccin (seccin A.2), la explicacin sobre la programacin del simulador (seccin A.3), los reconocimientos (seccin A.4), las referencias del manual (seccin A.5), el apndice sobre la librera de funciones (seccin A.6), el apndice con la estructura de directorios (seccin A.7), el apndice con los comandos seriales del Khepera (seccin A.8), un apndice con el archivo multirobots.h (seccin A.9) y las preguntas ms frecuentes del simulador Khepera (seccin A.9) En el anexo B se presentan los distintos escenarios seleccionados para realizar los experimentos descriptos en el captulo 5. En el anexo C se muestran los datos obtenidos durante la ejecucin del diseo experimental. En el anexo D se presenta la documentacin del sistema. Se da una introduccin (seccin D.1), se explica la descarga y compilacin del simulador Khepera (seccin D.2), se da una explicacin sobre la instalacin de los archivos fuentes del sistema inteligente autnomo (seccin D.3), se explica la integracin del SIA al Khepera (seccin D.4), se da una explicacin de los archivos fuente (seccin D.5), se presenta el esquema de
Introduccin Pablo M. Maceri 3
interaccin de los mdulos (seccin D.6), se explican los diagramas de estructura del sistema implementado (seccin D.7), se dan los comandos implementados (seccin D.8), se explican las estructuras de datos utilizadas (seccin D.9) y se presenta el formato de los archivos de estadsticas (seccin D.10). Por ltimo, en el anexo E se presenta el cdigo fuente de la implementacin del sistema inteligente autnomo integrado a la plataforma Khepera.
Pablo M. Maceri
Introduccin
Captulo 2
Estado de la Cuestin
En este captulo se establece el estado del dominio de conocimiento describiendo la arquitectura del sistema GINKO (seccin 2.1), la arquitectura del sistema PRODIGY (seccin 2.2), la arquitectura del sistema SOAR (seccin 2.3), la arquitectura LIVE (seccin 2.4), la arquitectura DYNA (seccin 2.5), el sistema de Christiansen (seccin 2.6), el sistema de Hayes-Roth (seccin 2.7) y por ltimo el sistema inteligente autnomo (seccin 2.8).
2.1. GINKO: Una arquitectura integrada para aprendizaje y planificacin en robtica

El sistema GINKO [Barbehenn y Hutchinson, 1991] consiste de cuatro componentes principales. Consta de un conjunto de sensores que son actualizados continuamente. Posee una memoria que es dividida conceptualmente en dos partes: un modelo del mundo y las lecturas de los sensores que le dan importancia y soporte a ese modelo. Tiene un componente de induccin que forma un modelo del mundo consistente con los datos. Y finalmente, posee un elemento de ejecucin que consiste de un planificador y monitores de planes en ejecucin. El elemento de ejecucin es responsable de llevar a cabo tareas en el ambiente y es completamente dependiente de los sensores y del modelo del mundo. En la figura 2-1 se muestra un diagrama de la arquitectura.
ENTORNO
Ejecucin Sensores
EJECUCION
Planificacin
Lecturas de los sensores
Modelo del mundo
MEMORIA
INDUCCION
Aprendizaje
Figura 2-1: arquitectura del sistema GINKO
Pablo M. Maceri
2.1.1. Aprendizaje Para cada par operador/sensor se particiona el espacio de configuracin en regiones de comportamiento cualitativo uniforme. Sobre cada regin, el efecto de ejecutar ese operador es incrementar, decrementar, o dejar sin cambios, el valor del sensor. Luego se combinan las particiones asociadas a cada operador para formar una representacin compuesta de los efectos de ese operador. Los operadores se dividen en regiones y cada regin de comportamiento cualitativo uniforme de cada particin de un operador es una regin caracterstica de ese operador. Cada regin caracterstica predice el cambio cualitativo en los valores del sensor que resultarn de ejecutar el operador asociado a esa regin. 2.1.2. Planificacin El problema de la planificacin consiste en encontrar una secuencia de operadores que, cuando se ejecuten, lleven al robot de una configuracin inicial (generalmente la configuracin actual) a alguna configuracin que satisfaga el objetivo propuesto. El planificador del GINKO usa directamente las particiones de los operadores para construir sus planes. El planificador utiliza un algoritmo convencional de bsqueda encadenada hacia atrs desde la regin objetivo hacia la configuracin inicial. 2.1.3. Ejecucin y monitoreo Los planes generados por el planificador de GINKO son abstractos en el sentido de que son cualitativos e imprecisos. Un plan concreto es generado por asociacin de monitores de ejecucin con los operadores programados. El efecto principal de estos monitores es usar los sensores para detectar sucesos inesperados o fallas, y volver a planificar localmente cuando sea necesario. Un plan no tiene garanta de tener xito ya que los efectos de los operadores son capturados slo cualitativamente y, en general, pueden ser caracterizados incorrectamente. Podra parecer que un solo operador es efectivo para alcanzar un objetivo cuando en realidad se necesita una interpolacin de varios operadores para dirigirse al objetivo, para corregir desviaciones cuantitativas de la trayectoria deseada.
Pablo M. Maceri
Es importante saber que las particiones de los operadores son el resultado de la generalizacin de la experiencia y son slo una aproximacin. Las inconsistencias pueden introducir errores en el plan. En dichos casos, los bordes de las regiones deben redefinirse y se debe generar un plan ms preciso. Se pueden hacer refinamientos de las regiones caractersticas inmediatamente o postergarlas por ejemplo hasta la falla del plan en ejecucin. El refinamiento puede ser incremental o un reparticionamiento total del espacio de configuracin. 2.1.4. Control El elemento de ejecucin es responsable de la seleccin y ejecucin de los operadores. En general, el componente de aprendizaje es activado por el elemento de ejecucin ante una falla en la ejecucin del plan si la estrategia de refinamiento es pasiva, o puede ser activado por el proceso de integracin de datos asociado con el almacenamiento de las lecturas de los sensores si la estrategia de refinamiento es activa.
2.2. PRODIGY: una arquitectura integrada para planificacin y aprendizaje

Un problema consiste de un estado inicial y una expresin objetivo. Para resolver un problema, el sistema PRODIGY [Carbonell y otros, 1991] debe encontrar una secuencia de operadores que, si se aplican a un estado inicial, produce un estado final satisfaciendo la expresin objetivo. El rbol de bsqueda inicialmente comienza como un solo nodo que contiene el estado inicial y la expresin objetivo. El rbol se va expandiendo al repetir los siguientes pasos: 1. Fase de decisin: hay cuatro tipos de decisiones que PRODIGY toma durante el problema de resolucin. Primero, debe decidir qu nodo en el rbol de bsqueda expandir. Cada nodo consiste de un conjunto de objetivos y un estado que describe el mundo. Luego, se selecciona un nodo, se debe seleccionar algn nodo objetivo, y se debe elegir un operador relevante a este objetivo. Finalmente, se debe decidir sobre un conjunto de relaciones entre los parmetros de ese operador. 2. Fase de expansin: si las precondiciones del operador instanciado se satisfacen, el operador es aplicado. En caso contrario, PRODIGY prepara subobjetivos sobre las precondiciones que no coincidieron. En ambos casos, se crea un nuevo nodo con informacin actualizada sobre el estado o los subobjetivos.
Estado de la Cuestin Pablo M. Maceri 7
La bsqueda termina luego de crear un nodo cuyo estado satisface la expresin objetivo de mayor nivel. Como PRODIGY intenta resolver un problema, debe tomar decisiones sobre qu nodo expandir, sobre qu objetivo trabajar, qu operador aplicar, y qu objetos usar. Estas decisiones pueden ser influenciadas por un control de reglas para incrementar la eficiencia de la bsqueda de solucin del problema y para mejorar la calidad de las soluciones que se encuentran. En vez de utilizar una estrategia de bsqueda de menor compromiso, PRODIGY espera que cualquier decisin importante ser guiada por la presencia de un control de conocimiento apropiado. Si para una decisin no hay ninguna regla de control relevante, entonces PRODIGY toma una alternativa rpida y arbitraria. Si de hecho se toma una alternativa incorrecta, se har un intento para aprender el conocimiento de control que se debe haber perdido. Las reglas de control pueden ser utilizadas para guiar los cuatro tipos de decisiones descriptos anteriormente. Cada regla de control tiene por un lado una condicin de prueba de aplicabilidad y por otro lado, indica si SELECCIONAR, RECHAZAR PREFERIR un candidato particular. Para hacer una decisin de control, dados un conjunto de candidatos (nodos, objetivos, operadores, relaciones, dependiendo de la decisin), PRODIGY primero pone en prctica las reglas de seleccin aplicables para seleccionar un subconjunto de los candidatos. Si ninguna regla de seleccin es aplicable, se incluyen todos los candidatos. Luego, las reglas de rechazo filtran este conjunto por eliminacin explcita de los candidatos restantes, y finalmente las reglas de preferencia se usan para encontrar la alternativa ms favorita. Si es necesario volver hacia atrs, se intenta con los candidatos favoritos siguientes, y as, hasta que se encuentra una solucin global, o hasta que todos los candidatos seleccionados y no rechazados se acaben. El solucionador de problemas general de PRODIGY se combina con varios mdulos de aprendizaje. El solucionador de problemas produce un rbol de bsqueda completo, encapsulando todas las decisiones (las correctas e incorrectas) como tambin la solucin final. Esta informacin es usada por cada componente de aprendizaje de diferentes maneras. En la figura 2-2 se puede observar el diagrama de la arquitectura de PRODIGY. Junto con el solucionador de problemas central, PRODIGY posee los siguientes componentes de aprendizaje:
Pablo M. Maceri
APRENDIZ: una interfase de usuario que puede participar en un dilogo parecido a un aprendiz [Joseph, 1989], permitiendo al usuario evaluar y guiar la resolucin de problemas y el aprendizaje del sistema. La interfase es grfica y est ligada directamente con el solucionador de problemas, de manera que los dos puedan adquirir conocimiento del dominio o aceptar consejos mientras el sistema est resolviendo un problema. EBL: una caracterstica de aprendizaje basado en la explicacin [Minton, 1988] para adquirir reglas de control de trazado de la resolucin de problemas. Las explicaciones son construidas de una teora axiomtica que describe tanto el dominio como los aspectos relevantes de la arquitectura del solucionador de problemas. Entonces, las descripciones resultantes son expresadas de la forma de reglas de control, y se retienen aquellas reglas de control cuya utilidad en la reduccin de bsqueda valen ms que el tope de su aplicacin. ESTATICO: un mtodo para aprender reglas de control analizando las descripciones del dominio antes de la resolucin del problema. El programa ESTATICO produce reglas de control sin utilizar ningn ejemplo de entrenamiento [Etzioni, 1991]. ANALOGIA: un motor de analoga derivacional [Veloso y Carbonell, 1990] que para resolver nuevos problemas usa problemas similares resueltos anteriormente. El solucionador de problemas guarda las justificaciones para cada decisin durante su proceso de bsqueda. Estas justificacioones son usadas luego para guiar la reconstruccin de la solucin de subsecuentes situaciones de resolucin de problemas donde las justificaciones similares se mantienen verdaderas. ALPINE: un mdulo de aprendizaje por abstraccin y planificacin [Knoblock, 1991]. El conocimiento del dominio axiomatizado se divide en mltiples niveles de abstraccin basado en el anlisis del dominio. Luego, durante la resolucin del problema, PRODIGY primero encuentra una solucin en un espacio abstracto y despus usa la solucin abstracta para guiar la bsqueda para soluciones en problemas de espacios ms detallados. EXPERIMENTACION: un mdulo de aprendizaje por experimentacin para refinar conocimiento del dominio que es incompleto o est especificado incorrectamente [Carbonell y Gil, 1990]. La experimentacin se dispara cuando el monitoreo de planes en ejecucin detecta una divergencia entre las espectativas internas y las observaciones externas. El foco principal de la experimentacin es refinar el conocimiento fctico del dominio, en vez del conocimiento de control.
ESTATICO
Conocimiento de control
Problema
Conocimiento de dominio
Interfase de usuario EBL SOLUCIONADOR DE PROBLEMAS Lineal / No lineal

Repeticin deriv.
Aprendizaje de abstraccin
Librera de planes
Multinivel
Jerarqua de abstraccin
Extractor derivativo
Trazado PS
Experimentador
Solucin
Procesos externos
Figura 2-2: arquitectura del sistema PRODIGY
Todos los mdulos de aprendizaje estn en cierta medida integrados ya que todos dan las mismas definiciones del dominio y comparten el mismo solucionador de problemas y estructuras de datos. El conocimiento aprendido por cada mdulo luego es incorporado en la base de conocimiento.
2.3. Un Anlisis de Soar como una Arquitectura Integrada

La arquitectura Soar [Lair y otros, 1991] puede ser descripta en tres niveles: el nivel de conocimiento [Newell, 1982 ; Rosenbloom y otros, 1991], el nivel del espacio del problema [Newel y otros, 1991] y el nivel de smbolos. En el nivel del espacio del problema, Soar est descripto en trminos de la diversidad de los espacios del problema que usa en una tarea, y dentro de un espacio de problema, los
10 Pablo M. Maceri Estado de la Cuestin
estados y operadores que usa para resolver los problemas dentro de ese espacio. En este nivel, se pueden identificar espacios de problemas especializados para interacciones externas, procesamiento de lenguaje natural, diseo, etc. Tambin hay espacios de problemas generales que soportan los cmputos requeridos para los espacios de problemas especializados. Por ejemplo, Soar tiene un espacio de problema de seleccin que es usado para un meta-nivel de control, y conjunto de espacios de problemas para realizar operaciones aritmticas. De esta manera, Soar no tiene mdulos predefinidos para las distintas tareas de un agente inteligente, como comprensin de lenguaje natural, generacin de lenguaje natural, diseo, etc. Sino que, la arquitectura soporta los espacios de problemas que contienen el conocimiento relevante para estas tareas. Estos espacios de problemas son dinmicos por s mismos, ya que se pueden crear nuevos operadores a travs del aprendizaje, y hasta se pueden crear nuevos espacios de problemas a travs de la experiencia. La integracin de los espacios de problemas se determinan con el mecanismo de subobjetivos, que crea subobjetivos automticamente en respuesta a himpases. Un himps surge cuando el conocimiento que est disponible para el problema es insuficiente (o inconsistente) para ejecutar las funciones bsicas del espacio del problema, como seleccionar y aplicar operadores. El propsito del subobjetivo es eliminar el himps a travs de la resolucin de problemas en un espacio de problemas. As, los espacios de problemas se usan para ejecutar funciones de otro espacio de problema que no puede ser ejecutado directamente. El nivel de smbolos tiene como propsito soportar las funciones primitivas necesarias para llevar a caso el nivel del espacio del problema. De esta manera, el nivel de smbolos debe proveer acceso al conocimiento relevante para la situacin de solucin de problemas corriente y los mtodos para combinar ese conocimiento para ejecutar las funciones del espacio del problema, como la seleccin y aplicacin de operadores. La arquitectura tambin provee las primitivas para la interaccin con los ambientes externos mediante la definicin de interfases para entrada y salida. Finalmente, la arquitectura soporta directamente la adquisicin de nuevo conocimiento.
Pablo M. Maceri
11
La figura 2-3 presenta una visin general del nivel de smbolos, incluyendo las memorias, los procesos que trabajan sobre los contenidos de las memorias, y el flujo de informacin entre ellos.
PERCEPCION
Memoria de preferencia
Decisin
EJECUCION
Memoria de trabajo
Comparar
Accin
Estructuras de grafos
Memoria de reconocimiento
producciones
trazados de producciones
Memoria de trazado
Encapsulamiento
Figura 2-3: arquitectura del nivel de smbolos del sistema Soar
Los rectngulos son memorias, mientras que los tringulos son procesos que toman como entrada el contenido de las memorias que tienen a su lado. Comenzando de la izquierda superior, la memoria de preferencia recibe entradas del ambiente externo a travs de los mdulos de percepcin como tambin directamente de los productores. La memoria de preferencia no recibe directamente los datos de la memoria de reconocimiento, sino que primero son procesados por el procedimiento de decisin, que computa los cambios a la memoria de trabajo basado en los contenidos de la memoria de preferencia. La memoria de reconocimiento contiene el conocimiento permanente que es codificado como producciones. Las producciones son simples reglas si-entonces cuyas condiciones ponen a prueba las condiciones de la memoria de trabajo y cuyas acciones crean preferencias. Las producciones en la memoria de reconocimiento son apareadas con la memoria de trabajo y si es exitoso, se agregan preferencias a la memoria de preferencia. Las preferencias que proponen nuevos objetos de contexto (espacios de problema, estados, y operadores) tambin son agregadas a la memoria de trabajo de manera que puedan servir como entrada para preferencias adicionales que determinarn qu objeto
seleccionar como el actual. El flujo principal de informacin se muestra con flechas y el comparar computa los cambios a la memoria de preferencia y decisin computa los cambios a la memoria de trabajo. Los contenidos de la memoria de trabajo tambin son procesados por accin, que enva comandos de motor al sistema de ejecutores. Mientras las producciones son apareadas y ejecutadas, los trazadores de produccin instanciados son enviados a la memoria de trazado que luego es procesada por el encapsulamiento. La salida del encapsulamiento son nuevas producciones que son agregadas por la memoria de reconocimiento. El mecanismo de aprendizaje utilizado por Soar es el de encapsulamiento (chunking) que le dan las siguiente propiedades: El aprendizaje es autnomo y no est bajo el control directo del conocimiento del dominio. Es as que, el aprendizaje no interfiere con otras actividades, simplemente ocurre. En contrapartida, no hay un comando simple que pueda ser usado para recordar un hecho declarativo, pero sin embargo, Soar debe emplear algunas actividades indirectas para aprender intencionalmente. El sistema debe crear de alguna manera una situacin en la cual surja un himps y el hecho por el que es llamado se vuelve el resultado del subobjetivo resultante. Surgen diferentes tipos de aprendizaje no de diferentes mecanismos de aprendizajes, sino a travs de diferentes tareas y diferentes mtodos para generar conocimiento dentro de los espacios de problemas. El encapsulamiento, como un mecanismo de aprendizaje, no puede mejorarse agregndole conocimiento. Sin embargo, el encapsulamiento incorporar nuevo conocimiento para resoluciones de problemas futuras. En particular, la calidad de los futuros comportamientos de aprendizaje se puede mejorar adquiriendo conocimiento que altera lo que ocurre en subobjetivos, y as alterar lo que se aprende.
2.4. LIVE: una arquitectura para aprendizaje del entorno

LIVE [Shen, 1991] es una arquitectura implementada para aprender del entorno. Dados un conjunto de acciones y percepciones, el sistema construye un conjunto de reglas de prediccin, como el modelo del entorno, y las usa para alcanzar sus objetivos. Cada regla de prediccin tiene tres partes: condicin, accin, y prediccin. Las condiciones y las predicciones se arman a partir de percepciones y de un conjunto de constructores, como
conectores lgicos , y , y funciones + y . Las predicciones no cambian ninguna estructura de datos interna pero sirven como plantillas para ser igualadas con las percepciones resultantes de las acciones. En otras palabras, las predicciones pueden fallar. La figura 2-4 muestra los componentes y los flujos de control de LIVE. Conceptualmente, la arquitectura de LIVE puede separarse en cuatro componentes principales: Planificador/Ejecutor, Explorador/Creador, Corrector/NuevosTrminos y Experimentador. Todos estos componentes usan la base de conocimiento interno que contiene las reglas de prediccin actuales para alcanzar objetivos producidos por el GoalG (generador de objetivos). El componente GoalG puede aceptar objetivos externamente de otros agentes o puede generar objetivos internamente para sus propios intereses. Cuando se trabaja hacia un objetivo, LIVE primero llama al Planificador para generar un plan basado en las reglas de prediccin que estn disponibles actualmente.
Nuevos Trminos Experimentador GoalG
Corrector
Planificador
Creador Ejecutor Monitor Reactor
Explorador
AMBIENTE Figura 2-4: arquitectura de LIVE
Si no se puede usar ninguna regla para alcanzar el objetivo actual, el Planificador llama al Explorador para explorar el entorno probando con diferentes acciones. La exploracin no es al azar sino a travs de un conjunto de heursticas que tratan de maximizar las ventajas de la informacin. Durante la exploracin, se construirn nuevas reglas por el Creador basado en las observaciones. Luego de la exploracin, el Planificador continuar con su actividad de planificacin. Si se puede construir un plan, el Planificador llamar al Ejecutor quien ejecutar el plan en el entorno y controlar los resultados de cada accin usando las predicciones hechas por las reglas. Si un resultado no concuerda con la prediccin (esto se llama una
sorpresa), el Ejecutor llamar al Corrector para revisar la regla que provoc la prediccin incorrecta. Durante la revisin, se pueden definir nuevos trminos cuando sea necesario. Si durante la planificacin se detectan reglas fallidas, el Planificador llama al Experimentador. Se pueden detectar dos sntomas comunes que son: cuando un subobjetivo se repite en el plan (subobjetivo cclico) y cuando un subobjetivo es la negacin del objetivo (contradiccin de objetivo). Cuando de esta manera se identifica una regla fallida, se llama al Experimentador para que proponga experimentos para revisar la regla. Cada experimento es un triplo de la forma (g, a, p), donde g es un estado en que la accin a debe ser ejecutada y los resultados p son esperados. En un experimento, el estado es tratado como un nuevo objetivo. Para ejecutar un experimento, el Planificador es llamado para traer al sistema al estado deseado y luego se ejecuta la accin experimental en ese estado. Si el experimento tiene xito (por ejemplo, produce una sorpresa), el Corrector ser llamado para refinar la regla en cuestin. Caso contrario, se propondrn nuevos experimentos. En general, estas actividades (resolucin de problemas, exploracin, aprendizaje, y experimentacin) continan de una forma intercalada hasta que LIVE haya aprendido un conjunto suficientemente bueno de reglas y todos los objetivos sean alcanzados (por ejemplo, antes que cualquier objetivo nuevo sea generado o aceptado). Como se puede ver, la integracin en LIVE est centralizada alrededor de las acciones y las predicciones. El solucionador de problemas (Planificador) usa las predicciones para planificar acciones; el componente de aprendizaje (Ejecutor y Corrector) usa las predicciones para detectar los errores en las reglas actuales; el experimentador usa las predicciones para buscar ejemplos opuestos para el componente de aprendizaje; y el explorador usa las predicciones para maximizar la ganancia de informacin.
2.5. Dyna: una Arquitectura Integrada para Aprendizaje, Planificacin y Reaccin

La arquitectura Dyna [Sutton, 1991] intenta integrar: - Aprendizaje por prueba y error de una poltica reactiva ptima, un mapeo desde las situaciones hacia las acciones;
Pablo M. Maceri
15
Aprendizaje del conocimiento de dominio en la forma de un modelo de accin, una caja negra que toma como entrada una situacin y una accin y como salida una prediccin de la situacin inmediata siguiente;
Planificacin: encontrando la poltica reactiva ptima dado el conocimiento de dominio (el modelo de accin);
Ejecucin reactiva: la planificacin no interviene entre percibir una situacin y responder a ella.
Adems, la arquitectura Dyna est especialmente diseada para el caso en que un agente no tiene un conocimiento completo y preciso de los efectos de sus acciones en el mundo y en el que esos efectos pueden ser no determinsticos. Dyna asume que la tarea del agente puede ser formulada como un problema de maximizacin de recompensa (Figura 2-5). En cada intervalo de tiempo discreto, el agente observa una situacin, toma una accin basado en ella, y luego, despus de un paso de reloj, observa una recompensa resultante y una nueva situacin. El objetivo del agente es elegir acciones de manera de maximizar la recompensa total que recibe a largo plazo. Esta formulacin del problema ha sido utilizada en estudios de aprendizaje por refuerzo por muchos aos y an es utilizada en estudios de planificacin y sistemas reactivos (por ejemplo [Russel, 1989]).
Agente Situacin/ Estado Recompensa Mundo Figura 2-5: la formulacin del problema utilizada en Dyna Accin
La esencia de Dyna est dada por el siguiente algoritmo genrico: REPETIR PARA SIEMPRE: 1. Observar el estado del mundo y elegir reactivamente una accin basada en l. 2. Observar la recompensa resultante y el nuevo estado. 3. Aplicar aprendizaje por refuerzo para esta experiencia. 4. Actualizar el modelo de accin basado en esta experiencia. 5. Repetir K veces: 5.1 Elegir un estado del mundo hipottico y una accin.
5.2 Predecir la recompensa resultante y el nuevo estado usando el modelo de accin. 5.3 Aplicar aprendizaje por refuerzo a esta experiencia hipottica. En este algoritmo, una experiencia es una unidad de experiencia que consiste de un estado inicial, una accin, un estado resultante, y una recompensa resultante. El primer paso del algoritmo es simplemente el de un sistema reactivo: el agente saca de su poltica reactiva qu hacer en la situacin actual. Los tres primeros pasos juntos comprenden un agente de aprendizaje por refuerzo estndar. Dada la suficiente experiencia, dicho agente puede aprender el mapeo reactivo ptimo de las situaciones a la accin. El cuarto paso es el aprendizaje del conocimiento del dominio en la forma de un modelo de accin (Lin, 1991) que puede ser utilizado para predecir los resultados de las acciones. El quinto paso del algoritmo es esencialmente aprendizaje por refuerzo de experiencias generadas del modelo hipotticamente; esto es, en efecto, un proceso de planificacin. La arquitectura Dyna contiene tres componentes principales: La estructura del modelo de accin y sus algoritmos de aprendizaje; Un algoritmo para seleccionar estados hipotticos y acciones; Un mtodo de aprendizaje por refuerzo, incluyendo un algoritmo de aprendizaje por ejemplos y una forma de generar variaciones en el comportamiento.
El modelo de accin es una simple imitacin del mundo. Toma una descripcin de un estado y una accin y emite una prediccin del estado resultante inmediato y de la recompensa. La experiencia actual con el mundo produce continuamente ejemplos de comportamiento deseado para dicho modelo. Esto puede ser usado en conjunto con una gran cantidad de algoritmos de aprendizaje para aprendizaje supervisado (aprendizaje por ejemplos). Dyna es completamente reactivo en el sentido que no interviene ninguna planificacin entre la observacin de un estado y la toma de una accin dependiente de ese estado. El tema crtico est en que la planificacin y los procesos reactivos no estn fuertemente ligados: el agente nunca se atrasa al responder a una situacin al planificar una respuesta para ella. A pesar de que el agente siempre responde reactiva e instantneamente, esto no significa que responda decididamente.
Pablo M. Maceri
17
La planificacin de la arquitectura Dyna tiene tanto ventajas como desventajas comparado con otros mtodos de planificacin. La ventaja principal est en que es totalmente incremental; cualquier tiempo gastado para planificar resulta en una mejora de las reacciones inmediatas del agente o de la funcin de evaluacin para algn estado. As, el rendimiento mejora continuamente, y se pueden encontrar secuencias de acciones ptimas arbitrariamente largas. Adems, fcilmente maneja tareas no determinsticas y es extremadamente general en el sentido que no toma suposiciones sobre el mundo ms que aquellas que pueden ser por lo menos parcialmente predecidas. La desventaja principal de la planificacin de la arquitectura Dyna es que puede requerir gran cantidad de memoria. Mientras que los mtodos de planificacin tradicional estn basados en la construccin de rboles de bsqueda y evaluaciones por demanda, la planificacin utilizada est basada en almacenar evaluaciones asociadas con cada estado o par estado-accin.
2.6. Sistema de Christiansen

El trabajo de Christiansen [Christiansen, 1992], enfoca el aprendizaje automtico de los efectos de las acciones de un sistema autnomo en un ambiente fsico. Los sensores y efectores del sistema le proveen un conjunto de valores que describen los efectos de las acciones. Las imperfecciones en el sistema sensor-efector del sistema y las caractersticas de las acciones fsicas se combinan para generar resultados observados con ruidos y no deterministas. El aprendizaje exitoso de los efectos de las acciones requiere algoritmos de aprendizaje tolerantes al ruido. La habilidad de obtener objetivos de forma exitosa requiere que el sistema sea capaz de razonar a partir de su incertidumbre y predecir el efecto de las acciones. En el trabajo de Christiansen las acciones son representadas por operadores continuos llamados "funnels". Los "funnels" son computados por un algoritmo de aprendizaje emprico que tolera el ruido y que asegura no realizar predicciones equivocadas. El sistema interacta con su entorno a travs de sus sensores y sus efectores. Para lograr sus objetivos, el sistema utiliza sus sensores para obtener informacin del entorno y los efectores para ajustar el entorno a estados favorables a la concrecin de los objetivos de aqul. En este contexto, el sistema debe ser capaz de predecir los efectos de las acciones que genera el subsistema efector. Existen dos enfoques, preprogramar esta habilidad o
18
Pablo M. Maceri
utilizar algoritmos que le permitan al sistema aprenderla [Vere, 1978; Rivest y Schapire, 1987; Shen y Simon, 1989] El trabajo de Christiansen se concentra sobre dos aspectos del aprendizaje desde el entorno que ha recibido poca atencin en la bibliografa: el tratamiento de las caractersticas del espacio continuo y el tratamiento del ruido y de la incertidumbre. Desde el punto de vista del aprendizaje del sistema, el entorno es una caja negra. El sistema provee acciones como entradas al entorno y recibe estados percibidos a travs de los sensores. Las salidas del entorno son llamadas estados, pero en general estos estados solo reflejan parcialmente los estados verdaderos del entorno. En el trabajo de Christiansen, se asume que ambos, estados y acciones, son conjunciones de valores ordenados, correspondientes a medidas continuas de las caractersticas del entorno. Estos estados y acciones son descritos por puntos en un espacio multidimensional de caractersticas. Los espacios relevantes son llamados el espacio de estados S y el espacio de acciones A. Es conveniente describir la situacin actual como un punto en el espacio <estado, accin>. Este punto indica el estado actual y la accin a ser ejecutada. El problema atacado por Christiansen es el de predecir el resultado de la ejecucin de una accin desde el estado percibido. Asumiendo que el sistema usa los sensores antes y despus de la ejecucin de varias acciones, la informacin sobre los efectos de las acciones vuelve al sistema como una cadena de puntos [s0, a0, s1, a1, s2, . . ]. Otra forma de ver esto es como una secuencia de estados de transicin [s,a,r] (estado, accin, estado resultante). Un aspecto interesante del problema de este aprendizaje es que el sistema solo recibe ejemplos posibles del concepto de inters. El sistema solo ve qu es lo que puede ocurrir como resultado de sus acciones. Nunca ve lo que no puede conseguir. Una aproximacin para la inferencia inductiva de los problemas de esta clase es asumir familias de restricciones o formas funcionales para las respuestas, y aplicar tcnicas de regresin para cambiar la mejor respuesta de acuerdo a algunas medidas de error. Estas tcnicas de regresin permiten tratar con ruido y valores de caractersticas continuos. Para que estas tcnicas sean exitosas se requiere que la familia de respuestas aceptables sea limitada "a priori". Esta limitacin, constituye una forma de sesgo inductivo. Para los sistemas que poseen una gran cantidad de conocimiento inicial, tal como los sistemas de aprendizaje basado en explicaciones, el xito del sistema de aprendizaje es altamente dependiente del conocimiento inicial elegido por el programador humano.
Pablo M. Maceri
19
Se asume que el sistema inicialmente tiene poco conocimiento sobre el entorno y que no posee inicialmente ninguna habilidad para predecir el efecto de las acciones. El sistema asume que las caractersticas observadas (estado percibido) corresponden a medidas continuas de las caractersticas del entorno, y asume que las caractersticas controladas (correspondientes a los parmetros controlados de las acciones) representa cambios continuos con causa en los efectos de las acciones fsicas. El sistema asume que los cambios de estado del entorno solo son por la influencia de sus acciones. Por otra parte, asume que el entorno no es dinmico: como resultado de cada accin, el entorno establece un estado invariante por el tiempo en el que el sistema usa los sensores para medir los resultados de sus acciones. El supuesto de la invarianza del tiempo permite al sistema generalizar sobre los estados de transicin observados, independientemente de la historia especfica de cada uno de ellos.
2.7. Sistema de Hayes-Roth

Para aprender en un mundo real, dinmico y observable en el cual las condiciones varan continuamente, un sistema necesita formular una teora sobre los efectos de las acciones sobre su entorno; necesita construir planes, monitorizar la ejecucin de esos planes para detectar espectativas violadas y diagnosticar y rectificar errores que los datos inconsistentes revelen. Hayes-Roth [Hayes-Roth, 1983] llam teoras al conocimiento que encapsula los efectos de las acciones, planteando la arquitectura de un sistema con estas caractersticas mediante el esquema presentado en la figura 2-6. El conocimiento que el sistema tiene del mundo evoluciona gradualmente en respuesta a su experiencia. El sistema planifica para alcanzar sus objetivos y emplea mtodos heursticos para rectificar los errores en las teoras. Las heursticas propuestas capturan modos especficos de arreglar la teora agregando o quitando restricciones para invocar la teora.
20
Pablo M. Maceri
ENTORNO OBJETIVOS
PLANES PLANIFICACION Y PROYECCION ESPECTATIVAS
EJECUCION DEL PLAN
RESULTADOS
JUSTIFICACION DEL PLAN
ESPECTATIVAS VIOLADAS
NO
FI N
TEORIAS
SI
TEORIA DE RECTIFICACION
TEORIAS CON ERRORES
DIAGNOSTICO DEL PLAN
Figura 2-6: arquitectura del sistema propuesto por Hayes-Roth
El sistema usa conocimiento para establecer las condiciones para alcanzar un objetivo. Un plan generado por el sistema a partir de un conjunto de teoras, queda justificado si, al aplicarse al estado inicial, alcanza el estado objetivo. El fallo del plan implica un error en las teoras asociadas. Entre las causas de fallo de un plan estn: Un plan es injustificable de acuerdo a las teoras y supuestos del sistema. Un plan justificado previo no predijo cambios en las teoras asociadas. La justificacin de un plan est equivocada. El fallo de un plan implica la refutacin de las teoras asociadas. Para rectificarlas se pueden aplicar las siguientes heursticas: Retraccin: consiste en restringir las predicciones de la teora para que sea consistente con las observaciones. Exclusin: excluir la teora que fue aplicada a la situacin asociada al fallo.
Invalidacin: desechar las situaciones que nieguen las predicciones de la teora.
Pablo M. Maceri
21
Aseguracin: incluir las situaciones que confirmen las predicciones de la teora. Inclusin: restringir la teora incluyendo los casos que la confirman.
2.8. Sistema Inteligente Autnomo

Uno de los puntos involucrados en el problema de la modelizacin de Sistemas Inteligentes [Fritz y otros, 1989] es lograr una base axiomtica que describa formalmente los fenmenos que tienen lugar en este tipo de sistemas. Esta descripcin formal apunta a proporcionar un instrumento para clasificar, medir y calcular en el campo de la inteligencia. Formalmente, no es relevante la clasificacin en natural o artificial. El propsito del trabajo es abstraer los rasgos comunes, si los hay, de todos los procesos inteligentes. Luego, clasificar como inteligentes a los sistemas capaces de dar lugar a procesos inteligentes. Un rasgo comnmente asociado con la inteligencia es la capacidad de adquirir nuevos conocimientos. Esto se manifiesta en los procesos de aprendizaje, que aceptan ser descritos en trminos de asimilacin e incorporacin de informacin extrada del contexto. Una forma de adquirir conocimiento nuevo es el llamado "mtodo del ensayoerror"; esta tcnica permite descubrir leyes simples cuya verdad se deduce a partir de la experiencia. En la teora presentada por los autores citados, esta adquisicin de conocimiento est centrada alrededor de la asimilacin de experiencias, siendo las leyes empricas las unidades de experiencia. Los Sistemas Inteligentes tienen objetivos, que consisten en acceder a una situacin que les conviene. Estn capacitados adems para elegir sus acciones segn tales objetivos y son capaces de aprender qu accin es til efectuar en cada situacin en relacin a los mismos. La situacin es el conjunto de los rasgos esenciales del estado de las cosas, en relacin a los objetivos del sistema. Se elabora sobre la base de todas las entradas sensoriales del momento y sobre su conceptualizacin. Sobre la base de esta modelizacin se elige cada accin. Para lograr sus objetivos, los Sistemas Inteligentes actan, y para poder elegir acciones adecuadas deben contar con una memoria en la cual archivan sus experiencias. Una unidad de experiencia se compone (por lo menos) de la situacin vivida, la accin realizada, la situacin resultante y el hecho de que las consecuencias de la accin hayan sido beneficiosas o no para lograr el objetivo. Este beneficio, o la falta del mismo, se traduce en utilidad resultante. La decisin sobre la accin que conviene realizar
22
Pablo M. Maceri
se toma en funcin de las experiencias acumuladas, si es que estn en relacin con las circunstancias actuales (pueden ser tanto experiencias directas del sistema como tambin experiencias conocidas a travs de lo que se verific en otros). Si en lo archivado como experiencia tal relacin existe y la accin elegida en aqul entonces result beneficiosa, habr una tendencia de elegir nuevamente esa misma accin o a optar por alternativas distintas si la accin result perjudicial.
EMISIONES
PERCEPCION DEL ENTORNO
DEFINICION DE LA SITUACION
ALMACENAMIENTO SITUACIONES Y EXPERIENCIAS
PLAN EN EJECUCION Y SITUACION ESPERADA
SUBOBJETIVO NO SELECCION DE SUBOJETIVO PLAN CONSTRUCCION DEL PLAN
SI EL PLAN EXISTE NO SELECCIONAR ACCION POR CURIOSIDAD
SI EL PLAN EXISTE NO SELECCIONAR ACCION POR AZAR
ACCION
ACCION HACER CADA ACCION DEL PLAN
SI
ACCION
ACCION
ACCION ES DORMIR
NO
ACCION
SI HACER ABSTRACCIONES
Figura 2-7: arquitectura del sistema inteligente autnomo
Cuando se trata de una situacin nueva, esto es, no existe experiencia previa de la misma, se efectan acciones razonadas guindose por los resultados obtenidos en actuaciones anteriores, o si no, por intuicin, instinto o incluso al azar. Frente a
situaciones conocidas, los Sistemas Inteligentes tienden a desarrollar una actuacin que (por experiencia) consideran ptima (no necesariamente es la ptima). Esta tendencia se denomina hbito. Un mal hbito se da cuando el sistema persiste en un cierto actuar aun cuando ste ya no corresponde a la situacin. El esquema del sistema inteligente autnomo (figura 2-7) permite visualizar la interaccin entre sus distintos componentes.
24
Pablo M. Maceri
Captulo 3
Descripcin del Problema
En este captulo se presenta el entorno en el cual se plantea el problema a abordar en la tesis (seccin 3.1), se sealan cuestiones relativas a la integracin de la arquitectura elegida con una plataforma estndar (seccin 3.2), surgen las cuestiones relativas a la extensin de la arquitectura elegida (seccin 3.3), se sealan aspectos a explorar como resultado de la interaccin de esta estrategia de aprendizaje (seccin 3.4), y se identifican otras partes de la tesis donde se abordan las cuestiones precedentemente tratadas (seccin 3.5).
3.1. Introduccin
De los sistemas inteligentes relevados en el captulo sobre el estado de la cuestin surge como un marco de trabajo consistente los sistemas inteligentes autnomos ya que los mismos proveen un modelo integrado de aprendizaje y planificacin [Garca Martinez, 1997b]. Interesa estudiar aspectos vinculados al intercambio de operadores bajo condiciones reales o simulaciones de un entorno real por lo que se considera el uso de la plataforma Khepera. En este contexto en el que se articula la arquitectura de un sistema inteligente autnomo y una plataforma robot mvil real se dan las condiciones para explorar problemas abiertos de aprendizaje cooperativo. Por un lado los sistemas inteligentes autnomos tienen la capacidad de aprender teoras sobre como su entorno funciona, cmo esas teoras pueden ser utilizadas para armar planes para alcanzar objetivos autopropuestos, y en la medida que estos planes fallan rever las teoras asociadas a esos planes mediante mecanismos tales como mutacin basada en heursticas y ponderaciones. Por otro lado parece natural pensar en sistemas inteligentes autnomos que son capaces de intercambiar sus teoras/operadores para mejorar los aprendizajes del modelo que tienen del entorno, pudiendo ser el universo de funcionamiento de estos grupos de sistemas inteligentes autnomos los que provee el universo de funcionamiento de la plataforma Khepera.
Descripcin del Problema Pablo M. Maceri 25
3.2. Integracin SIA-Khepera

De la integracin de un sistema inteligente autnomo con la plataforma Khepera surge la cuestin: Cuestin 1: Cul es la repetibilidad de los resultados de trabajos previos en la teora de sistemas inteligentes autnomos [Garca Martinez y Borrajo, 1997;1998] al cambiar de plataforma robot (migrar de la plataforma [Fritz et al., 1989] a Khepera)?
3.3. El problema de la extensin del modelo del SIA

La arquitectura de sistemas inteligentes autnomos no est prevista originalmente [Fritz et al., 1989; Garca Martnez, 1993c; 1994] para contemplar el intercambio de operadores y su consecuente integracin en un conjunto de teoras unificado. En este contexto surgen las siguientes cuestiones: Cuestin 2: Cmo debe ser modificada la arquitectura del sistema inteligente autnomo para admitir procesos de intercambio de operadores? Cuestin 3: Qu mecanismos deben utilizarse para integrar los operadores que un sistema inteligente autnomo recibe de otro con los que ya forman parte de su base de teoras?
3.4. Interaccin entre intercambio de operadores y otras estrategias

Bajo el supuesto de que las modificaciones que surgiran de atender las cuestiones precedentemente expuestas funcionaran, debera analizarse las cuestiones relacionadas con la mejora de la calidad de lo aprendido y en qu medida la nueva estrategia se relaciona con las estrategias preexistentes. En este contexto surgen las siguientes cuestiones: Cuestin 4: En qu medida este intercambio de teoras/operadores acelera los tiempos de aprendizaje del modelo del entorno que el sistema inteligente autnomo va formando por interaccin con aquel?
26
Pablo M. Maceri
Cuestin 5: En qu medida el intercambio de operadores afecta o se ve afectado por el uso de otras estrategias de aceleracin de aprendizaje como la mutacin? Cuestin 6: En qu medida el intercambio de operadores afecta o se ve afectado por el uso de otras estrategias de aceleracin de aprendizaje como la ponderacin de planes? Cuestin 7: En qu medida la combinacin del intercambio de operadores con aprendizaje por mutacin acelera el aprendizaje? Cuestin 8: En qu medida la combinacin del intercambio de operadores con aprendizaje por ponderacin de planes acelera el aprendizaje?
3.5. Lugar de las soluciones

Las cuestiones 1, 2 y 3 son abordadas en el captulo solucin propuesta en el que se presenta una extensin de la arquitectura del sistema inteligente autnomo para admitir intercambio de operadores y su integracin al universo de funcionamiento Khepera. Las cuestiones 4, 5, 6, 7 y 8 son abordadas en el captulo sobre experimentos al tratar las estadsticas del sistema y las estadsticas sobre su rendimiento.
Pablo M. Maceri
27
Captulo 4
Solucin Propuesta
En este captulo se presenta una introduccin al sistema implementado y la plataforma utilizada (seccin 4.1), la representacin del modelo de teora (seccin 4.2), se da la descripcin general del sistema (seccin 4.3), se explica su arquitectura (seccin 4.4), se describe el entorno del sistema (seccin 4.5), se describe el sistema sensor (seccin 4.6), se explica el mdulo de aprendizaje (seccin 4.7), se da una descripcin del mdulo planificador (seccin 4.8), se explica el mdulo ponderador de planes (seccin 4.9), se presenta el mdulo controlador de planes en ejecucin (seccin 4.10) y se explica el mdulo de intercambio de teoras (seccin 4.11). Por ltimo, se detalla un ejemplo integrador de la funcionalidad del sistema (seccin 4.12).
4.1. Introduccin
El sistema propuesto simula el comportamiento de un robot mvil (Sistema Inteligente Autnomo) sobre la Plataforma Khepera, desarrollada en la Universidad de Niza SophiaAntipolis (Suiza) por Oliver Michel. Bsicamente esta plataforma se trata de un entorno de simulacin, que permite definir un mundo de dos dimensiones a ser explorado por uno o ms robots. Adems permite actuar sobre los motores de los robots a fin de conducir su comportamiento y tener acceso a sus sensores de manera que pueda interactuar con el entorno.
Sistema ejecutor
accin Conversor de acciones accin teoras
Plataforma Khepera
Sistema sensor
situacin Conversor de lecturas situacin
Subsistema controlador de planes en ejecucin

planes teoras plan
Subsistema de aprendizaje
Subsistema planificador
confiable si/no
Subsistema ponderador de planes
Figura 4-1: componentes de un sistema inteligente autnomo implementado sobre Khepera

Solucin propuesta Pablo M. Maceri
29
En la figura 4-1 se presenta el esquema de los componentes del sistema y la forma en que estos se integra a la plataforma Khepera. Para que el sistema inteligente autnomo interacte con la plataforma Khepera se desarrollaron dos mdulos conversores. Uno para transformar las situaciones percibidas por la plataforma al formato utilizado por el sistema (conversor de lecturas) y otro para que la acciones seleccionadas puedan ser aplicadas por el simulador (conversor de acciones). Una vez que la situacin percibida ha sido interpretada, se procesa por el subsistema de aprendizaje quin la incorpora y actualiza la experiencia del sistema para pasarla al subsistema controlador de planes en ejecucin. ste est encargado de verificar que las predicciones de los planes se hayan verificado y en caso de necesitarlo le pide al subsistema planificador que cree nuevos planes quien mediante el subsistema ponderador de planes decide si un plan es confiable o no. Luego de este proceso el subsistema controlador puede enviarle a la plataforma Khepera la prxima accin a ejecutar.. El sistema implementado, permite estudiar el comportamiento del sistema inteligente autnomo basado en el intercambio de operadores. El simulador Khepera soporta la simulacin de mltiples robots en el mismo escenario. Esta funcionalidad fue aprovechada y se desarroll un mdulo que permite el intercambio de operadores entre varios sistemas autnomos inteligentes simulados. En la figura 4-2 se representa la incorporacin de este mdulo y su interaccin con cada sistema simulado.
Plataforma Khepera
Accin Situacin SIA 1 Situacin SIA 2
Accin Situacin
Accin
........
SIA n
Operadores
Operadores Mdulo de intercambio de operadores
Operadores
Figura 4-2: arquitectura multiagente implementada sobre Khepera.
30
Pablo M. Maceri
Solucin propuesta
En el esquema se puede ver que la plataforma soporta la simulacin conjunta de ms de un sistema inteligente autnomo. Estos pueden interactuar entre s a travs del mdulo de intercambio de operadores. Este intercambio puede ser utilizado por los sistemas inteligentes autnomos cuando sea necesario para que el conocimiento pueda ser compartido entre ellos.
4.2. Representacin del modelo de teora

En la teora de Sistemas Inteligentes Artificiales planteada en [Fritz y otros, 1989; 1990; Garca Martnez, 1992b] el aprendizaje est definido cada vez que el sistema adquiere la descripcin de una nueva situacin o de una nueva unidad de experiencia. El autor citado propone una estructura para la unidad de experiencia de la forma: [Situacin Inicial, Accin, Situacin Final], donde aplicada la Accin a la Situacin Inicial, se obtiene la Situacin Final. El concepto de unidad de teora de Fritz es equivalente al concepto de teora de Hayes-Roth [Hayes-Roth, 1983] si se establecen las equivalencias: Condiciones Supuestas = Situacin Inicial y Efectos Predecidos = Situacin Final. En [Garca Martnez, 1997b], la representacin de los operadores se basaba en el modelo propuesto en [Fritz y otros, 1989], donde una observacin (unidad de experiencia) tiene la estructura: [Situacin Inicial, Accin, Situacin Final], donde Situacin Inicial y Situacin Final son proposiciones que pueden ser verdaderas o falsas. Las observaciones fueron directamente utilizadas como operadores para planificacin. En otros trabajos [Garca Martnez, 1991a;1991b; 1992a; 1992b] se han explorado mtodos de aprendizaje que contemplen el concepto de que la teora que es utilizada con xito debe ser reforzada, mientras que la teora que es utilizada de forma infructuosa debe ser debilitada [Sutton, 1984, 1988, 1990, 1992; Lesprance, 1991]. En Garca Martnez [Garca Martnez, 1991a] se propone un modelo de teora que es una extensin del descripto por Anderson y Kline [Anderson y Kline, 1979] y es representado por la quntupla (CTi, ATi, ETi, P, K, U), donde: Teora : Partes : Ti CTi ATi ETi P K
Solucin propuesta
Condiciones supuestas Accin Efectos Predecidos Cantidad de veces que la teora Ti fue utilizada con xito (se obtuvieron los efectos predecidos) Cantidad de veces que la teora Ti se utiliz
Pablo M. Maceri 31
En esta tesis se propone un sistema que puede evaluar cun til (o intil) puede ser realizar una accin para alcanzar sus objetivos. En el ejemplo dado para el sistema inteligente autnomo simulado sobre la plataforma Khepera se consideran ms tiles aquellas teoras asociadas a acciones que le permiten alcanzar situaciones con mayor nivel de luz, ya que stas, se podra decir, llevan a un robot a aumentar el nivel de bateria (lo cual constituye una situacin altamente deseable). En este contexto, el modelo de teora o la representacin de un operador utilizado se forma mediante los siguientes componentes: Si A Sf P K U Situacin Inicial (Condiciones Supuestas) Accin Situacin Final (Efectos Predecidos) Cantidad de veces que la teora fue utilizada con xito (se obtuvo la situacin final) Cantidad de veces que se aplic la accin A a la situacin inicial Si Nivel de utilidad alcanzado al aplicar la accin A a la situacin inicial Si Los parmetros P y K permiten a la arquitectura disminuir el efecto del ruido en los sensores o en el ambiente, y el problema del estado oculto. Esto es debido a la predisposicin del sistema a asumir que el ambiente puede ser dinmico, ruidoso, y que pueden existir caractersticas del estado que no pueden ser capturadas por el sistema sensor, y por lo tanto, no pueden ser manejadas por el planificador o por los mecanismos de aprendizaje. Por otro lado, en el modelo utilizado se consideran que dos teoras son iguales cuando poseen la misma situacin inicial, la misma accin y la misma situacin final. Dos teoras son similares cuando su situacin inicial y su accin son las mismas.
4.3. Descripcin General del Sistema

El sistema implementado tiene como objetivo simular uno o ms robots cuyas tareas son planificar de una manera autnoma para conseguir objetivos propuestos por ellos mismos, ejecutar estos planes en el entorno, encontrar desviaciones en los planes o corregir su
32
Pablo M. Maceri
Solucin propuesta
comportamiento, y aprender operadores (teoras) que predicen los efectos de las acciones en el entorno mediante la observacin de las consecuencias de dichas acciones. El sistema puede ser descripto como un o ms robots de exploracin que reciben percepciones del entorno, las cuales se llaman situaciones, aplican acciones, aprenden de sus interacciones con el mundo y pueden intercambiar su conocimiento entre ellos. El algoritmo de alto nivel que representa el comportamiento general del sistema se puede describir de la siguiente forma:
1. Para cada robot 1.1. Percibir situacin S 1.2. Seleccionar una accin al azar A 2. Repetir n veces 2.1 Para cada robot 2.1.1 Ejecutar la accin A 2.1.2 Percibir situacin S 2.1.3 Percibir la utilidad U 2.1.4 Si es necesario intercambiar operadores 2.1.5 Adquirir nuevo conocimiento a partir de S, A, S y U 2.1.6 SI no existe un plan en ejecucin S no es la situacin esperada por el plan ENTONCES planificar 2.1.7 Seleccionar la siguiente accin del plan A 2.1.8 S=S
Al comienzo, cada robot no tiene ningn conocimiento, por lo tanto cada uno percibe la situacin inicial (1.1) y selecciona una accin al azar para ejecutar en el entorno (1.2). Luego, el sistema entra en un ciclo (2.1) en el que se ejecuta un turno de robot por vez. En cada turno, un robot ejecuta la accin (2.1.2), percibe la situacin resultante (2.1.2) y la utilidad (2.1.3). Luego, verifica si es necesario el intercambio de operadores con otro robot (2.1.4), si es as lo lleva a cabo mediante un mdulo de intercambio, sino sigue con la ejecucin, es decir, aprende de la observacin del efecto que provoca aplicar la accin en el ambiente (2.1.5), y planifica (2.1.6) para futuras interacciones con el mundo cuando el plan termin su ejecucin o cuando el sistema observa un desvo entre la situacin prevista y la situacin percibida. El turno de un robot termina seleccionando una nueva accin (2.1.7), que es la siguiente accin del plan, y tomando la situacin percibida como la nueva situacin inicial (2.1.8), con esto puede comenzar el prximo turno.
Solucin propuesta Pablo M. Maceri 33
4.4. Arquitectura del Sistema

Para entrar ms en detalle en la descripcin del sistema, en la figura 4-3 se presenta un diagrama de la arquitectura del sistema donde se observa su interaccin con el entorno, y el funcionamiento general de los mdulos de aprendizaje, planificacin, ponderacin, control e intercambio de operadores.
Sistema Ejecutor Sistema Sensor
Situacin SI Conjunto de Teoras
Plataforma Khepera
Conjunto de Teoras Intercambio de operadores
Intercambiar Operadores NO Situacin Armado de Teora Local
Teora Local
Existe Teora Registrada similar a la Teora Local SI Existe Teora Registrada igual a la Teora Local SI
NO
NO
Ponderar Teoras Similares a la Teora Local Teora Local Generar Teoras Mutantes
Enviar siguiente accin del plan a ejecutar
Reforzar Teora Registrada
Registrar y Ponderar Teoras Mutantes
SI Situacin es situacin esperada por ejecucin del plan
Incorporar Teora Local SI Existe Plan en Ejecucin
NO Abortar plan
NO
SI
El plan es aceptable
Ponderar Plan
Plan
Armar Plan
NO
Figura 4-3: arquitectura del sistema

34 Pablo M. Maceri Solucin propuesta
El sistema inteligente autnomo percibe el entorno a travs del sistema sensor. Antes de realizar cualquier accin se pregunta si es necesario intercambiar operadores con otro sistema inteligente autnomo. Este proceso se lleva a cabo mediante un mdulo de intercambio de operadores. Luego, se registra la situacin percibida del entorno, y arma una teora local con la situacin previa y la accin ejecutada. Una teora es local, cuando todava no tiene valores establecidos para su P, K y utilidad. Si la teora local es igual a alguna teora registrada, sta se refuerza, si no existe una teora igual pero existen similares, stas se ponderan y se generan teoras mutantes las cuales son registradas y ponderadas de la misma forma. Por ltimo (luego del proceso de generar teora mutantes o si no existen teoras similares) se incorpora la teora local y se pasa el control al subsistema controlador. Si existe un plan en ejecucin, se verifica que la situacin obtenida sea la esperada; si no ocurre esto, se aborta el plan y el control es devuelto al planificador. Si no existe un plan en ejecucin, el planificador genera uno, lo enva al ponderador y mediante un criterio heurstico, se determina si el plan es aceptable. En caso afirmativo, el controlador de planes en ejecucin determina la siguiente accin a ser ejecutada, la cual es pasada a la plataforma para que sta la aplique en el entorno.
4.5. Entorno del Sistema

El entorno con el que interacta el sistema es un mundo de dos dimensiones representado por el Simulador Khepera en el que se pueden encontrar ladrillos, corchos y lmparas. El mundo es simulado mediante un mapa de bits de 500x500. Este mapa puede ser correspondido con una matriz de bits 500x500 en la que un 1 representa la presencia de un objeto y 0 representa la ausencia de un objeto.
Figura 4-4: entornos posibles del sistema

En trminos generales, el entorno del sistema puede ser descripto como una cuadrcula en la que cada posicin tiene una marca que indica si la posicin est ocupada o no por un obstculo. En el manual del Simulador Khepera (anexo A) se puede encontrar en ms detalle cmo armar nuevos mundos o modificar alguno existente. En las preguntas ms frecuentes del Simulador Khepera (seccin A.9 del anexo A) existe una explicacin ms detallada de la representacin interna del mundo. En la figura 4-4 se muestran dos ejemplos de mundos que vienen con el paquete original del Simulador Khepera, los cuales pueden ser entornos del sistema estudiado.
4.6 Sistema Sensor

El sistema sensor de la plataforma de simulacin Khepera se compone de ocho sensores infrarrojos que le permiten al robot detectar por reflexin la proximidad de los objetos enfrente de ellos. Mediante un conversor de lecturas es posible adaptar este sistema de sensores a uno en que cada sensor se corresponde con un bit en una cadena de bits. Un bit representa la presencia o ausencia de un obstculo en el rea de barrido ese sensor. Una situacin en un momento dado es una configuracin dada de esa cadena de bits. En la figura 4-5 se muestra la correspondencia de subregiones con bits.
2 1 0 3 4 ROBOT 7 0 1 2 3 4 6 5 6 7 5
Figura 4-5: correspondencia de reas frente a los sensores con bits.
De esta manera cada bit indica la presencia (si est en 1) o la ausencia (si est en 0) de un obstculo en el rea en frente al sensor. Hay que tener en cuenta que esto es una modelizacin ya que, como se puede ver en el manual del Khepera (anexo A), cada sensor del robot indica un valor entre 0 y 1023 que
representa la cercana de un objeto al sensor, donde 0 significa que ningn objeto es percibido y 1023 que un objeto est muy cerca del sensor. Debido a que el valor de cada sensor es convertido a un 1 (uno) a un 0 (cero) para representar la presencia o ausencia de un obstculo en frente de cada sensor, se debe seleccionar un umbral para realizar dicha transformacin. Por ejemplo si el valor del umbral elegido es 750, un sensor marcar la presencia de un objeto en frente de l (con el bit en 1) si el valor devuelto por ese sensor va entre 750 a 1023. Y la ausencia de un objeto frente a un sensor, indicada con el bit en 0, se producir cuando el valor del sensor es menor a 750. Los sensores tambin son capaces de medir el nivel de luz ambiental alrededor del robot. Ellos retornan un valor entre 50 y 500, siendo 50 un nivel de mxima luz y 500 oscuridad total. Esta percepcin de luz es til para el clculo de la utilidad de las teoras.
4.7. Mdulo de Aprendizaje

Si el sistema percibe una situacin al ejecutar una accin a la situacin precedente, el mdulo de aprendizaje procesa la nueva observacin mediante el siguiente algoritmo:
ENTRADA: Situacin Precedente, Accin Ejecutada, Situacin Obtenida, Conjunto de Teoras SALIDA: Conjunto de Teoras 1. Armar Teora Local (Situacin Inicial + Accin + Situacin Final) 2. SI existe una teora registrada igual a la teora local ENTONCES incrementar el P y el K en 1 de la teora igual registrada Y incrementar en 1 el K de todas las teoras similares (las que tienen igual Situacin Inicial e igual Accin) 3. SI no existe teora registrada igual Y existe teora registrada similar (Ti) a la teora local ENTONCES 3.1 Incorporar la teora formulada con P=1 y K=KTi + 1 3.2 Para cada Ti: 3.2.1 Incrementar en 1 el K 3.2.2 Generar teora mutante (Tm) a partir de la teora local 3.2.3 SI existe teora registrada igual a Tm ENTONCES incrementar el P y el K en 1 de la teora registrada Y incrementar el K en 1 de las teoras similares 3.2.4 SI no existe teora registrada igual a Tm Y existe teora registrada similar a Tm ENTONCES incorporar Tm con P=1 y K=K+1 Y incrementar el K de todas las teoras similares 4. SI no existe una teora que coincida al menos en las condiciones supuestas y la accin de la teora local ENTONCES incorporar teora con K=1 y P=1
Solucin propuesta
Pablo M. Maceri
37
Este mdulo a partir de la situacin precedente, la accin ejecutada y la situacin obtenida que recibe como entrada, formula una teora local (1). Existen tres casos que considerar para poder registrar esta teora. El primero (2) es aquel en el que existe una teora registrada que sea igual a la teora local (es decir que coincidan en la situacin inicial, la accin y la situacin final). Si sucede esto se debe reforzar la teora incrementndole en uno el P y el K y se deben penalizar, si existen, las teoras similares incrementndoles en uno el K. El segundo caso (3) se produce cuando no existe ninguna teora registrada que sea igual a la teora local, pero s existe una o ms teoras similares (es decir que coincidan en la situacin inicial y la accin). Aqu, en primer lugar, se debe registrar la nueva teora con P=1 y un K igual al de una teora similar incrementado en uno (3.1). Luego para cada teora similar encontrada (3.2) se debe incrementar el K en uno y generar una teora mutante. Con esta teora mutante se procede de la misma forma que con la teora local pero sin volver a mutar, es decir si existe una teora registrada igual se debe reforzar y penalizar las similares, caso contrario se registra la teora mutante y se penalizan las similares. El tercer y ltimo caso se da cuando no existe ninguna teora que coincida al menos en la situacin inicial y en la accin con la teora local (4). Este es el caso ms simple y solamente hay que registrar la nueva teora con su P y su K inicializados en uno. Este algoritmo presenta la propiedad de preservar que la suma del cociente P/K de todas las teoras similares es igual a uno.
4.8. Mdulo Planificador

El planificador se encarga de construir planes (conjunto de acciones ordenadas a ser ejecutadas) que le permiten al sistema transformar su situacin actual en una situacin objetivo. Este objetivo est implcito en el sistema y depende de cmo se mida la utilidad. Como cada teora tiene su propia utilidad, el planificador tratar de construir un plan que transforme la situacin actual en la situacin asociada a la teora con la utilidad ms alta, es decir la teora que logre la situacin de mayor utilidad (su situacin final). Por lo tanto, el objetivo a cumplir es seleccionado a partir de todas las teoras registradas. Se elige aquella teora cuya utilidad sea mxima y si se puede construir un plan que lleve
38
Pablo M. Maceri
Solucin propuesta
al sistema de la situacin actual hasta ella, esta situacin se convierte en situacin deseable o situacin objetivo. El planificador se puede pensar como una funcin que recibe dos argumentos: el conjunto de teoras y la situacin actual, debiendo retornar un conjunto de planes (eventualmente ninguno en el caso de que a partir de las teoras aprendidas por el sistema no pueda armarse un plan) que aplicado a la situacin actual, genere la situacin objetivo (situacin cumplible de utilidad mxima). En este contexto, el planificador acta como un confirmador de objetivos. Si retorna un plan distinto del nulo, quiere decir que el plan existe y efectivamente se puede tomar a la situacin deseable (candidata) como situacin objetivo. Si el planificador no pudo formular un plan (retorna un plan nulo) se pasa a ejecutar el plan de contingencia azar. Este plan se forma mediante una heurstica que consiste en elegir una accin al azar. A continuacin se presenta el algoritmo de planificacin:
ENTRADA: SALIDA: Situacin Actual, Conjunto de Teoras Plan
1. Armar pila de situaciones deseables (de mayor a menor utilidad) 2. MIENTRAS existen situaciones deseables Y no existe un plan 2.1 Tomar el tope de la pila como raz del rbol 2.2 Armar rbol de situaciones 2.3 Buscar nodo asociado a la situacin actual 2.4 SI existe el nodo ENTONCES armar el plan asociado al camino de mnimo recorrido entre el nodo situacin actual y el nodo raz (situacin deseable). 3. SI no existe un plan ENTONCES tomar plan por contingencia (azar)
El planificador arma, a partir de todas las situaciones conocidas, la pila de situaciones deseables (1). Una situacin es conocida si est registrada como situacin inicial o final de alguna teora del conjunto de teoras. Una situacin es deseable si es situacin final de una teora que tiene asociado un nivel de utilidad positiva. La pila de situaciones deseables est ordenada de mayor a menor nivel de utilidad. Armada la pila y hasta que la situacin deseable sea la situacin objetivo o se hayan agotado todas las situaciones deseables, se procede al armado del rbol de situaciones (2.2), tomando como raz el tope de la pila (2.1).
Solucin propuesta
Pablo M. Maceri
39
Para armar el rbol de situaciones cada situacin puede ser interpretada como la consecuencia de haber aplicado una accin a una situacin previa. Esto determina la precedencia entre las distintas situaciones, a partir de lo cual se puede armar el rbol de situaciones, comenzando con la situacin deseable como raz del rbol y su precedente la situacin inicial de la teora que tiene asociada a la situacin deseable como situacin final. Con el rbol de situaciones armado, el planificador procede a buscar si existe entre los nodos descendientes la situacin actual (2.3). Si es encontrada (2.4), se construye el camino entre la situacin actual y la raz (situacin deseable). De encontrarse varios caminos, se selecciona el de menor longitud, devolviendo el plan asociado al camino de mnimo recorrido entre la situacin actual y la deseable (raz del rbol). De no encontrarse la situacin actual en el rbol construido, se toma otra situacin de la pila de situaciones. Si la pila se vaca y no se obtuvo un plan, entonces se genera un plan por contingencia mediante el uso de heursticas. El planificador utiliza el ponderador de planes (presentado en la siguiente seccin) para determinar si un plan es confiable o no. Para no complicar el algoritmo de planificacin no se muestra este proceso que se puede ver ms claramente en el diagrama de la arquitectura del sistema inteligente autnomo (seccin 4.4). Luego de encontrar un plan entre la situacin actual y la situacin objetivo el ponderador de planes determina si el plan es confiable o no. Si no lo es se descarta y el planificador toma otra situacin deseable para volver a planificar. Para dar un ejemplo de cmo procede este algoritmo, supongamos que el sistema en un momento dado acumul el siguiente conjunto de ocho teoras donde hay dos acciones (A1 y A2) y cinco situaciones (S1 a S5). Cada teora se representa con la sxtupla (Situacin Inicial, Accin, Situacin Final, P, K, Utilidad): T1 = (S1, A2, S4, 2, 3, 3/4) T2 = (S1, A2, S5, 1, 3, 2/3) T3 = (S2, A1, S1, 3, 4, 3/4) T4 = (S2, A1, S4, 1, 4, 1/3) T5 = (S3, A1, S2, 2, 5, 1/3) T6 = (S3, A1, S5, 3, 5, 1/4) T7 = (S4, A2, S3, 2, 2, 1) T8 = (S5, A2, S2, 1, 1, 1/2)
40
Pablo M. Maceri
Solucin propuesta
Este conjunto de teoras es representado por el grafo de la figura 4-6, donde cada nodo representa una situacin (condiciones supuestas o efectos predecidos) y cada arco est marcado con una cudrupla (A, P, K, U), donde el primer elemento es la accin, el segundo elemento es el valor de P, el tercer elemento es el valor de K y el cuarto elemento es el valor de utilidad:
(2,1,3,2/3) (1,3,4,3/4) (2,1,1,1/2)
S1
S5
(2,2,3,3/4)
S2
(1,1,4,1/3) (1,2,5,1/3)
(1,3,5,1/4)
S4
(2,2,2,1)
S3
Figura 4-6: grafo de teoras
Dado este conjunto de teoras y sea S2 la situacin actual, si el planificador intenta encontrar un plan para lograr alcanzar el objetivo de mayor utilidad desde la situacin actual S2, primero genera la siguiente pila de situaciones deseables en orden descendiente de utilidad: [ S3, 1] [ S4, 3/4] [ S1, 3/4] [ S5, 2/3] [ S2, 1/2] Donde S3 es el tope de la pila con utilidad 1 y S2 su base con utilidad 1/2. Tomando a S3 como situacin deseable (porque tiene el mximo nivel de utilidad asociado), el algoritmo arma el rbol de situaciones de la figura 4-7. La situacin actual S2 se encuentra en el rbol y existen 2 caminos para llegar de S2 a S3, ellos son S2-S4-S3 y S2-S1-S4-S3. Por lo tanto, se encuentra el camino de mnimo recorrido entre la situacin actual S2 y la situacin deseable S3 que forma el plan [ A1 o A2 ] (o representa la concatenacin de las acciones de un plan). Este es el plan que devuelve el planificador.
Solucin propuesta
Pablo M. Maceri
41
S3 A2 S4 A1 S2 A2 A2 S1 S5 A1 S3 A2 S1 A1 S3 A2 S5 A1 S3 A2 S1 A1 S2 A1 S3
Figura 4-7: rbol de situaciones
4.9. Mdulo Ponderador de Planes

Para estimar la probabilidad de xito de los planes, el mdulo ponderador de planes se basa en una extensin de la teora de autmatas estocsticos. El conocimiento que posee el sistema en un momento dado (el conjunto de teoras), puede ser visto como un modelo de cmo el ambiente reaccionar frente a las acciones que ejecuta el sistema. El cociente PTk/KTk de una teora Tk dada, es el estimador de probabilidad de que aplicando la accin ATk a la situacin Si se obtenga la situacin Sj. Por lo tanto, el conocimiento que el sistema posee sobre los efectos de una accin Ak en un momento dado puede ser representado por la matriz de transicin MAk, que tiene, en la posicin (i,j), el cociente P/K de la teora cuya accin es Ak, su situacin inicial es Si, y su situacin final es Sj. En planificacin, si para llegar de la situacin Si a la situacin Sj, se puede construir el plan Pij = A1o A2 o . . . o An, entonces la matriz MPij resultante de realizar el producto matricial MA1 x . . . x MAn, contiene en la posicin (i,j) la probabilidad de que el plan Pij aplicado a la situacin que Si, resulte la situacin Sj. Por ejemplo, si se toman las situaciones iniciales y las situaciones finales como nodos, las acciones como rtulos de los arcos y el P y el K como pesos de un arco, se puede presentar el conjunto de teoras Ti como un conjunto de elementos con una estructura de la forma: ( STi , ATi, STi , PTi ,KTi ).
Puede definirse a partir de tales elementos un grafo que representa el estado de las teoras en un instante determinado. Sea, por ejemplo, el grafo presentado en la figura 4-6 de la seccin 4.8.1, la matriz MA1 asociada a la accin A1 resulta :
S1 S1 MA1 = S2 S3 S4 S5 0 0 0 0 0 S2 0 3/4 2/5 0 0 S3 0 0 0 0 0 S4 0 S5 0
1/4 0 0 3/5 0 0 0 0
La matriz MA2 asociada a la accin A2 resulta:

S1 S1 S2 S3 S4 S5 0 0 0 0 0 S2 0 0 0 0 1 S3 0 0 0 1 0 S4 S5
MA2 =
2/3 1/3 0 0 0 0 0 0 0 0
Por tanto, la matriz MP asociada al plan P = A1 o A2 resulta:

S1 S1 S2 S3 S4 S5 0 0 0 0 0 S2 0 0 3/5 0 0 S3 0 1/4 0 0 0 S4 0 0 0 0 0 S5 0 0 0 0 0
MP =
Del anlisis de MP surge que la probabilidad de que el plan P aplicado a la situacin S2 de la situacin S3 es 1/4, y la probabilidad de que el plan P aplicado a la situacin S3 de la situacin S2 es 3/5. En esta seccin, se ha presentado un mtodo basado en autmatas estocsticos para que teoras ponderadas pueden ser utilizadas en la valoracin de los planes que se generan a partir de ellas. La solucin al problema de estimar "a priori" en qu medida de la ejecucin de un plan se obtendrn los resultados esperados, permite descartar planes con
Solucin propuesta
Pablo M. Maceri
43
baja confiabilidad de xito antes de su ejecucin. Esta propiedad es crtica cuando el sistema debe actuar sin supervisin. A continuacin se presenta el algoritmo asociado al proceso de ponderacin de planes:
ENTRADA: Plan, Situacin Actual, Situacin Deseable, Conjunto de teoras SALIDA: Estimador de probabilidad 1. A = tomar primera accin del plan 2. MP = armar matriz de transicin asociada a la accin A 3. Mientras existan acciones en el plan 3.1 A = tomar siguiente accin del plan 3.2 MA = armar matriz asociada a la accin A 3.3 MP = MP x MA 4. Retornar el valor de la posicin (Situacin Actual, Situacin Deseable) de la matriz MP.
El algoritmo de ponderacin de planes es bastante simple. Su entrada son el plan a ponderar, la situacin actual, la situacin deseable y el conjunto de teoras que representa el conocimiento del sistema en ese instante. En primer lugar el mdulo ponderador toma la primera accin del plan (1) y arma la matriz de transicin asociada a esta accin (2) donde en la posicin (i,j) se representa el cociente P/K de la teora que al aplicar dicha accin a la situacin Si obtiene la situacin Sj. Luego, entra en un ciclo (3) en el que arma la matriz de transicin correspondiente a la siguiente accin del plan (3.2). Esta matriz se multiplica con la matriz obtenida anteriormente (3.3) y se sigue el ciclo hasta que no queden ms acciones en el plan. De esta manera, al finalizar el ciclo, tendremos la matriz de transicin asociada al plan y buscando la posicin correspondiente a la fila que representa la situacin actual y la columna que representa la situacin deseable, obtenemos el estimador de probabilidad buscado para el plan (4).
44
Pablo M. Maceri
Solucin propuesta
4.10. Mdulo Controlador de Planes en Ejecucin

El controlador del plan en ejecucin tiene las funciones que se describen en el siguiente algoritmo:
ENTRADA: SALIDA: Conjunto de Teoras Accin
1. SI existe un plan en ejecucin Y la situacin actual es la situacin que se esperaba obtener al aplicar la accin anterior a la situacin precedente ENTONCES se sigue con la siguiente accin del plan en ejecucin 2. SI existe un plan en ejecucin Y la situacin actual no es la situacin que se esperaba obtener a aplicar la accin anterior a la situacin precedente ENTONCES 2.1 Abortar el plan 2.2 Pasar el control al MODULO PLANIFICADOR 3. SI no existe un plan en ejecucin ENTONCES pasar el control al MODULO PLANIFICADOR 4. SI existe un plan enviar la primera accin del mismo SINO aplicar plan por contingencia
El mdulo controlador recibe como entrada el conjunto de teoras del sistema actualizado por el mdulo de aprendizaje. Si existe un plan en ejecucin (1), el controlador debe comprobar si la situacin actual es la esperada por el plan. Si esto es correcto, le enva a la plataforma la siguiente accin del plan en ejecucin para ser aplicada. En caso de que no se haya obtenido la situacin esperada por el plan (2), ste se debe abortar (2.1) y volver a planificar, por lo tanto se pasa el control al mdulo planificador (2.2). Esto tambin se debe hacer en caso de que no exista un plan en ejecucin (3) o el plan en ejecucin haya terminado (caso en que se haya aplicado la ltima accin del plan y no queden ms acciones por ejecutar). Por ltimo, si existe un plan, es decir el planificador pudo formular un plan, se enva a ejecutar su primera accin, sino se aplica un plan por contingencia (4).
4.11. Mdulo de Intercambio de Teoras

El intercambio de operadores permite que dos sistemas inteligentes autnomos puedan compartir el conocimiento que han adquirido de interactuar con su entorno. Cuando dos sistemas comparten su experiencia acumulada estn aprendiendo tanto de los errores como de los aciertos del otro. Por lo tanto, siguiendo el modelo de teora y su
mtodo de ponderacin, es necesario, al intercambiar operadores, reflejar este conocimiento en el otro sistema, manteniendo la consistencia del conjunto de teoras. El mtodo utilizado, contempla el concepto de que la teora que es utilizada con xito debe ser reforzada (incrementando su P y K), y que la teora que es utilizada de forma infructuosa debe ser debilitada (incrementando su K sin incrementar su P). Esto mismo se respeta en el intercambio de operadores, de manera que si una teora existe en ambos sistemas, sta se refuerza sumando sus P y sus K. Por otro lado, si una teora existe en un sistema y en el otro slo existen teoras similares se la debe debilitar dejndole el mismo P pero sumando su K con el K de las teoras similares del otro sistema. Por ltimo, aquellas teoras de un sistema que no tengan ni similar ni igual en el otro sistema, no presentarn cambio alguno en el proceso de intercambio. De esta manera se mantiene tambin la consistencia que debe poseer el mtodo de ponderacin de teoras ya que se sigue verificando luego del intercambio que la suma de los P de las teoras similares es igual al K de cualquiera de ellas. A continuacin se encuentra el algoritmo que implementa el mdulo de intercambio de operadores:
ENTRADA: SALIDA: Conjunto de Teoras CT1, Conjunto de Teoras CT2 Conjunto de Teoras CT1
1. PARA CADA TEORIA Ti EN CT1 COMIENZO 1.1 SI existe Tj que pertenece a CT2 similar a Ti ENTONCES 1.1.1 KTi = KTi + KTj 1.1.2 SI existe Tj que pertenece a CT2 igual a Ti ENTONCES PTi = PTi + PTj FIN 2. PARA CADA TEORIA Ti EN CT2 SI no existe Ti que pertenece a CTi igual a Ti ENTONCES COMIENZO 2.1 Si existe Ti que pertenece a CTi similar a Ti ENTONCES Registrar Tj con P = PTj y K = KTi en CTi SINO Registrar Tj con P = PTj y K = KTj en CTi FIN
El mdulo de intercambio de operadores recibe como entrada dos conjuntos de teoras (CT1 y CT2) donde las teoras del segundo conjunto sern incorporadas a las teoras del primer conjunto. El algoritmo funciona de la siguiente forma: para cada teora del primer conjunto CT1 (1)
46
Pablo M. Maceri
Solucin propuesta
se busca si existe una teora similar en el conjunto de teoras CT2 (1.1). Si este es el caso se suman los K de las teoras similares (1.1.1). Luego, si adems de existir una teora similar existe una teora igual en el conjunto CT2 se suman los P de las teoras iguales (1.1.2). Luego de repetir este proceso para cada teora existente en CT1 se procesan aquellas teoras del conjunto CT2 que no tienen teoras iguales en el conjunto CT1 (2). Si una teora de CT2 tiene una teora similar en CT1 (2.1) se la registra en este con el P de la teora de CT2 y el K de la teora similar de CT1. En el caso de que no exista una teora similar, se la registra en CT1 con el P y el K sin modificar. Se ejemplificarn los distintos casos con los que el mdulo de intercambio de operadores se puede encontrar durante un intercambio. En todos los casos para representar una teora se utiliza la notacin: (Situacin Inicial, Accin, Situacin Final, P, K). Para mayor claridad se omite el valor de la utilidad, pero hay que tener en cuenta que en la implementacin cuando existe una teora que es igual en ambos sistemas se promedian sus utilidades. 1) Intercambio de teoras iguales Dado el siguiente conocimiento del robot 1: (S1,A1,S2,12,12) y dado el siguiente conocimiento del robot 2: (S1,A1,S2,3,3) al coincidir la misma teora en ambos sistemas se suman tanto el P como el K, y el conocimiento del robot 1 luego de incorporar el conocimiento del robot 2 queda: (S1,A1,S2,15,15) 2) Intercambio de teoras similares Dado el siguiente conocimiento del robot 1: (S2,A1,S1,5,5) y dado el siguiente conocimiento del robot 2:
(S2,A1,S3,2,3) (S2,A1,S4,1,3) al no existir ninguna teora igual pero s similares el P de las teora del robot 1 queda igual pero su K se suma con el de la teora similar. La teoras del robot 2 se incorporan manteniendo sus P, y con el K modificado de la teora del robot1. De esta manera, el conocimiento del robot 1 luego de incorporar el conocimiento del robot 2 resulta: (S2,A1,S1,5,8) (S2,A1,S3,2,8) (S2,A1,S4,1,8) Como se puede observar la consistencia del sistema se mantiene ya que la sumatoria de los P para teoras similares es igual al K de cualquiera de ellas ( 5 + 2 + 3 = 8 ). 3) Intercambio de teoras ni iguales ni similares Dado el siguiente conocimiento del robot 1: (S3,A1,S5,2,2) y dado el siguiente conocimiento del robot 2: (S4,A2,S1,4,4) en este caso en el robot 2 no existen teoras iguales o que al menos sean similares a las teoras del robot 1, por lo tanto las teoras conservan su P y K. El resultado es el siguiente: (S3,A1,S5,2,2) (S4,A2,S1,4,4) 4) Intercambio mixto Ahora se van a integrar los ejemplos anteriores para observar el mtodo completo. El conocimiento del robot 1 antes del intercambio es el siguiente:
48
Pablo M. Maceri
Solucin propuesta
(S1,A1,S2,12,12) (S2,A1,S1,5,5) (S3,A1,S5,2,2) y el conocimiento del robot 2 antes del intercambio est dado por: (S1,A1,S2,3,3) (S2,A1,S3,2,3) (S2,A1,S4,1,3) (S4,A2,S1,4,4) La primera teora del robot 1 es igual a la primera del robot 2, por lo tanto, se suman sus P y K. Luego, la segunda teora del robot 1 es similar a la segunda y tercera teora del robot 2, con lo que se le debe sumar el K de alguna de las similares. La tercera teora del robot 1 no tiene ninguna teora que sea igual o similar en el robot 2, por lo tanto queda sin cambios. Por ltimo, las teoras del robot 2 que no tienen una teora igual en el robot 1 se deben incorporar al conjunto de teoras de este ltimo. Aquellas que no tiene similares (cuarta teora) se incorporan directamente y aquellas que tienen similares (segunda y tercera teora) se incorporan con el K de la similar. De incorporar el conocimiento del robot 2, el conjunto de teoras del robot 1 es el siguiente: (S1,A1,S2,15,15) (S2,A1,S1,5,8) (S3,A1,S5,2,2) (S2,A1,S3,2,8) (S2,A1,S4,1,8) (S4,A2,S1,4,4)
Solucin propuesta
Pablo M. Maceri
49
4.12. Ejemplo Integrador

En esta seccin se presenta un ejemplo que muestra como se integran todos los componentes del sistema vistos en las secciones anteriores. En l se simulan dos robots (A y B) que comienzan con conocimiento nulo y terminan intercambiando el conocimiento aprendido luego de varios ciclos de percepcin, aprendizaje, planificacin y ejecucin de acciones. Por cuestiones de simplicidad se
A
define la utilidad de una teora como U = 1/ valor-absoluto(1 + D), donde D es la distancia de situacin final de la teora a un centro de provisin de energa (representado con una estrella). Al ser este un ejemplo instructivo se utiliza una funcin de utilidad ms simple que en la implementacin debido a que en sta la utilidad se calcula de acuerdo al
Energa Obstculo
nivel de luz de los sensores (lo cual

B
Robot
introducira una complicacin en el ejemplo).
Figura 4-8: posicin inicial del sistema
Las reas rellenas representan ladrillos, que pueden ser percibidos como obstculos por los sensores de los robots. En la figura 4-8 se muestra el mundo simulado y la posicin inicial de los robots. El simulador Khepera funciona de manera asincrnica con respecto a los movimientos de los robots. Esto quiere decir que no se mueven simultneamente sino que hacen un movimiento por vez. Para este ejemplo se utilizar el mismo criterio. Se asume que la primer accin que ambos sistemas ejecutan cuando no tienen conocimiento alguno sobre su entorno es AVANZAR. Paso 1 Robot A El sistema sensor del robot A percibe la situacin (00000000) y aplica la accin
AVANZAR (recordamos que la primera accin a ejecutar la asumimos como predefinida).
50
Pablo M. Maceri
Solucin propuesta
Luego de aplicar la accin AVANZAR el sistema sensor percibe la situacin (00000000) representado en la figura 4-9 con lo cual se arma la teora: (00000000, AVANZAR, 00000000, ?, ?, ?) que tiene valores de P, K y U no establecidos. Como no existe una teora registrada (el conjunto de teoras es vaco) que sea igual o similar a la teora local armada, se registra y pondera la teora local y se le asigna un nivel de utilidad con lo que la teora local queda como teora registrada de la siguiente forma: Teora 1 (00000000, AVANZAR, 00000000, 1, 1, 1/3) Como no existe un plan en ejecucin se invoca al planificador para armar un plan.
A
El planificador arma la pila de situaciones deseables dada por: [situacin, utilidad] Como hay una sola teora, la pila de situaciones deseables queda: [00000000, 1/3] Toma la primera situacin deseable y arma el rbol de situaciones asociado, quedando este de la siguiente manera:
B
Robot
Energa Obstculo
00000000
AVANZAR
Figura 4-9: paso 1 del robot A
00000000
Dado que la situacin actual es la (00000000) y hay un camino de mnimo recorrido entre la situacin actual y la situacin deseable, arma el plan asociado al camino de mnimo recorrido: Plan = AVANZAR Construido el plan se procede a valorar su calidad segn el conocimiento adquirido del entorno mediante el ponderador. En este caso la matriz asociada al plan es igual a la matriz asociada a la accin AVANZAR que es la matriz [1].
Solucin propuesta
Pablo M. Maceri
51
Entonces, segn el conocimiento del sistema, la probabilidad estimada de que el sistema aplicando la accin AVANZAR a la situacin (00000000) obtenga la situacin (00000000) es 1. Dado que se considera que el plan es confiable (tiene una alta estimacin de probabilidad) se enva el plan ponderado al controlador de planes en ejecucin quien procede a su ejecucin. Paso 1 Robot B El robot B percibe la situacin (01001000) y aplica la accin AVANZAR. Al aplicar esta accin predefinida AVANZAR (figura 4-10) el sistema sensor percibe la situacin (10000100) con lo cual se arma la teora: (01001000, AVANZAR, 10000100, ?, ?, ?) que tiene valores de P, K y U no establecidos. Como no existe una teora registrada que sea igual o similar a la teora local armada, se registra y pondera la teora local y se le asigna un nivel de utilidad con lo que la teora local queda como teora registrada de la siguiente forma: Teora 1 (01001000, AVANZAR, 10000100, 1, 1, 1/3) Como no existe un plan en ejecucin se invoca al planificador para armar un plan. El planificador arma la pila de situaciones deseables dada por: [situacin, utilidad] La pila de situaciones deseables queda: [10000100, 1/3] Con la primera situacin deseable el rbol de situaciones asociado es:
Energa Obstculo Robot
10000100
AVANZAR
Figura 4-10: paso 1 del robot B
01001000
Como la situacin actual es la (10000100), y no hay un camino de mnimo recorrido entre la situacin actual y la situacin deseable y no existen ms situaciones deseables en la pila
se ejecuta el plan por contingencia azar. Suponiendo que la accin al azar obtenida es AVANZAR, el sistema la aplica en el entorno. Paso 2 Robot A Ahora le corresponde el turno nuevamente al robot A que aplic la accin AVANZAR a la situacin (00000000). Esto produce una modificacin en la percepcin del entorno (figura 4-11), siendo la nueva situacin percibida (11001100) Se arma la teora (00000000, AVANZAR, 11001100, ?, ?, ?) No existe una teora registrada que sea igual, pero s existe una teora que es similar a la teora local armada, por lo tanto se registra la nueva teora con la ponderacin complementaria quedando el conjunto de teoras como: Teora 1 Teora 2 (00000000, AVANZAR, 00000000, 1, 2, 1/3) (00000000, AVANZAR, 11001100, 1, 2, 1/2) La heurstica de mutacin utilizada es una adaptacin de la retraccin [Hayes-Roth, 1983] en que se toman los elementos comunes a las situaciones finales de ambas teoras, y a los que no coinciden se le asigna un valor al azar. El valor de la utilidad de la teora mutante ser un promedio entre las utilidades de las teoras que la originan. De aplicar esta heurstica surge la teora mutante:
B
(00000000, AVANZAR, 01001000, ?, ?, 5/12)
Ahora se procede a la ponderacin de las teoras mutantes y a la ponderacin de las teoras registradas asociadas, quedando las teoras con la siguiente ponderacin: Teora 1 Teora 2 Teora 3
Solucin propuesta
(00000000, AVANZAR, 00000000, 1, 3, 1/3) (00000000, AVANZAR, 11001100, 1, 3 1/2) (M) (00000000, AVANZAR, 01001000, 1, 3, 5/12)
Pablo M. Maceri 53
Debido a que no existe un plan en ejecucin se invoca al planificador para armar un plan, y el planificador arma la pila de situaciones deseables dada por: [situacin, utilidad] La pila de situaciones deseables queda: [ 11001100 , 1/2 ] [ 01001000 , 5/12 ] [ 00000000 , 1/3 ] Toma la primer situacin deseable y arma el rbol de situaciones asociado, quedando ste de la siguiente manera: 11001100
AVANZAR
00000000
AVANZAR
00000000 Como no existe un camino de mnimo recorrido entre la situacin actual y la situacin deseable se procede a armar el rbol con la prxima situacin deseable. Este rbol queda de la siguiente forma: 01001000
AVANZAR
00000000
AVANZAR
00000000 No existe un camino de mnimo recorrido entre (11001100) que es la situacin actual y (01001000) que es la situacin deseable. Por lo tanto se toma la prxima situacin deseable (00000000) y se forma el siguiente rbol:
54
Pablo M. Maceri
Solucin propuesta
00000000
AVANZAR
00000000 Tampoco, para la situacin deseable (00000000) se puede armar un plan y como no existen ms situaciones deseables en la pila se aplica el plan por contingencia azar. De este plan por contingencia, se puede suponer que surge aplicar la accin AVANZAR. Paso 2 Robot B Luego de aplicar la accin AVANZAR, el robot B percibe la situacin (01001000) y se arma la teora (10000100, AVANZAR, 01001000, ?, ?, ?). Esta es una nueva teora para el sistema, y como no existe ninguna similar a ella se la registra, pondera y se le asigna el nivel de utilidad quedando el conjunto de teoras como sigue: Teora 1 Teora 2 (01001000, AVANZAR, 10000100, 1, 1, 1/3) (10000100, AVANZAR, 01001000, 1, 1, 1/2) Como no existe ningn plan en ejecucin, se arma la siguiente pila de situaciones deseables:
A
[ 01000100, 1/2 ] [ 10000100, 1/3 ] Se toma la situacin (01000100) que es el tope de la pila y se forma el siguiente rbol: 01001000
B
AVANZAR
10000100
AVANZAR
01001000
Como existe un camino de mnimo recorrido entre la situacin actual (01000100) y la situacin deseable (01001000) se arma un plan a partir de ste:
Plan = AVANZAR o AVANZAR El ponderador calcula el estimador de probabilidad para el plan. Si asociamos la fila y columna 1 a la situacin 01001000 y la fila y columna 2 a la situacin 10000100, la matriz asociada al plan corresponde con la matriz de multiplicar la matriz asociada a la accin AVANZAR consigo misma: 1 0 M AVANZAR = 0 1 Entonces, 1 0 1 0 M PLAN = 0 1 0 1 1 0 M PLAN = 0 1 Por lo tanto la probabilidad estimada de que el sistema B aplicando el plan AVANZAR o AVANZAR a la situacin (01001000) obtenga la situacin (01001000) es 1, con lo cual, se puede aplicar el plan. Paso 3 Robot A Al aplicar la accin AVANZAR se produce una modificacin en la percepcin del entorno, representada en la figura 4-13, siendo la nueva situacin percibida (11001100) con la que se puede formar la teora (11001100, AVANZAR, 11001100, ?, ?, ?), que tiene valores de P, K y U no establecidos. No existe una teora registrada que sea igual o similar a la teora local armada, por lo tanto se registra y pondera la teora local y se le asigna un nivel de utilidad con lo que la teora local queda como teora registrada de la siguiente forma: (11001100, AVANZAR, 11001100, 1, 1, 1) Luego el conjunto de teoras del sistema A queda definido por: Teora 1 Teora 2 Teora 3 Teora 4 (M) (00000000, AVANZAR, 00000000, 1, 3, 1/3) (00000000, AVANZAR, 11001100, 1, 3 1/2) (00000000, AVANZAR, 01001000, 1, 3, 5/12) (11001100, AVANZAR, 11001100, 1, 1, 1)
56
Pablo M. Maceri
Solucin propuesta
Como existe un plan en ejecucin, se invoca al planificador para armar un plan. El planificador arma la pila de situaciones que queda de la siguiente forma: [ 11001100, 1 ] [ 01001000, 5/12 ] [ 00000000, 1/3 ] Toma la primer situacin deseable y arma el rbol de situaciones asociado, quedando ste de la siguiente manera:
11001100
AVANZAR
11001100
AVANZAR
B
00000000
AVANZAR
00000000
Dado que la situacin actual es la (11001100) y hay un camino de mnimo recorrido entre la situacin actual y la situacin deseable arma el plan asociado al camino de mnimo recorrido: Plan = AVANZAR Construido el plan, se procede a valorar su calidad segn el conocimiento adquirido del entorno mediante el ponderador. En este ejemplo (asociando la fila y columna 1 a la situacin 00000000, la fila y columna 2 a la situacin 11001100 y la fila y columna 3 con la situacin 01001000) la matriz asociada al plan corresponde con la matriz asociada a la accin AVANZAR que es la matriz: M AVANZAR
Solucin propuesta
1 / 3 1 / 3 1 / 3 = 0 1 0 0 0 0
Pablo M. Maceri 57
Luego, segn el conocimiento de que dispone el sistema la probabilidad estimada de que el sistema aplicando la accin AVANZAR a la situacin (11001100) obtenga la situacin (11001100) es 1. De esta manera, se puede proceder con la aplicacin de esta accin. Paso 3 Robot B Luego de aplicar la accin AVANZAR (figura 4-14), el sistema percibe la situacin (10000100) con la que arma la teora (01001000, AVANZAR, 10000100, ?, ?, ?). Como existe una teora que es igual a la teora
A
local formada, le incrementa su P y K y promedia la nueva utilidad con la anterior almacenada. El conjunto de teoras del sistema B queda: T1 (01001000, AVANZAR, 10000100, 2, 2, 2/3) T2 (10000100, AVANZAR, 01001000, 1, 1, 1/2)
B
Energa Obstculo
Robot
Como existe un plan en ejecucin y la situacin obtenida es la esperada por el controlador de planes en ejecucin se contina con la accin AVANZAR que es la siguiente accin a ejecutar del plan.
Paso 4 Robot A El sistema aplica la accin AVANZAR y se produce una nueva modificacin en la percepcin del entorno, que se muestra en la figura 4-15, siendo la nueva situacin percibida (00000000). Se arma la teora (11001100, AVANZAR, 00000000, ?, ?, ?) con valores de P, K y U no establecidos. Para esta teora local armada no existe una teora registrada que sea igual, pero s existe una teora que es similar, por lo que se registra la nueva teora con la ponderacin complementaria, quedando el conjunto de teoras como: Teora 1 Teora 2 (00000000, AVANZAR, 00000000, 1, 3, 1/3) (00000000, AVANZAR, 11001100, 1, 3 1/2)
58
Pablo M. Maceri
Solucin propuesta
Teora 3 Teora 4 Teora 5
(M)
(00000000, AVANZAR, 01001000, 1, 3, 5/12) (11001100, AVANZAR, 11001100, 1, 2, 1) (11001100, AVANZAR, 00000000, 1, 2, 1/3)
Se aplica la heurstica de mutacin y queda la teora mutante: (11001100, AVANZAR, 01000100, ?, ?, 2/3) Despus de generada la teora mutante, se procede a la ponderacin de la misma y a la ponderacin de las teoras registradas asociadas, quedando las teoras con la siguiente ponderacin: Teora 1 Teora 2 Teora 3 Teora 4 Teora 5 Teora 6 (M) (M) (00000000, AVANZAR, 00000000, 1, 3, 1/3) (00000000, AVANZAR, 11001100, 1, 3 1/2) (00000000, AVANZAR, 01001000, 1, 3, 5/12) (11001100, AVANZAR, 11001100, 1, 3, 1) (11001100, AVANZAR, 00000000, 1, 3, 1/3) (11001100, AVANZAR, 01000100, 1, 3, 2/3) Como no existe un plan en ejecucin, se invoca al planificador para armar un plan, el planificador
A
arma la siguiente pila de situaciones deseables dada: [ 11001100, 1 ] [ 01000100, 2/3 ]

B
[ 01001000, 5/12 ] [ 00000000, 1/3 ]
Solucin propuesta
Pablo M. Maceri
59
Toma la primer situacin deseable (11001100) y arma el rbol de situaciones asociado, quedando ste de la siguiente manera: 11001100
AVANZAR
11001100
AVANZAR
00000000
AVANZAR AVANZAR
11001100
00000000
Dado que la situacin actual es la (00000000) y hay un camino de mnimo recorrido entre la situacin actual y la situacin deseable, arma el plan asociado al camino de mnimo recorrido: Plan = AVANZAR o AVANZAR Construido el plan, se procede a valorar su calidad segn el conocimiento adquirido del entorno mediante el ponderador. En este ejemplo (asociando la fila y columna 1 a la situacin 00000000, la fila y columna 2 a la situacin 11001100, la fila y columna 3 con la situacin 01001000 y la fila y columna 4 con la situacin 010000100 ) la matriz asociada al plan corresponde con la matriz asociada a la accin AVANZAR que es la matriz :
M AVANZAR
1 / 3 1 / 3 1 / 3 0 1 / 3 1 / 3 0 1 / 3 = 0 0 0 0 0 0 0 0 1 / 3 1 / 3 1 / 3 0 1 / 3 1 / 3 1 / 3 0 1 / 3 1 / 3 0 1 / 3 1 / 3 1 / 3 0 1 / 3 = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
M PLAN
Luego,
60
Pablo M. Maceri
Solucin propuesta
M
PLAN
2 / 9 2 / 9 1 / 9 1 / 9 2 / 9 2 / 9 1 / 9 1 / 9 = 0 0 0 0 0 0 0 0
Luego, segn el conocimiento de que dispone el sistema, la probabilidad estimada de que el sistema aplicando el plan AVANZARoAVANZAR a la situacin (00000000) obtenga la situacin (11001100) es 2/9. Por lo tanto, el sistema puede proceder con la aplicacin de este plan. Paso 4 Robot B El robot B aplica la accin AVANZAR (figura 4-16) obteniendo la percepcin de la situacin (01001000) con la que se forma la teora (01001000, AVANZAR, 01000100, ?, ?, ?). Al existir una teora registrada que es igual a la teora local formada, se incrementan en 1 su P y K y se promedia la utilidad quedando el conjunto de teoras del sistema B: Teora 1 Teora 2 (01001000, AVANZAR, 10000100, 2, 2, 2/3) (10000100, AVANZAR, 01001000, 2, 2, 1/2)
La situacin obtenida es la situacin esperada por el controlador de planes en ejecucin, pero como no quedan ms acciones del plan para ejecutar el planificador arma la pila de situaciones deseables: [ 10000100 , 2/3 ]
A
[ 01001000, 1/2 ] Con el tope de la pila el planificador arma el siguiente rbol de situaciones:
B
10000100
AVANZAR
Energa Obstculo
01001000
AVANZAR
Robot
10000100

Existe un camino de mnimo recorrido entre la situacin actual (01001000) y la situacin deseable (10000100) con lo cual se puede armar el plan AVANZAR. El ponderador forma la matriz asociada al plan que corresponde con la matriz asociada a la accin AVANZAR si asociamos la fila y columna 1 a la situacin 01000100 y la fila y columna 2 a la situacin 10000100: 1 0 M AVANZAR = 0 1 Entonces, la probabilidad estimada de que el sistema aplicando la accin AVANZAR a la situacin (01001000) obtenga la situacin (10000100) es 1, con lo que el sistema la puede aplicar en el entorno. Paso 5 Robot A De aplicar la primera accin del plan, que es AVANZAR, se produce una modificacin en la percepcin del entorno (figura 4-17) siendo la nueva situacin percibida (11001100) y se arma la teora: (00000000, AVANZAR, 11001100, ?, ?, ?)
B
que tiene valores de P, K y U no establecidos.

Como existe una teora registrada que es igual, se incrementa en 1 el P y el K de la teora registrada y el K de las teoras similares quedando las teoras:
Teora 1 Teora 2 Teora 3 Teora 4 Teora 5 Teora 6

62
(00000000, AVANZAR, 00000000, 1, 4, 1/3) (00000000, AVANZAR, 11001100, 2, 4 1/2) (M) (00000000, AVANZAR, 01001000, 1, 4, 5/12) (11001100, AVANZAR, 11001100, 1, 3, 1) (11001100, AVANZAR, 00000000, 1, 3, 1/3) (M) (11001100, AVANZAR, 01000100, 1, 3, 2/3)
Pablo M. Maceri Solucin propuesta
Como la situacin obtenida es la situacin esperada por el controlador de planes en ejecucin (11001100), toma la siguiente accin a ejecutar que es AVANZAR. Paso 5 Robot B Al aplicar la accin AVANZAR (figura 4-18) el robot B percibe la situacin (11001100) y arma la teora local (01001000, AVANZAR, 11001100, ?, ?, ?). En el conjunto de teoras no existe una teora igual pero si existe una similar, por lo tanto se registra la nueva teora y se pondera la teora similar quedando el conjunto de teoras: Teora 1 Teora 2 Teora 3 (01001000, AVANZAR, 10000100, 2, 3, 2/3) (10000100, AVANZAR, 01001000, 2, 2, 1/2) (01001000, AVANZAR, 11001100, 1, 3, 1/2)
De aplicar la heurstica de mutacin se agrega una nueva teora al conjunto de teoras el cual queda: Teora 1 Teora 2 Teora 3 Teora 4 (M) (01001000, AVANZAR, 10000100, 2, 4, 2/3) (10000100, AVANZAR, 01001000, 2, 2, 1/2) (01001000, AVANZAR, 11001100, 1, 4, 1/2) (01001000, AVANZAR, 11000100, 1, 4, 7/12) Como existe un plan en ejecucin pero la situacin esperada (1000100) por el controlador de planes en ejecucin no es la situacin obtenida (11001100), se aborta el plan y se vuelve a planificar. Entonces, el planificador arma la
B
siguiente pila de situaciones deseables: [ 10000100 , 2/3 ] [ 01001000 , 1/2 ]
Energa Obstculo
[ 11001100 , 1/2 ]
Robot

Con el tope de la pila (10000100) se arma el siguiente rbol de situaciones: 10000100

AVANZAR
01001000
AVANZAR
10000100 Como no existe un camino de mnimo recorrido entre la situacin actual y la situacin 01001000
AVANZAR
10000100
AVANZAR
01001000 deseable se toma la prxima situacin en la pila para armar el rbol: No existe un camino de mnimo recorrido para este rbol tampoco, entonces se toma la 11001100
AVANZAR
01000100
AVANZAR
10000100
AVANZAR
01000100 siguiente situacin (11001100) de la pila que es la ltima y se arma el rbol: Tampoco se puede encontrar un camino de mnimo recorrido para este rbol y como no existen ms situaciones en la pila de situaciones deseables se ejecuta el plan por contingencia azar del que se supone que surge la accin AVANZAR.
64
Pablo M. Maceri
Solucin propuesta
Paso 6 Robot A Al aplicar la accin AVANZAR se produce una modificacin en la percepcin del entorno
B
(figura 4-19), siendo la nueva situacin percibida (11001100) Se arma la teora (11001100, AVANZAR,
11001100, ?, ?, ?) que tiene valores de P, K y U no establecidos. Como existe una teora registrada que es igual, se incrementa en 1 el P y el K de la teora
Energa Obstculo
Robot
registrada y el K de las teoras similares quedando el conjunto de teoras registradas de la siguiente manera:
Teora 1 Teora 2 Teora 3 Teora 4 Teora 5 Teora 6 (M) (M)
(00000000, AVANZAR, 00000000, 1, 4, 1/3) (00000000, AVANZAR, 11001100, 2, 4 1/2) (00000000, AVANZAR, 01001000, 1, 4, 5/12) (11001100, AVANZAR, 11001100, 2, 4, 1) (11001100, AVANZAR, 00000000, 1, 4, 1/3) (11001100, AVANZAR, 01000100, 1, 4, 2/3)
Obsrvese que la nueva matriz asociada a la accin AVANZAR es: 1 / 4 2 / 4 1 / 4 0 1 / 4 2 / 4 0 1 / 4 = 0 0 0 0 0 0 0 0 3 / 16 6 / 16 1 / 16 2 / 16 3 / 16 6 / 16 1 / 16 2 / 16 = 0 0 0 0 0 0 0 0

Pablo M. Maceri 65
M AVANZAR
M
PLAN
Solucin propuesta
M PLAN
1 / 4 2 / 4 1 / 4 0 1 / 4 2 / 4 1 / 4 0 1 / 4 2 / 4 0 1 / 4 1 / 4 2 / 4 0 1 / 4 = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Obsrvese tambin que la probabilidad estimada de que el sistema aplicando el plan AVANZARoAVANZAR a la situacin (00000000) obtenga la situacin (11001100) es 6/16. Si se compara este resultado con el resultado anterior (2/9) se puede decir que el sistema ha ganado confianza en el plan. En particular un plan que lo lleva a una situacin de mxima utilidad (1). Paso 6 Robot B El sistema B aplica la accin AVANZAR obteniendo
A
la
percepcin
de
la
situacin
(11001100) con la que se forma la teora (11001100, AVANZAR, 11001100, ?, ?, ?). Como existe una teora registrada que es igual, se incrementa en 1 el P y el K de la teora registrada quedando el conjunto de teoras de este sistema:
Teora 1 Teora 2 Teora 3 Teora 4 Teora 5 (M)
(01001000, AVANZAR, 10000100, 2, 4, 2/3) (10000100, AVANZAR, 01001000, 2, 2, 1/2) (01001000, AVANZAR, 11001100, 1, 4, 1/2) (01001000, AVANZAR, 11000100, 1, 4, 7/12) (11001100, AVANZAR, 11001100, 1, 1, 1)
66
Pablo M. Maceri
Solucin propuesta
Intercambio de operadores entre el robot A y el robot B Al finalizar el paso 6 de ambos robots (robot A y robot B) se hace la suposicin de que el sistema inteligente autnomo A ejecuta el proceso de intercambio de operadores. Vase cmo trabaja el mtodo. En este instante el conjunto de teoras del robot A se encuentra formado por: Teora 1A Teora 2A Teora 3A Teora 4A Teora 5A Teora 6A (M) (M) (00000000, AVANZAR, 00000000, 1, 4, 1/3) (00000000, AVANZAR, 11001100, 2, 4 1/2) (00000000, AVANZAR, 01001000, 1, 4, 5/12) (11001100, AVANZAR, 11001100, 2, 4, 1) (11001100, AVANZAR, 00000000, 1, 4, 1/3) (11001100, AVANZAR, 01000100, 1, 4, 2/3)
Y el conjunto de teoras del robot B en este instante se compone de: Teora 1B Teora 2B Teora 3B Teora 4B Teora 5B (M) (01001000, AVANZAR, 10000100, 2, 4, 2/3) (10000100, AVANZAR, 01001000, 2, 2, 1/2) (01001000, AVANZAR, 11001100, 1, 4, 1/2) (01001000, AVANZAR, 11000100, 1, 3, 7/12) (11001100, AVANZAR, 11001100, 1, 4, 1)
Para diferenciar las teoras entre los dos sistemas se les agregan subndices (por ejemplo la Teora 1A representa la teora 1 del robot A y Teora 1B representa a la teora 1 del robot B). Se observa de ambos conjuntos de teoras que la teora 5 del robot B es igual a la teora 4 del robot A: Teora 4A Teora 5B (11001100, AVANZAR, 11001100, 2, 4, 1) (11001100, AVANZAR, 11001100, 1, 4, 1)
Solucin propuesta
Pablo M. Maceri
67
Por lo tanto, si se aplica el mtodo de intercambio de operadores presentado en la seccin 4.11, se deben sumar los P y los K de las teoras que coinciden (promediando su utilidad). De esta manera la teora 4 del robot A queda: Teora 4A (11001100, AVANZAR, 11001100, 3, 5, 1)
Por otro lado, la teora 5 del robot B tambin es similar a dos teoras del robot A (la teora 5A y la teora 6A): Teora 5A Teora 6A Teora 5B (11001100, AVANZAR, 00000000, 1, 4, 1/3) (11001100, AVANZAR, 01000100, 1, 4, 2/3) (11001100, AVANZAR, 11001100, 1, 4, 1)
En este caso, y de acuerdo al algoritmo de intercambio, se debe sumar el K de las teoras similares. Entonces las teoras 5A y 6A quedan: Teora 5A Teora 6A (11001100, AVANZAR, 00000000, 1, 5, 1/3) (11001100, AVANZAR, 01000100, 1, 5, 2/3)
Luego, aquellas teoras del conjunto de teoras del robot B que no son ni iguales ni similares a ninguna del conjunto de teoras del robot A se incorporan directamente al sistema A sin cambio alguno en sus P, K o utilidades. Estas teoras son: Teora 1B Teora 2B Teora 3B Teora 4B (01001000, AVANZAR, 10000100, 2, 4, 2/3) (10000100, AVANZAR, 01001000, 2, 2, 1/2) (01001000, AVANZAR, 11001100, 1, 4, 1/2) (01001000, AVANZAR, 11000100, 1, 3, 7/12)
Conjunto de teoras del robot A luego del intercambio de operadores Entonces, luego del intercambio el conocimiento del robot A queda formado por el siguiente conjunto de teoras: Teora 1A Teora 2A
68
(00000000, AVANZAR, 00000000, 1, 4, 1/3) (00000000, AVANZAR, 11001100, 2, 4 1/2)

Pablo M. Maceri Solucin propuesta
Teora 3A Teora 4A Teora 5A Teora 6A Teora 7A Teora 8A Teora 9A Teora 10A
(00000000, AVANZAR, 01001000, 1, 4, 5/12) (11001100, AVANZAR, 11001100, 3, 5, 1) (11001100, AVANZAR, 00000000, 1, 5, 1/3) (11001100, AVANZAR, 01000100, 1, 5, 2/3) (01001000, AVANZAR, 10000100, 2, 4, 2/3) (10000100, AVANZAR, 01001000, 2, 2, 1/2) (01001000, AVANZAR, 11001100, 1, 4, 1/2) (01001000, AVANZAR, 11000100, 1, 4, 7/12)
Estimador de probabilidad para un plan del robot A Se puede calcular, para este nuevo conjunto de teoras del robot A, la matriz asociada al plan AVANZARoAVANZAR. Formando la matriz asociada a la accin AVANZAR donde cada fila y cada columna se asocian con las siguientes situaciones: Fila y columna 1: 00000000 Fila y columna 2: 11001100 Fila y columna 3: 01001000 Fila y columna 4: 01000100 Fila y columna 5: 10000100 Fila y columna 6: 11000100 Entonces, la matriz asociada a la accin AVANZAR queda: 0 0 1 / 4 2 / 4 1 / 4 0 1 / 5 3 / 5 0 1 / 5 0 0 0 1/ 4 0 0 2 / 4 1 / 4 = 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0
Pablo M. Maceri 69
M AVANZAR
Solucin propuesta
Por lo tanto, 0 0 1 / 4 2 / 4 1 / 4 0 0 0 1 / 4 2 / 4 1 / 4 0 1 / 5 3 / 5 0 1 / 5 0 1 / 5 3 / 5 0 1 / 5 0 0 0 0 1/ 4 0 0 2 / 4 1 / 4 0 1 / 4 0 0 2 / 4 1 / 4 = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0.1625 0.4875 0.0625 0.1 0.125 0.625 0.17 0.46 0.05 0.12 0 0 0.05 0.15 0.5 0.05 0 0 = 0 0 0 0 0 0 0 0.25 0 0 0.5 0.25 0 0 0 0 0 0
M PLAN
M PLAN
De la observacin de esta matriz surge que la probabilidad estimada de que el sistema A aplicando el plan AVANZARoAVANZAR a la situacin (00000000) obtenga la situacin (11001100) es 0.4875. Por lo tanto comparado con el ltimo resultado obtenido en el paso 6 del robot A (6/16, o lo que es lo mismo 0.375) se puede decir que el robot A ha ganado ms confianza luego del intercambio de operadores con el robot B.
70
Pablo M. Maceri
Solucin propuesta
Captulo 5
Experimentos
En este captulo se presentan los resultados experimentales del comportamiento del sistema inteligente autnomo implementado en la plataforma Khepera. En la seccin 5.1 se da una introduccin, luego se da una visin del diseo experimental en la seccin 5.2 y por ltimo, en la seccin 5.3, se muestran grficamente los resultados obtenidos y su interpretacin.
5.1. Introduccin
El sistema que simula varios robots de exploracin autnomo simultneamente ha sido probado en entornos diferentes (ver anexo B). En cada entorno han aprendido los efectos de aplicar determinadas acciones a determinadas situaciones. En un mismo entorno los robots han podido intercambiar este aprendizaje y han formulado un conjunto de teoras que les permiten predecir "a priori" el efecto de las acciones. Esta habilidad es utilizada por los robot simulados en la formulacin de planes. Los planes tienen por objetivo que un robot llegue a reas de mximo nivel de luz o de recarga de energa.
5.2. Diseo Experimental

Los experimentos descriptos en este captulo fueron diseados para estudiar los efectos de la aplicacin de los siguientes componentes del sistema : - Aprendizaje de teoras por mutacin - Ponderacin de planes - Intercambio de teoras El procedimiento utilizado para generar cada experimento puede describirse de la siguiente manera: 1. Elegir aleatoriamente un entorno como escenario del experimento. 2. Elegir aleatoriamente una posicin inicial del robot en el entorno elegido. 3. Ejecutar el sistema que simula el robot durante 500 ciclos (ciclo = percepcin/accin). 4. Cada 20 ciclos generar un informe sobre el estado de las variables del sistema e intercambiar los operadores entre los robots simulados.
Experimentos Pablo M. Maceri 71
5. Construir una matriz que contiene en la fila I toda la informacin sobre las variables del sistema generada en el ciclo I*20. El procedimiento experimental general puede describirse de la siguiente manera: 1. Generar 50 experimentos. 2. Construir una matriz promedio de las matrices asociadas a cada experimento. 3. Generar las grficas de comportamiento del sistema a partir de la informacin contenida en la matriz promedio. 4. Interpretar resultados.
5.2.1. Variables Independientes tiempo: los experimentos se basan en esta nica variable independiente. Se define una unidad de tiempo como el lapso transcurrido entre una percepcin del entorno y otra. Es una variable cuantitativa cuyo valor pertenece al intervalo [0,500]. mutacin: esta variable indica que los planes a ejecutar por el sistema se han generado a partir de teoras que han sido mutadas. Es una variable cualitativa (1 = se usa mutacin, 0 = no se usa mutacin). ponderacin: esta variable indica que los planes a ejecutar han sido ponderados (se ha calculado el estimador de probabilidad del plan y se ha descartado si es menor a un cierto umbral). Es una variable cualitativa (1 = se usa ponderacin, 0 = no se usa ponderacin). intercambio: esta variable indica que el sistema utiliza intercambio de teoras entre los robots simulados. Es una variable cualitativa (1 = se usa intercambio, 0 = no se usa intercambio). 5.2.2. Variables Dependientes Cantidad de situaciones: esta variable indica la cantidad promedio de situaciones diferentes que han sido reconocidas por el sistema hasta el instante dado por la variable tiempo. Es una variable cuantitativa cuyo valor pertenece al intervalo [0,100].
72
Pablo M. Maceri
Experimentos
Cantidad de teoras: esta variable indica la cantidad promedio de teoras diferentes que han sido generadas por el sistema hasta el instante dado por la variable tiempo. Es una variable cuantitativa cuyo valor pertenece al intervalo [0,200]. Porcentaje de planes exitosos: esta variable indica el porcentaje promedio de planes exitosos que han sido generados por el sistema en el intervalo de tiempo: [0 , tiempo]. Es una variable cuantitativa cuyo valor pertenece al intervalo [0,100]. Se considera un plan exitoso cuando luego de aplicar cada accin del mismo se obtiene la situacin esperada por el sistema. Cuando una situacin no es la esperada, se aborta el plan en ejecucin y se contabiliza como un plan parcialmente exitoso. Este valor se calcula como la cantidad de acciones del plan que obtuvieron una situacin esperada sobre la cantidad total de acciones del plan.
5.3. Grficas y su Interpretacin

Para analizar el comportamiento del sistema se han desarrollado siete experimentos que surgen de utilizar los distintos mtodos de aprendizaje y la combinacin entre ellos. Estos experimentos comprenden: el sistema utilizando solamente el mtodo de mutacin de teoras, el sistema utilizando slo ponderacin de planes, el sistema utilizando slo intercambio de operadores, el sistema utilizando la combinacin de la mutacin de teoras y la ponderacin de planes, el sistema utilizando la combinacin de la mutacin de teoras y el intercambio de operadores, el sistema utilizando la combinacin de la ponderacin de planes y el intercambio de operadores y el sistema utilizando la combinacin de los mtodos de mutacin de teoras, la ponderacin de planes y el intercambio de operadores. En la seccin 5.3.1 se grafican la cantidad de situaciones y la cantidad de teoras para cada experimento. En la seccin 5.3.2 se presentan tres grficos comparativos de la cantidad de operadores entre distintos experimentos. Y en la seccin 5.3.3 se muestran tres grficos comparativos del porcentaje de planes exitosos entre distintos experimentos. 5.3.1. Cantidad de situaciones y cantidad de teoras a lo largo del tiempo De la grfica 5-1 a 5-7 se muestra la cantidad de situaciones y teoras a lo largo del tiempo para cada mtodo (mutacin, ponderacin e intercambio) y la combinacin entre ellos. En todos los casos se observa que la cantidad de teoras aumenta ms rpido que la cantidad de situaciones (condiciones supuestas o efectos predecidos). Esto sostiene la
hiptesis de que el sistema descubre nuevas relaciones entre situaciones an despus que se ha estabilizado el nmero de situaciones.
1 0 0 .0 0 9 0 .0 0 8 0 .0 0 7 0 .0 0 6 0 .0 0 5 0 .0 0 4 0 .0 0 3 0 .0 0 2 0 .0 0 1 0 .0 0 0 .0 0
20 60 0 0 0 0 0 0 0 0 0 0 10 14 18 22 30 26 34 38 42 46 50 50 0 0
s itu a c io n e s te o r ia s
Grfico 5-1: Cantidad de situaciones y cantidad de teoras vs. tiempo en el intervalo [0,500] utilizando slo mutacin.
En el grfico 5-1 se ve que tanto la cantidad de situaciones como de teoras tienden a estabilizarse cuando se utiliza slo el mtodo de mutacin de teoras. La cantidad de situaciones pareciera hacerlo antes ya que los experimentos indican que se siguen encontrando nuevas relaciones entre situaciones an despus de que se ha estabilizado la cantidad de situaciones.
1 0 0 .0 0 9 0 .0 0 8 0 .0 0 7 0 .0 0 6 0 .0 0 5 0 .0 0 4 0 .0 0 3 0 .0 0 2 0 .0 0 1 0 .0 0 0 .0 0
20 60 0 0 0 0 0 0 0 0 0 10 14 18 22 26 30 34 38 42 46
te o r ia s
Grfico 5-2: Cantidad de situaciones y cantidad de teoras vs. tiempo en el intervalo [0,500] utilizando slo ponderacin de planes.
En el grfico 5-2 se puede observar que cuando se utiliza el mtodo de ponderacin de planes la cantidad de situaciones y la cantidad de teoras presentan un crecimiento mayor a lo largo1 0 0 .0 0 tiempo respecto de la grfica 5.1. del
9 0 .0 0 8 0 .0 0 7 0 .0 0 6 0 .0 0 5 0 .0 0 4 0 .0 0 3 0 .0 0
s itu a c io n e s
74
2 0 .0 0 1 0 .0 0 0 .0 0
20 60 10 0 14 0 18 0
Pablo M. Maceri
Experimentos
22 0
26 0
30 0
34 0
38 0
42 0
46 0
50 0
Grfico 5-3: Cantidad de situaciones y cantidad de teoras vs. tiempo en el intervalo [0,500] utilizando slo intercambio de operadores.
En el grfico 5-3 se presentan la cantidad de situaciones y la cantidad de teoras utilizando el mtodo de intercambio de operadores solamente. Se puede observar que ambas cantidades tienden a estabilizarse pero cabe notar que la cantidad de teoras presenta un crecimiento ms rpido.
1 0 0 .0 0 9 0 .0 0 8 0 .0 0 7 0 .0 0 6 0 .0 0 5 0 .0 0 4 0 .0 0 3 0 .0 0 2 0 .0 0 1 0 .0 0 0 .0 0
20 60 10 0 14 0 18 0 22 0 26 0 30 0 34 0 38 0 42 0 46 0 50 0
s itu a c io n e s te o r ia s s itu a c io n e s te o r ia s
Grfico 5-4: Cantidad de situaciones y cantidad de teoras vs. tiempo en el intervalo [0,500] utilizando la combinacin de la mutacin con la ponderacin de planes.
En el grfico 5-4 se combinan los mtodos de mutacin de teoras y ponderacin de planes para analizar la cantidad de situaciones y teoras a lo largo del tiempo. Se puede observar que estas cantidades tienen un crecimiento casi lineal. El crecimiento de la cantidad de teoras, como en los casos anteriores, es superior al de la cantidad de teoras durante toda la simulacin.
1 0 0 .0 0 9 0 .0 0 8 0 .0 0 7 0 .0 0 6 0 .0 0 5 0 .0 0 4 0 .0 0 3 0 .0 0 2 0 .0 0 1 0 .0 0 0 .0 0
20 60 10 0 14 0 18 0 22 0 26 0 30 0 34 0 38 0 42 0 50 0 46 0
Grfico 5-5: Cantidad de situaciones y cantidad de teoras vs. tiempo en el intervalo [0,500] utilizando la combinacin de la mutacin con el intercambio de operadores.
Experimentos
Pablo M. Maceri
75
El grfico 5-5 presenta un comportamiento similar que el grfico 5-3. La cantidad de situaciones y la cantidad de teoras en el mtodo de intercambio de operadores no se ve afectado en gran medida por la mutacin de teoras.
1 6 0 .0 0 1 5 0 .0 0 1 4 0 .0 0 1 3 0 .0 0 1 2 0 .0 0 1 1 0 .0 0 1 0 0 .0 0 9 0 .0 0 8 0 .0 0 7 0 .0 0 6 0 .0 0 5 0 .0 0 4 0 .0 0 3 0 .0 0 2 0 .0 0 1 0 .0 0 0 .0 0
20 60 10 0 14 0 18 0 22 0 30 0 26 0 34 0 38 0 42 0
46 0
Grfico 5-6: Cantidad de situaciones y cantidad de teoras vs. tiempo en el intervalo [0,500] utilizando la combinacin de la ponderacin de planes con el intercambio de operadores.
En el grfico 5-6 se puede observar que la ponderacin provoca sobre el intercambio de operadores un aumento en la cantidad de situaciones y este aumento es ms significante en la cantidad de teoras. Las poligonales no llegan a estabilizarse ya que la simulacin finaliza en el momento en que el sistema se encuentra en pleno aprendizaje. Pero se observa que la asntota de crecimiento va disminuyendo en ambas poligonales tendiendo a una estabilidad.
76
Pablo M. Maceri
50 0
Experimentos
1 6 0 .0 0 1 5 0 .0 0 1 4 0 .0 0 1 3 0 .0 0 1 2 0 .0 0 1 1 0 .0 0 1 0 0 .0 0 9 0 .0 0 8 0 .0 0 7 0 .0 0 6 0 .0 0 5 0 .0 0 4 0 .0 0 3 0 .0 0 2 0 .0 0 1 0 .0 0 0 .0 0
20 60 18 0 22 0 26 0 30 0 34 0 38 0 42 0 46 0 10 0 14 0 50 0
Grfico 5-7: Cantidad de situaciones y cantidad de teoras vs. tiempo en el intervalo [0,500] utilizando la combinacin los tres mtodos: la mutacin, la ponderacin de planes y el intercambio de operadores.
Finalmente, en el grfico 5-7, se presenta la cantidad de situaciones y la cantidad de teoras a lo largo del tiempo combinando los tres mtodos (mutacin, ponderacin e intercambio). Este grfico es similar al 5-6, mostrando nuevamente que la mutacin no afecta en gran medida la cantidad total de situaciones y teoras a lo largo del tiempo. 5.3.2. Cantidad de operadores Grficos comparativos En esta seccin se analizan tres grficos donde cada uno representa el anlisis un mtodo comparndolo con los otros dos mtodos. Primero se analiza la mutacin de teoras, luego la ponderacin de planes y finalmente el intercambio de operadores. 5.3.2.1. Mutacin
160.00
muta
140.00 120.00 100.00 80.00 60.00 40.00 20.00 0.00
muta/ponde muta/inter muta/ponde/inter
40
os
80
12
16
20
24
28
32
36
40
44
Grfico 5-8: Cantidad de teoras vs. tiempo en el intervalo [0,500] respecto de la mutacin
Experimentos
ci
cl
Pablo M. Maceri
48
77
En el grfico 5-8 se analiza la cantidad de operadores de la mutacin cuando se la combina con los otros dos mtodos (ponderacin e intercambio). Se observa que la mutacin combinada tanto con la ponderacin, como con el intercambio de operadores o con ambos, provoca un aumento en la cantidad de operadores (teoras que relacionen situaciones). Al comienzo de la simulacin, cuando ambos sistemas poseen muy poco conocimiento de su entorno, el intercambio produce sobre la mutacin un crecimiento ms significativo en la cantidad de teoras, aunque llegando al final, este crecimiento se estabiliza y llega a ser superado por la cantidad de teoras generadas al utilizar la mutacin y la ponderacin juntas. Al utilizar los tres mtodos juntos la cantidad de operadores supera a cualquier otra combinacin de estos mtodos y no tiende estabilizarse la cantidad de operadores. 5.3.2.2. Ponderacin de planes
160.00 140.00 120.00 100.00 80.00 60.00 40.00 20.00 0.00
0 0 0 0 0 0 0 0 0 40 os 80 12 16 20 24 28 32 36 40 44 ci cl 48 0
ponde muta/ponde ponde/inter muta/ponde/inter
Grfico 5-9: Cantidad de teoras vs. tiempo en el intervalo [0,500] respecto de la ponderacin
En el grfico 5-9 se muestra la cantidad de operadores para la ponderacin y la combinacin de esta con los otros dos mtodos. En este caso la combinacin de dos mtodos, ponderacin y mutacin, produce una menor cantidad de teoras que al utilizar el mtodo de ponderacin solamente. Si se combina la ponderacin con el intercambio, la cantidad de situaciones y teoras aumentan considerablemente, y llega a superar la combinacin de los tres mtodos (mutacin, ponderacin de planes e intercambio de operadores).
78
Pablo M. Maceri
Experimentos
5.3.2.3. Intercambio de operadores

160.00 140.00 120.00 100.00 80.00 60.00 40.00 20.00 0.00
0 0 0 0 0 0 0 0 0 40 os 80 12 16 20 24 28 32 36 40 44 ci cl 48 0
inter muta/inter ponde/inter muta/ponde/inter
Grfico 5-10: Cantidad de teoras vs. tiempo en el intervalo [0,500] respecto del intercambio
El grfico 5-10 presenta la cantidad ms baja de operadores cuando el sistema utiliza slo intercambio de operadores. No se observa un aumento apreciable si se lo combina a ste con la mutacin. Estas dos poligonales tienden a estabilizarse rpidamente. No ocurre lo mismo cuando se combina el intercambio con la ponderacin de planes o con la combinacin de los tres mtodos (mutacin, ponderacin e intercambio). 5.3.3. Rendimiento del sistema Para analizar el rendimiento del sistema se grfica el porcentaje de planes exitosos a lo largo del tiempo. Para lograr una mejor compresin del comportamiento general del sistema, se han realizado tres grficos. En cada grfico se representa la poligonal de rendimiento de un mtodo junto con las poligonales de rendimiento de este mtodo combinado con otro. En total para cada grfico se muestran tres poligonales. Como en la seccin anterior (5.3.2) se analiza primero la mutacin (5.3.3.1), luego la ponderacin de planes (5.3.3.2) y se concluye con el intercambio de operadores (5.3.3.3).
Experimentos
Pablo M. Maceri
79
5.3.3.1 Rendimiento de la mutacin

5 0 .0 0 mu ta mu ta /p o n d e 4 0 .0 0 mu ta /in te r
3 0 .0 0
2 0 .0 0
1 0 .0 0
0 .0 0
0 0 0 0 0 0 0 0 0 40 ci cl os 80 12 16 20 24 28 32 36 40 44 48 0
Grfico 5-11: Porcentaje de planes exitosos vs. tiempo en el intervalo [0,500] respecto de la mutacin
En el grfico 5-11 se comparan el rendimiento del sistema usando slo mutacin, mutacin combinada con ponderacin y mutacin combinada con intercambio de operadores. A partir de esto se puede observar que la mutacin muestra su mejor comportamiento cuando se la combina con la ponderacin. El intercambio de operadores produce el efecto inverso sobre la mutacin ya que hace bajar considerablemente el porcentaje de planes exitosos a lo largo de la vida del sistema. Esto abona la tesis que la ponderacin mejora significativamente el comportamiento de la mutacin, en cambio el intercambio produce un efecto negativo sobre ella ya que baja el porcentaje de planes exitosos a lo largo de todo la vida del sistema respecto de la mutacin sin combinar.
80
Pablo M. Maceri
Experimentos
5.3.3.2 Rendimiento de la ponderacin de planes

5 0 .0 0 ponde m u ta /p o n d e 4 0 .0 0 p o n d e /in t e r
3 0 .0 0
2 0 .0 0
1 0 .0 0
0 .0 0
0 0 0 0 0 0 0 0 0 40 ci cl os 80 12 16 28 32 36 20 24 40 44 48 0
Grfico 5-12: Porcentaje de planes exitosos vs. tiempo en el intervalo [0,500] respecto de la ponderacin
El grfico 5-12 muestra el rendimiento de la ponderacin sola, la ponderacin combinada con la mutacin, y la ponderacin combinada con el intercambio. En este grfico no se observan diferencias significativas entre la ponderacin sin combinar y la combinacin con los otros mtodos. Pero se puede observar que el intercambio produce una leve mejora de la ponderacin ya que a lo largo del tiempo el porcentaje de planes exitosos es mayor cuando se combinan la ponderacin y el intercambio de operadores. Con la mutacin es ms difcil el anlisis ya que el comportamiento es variable a lo largo del tiempo. Sin embargo la mayor parte del tiempo se puede observar que la poligonal de la ponderacin combinada con la mutacin se mantiene por encima de la poligonal de la ponderacin sola, aunque no supera el comportamiento de la ponderacin combinada con el intercambio excepto en los primeros estados, cuando el sistema posee poco conocimiento del entorno. Con esto se puede afirmar que cualitativamente el mejor comportamiento lo presenta la combinacin de la ponderacin y el intercambio, seguido de la combinacin de la ponderacin y mutacin, y un poco por debajo se encuentra la ponderacin sola. Tambin se debe aclarar que esta superioridad de la ponderacin combinada con el intercambio se presenta luego de adquirir cierta cantidad de conocimiento, es decir que cuando el conocimiento que posee el sistema de su entorno es poco (o de mala calidad), combinar la
ponderacin con el intercambio no es un buen mtodo para mejorar el rendimiento del sistema. 5.3.3.3 Rendimiento del intercambio de operadores
5 0 .0 0
inter muta/inter ponde/inter
4 0 .0 0
3 0 .0 0
2 0 .0 0
1 0 .0 0
0 .0 0
40 80 os 0 0 0 0 0 0 0 0 16 20 24 28 0 12 32 36 40 cl 44 48 0
Grfico 5-13: Porcentaje de planes exitosos vs. tiempo en el intervalo [0,500] respecto del intercambio
En el grfico 5-13 se representan el rendimiento del intercambio slo, el rendimiento del intercambio combinado con la mutacin y el rendimiento de la combinacin del intercambio con la ponderacin. En este caso se ve claramente que el intercambio de operadores mejora en gran medida su rendimiento cuando se lo combina con la ponderacin y presenta una leve baja cuando se lo combina con la mutacin. La combinacin del intercambio con la ponderacin presenta un muy buen comportamiento si se lo compara con el intercambio slo. Al principio se puede observar, como en el anlisis del rendimiento de la ponderacin (figura 5.12), que la combinacin del intercambio con la ponderacin no es tan buena, porque es superada tanto por el intercambio sola y la combinacin de sta con la mutacin. Por lo tanto, se puede afirmar que la combinacin del intercambio con la ponderacin no es un buen mtodo para aplicar cuando el sistema tiene poca informacin de su entorno.
82
ci
Pablo M. Maceri
Experimentos
Captulo 6
Conclusiones
En este captulo se toman las cuestiones abordadas en el captulo 3 y se sumarizan las respuestas a las mismas que aparecen a lo largo de la tesis. Cuestin 1: Cul es la repetibilidad de los resultados de trabajos previos en la teora de sistemas inteligentes autnomos [Garca Martinez y Borrajo, 1997;1998] al cambiar de plataforma robot (migrar de la plataforma [Fritz et al., 1989] a Khepera)? Para analizar el comportamiento del sistema se han desarrollado siete experimentos que surgen de utilizar el sistema con los distintos mtodos de aprendizaje y la combinacin entre ellos. Estos experimentos comprenden: el sistema utilizando solamente el mtodo de mutacin de teoras, el sistema utilizando slo ponderacin de planes, el sistema utilizando slo intercambio de operadores, el sistema utilizando la combinacin de la mutacin de teoras y la ponderacin de planes, el sistema utilizando la combinacin de la mutacin de teoras y el intercambio de operadores, el sistema utilizando la combinacin de la ponderacin de planes y el intercambio de operadores y el sistema utilizando la combinacin de los mtodos de mutacin de teoras, la ponderacin de planes y el intercambio de operadores. En la seccin 5.3.1 se grafican la cantidad de situaciones y la cantidad de teoras a lo largo del tiempo para cada experimento. En la seccin 5.3.2 se presentan tres grficos comparativos de la cantidad de operadores a lo largo del tiempo entre distintos experimentos. Y en la seccin 5.3.3 se muestran tres grficos comparativos del porcentaje de planes exitosos a lo largo del tiempo entre distintos experimentos. En trabajos previos en la teora de sistemas inteligentes autnomos [Garca Martinez y Borrajo, 1997;1998] se realizan experimentos similares en los que se grafican la cantidad de situacin y de teoras a lo largo del tiempo y se comparan distintos mtodos de aprendizaje a travs del anlisis del porcentaje de planes exitosos a lo largo del tiempo. En este ltimo caso se
Conclusiones Pablo M. Maceri 83
compara el sistema base, es decir sin utilizar ningn mtodo, el sistema usando mutacin, el sistema utilizando ponderacin y el sistema combinando mutacin y ponderacin. Cuestin 2: Cmo debe ser modificada la arquitectura del sistema inteligente autnomo para admitir procesos de intercambio de operadores? La arquitectura de un sistema inteligente autnomo debe ser extendida para admitir procesos de intercambio de operadores. En un sistema multiagente cada agente mantiene internamente la estructura y los mdulos que son propios de un sistema inteligente autnomo. Para lograr el intercambio de operadores se debe extender la arquitectura del sistema inteligente autnomo introduciendo un mdulo que se encargue del proceso de intercambio de operadores entre agentes cuando sea necesario. Este mdulo ser el encargado de combinar los operadores de dos sistemas inteligentes autnomos manteniendo su consistencia. Luego del intercambio el sistema inteligente autnomo contina su ciclo de vida normal con su conjunto de teoras actualizado utilizando de esta manera el conocimiento aportado por otro sistema. Cuestin 3: Qu mecanismos deben utilizarse para integrar los operadores que un sistema inteligente autnomo recibe de otro con los que ya forman parte de su base de teoras? De acuerdo al modelo de representacin de operadores utilizado (seccin 4.2) en el que una teora est formado por los siguientes componentes: Si A Sf P K U Situacin Inicial (Condiciones Supuestas) Accin Situacin Final (Efectos Predecidos) Cantidad de veces que la teora fue utilizada con xito (se obtuvo la situacin final) Cantidad de veces que se aplic la accin A a la situacin inicial Si Nivel de utilidad alcanzado al aplicar la accin A a la situacin inicial Si Y donde las siguientes afirmaciones son verdaderas:
84
Pablo M. Maceri
Conclusiones
Dos teoras son iguales cuando poseen la misma situacin inicial, la misma accin y la misma situacin final. Dos teoras son similares cuando poseen la misma situacin inicial y la misma accin. El conjunto de teoras de un sistema inteligente autnomo es consistente cuando la suma de los P de todas las teoras similares es igual al K de cualquiera de ellas.
Debido a que la consistencia del conjunto de teoras es imprescindible para este modelo, dicha consistencia debe ser mantenida ante un intercambio de operadores entre dos sistemas inteligentes autnomos. Para lograr esto, en el proceso de intercambio, se debe considerar la afirmacin anteriormente expuesta donde teoras similares deben mantener el mismo K y la suma de los P de todas las teoras similar deben ser igual al K de cualquiera de ellas. De esta manera se present en el captulo 4 (seccin 4.11) un mdulo que permite intercambiar operadores entre dos sistemas manteniendo la consistencia del conjunto de teoras. Cuestin 4: En qu medida este intercambio de teoras/operadores acelera los tiempos de aprendizaje del modelo del entorno que el sistema inteligente autnomo va formando por interaccin con aquel? En las grficas 5-8 y 5-9 del captulo 5 se puede observar que el intercambio de operadores acelera los tiempos de aprendizaje del sistema inteligente autnomo ya que al combinarlo con otras estrategias, como la mutacin y la ponderacin, provoca un aumento en la cantidad de teoras que el sistema adquiere de la interaccin con el entorno. En la grfica 5-8, la cantidad de teoras del sistema actuando por mutacin e intercambio es considerablemente mayor que la cantidad de teoras para el sistema actuando slo por mutacin. De la misma forma, en la grfica 5-9, se observa que la cantidad de teoras cuando el sistema acta combinando los mtodos de ponderacin e intercambio supera en gran medida a la cantidad de teoras cuando el sistema utiliza slo el mtodo ponderacin de planes. Cuestin 5: En qu medida el intercambio de operadores afecta o se ve afectado por el uso de otras estrategias de aceleracin de aprendizaje como la mutacin?
Conclusiones Pablo M. Maceri 85
Cuando el sistema combina el intercambio de operadores con la mutacin se presenta una merma en el rendimiento del sistema. Esto se puede observar en la grfica 5-13 donde un sistema que combina el intercambio de operadores con la mutacin presenta un rendimiento menor que un sistema que utilice slo el intercambio de operadores. Cuestin 6: En qu medida el intercambio de operadores afecta o se ve afectado por el uso de otras estrategias de aceleracin de aprendizaje como la ponderacin de planes? Del anlisis de la grfica 5-13 del captulo 5 surge que el intercambio de operadores muestra una mejora considerable en el rendimiento del sistema cuando se lo combina con la ponderacin de planes. Es importante aclarar que esta mejora se alcanza luego de que el sistema alcanz cierta cantidad de conocimiento, es decir que cuando un sistema inteligente autnomo posee poco conocimiento de su entorno (o de mala calidad) se ve favorecido en su rendimiento cuando utiliza slo el mtodo de intercambio de operadores. Cuestin 7: En qu medida la combinacin del intercambio de operadores con aprendizaje por mutacin acelera el aprendizaje? La combinacin del intercambio de operadores con aprendizaje por mutacin logra aumentar la aceleracin del aprendizaje ya que, observando el grfico 5-10, al combinar el uso de la mutacin y el intercambio de operadores la cantidad de operadores a lo largo del tiempo aumenta. Cuestin 8: En qu medida la combinacin del intercambio de operadores con aprendizaje por ponderacin de planes acelera el aprendizaje? La grfica 5-10 muestra un aumento considerable de la cantidad de operadores del sistema al combinar en el sistema la utilizacin del intercambio de operadores con la ponderacin de planes. Es decir que, el sistema utilizando el intercambio de operadores presenta una aceleracin en el aprendizaje si se utiliza la ponderacin de planes.
86
Pablo M. Maceri
Conclusiones
Referencias
[Anderson y Kline, 1979] Anderson, J. Y Kline, J. A Learning System and Its Psichological Implications. Proceedings of the Sixth International Joint Conference an Artificial Intelligence Pg. 16-21. Tokio. 1979. [Barbehenn y Hutchinson, 1991] Barbehenn, M. & Hutchinson, S. An Integrated Architecture for Learning and Planning in Robotic Domains. 1991. [Birnbaum y otros, 1990] Birnbaum, L., Collins, G., Fredd, M., & Krulwich, B. Model-based diagnosis of planning failures. Proceeding of the Eighth National Conference on Artificial Intelligence, Boston, MA, pginas 318-323. 1990. Bock, P. The Emergence of Artificial Intelligence: Learning to learn. A.I. Magazine Fall. Pg. 180-190. EEUU. 1985. Carbonell, J. Learning by Analogy: Formulating and Generalizing Plans from Past Experience. En Machine Learning: The Artificial Intelligence Approach Volumen I editado por Michalski, R., Carbonell, J., y Mitchell T. Morgan Kauffmann. 1983. [Carbonell y Gil, 1990] Carbonell, J. & Gil, Y. Learning by experimentation: The operator refinement method. En Machine Learning, An Artificial Intelligence Approach, Volume III, pginas 191-213. Morgan Kaufman, San Mateo, CA.1990. [Carbonell y otros, 1991] Carbonell, J., Etzioni, O., Gil, Y., Joseph, R., Knoblock, C., Minton, S. & Veloso, M. PRODIGY: An Integrated Architecture for Planning and Learning. 1991.
[Bock, 1985]
[Carbonell, 1983]
Referencias
Pablo M. Maceri
87
[Christiansen, 1992]
Christiansen, A. Automatic Acquisition of Task Theories for Robotic Manipulation. Ph.D. Thesis. School of Computer Science, Carnegie Pittsburgh, PA. Marzo 1992. Mellon University,
[Collins y otros,1991a]
Collins, G., Birnbaum, L., Krulwich, B., & Freed, M. Model-Based Integration of Planning and Learning.
[Collins y otros, 1991b]
Collins, G., Birnbaum, L., Krulwich, B., & Freed, M. Plan debugging in an intentional system. To appear in Proceeding of the Twelfth International Joint Conference on Artificial Intelligence, Sydney, Australia. 1991.
[Eiter y Gotlob, 1992]
Eiter, T. Y Gottlob, G. On the Complexity of Propositional Knowledge Base Revision, Updates, & Counterfactuals. Volumen 57. Pginas 227-270. Elsevier. 1992.
[Etzioni, 1991]
Etzioni, O. STATIC: a problem-space compiler for PRODIGY. En Proceeding of the Ninth National Conference on Artificial Intelligence, Anaheim, CA. 1991. Falkenhaimer, B. A Unified Approach to Explanation and Theory Formation. En Computational Models of Scientific Discovery and Theory Formation. Shrager, J. Y Langley, P. (Editores). Morgan Kaufman. 1990.
[Falkenhaimer, 1990]
[Fritz y otros, 1989]
Fritz, W., Garca Martnez, R., Blanqu, J., Rama, A., Adobbati, R. y Samo, M. The Autonomous Intelligent System. Robotics and Autonomous Systems. Vol. 5 Nro. 2. Pg. 109-125. Elsevier. 1989.
[Fritz y otros, 1990]
Fritz, W., Garca Martnez, R. & Marsiglio, A. Sistemas Inteligentes Artificiales. C.E.I.L.P. La Plata. 1990.
88
Pablo M. Maceri
Referencias
[Garca Martnez, 1991a]
Garca Martnez, R. Un Mtodo de Aprendizaje por Ajuste de Coeficientes en Sistemas Inteligentes Artificiales. Anales del II Simposio de Inteligencia Artificial y Robtica. Buenos Aires. 1991.
[Garca Martnez, 1991b]
Garca Martnez, R. Heursticas de Ajuste de Unidades de Experiencia para Sistemas Inteligentes Artificiales. Porduccin Cientfica del Programa IDEIA. Pg. 20-29. Departamento de Ciencias Nacional de Lujn. 1991. Bsicas. Universidad
Garca Martnez, R. Aprendizaje basado en formacin de teoras sobre el efecto de las acciones en el entorno. 124 pginas. Tesis de Master. Departamento de Inteligencia Artificial. Facultad de Informtica. Universidad Politcnica de Madrid. 1992. Garca Martnez, R. Aprendizaje Automtico no Supervisado. Cuaderno N 4. Secretara de Ciencia y Tcnica. Universidad Nacional de Lujn. 1992. Garca Martnez, R. Heuristic theory formation as a machine learning method Proceedings VI International Symposium on Artificial Inteligence. Pginas 294-298. Editorial LIMUSA. Mxico. 1993.
Garca Martnez, R. 1993b. Measures for theory formation in autonomous intelligent systems. Proceedings RPIC93. pp. 451-455. Imprenta de la Universidad Nacional de Tucumn. Horco Molle.
[Garca Martnez, 1993c]
Garca Martnez, R. Aprendizaje Automtico basado en Mtodo Heurstico de Formacin y Ponderacin de Teoras. Revista Tecnologa. Brasil. Volumen 15. Nmero 1-2. Pginas 159-182. 1993.
[Garca Martnez, 1994]
Garca Martnez, R. Un Sistema con Aprendizaje Nosupervisado basado en Mtodo Heurstico de Formacin
Referencias
Pablo M. Maceri
89
y Ponderacin de Teoras. Revista Latino Americana de Ingeniera. Volumen 2. Nmero 2. Pginas 105-127. 1994. [Garca Martnez, 1995] Garca Martnez, R. Theory formation by heuristics. Proceedings of the II International Congress on Information Engineering. pp. 200-205. Buenos Aires. 1995. [Garca Martnez, 1996] Garca Martnez, R. Planning while Learning-byInteraction Systems: A Theoretical Approach. Proceedings of INFOCOM96. pp. 410-416. Buenos Aires. 1996. [Garca Martnez, 1997a] Garca Martnez, R. An Overview of an Autonomous Intelligent System with an Embedded Machine Learning Mechanism. Proceedings of INFOCOM97. pp. 184190. Buenos Aires. 1997. [Garca Martnez, 1997b] Garca Martnez, R. Un Modelo de Aprendizaje por observacin en Planificacin. Ph.D. Thesis, Facultad de Informtica, Universidad Politcnica de Madrid. 1997. An Integrated Approach of Learning, Planning, and Execution.?? [Garca Martnez et al., 1998a] Garca Martnez, R. Fernndez, V & Merlo, G. Autonomous Intelligent Systems with Machine Learning. Proceedings del IV International Congress on Information Engineering. pp 100-105. Buenos Aires. 1998. [Garca Martnez et al., 1998b] Garca Martnez, R. Fernndez, V & Merlo, G. Learning in Autonomous Intelligent Systems: A Theoretical Framework Proceedings del IV International Congress on Information Engineering. Pp. 106-113. Buenos Aires. 1998.
[Garca Martnez, 2000]
90
Pablo M. Maceri
Referencias
[Garca Martnez et al., 1999a]
Garca Martnez R., Cernic, S., Jezierski, E., Britos, P. & Rossi, B. Genetic Algorithms Applied to Robot Navigation Controller Optimization. Proceedings of the International Conference on Intelligent Systems and Control. . Pp 230-234. Santa Brbara. California. 1999.
[Garca Martnez et al., 1999b] Garca Martnez R., Cernic, S., Jezierski, E., Britos, P. & Rossi, B. Neural Networks Applied to Automatic Navigation. Proceedings of the International Conference on Intelligent Systems and Control. Pp 157-160. Santa Brbara. California. 1999. [Garca Martnez y Borrajo, 1996] Garca Martnez, R. & Borrajo Milln, D.
Unsupervised Machine Learning Embedded in Autonomous Intelligent Systems. Proceedings of the XIV International Conference on Applied Informatics. pp. 71-73. Innsbruck. Austria. 1996. [Garca Martnez y Borrajo, 1997] Garca Martnez, R. y Borrajo, D. Planning, Learning and Executing in Autonomous Systems. Lecture Notes in Artificial Intelligence. Nber. 1348 (Ed. Sam Steel & Rachid Alami) Pginas 208-210. SpringerVerlag. 1997. Garca Martnez, R. & Borrajo Milln, D. Learning
[Garca Martinez y Borrajo, 1998]
in Unknown Environments by Knowledge Sharing. Proceedings of the Seventh European Workshop on Learning Robots. Pginas 22-32. Editado University of Edinburg Press. 1998. [Hayes-Roth, 1983] Hayes-Roth, F. Using Proofs and Refutations to Learn from Experience. En Machine Learning: The Artificial Intelligence Approach Volumen I editado por Carbonell J., Michalski R. & Mitcehll T. Morgan Kaufmann. 1983. [Joseph, 1989] Joseph, R. Graphical knowledge acquisition. En Proceeding of the Fourth Knowledge Acquisition For
Referencias
Pablo M. Maceri
91
Knowledge-Based Systems Workshop, Banff, Canada. 1989. [Knoblock, 1991] Knoblock, C. Automatically Generating Abstractions for Problem Solving. PhD thesis, School of Computer Science, Carnegie Mellon University. 1991 [Lair y otros, 1991] Lair J., Hucka, M., Huffman, S., Rosenbloom, P. An Analysis of Soar as an Integrated Architecture. Lesprance, A Formal Theory of Indexical Knowledge and Action. Technical Report CSRI-248. Computer Systems Research Institute. Universidad de Toronto. Febrero 1991. Y.
[Lesprance, 1991]
[Lin, 1991]
Lin, Long-Ji. Self-improving reactive agents: Case studies or reinforcementlearning frameworks. En: Procedimientos de la International Conference on the Simulation of Adaptive Behavior, 297-305, MIT Press. 1991. Learning Effective Search Control Knowledge: An explanation-Based Aproach. PhD thesis, Computer Science Department, Carnegie Mellon University. 1988. Minton, S.
[Minton, 1988]
[Moravec, 1988]
Moravec, H. Mind Children, The future of robot and human intelligence. Harvard University Press. 1988. Newell, A. The Knowledge Level. Artificial Intelligence, 18:87-127. 1982. Newel, A., Yost, G., Laird, J., Rosenbloom P., & Altmann, E. Formulating the problem space computational model. En R. F. Rashid, editor, Carnegie Mellon Computer Science: A 25 Year Commemorative. ACM Press / Addison-Wesley. 1991.
[Newell, 1982]
[Newel y otros, 1991]
92
Pablo M. Maceri
Referencias
[Rauch-Hindin, 1985]
Rauch-Hindin, W. Artificial Intelligence in Business, Science and Industry. Vol. II. Prentice Hall. EE.UU. 1985.
[Rivest y Schapire, 1987]
Rivest, R. y Schapire, R. A New Approach to Unsupervised Learning in Deterministic Environments. Proceedings of International Workshop on Machine Learning. Pg. 364-375. 1987.
[Rosenbloom y otros, 1991]
Rosenbloom, P., Newel, A., & Laird, J. Towards the knowledge level in Soar: The role of the architecture in the use of knowledge. En K. VanLehn, editor, Architectures for Intelligence. Erlbaum, Hillsdale, NJ. 1991.
[Russel, 1989]
Russel, S. J. Execution architectures and compilation. Procedimientos de IJCAI-89, 15-20. 1989. Shen, W. LIVE: An Architecture for Learning from the Environment. Shen, W. & Simon, H. Rule Cration and Rule Learning Through Environmental Exploration. Proceedings of the Eleventh International Joint Conference on Artificial Intelligence. Pg. 675-680. Morgan Kauffman. 1989.
[Shen, 1991]
[Shen y Simon, 1989]
[Sutton, 1984]
Sutton,
Temporal Credit Assignment in Reinforcement Learning. Ph.D. Dissertation. Graduate School of the University of Massachusetts. 1984.
R.
[Sutton, 1988]
Sutton, R. Learning to Predict by the Method of Temporal Diferences. Machine Learning. Volmen 3. Pg. 9-44. Kluwer Academic Press. 1988.
[Sutton, 1990]
Sutton, R. Integrated Architectures for Learning, Planning, and Reacting Based on Approximating. Proceedings of the Seventh International Conference on Machine Learning. Pg. 216-224. Kaufman. 1990
Referencias
Pablo M. Maceri
93
[Sutton, 1991]
Sutton, R. Dyna, an Integrated Architecture for Learning, Planning, and Reacting. Sutton, R. (Editor) Machice Learning: Special Issue on Reinforcement Learning. Volmen 8. Nmeros . Kluwer Academic Publishers. 1992.
[Sutton, 1992]
[Veloso y Carbonell, 1990]
Veloso, M & Carbonell, J. Integrating analogy into a general problem-solving architecture. En Intelligent Systems. Ellis Horwood Limited, West Sussex, England. 1990.
[Vere, 1978]
Vere, S. Inductive Learning of Realtional Productions. En Pattern-directed Inference Systems editado por Waterman y Hayes-Roth. Academic Press. 1978. Wang, X. Learning Planning Operators by Observation and Practice. Proceedings of the Second International Conference on Artificial Intelligence Planning Systems. Pg. 335-340. 1994.
[Wang, 1994]
[Wang, 1995]
Wang, X. Learning by Observation and Practice: An Incremental Approach for Planning Operator Acquisition. Proceedings of the 12th International Conference on Machine Learning. 1995.
94
Pablo M. Maceri
Referencias
Anexo A
Simulador Khepera versin 2.0
En este anexo se presenta una adaptacin del documento de dominio pblico preparado por Oliver Michel (E-mail: Olivier.Michel@epfl.ch) acerca del manual del usuario del Simulador Khepera versin 2.0 y las preguntas ms frecuentes sobre el mismo. Se da el acuerdo de licencia (seccin A.1), una introduccin (seccin A.2), la explicacin sobre la programacin del simulador (seccin A.3), los reconocimientos (seccin A.4), las referencias del manual (seccin A.5), el apndice sobre la librera de funciones (seccin A.6), el apndice con la estructura de directorios (seccin A.7), el apndice con los comandos seriales del Khepera (seccin A.8), un apndice con el archivo multirobots.h (seccin A.9) y las preguntas ms frecuentes del simulador Khepera (seccin A.9)
A.1. Acuerdo de Licencia

El Simulador Khepera es un software de dominio de distribucin gratuita y pblico escrito por Oliver MICHEL. El autor no puede tener responsabilidad por daos sobre cualquier software o hardware causados por el uso del Simulador Khepera. Use este software bajo su propio riesgo. Se otorga por este medio el permiso de copiar este paquete para su distribucin gratuita. El nombre del autor y su derecho de autor debe ser incluido en cualquier copia. Est prohibido su uso comercial. Si usted publica un artculo, libro, tratado u otro trabajo acadmico basado en experimentos conducidos usando el Simulador Khepera, usted debe citar el Simulador Khepera e incluir la siguiente referencia mencionando la direccin World Wide Web del Simulador Khepera: Oliver Michel. Paquete Simulador Khepera versin 2.0: simulador de robot mvil de distribucin gratuita escrito en la University of Nice Sophia-Antipolis por Oliver Michel. Descargable de la World Wide Web en http://diwww.epfl.ch/lami/team/michel/khep-sim/.
A.2. Introduccin
Este paquete permite escribir algoritmos de control (redes neuronales, sistema clasificador, o cualquier otra cosa que se pueda imaginar) usando lenguajes C o C++. Es provista una librera de funciones que permiten manejar el robot y visualizar los resultados. El simulador corre sobre estaciones de trabajo UNIX y exhibe una bonita y colorida interfase grfica X11. Con este paquetes se dan algunos ejemplos de
Anexo A Manual del usuario Khepera Pablo M. Maceri 95
controladores, incluyendo un controlador de redes neuronales. El simulador tambin presenta la habilidad de manejar un robot Khepera real, por lo tanto se puede fcilmente transferir los resultados del simulador a un robot real pulsando en un botn.
Figura A-1: Simulador Khepera
La pantalla del Simulador Khepera est dividida en dos partes: la parte del mundo se encuentra en la izquierda mientras que la parte del robot se encuentra en la derecha (ver figura A-1). En la parte del mundo, se puede observar el comportamiento del robot en su ambiente y en la parte del robot, se puede observar que est pasando dentro del robot (sensores, motores y controlador). A.2.1. Descripcin del mundo
Figura A-2: dos ejemplos de mundos simulados
En el directorio SIM/WORLD/ se encuentran disponibles varios mundos para el robot.

96 Pablo M. Maceri Anexo A Manual del usuario Khepera
Para cargar uno de ellos se debe presionar el botn load y tipear el nombre del archivo del mundo (sin la extensin .world). Adems es posible editarlos o disear un nuevo mundo presionando el botn new. Situados en el ambiente hay ladrillos, corchos o lmparas resultando en laberintos ms o menos complejos (ver por ejemplo la figura A2). Las dimensiones reales de este ambiente simulado (comparando con el robot Khepera real) son 1m x 1m. Para agregar un objeto, hay que seleccionarlo usando los botones + y -. Para girar un objeto sobre si mismo (para un ladrillo por ejemplo), hay que presionar el botn turn tantas veces como sea necesario. Luego, para colocar el objeto en un lugar del mundo, se debe presionar el botn add y dejar caer el objeto en el mundo, luego hay que soltar el botn add. Si se desea eliminar objetos, hay que presionar el botn remove y pulsar sobre los objetos que se quieran eliminar. Para salir del modo de eliminacin, se debe soltar el botn remove. Una vez que los ladrillos y los corchos hayan sido ubicados, es necesario presionar el botn scan antes de que el robot los pueda percibir. Es posible chequear qu es lo que el robot puede percibir presionando el botn !. A.2.2. Descripcin del robot
Figura A-3: Khepera (5 cm de dimetro) y su equivalente simulado
A.2.2.1. Presentacin El simulador del robot incluye 8 sensores infrarrojos que le permiten detectar por reflexin (pequeos rectngulos) la proximidad de los objetos enfrente de l, detrs de l, y a la derecha y a la izquierda de l. Cada sensor retorna un valor entre 0 y 1023 representado en niveles de colores. 0 significa que ningn objeto es percibido mientras que 1023 significa que un objeto est muy cerca del sensor (casi tocando el sensor). Los valores intermedios pueden dar una idea aproximada de la distancia entre el sensor y el objeto. Estos sensores pueden medir tambin el nivel de luz ambiental (pequeos
tringulos) todo alrededor del robot. Retornan un valor visualizado en niveles de colores cerca de 500 en la oscuridad y cerca de 50 en frente de una fuente de luz. Cada motor puede tomar una velocidad entre 10 y +10. Las flechas rojas sobre los motores indican esta velocidad. A.2.2.2. Modelo del motor El modelo de los motores simulados avanzan en lnea recta: el robot se mueve de acuerdo a la velocidad que el usuario le da. A la amplitud de la velocidad del motor se le agrega un ruido aleatorio del 10% y a la direccin resultado de la diferencia de velocidades de los motores se le agrega un ruido aleatorio del 5% (ver funcin SolveEffectors(...) en el archivo de cdigo fuente robot.h para ms detalles). A.2.2.3. Modelo del sensor Para calcular el valor de salida de la distancia, un sensor simulado explora un conjunto de 15 puntos en un tringulo en frente de l. Se computa un valor de salida como una funcin de presencia (o ausencia) de obstculos en estos puntos. Al valor de salida de la distancia se le agrega un ruido aleatorio correspondiente al 10% de su amplitud (ver la funcin IRSensorDistanceValue(...) en el archivo de cdigo fuente robot.h para ms detalles). A.2.2.4. Operando el Robot Para posicionar el robot en una ubicacin dada en el mundo, se debe presionar el botn set robot (en la parte del mundo) y pulsar en algn lugar del mundo (si es posible no sobre un objeto). El robot tambin puede ser orientado en la direccin que se quiera. Para hacer esto, hay que presionar el botn command y tipear por ejemplo set angle 45, se ver al robot girar hasta alcanzar la posicin de 45 grados. La figura A-3 muestra el robot simulado a una posicin de 90 grados. Si est mirando hacia la derecha (resp. hacia la izquierda), debera estar en 0 grados (resp. a 180 grados). Si se presiona el botn run, sim llamar continuamente a la funcin de control de usuario RobotStep(robot) (escrita en C en el archivo fuente user.c) hasta que run se vuelva a presionar. Si se quiere observar una corrida paso a paso del robot, entonces hay que presionar el botn step y se ejecutar una sola vez la funcin RobotStep(robot). El botn ? permite probar los sensores del robot (especialmente til para el robot real).
98
Pablo M. Maceri
Anexo A Manual del usuario Khepera
A.3. Programacin
A.3.1. Introduccin Esta seccin explica como programar su propio controlador Khepera. Describe los diferentes archivos que se necesitan conocer y comienza con un ejemplo instructivo. En la seccin A.6 se encuentra una lista completa de las estructuras y funciones C necesaria para programar el Simulador Khepera. En la seccin A.7 contiene la estructura de directorio de este paquete. A.3.2. Archivos fuentes del simulador: no modificarlos Los archivos fuente del simulador se encuentran en el directorio SIM/SRC. Ellos no deben ser modificados. Esto es muy importante para futuras actualizaciones del software. Estos fuentes estn escritos en ANSI C. Por lo tanto, si se desea escribir un controlador en C, hay que compilar estos fuentes con un compilador C (gcc c), y si se prefiere C++, tambin se pueden compilar con un compilador C++ (reemplazar gcc c por g++ -c en el archivo makefile), entonces esto ser ms fcil para enlazarlos junto (gcc) con su controlador. A.3.3. Archivos de usuario A.3.3.1. Preferencias: el archivo .simrc El archivo .simrc es un archivo de preferencia respecto a las configuraciones de hardware. Es ledo por el Simulador Khepera cada vez que es ejecutado sim. Est oculto en el directorio /SIM, por lo tanto se debe tipear algo como ls a para verlo. Contiene 3 parmetros importantes que pueden ser editados: KHEPERA_AVAILABLE: puede ser TRUE o FALSE, dependiendo si un robot Khepera real est conectado o no. SERIAL_PORT: es el puerto serial al que est conectado el robot (si est disponible). Puede ser /dev/ttya colocado para el puerto serial A en una estacin de trabajo Sun, pero generalmente depende del tipo de computadora que se use. Este valor es usado slo cuando KHEPERA_AVAILABLE est en TRUE. MONODISPLAY: puede ser TRUE FALSE de acuerdo al tipo de pantalla usada. Ponindolo en TRUE permite correr el Simulador Khepera en una pantalla monocromo.
Cuando se llama a sim, la opcin s permite correr el Simulador Khepera en modo simulacin solamente (no se hace uso de la conexin serial para el Khepera real) a pesar de que KHEPERA_AVAILABLE est en TRUE. A.3.3.2. Archivos fuente del controlador Estos archivos son suyos. Los puede modificar de la forma que quiera. Tambin puede agregar nuevos archivos (y consecuentemente modificar el makefile asociado). Ellos estn en el directorio SIM/USER. En el directorio SIM/EXAMPLES/EXAMPLE0 se encuentra disponible un versin de una controlador bsico vaco. Pero si se quiere construir un controlador propio, se puede empezar con el ejemplo 1 que es el controlador por defecto de este paquete (tambin disponible en el directorio SIM/EXAMPLES/EXAMPLE1). Este ejemplo muestra cmo leer las entradas y cmo escribir las salidas del robot. Implementa un algoritmo de control muy simple. En la siguiente seccin se encuentra en mayor detalle. A.3.3.3. Configuracin de la informacin al usuario Como un programador usuario del Simulador Khepera, usted necesitar un rea para visualizar algunas de sus variables, grficos, explicaciones, etc. Esta rea existe y le permite escribir valores numricos, textos, dibujos, etc. en la pantalla principal del Simulador Khepera. Toda la informacin que puede escribir est dividida en directorios que contiene pginas. Un directorio por defecto de tres pginas contiene una descripcin del Simulador Khepera. Presionando el botn info se puede cambiar entre directorios. Con los botones + o - a lado del botn info se puede cambiar de pgina. Se pueden crear hasta 4 directorios de usuarios, cada uno conteniendo hasta 255 pginas! Para definir esto, se debe editar el archivo user_info.h que se encuentra en el directorio USER. Luego de esto, se deber llenar la funcin DrawUserInfo(struct Robot *robot, char info, char page) donde info es el directorio de informacin y page es la pgina actual de este directorio. Aqu estn las constantes a ser editadas en el archivo de encabezado user_info.h: NUMBER_OF_INFO es el nmero de directorios de informacin al usuario que se desean. Este valor debe estar entre 0 y 4. NUMBER_INFO_x es el nmero de pginas para el directorio nmero x (x entre 1 y 4). Estos valores deben estar entre 0 y 255. TITLE_INFO_x es el ttulo del directorio x (x entre 1 y 4).
100
Pablo M. Maceri
A.3.4. Un ejemplo instructivo A.3.4.2. Prefacio Con el paquete del Simulador Khepera se encuentran cuatro ejemplos. Se encuentran en el directorio SIM/EXAMPLES/EXAMPLEx donde x, entre 0 y 3, es el nmero de ejemplo. El ejemplo 0 no es realmente un ejemplo para un controlador ya que contiene todas las funciones necesarias para correr el Simulador Khepera, pero estas funciones estn vacas, resultando en un controlador vaco. Slo el ejemplo 1 ser explicado en este instructivo. Para todos los ejemplos, se debe leer los archivos readme que se encuentran en los directorios EXAMPLES/EXAMPLEx. Ellos contienen indicaciones sobre la instalacin y compilacin de los ejemplos. Aqu hay una corta descripcin de los ejemplos: Ejemplo 0: el ejemplo de controlador vaco. Ejemplo 1: un ejemplo de un algoritmo de control simple. Ejemplo 2: redes neuronales artificiales y gnuplot. Este ejemplo muestra como implementar redes neuronales artificiales para manejar el robot. Tambin presenta una conexin a la utilidad gnuplot para visualizar grafos (aqu es el camino del robot). Las redes neuronales mostradas aqu son el resultado de un proceso de evolucin usando algoritmos genticos, morfognesis, y metabolismo artificial descripto en [2]. Ejemplo 3: el mdulo multiagente del Simulador Khepera desarrollado por Manuel Clergue permite controlar varios robots Khepera simulados. Ejemplo 4: mdulo del dispositivo serial del Simulador Khepera simulado. Este mdulo es especialmente til si previamente se desarroll un programa que enva comandos seriales a Khepera real a travs de la conexin serial de la computadora. Slo necesita redireccionar las corrientes seriales de entrada y salida al los archivos de enlace del Simulador Khepera y se podr observar el Khepera simulado manejado por los comandos seriales. En la seccin A.8 est disponible una lista de comandos soportados por el Simulador Khepera. A.3.4.2. Vamos a programar un controlador Khepera! Este instructivo muestra la implementacin de un algoritmo de control muy simple inspirado de Braitenberg [1]. Los archivos fuente se encuentran en el directorio EXAMPLES/EXAMPLE1/USER. Primero de todo, vamos a definir nuestro algoritmo
repetir Si el robot no percibe un obstculo, entonces moverse hacia delante. Si se percibe un obstculo a la izquierda del robot, entonces girar hacia la derecha. Si se percibe un obstculo a la derecha del robot, entonces girar hacia la izquierda. Hasta que se detecte algo detrs del robot. Para programar esto en el Simulador Khepera, necesitamos traducir no percibe un obstculo en algo que tenga que ver con los sensores de los robots. Los sensores del robot son legibles a travs de la variable robot (tipo struct robot). El valor correspondiente a la distancia medida del frente del sensor 2 (ver figura A-3) se encuentra almacenado en: robot->IRSensor[2].DistanceValue (tipo int). Los valores se encuentran en un rango entre 0 y 1023. Por lo tanto si este valor excede un umbral dado, digamos 900 (que ser definido en la constante COLLISION_TH), se puede considerar que se ha detectado un obstculo por este sensor. Para manejar los motores del robot, se debe escribir los valores correspondientes a la velocidad de cada motor que queremos aplicar en la variable robot. Estos dos enteros sern escritos en robot->Motor[LEFT].Value y robot->Motor[RIGHT].Value. Ellos estn en el rango entre 10 y +10. Vamos a definir TURN_SPEED y FORWARD_SPEED como constantes en este rango. Todas las operaciones de entrada y de salida deben ocurrir con la funcin del tipo boolean StepRobot(struct Robot *robot). Esta funcin retorna FALSE para detener la corrida del robot y TRUE en caso contrario:
#define FORWARD_SPEED 5 #define TURN_SPEED 4 #define COLLISION_TH 900 /* velocidad de avance normal (baja) */ /* velocidad de giro normal (baja) */ /* valor de los sensores infrarrojos para */ /* ser considerado colisin */
boolean StepRobot(struct Robot *robot) { pas++; DrawStep(); if ((robot->IRSensor[0].DistanceValue > COLLISION_TH) || (robot->IRSensor[1].DistanceValue > COLLISION_TH) || (robot->IRSensor[2].DistanceValue > COLLISION_TH)) /* if there is a collision on the left side of the robot */ { robot->Motor[LEFT].Value = TURN_SPEED;
102 Pablo M. Maceri Anexo A Manual del usuario Khepera
robot->Motor[RIGHT].Value = -TURN_SPEED; /* turn right */ } else if ((robot->IRSensor[3].DistanceValue > COLLISION_TH) || (robot->IRSensor[4].DistanceValue > COLLISION_TH) || (robot->IRSensor[5].DistanceValue > COLLISION_TH)) /* if there is a collision on the right side of the robot */ { robot->Motor[LEFT].Value = -TURN_SPEED; robot->Motor[RIGHT].Value = TURN_SPEED; /* turn left */ } else { robot->Motor[LEFT].Value = FORWARD_SPEED; robot->Motor[RIGHT].Value = FORWARD_SPEED; /* else go forward (default) */ } if ((robot->IRSensor[6].DistanceValue > COLLISION_TH)|| /* collision in */ (robot->IRSensor[7].DistanceValue > COLLISION_TH)) /* the back */ return(FALSE); else return(TRUE); }
Con este cdigo de ejemplo, hemos definido un controlador de robot completo. Correr en un ciclo cuando se presione el botn run o correr una vez cuando se presiones el botn step. Ahora se puede compilar el ejemplo 1 en la computadora. Normalmente, este es el ejemplo instalado por defecto con el paquete, por lo tanto slo se debe tipear make. Esto crear los archivos objeto en el directorio SIM/OBJ/ y producir el archivo ejecutable: sim. Para correr el Simulador Khepera se debe tipear sim. Para mostrar algn texto, valores numricos, o dibujes en el rea de informacin al usuario, hay que ver la funcin DrawUserInfo(...) en el archivo fuente user.c que se encuentra en el directorio SIM/EXAMPLE1/USER. Parece tan simple que no se describir aqu. Se encuentran disponibles muchas funciones grficas para liberar su imaginacin como sea posible (ve apndice A.3 para ms informacin). A.3.5. Paquete multiagente A.3.5.1. Visin general El propsito de esta extensin del Simulador Khepera es operar un grupo de robots en vez de un solo robot. Este grupo de robots es visto por el simulador como una entidad sola, una estructura C (Multirobots). Cada robot de la entidad reacciona de acuerdo a un comportamiento especificado por el usuario. Todos los robots pueden tener el mismo comportamiento o algunos robots pueden tener un comportamiento especfico, como
usted lo necesite. Las acciones de los robots en un determinado momento son calculadas de una manera asincrnica, es decir que los robots se mueven uno despus del otro. Este paquete trabaja solamente con robots simulados. A.3.5.2. Implementacin El cdigo C multiagente puede ser encontrado en los archivos multirobots.c y multirobots.h, situados en el directorio CONTRIB. Estos archivos definen la estructura Multirobots y algunas funciones tiles. Se puede ver el archivo multirobots.h para la descripcin de estas funciones. La estructura est compuesta por tres campos. Un campo para almacenar el nmero de robots del grupo. Este nmero se fija en el momento de la creacin de la estructura y no debera cambiar hasta que se destruya la estructura. Otro campo es un vector de punteros a robots. Estos punteros, dados por una operacin malloc, no deberan cambiar. Por otro lado, las estructuras apuntadas por estos punteros deben cambiar del modo que se quiera, si permanecen como estructuras Robot. El tercer campo es una marca que indica el nmero del robot actual. Las funciones ms importantes son MultiRobotRun y MultiRobotRunFast, que ejecutan un ciclo de movimiento de los robots. Cuando se llaman a estas funciones con una estructura Multirobots, ellas llaman a StepMultiRobots y FastStepMultiRobots para cada robot, cambiando el nmero del robot actual cada vez. Las funciones StepMultiRobots y FastStepMultiRobots reciben una estructura Multirobots como parmetro. Deberan aplicar una funcin parecida a StepRobot en el robot actual. Para tener robots con comportamientos diferentes, slo se debe escribir varias funciones parecidas a StepRobot y llamarlas de acuerdo al robot actual. Se proveen dos versiones que permiten una corrida con visualizacin grfica (MultiRobotRun) y una ms rpida sin dicha visualizacin (MultiRobotRunFast). A.3.5.3. Cmo usarlo? De la misma forma en que se hace con un simulador simple, se debe escribir un archivo user.c, en el que se definen algunas funciones. Adems de las generales (como las del simulador simple), se deben implementar dos funciones especficas:
104
Pablo M. Maceri
boolean FastStepMultiRobots(struct MultiRobots *multi); boolean StepMultiRobots(struct MultiRobots *multi); Para usar una estructura MultiRobots, se la debe crear usando CreateMultiRobots. Esta funcin tiene como parmetro el nmero de robots que se desea en el grupo. Luego, se deben correr los robots usando las funciones MultiRobotRun y MultiRobotRunFast. Estas funciones, que estn definidas en multirobots.c, hacen use de las StepMultiRobots y FastStepMultiRobots comportamiento del robot actual del grupo. funciones para determinar el
Despus de usarla, se debe llamar a FreeMultiRobots para liberar la memoria. Antes de codificar su propia simulacin multiagente, debe animarse a darle un vistazo al ejemplo 3. A.3.5.4. Trabajos futuros La mayor deficiencia de este paquete es la imposibilidad de comandar varios robots reales. Versiones futuras del simulador deberan permitir esta caracterstica. A.3.6. Notas del autor Los modelos de los sensores y los motores son muy simples. Se ha elegido la eficiencia de la computadora en vez de la precisin, haciendo este simulador adecuado para los algoritmos de computadora costosos, especialmente algoritmos genticos. No se manejan problemas de tiempo real en el ejemplo instructivo presentado aqu porque el controlador es muy simple y no necesita ninguna sincronizacin. De todas maneras, es interesante conocer que a una velocidad de 10 (en ambos motores), el robot simulado cubre exactamente 5 milmetros para un paso de simulacin, mientras que el robot real cubre una distancia desconocida (dependiendo de muchos factores incluyendo la velocidad de la computadora, la complejidad del algoritmo de control, la conexin serial, etc.). Esto puede dar idea para construir un sistema teniendo cuidado de los problemas de tiempo real.
A.4. Reconocimientos
He desarrollado este software durante mi Ph-D en el laboratorio i3S con el profesor Jolle Biondi y el profesor asistente Philippe Collard como directores Ph-D (Mage Team).
Manuel Clergue, un estudiante Ph-D estudiando algoritmos genticos y redes neuronales evolutivas en nuestro laboratorio, fue el primer usuario y beta-tester de este software. El tambin desarroll el mdulo multiagentes incluido en el ejemplo 3. Estoy muy agradecido a todas estas personas por su asistencia y algunos consejos valiosos durante el desarrollo de este software. Adems, quisiera felicitar a los diseadores del robot Khepera: Edo Franzi, Andr Guignard y Francesco Mondada (K-Team SA, Preverenges, CH) por su brillante realizacin.
A.5. Referencias
[1] Valentino Braitenberg. Vehicles: Experiments in Synthetic Psychology. MIT Press, Cambridge, 1984. [2] Oliver Michel y Jolle Biondi. Morphogenesis of neural networks. Neural Processing Letters, 2(1), Enero 1995. [3] F. Mondada, E. Franzi, y P. Ienne. Mobile robot miniaturisation: Atool for investigation in control algorithms. En Thisd International Symposium on Experimental Robotics, Kyoto, Japn, Octubre 1993.
106
Pablo M. Maceri
A.6. Apndice: Librera de funciones

A.6.1. Estructuras de datos Usted necesita conocer tres estrucuras C para manejar el robot Khepera que estn definidas en el archivo robot.h en el directorio SIM/SRC/:
struct Motor { double X,Y,Alpha; short int Value; }; struct IRSensor { double X,Y,Alpha; short int DistanceValue; short int LightValue; };
/* velocidad del motor entre 10 y +10 */
/* generalmente entre 0 y 1023 */ /* generalmente entre 0 y 500 */
struct Robot { u_char State; char Name[16]; double X,Y,Alpha; /* X e Y (milmetros), Alpha (radianes) */ double Diameter; /* (milmetros) */ struct Motor Motor[2]; /* usar RIGHT & LEFT en vez de 0 & 1 */ struct IRSensor IRSensor[8]; /* ver robot simulado en la figura 1 */ };
A.6.2. Funciones a completar Estas funciones necesitan ser llenadas para conferir acciones a los botones de la interfase grfica. void NewRobot(struct Robot *robot) Esta funcin es llamada cuando se presiona el botn NEW ROBOT. void LoadRobot(struct Robot *robot,FILE *file) Esta funcin le permite al usuario escribir algunos datos en el archivo del robot, usando las funcin C fprintf(archivo, patrn, datos). Es llamada cuando se presiona el botn LOAD ROBOT. void SaveRobot(struct Robot *robot,FILE *file) Esta funcin permite obtener los datos guardados por la funcin LoadRobot usando la funcin C fscanf(archivo, patrn, datos). Es llamada cuando se
presiona el botn SAVE ROBOT. Ambas funciones deben ser actualizadas de la misma forma (deben cargar y guardar exactamente los mismos datos en el mismo orden). void RunRobotStart(struct Robot *robot) Esta funcin es llamada una vez cuando se presiona del botn RUN ROBOT. boolean StepRobot(struct Robot *robot) Esta funcin es llamada mientras que el botn RUN ROBOT est presionado. void FastStepRobot(struct Robot *robot) Esta funcin es llamada por FastRunRobot(). void RunRobotStop(struct Robot *robot) Esta funcin es llamada cuando es soltado el botn RUN ROBOT. void ResetRobot(struct Robot *robot) Esta funcin es llamada cuando el botn RESET ROBOT es presionado. void UserCommand(struct Robot *robot,char *text) Esta funcin es llamada cuando es presionado el botn COMMAND. El parmetro text que se le pasa es el texto que el usuario tipea en el teclado. Es una forma poderosa de hacer cualquier cosa que uno quiera (fijar parmetros, iniciar varios algoritmos, etc.). void DrawUserInfo(struct Robot *robot,u_char info,u_char page) Esta funcin es llamada cada vez que el programa necesita volver a dibujar la pantalla de la ventana. Debe contener todos los dibujos y los textos para el cuadro de informacin al usuario. void UserInit(struct Robot *robot) Esta funcin es llamada al comienzo del programa. Puede ser utilizada para realizar algunas inicializaciones. void UserClose(struct Robot *robot)
108
Pablo M. Maceri
Esta funcin es llamada al final del programa. Permite cerrar algn archivo eventualmente abierto durante UserInit() o para liberar memoria. A.6.3. Funciones grficas Estas funciones permiten dibujar textos y grficos en el cuadro de informacin al usuario. Las coordenadas (0,0) indican la esquina izquierda superior del cuadro y las coordenadas (500,400) indican la esquina derecha inferior del cuadro. void Color(char color) Fija el color del lpiz. Los colores disponibles son: BLACK, DIM_GREY, GREY_69, GREY, LIGHT_GREY, WHITE, BLUE, BLUE_CYAN, CYAN, CYAN_GREEN, GREEN, GREEN_YELLOW, YELLOW, YELLOW_RED, RED, MAGENTA, LIME_GREEN, BROWN, MAROON, GOLD, AQUAMARINE, FIREBRICK, GOLDENROD, BLUE_VIOLET, CADET_BLUE, CORAL, CORNFLOWER_BLUE, DARK_GREEN, DARK_OLIVE_GREEN, PEACH_PUFF, PAPAYA_WHIP, BISQUE, AZURE, LAVENDER, MISTY_ROSE, MEDIUM_BLUE, NAVY_BLUE, PALE_TURQUOISE y SEA_GREEN. void FillRectangle(int x, int y, int width, int height) Dibuja un rectngulo relleno con el ngulo izquierdo superior en (x,y). void Drawline(int x1, int y1, int x2, int y2) Dibuja una lnea entre (x1,y1) y (x2,y2). void DrawPoint(int x, int y) Dibuja un punto en (x,y). void DrawRectangle(int x, int y, int width, int height) Dibuja un rectngulo vaco con el ngulo izquierdo superior en (x,y). void FillArc(x, y, width, height, angle1, angle2) Dibuja un arco relleno con el ngulo izquierdo superior en (x,y) entre (angle1 / 64) y (angle2 / 64) en grados. void DrawText(int x, int y, char *text) Dibuja un texto en (x,y).
void UndrawText(int x, int y) Desdibuja un texto en (x,y). void WriteComment(char *text) Escribe un comentario en la lnea de comentarios. void EraseComment() Borra el comentario de la lnea de comentarios. void DrawRobot(struct Robot *robot) Redibuja el robot simulado en su ambiente. void ShowUserInfo(int info, int page) Muestra una pgina del cuadro de informacin al usuario. u_char GetUserInfo() Devuelve el nmero de informacin al usuario actual (entre 1 y 4). u_char GetUserInfoPage() Devuelve el nmero de pgina informacin al usuario actual (entre 0 y 255). A.6.4. Otras funciones tiles Estas funciones deberan ser llamadas por la funcin UserCommand() o subfunciones. boolean StopCommand() devuelve TRUE si el botn COMMAND se encuentra liberado. void FastRunRobot(struct Robot *robot) corre el robot simulado sin visualizarlos (rpido). void RunRobot(struct Robot *robot) corre el robot simulado. Devuelve FALSE si el robot es detenido.
110
Pablo M. Maceri
A.7. Apndice: Estructura de directorios

SIM/ CONTRIB/ multirobots.c multirobots.h neural.c neural.h Archivos fuente de contribucin (no modificar)
DOCS/
manual.ps Este manual. ...(archivos fuentes del manual y otras cosas)
EXAMPLES/ EXAMPLE0/
install_example0 makefile readme remove_example0 USER/ user.c user.h user_info.c EXAMPLE1/ ... ... EXAMPLE2/ ... ...
Ejemplo 0: archivos de usuario vacos.
Ejemplo 1: un controlador muy simple. Ejemplo 2: un controlador neuronal. Ejemplo 3: un mdulo multiagente. Ejemplo4: un mdulo serial simulado.
... OBJ/
sim.o user.o el compilador C/C++ genera los archivos aqu. world.o ... (otros archivos objetos producidos durante la instalacin) ... ... ... (archivos robot) graphics.c header.h include.h robot.c robot.h sim.c user_info.c world.c ... (otros archivos fuente) sim graba y carga los robots en este directorio. (ver ejemplo 2 para el uso de este directorio)
ROBOT/
SRC/
archivos fuente, no deben ser modificados!
USER/
user.c user.h user_info.h ... (otros archivos fuente de usuario) maze.world home.world chaos.world ... (archivos world)
estos son sus propios archivos fuente puede modificarlos como quiera.
WORLD\
sim graba y carga mundos en este directorio.
.simrc .makefile .readme
es el archivo de configuracin (especialmente para configuraciones de hardware). su archivo makefile (puede modificarlo como lo necesite). El archivo readme principal.
Pablo M. Maceri
111
A.8 Apndice: Comandos seriales Khepera

A B Configurar (no implementado en el Simulador Khepera) Leer versin del software (no implementado en el Simulador Khepera)
D Fijar velocidad Formato del comando: D, velocidad_motor_izquierdo, velocidad_motor_derecho</n> Formato de la respuesta: d<\n> Efecto: Fijar la velocidad de los dos motores. La unidad es pulso/10 ms que corresponde a 8 milmetros por segundo en el robot real. Leer velocidad E Formato del comando: E</n> Formato de la respuesta: e, velocidad_motor_izquierdo, velocidad_motor_derecho</n> Efecto: Lee la velocidad instantnea de los dos motores. La unidad es pulso/10 ms que corresponde a 8 milmetros por segundo en el robot real. G H Fijar posicin (no implementado en el Simulador Khepera) Leer posicin (no implementado en el Simulador Khepera)
N Leer sensores de proximidad Formato del comando: N</n> Formato de la respuesta: n, val_sens_izq_90, val_sens_izq_45, val_sens_izq_10, val_sens_der_90, val_sens_der_45, val_sens_der_10, val_sens_atras_der, val_sens_atras_izq</n> Efecto: Lee los valores de 10 bit de los 8 sensores de proximidad, desde el sensor frontal situado a la izquierda del robot, girando en sentido horario hasta el sensor trasero izquierdo. O Leer sensores de luz ambiental Formato del comando: O</n> Formato de la respuesta: o, val_sens_izq_90, val_sens_izq_45, val_sens_izq_10, val_sens_der_90, val_sens_der_45, val_sens_der_10, val_sens_atras_der, val_sens_atras_izq</n> Efecto: Lee los valores de 10 bit de los 8 sensores de luz ambiente, desde el sensor frontal situado a la izquierda del robot, girando en sentido horario hasta el sensor trasero izquierdo.
112
Pablo M. Maceri
A.9. Apndice: multirobots.h

/********************************************************************************************/ /* File: multirobots.h (Khepera Simulator) */ /* Author: Manuel CLERGUE <clerguem@alto.unice.fr> */ /* Date: Thu Jan 16 14:39:05 1996 */ /* Description: Extension of Khepera Simulator */ /* for multi-agents simulation */ /* Copyright (c) 1995 */ /* Olivier MICHEL */ /* MAGE team, i3S laboratory, */ /* CNRS, University of Nice - Sophia Antipolis, FRANCE */ /* */ /* Copyright (c) 1996 */ /* Manuel CLERGUE */ /* MAGE team, i3S laboratory, */ /* CNRS, University of Nice - Sophia Antipolis, FRANCE */ /* */ /* Permission is hereby granted to copy this package for free distribution. */ /* The author's name and this copyright notice must be included in any copy. */ /* Commercial use is forbidden. */ /********************************************************************************************/ #ifndef MULTIROBOTS_H #define MULTIROBOTS_H #define D_MAX #define IR_MAX 50.0 /* max. dist. between 2 robots for mutual perc. */ 1023 /* max. value of IR captors */
/* useful external functions */ extern struct Robot *CreateRobot(); extern void DrawLittleRobot(struct Robot *sr,struct Robot *r); extern void ChooseRandomPosition(struct World *world,double *x,double *y, double *alpha); extern u_short IRSensorDistanceValue(struct World *world,short int x,short int y, double alpha); extern u_short IRSensorLightValue(struct World *world,short int x,short int y, double alpha); extern void RefreshWindow(struct Context *context); extern void DrawWorldSquare(struct World *world); extern void InitSensors(struct Context *context); extern void SolveEffectors(struct Context *context); extern boolean TestCollision(struct Context *context,double ox,double oy, double oalpha); /* The MultiRobots structure manage the use of several robots */ /* Some services are provided with this structure */ /* It is highly recommended to use them (or to create others) */ /* instead of using those of the Robot structure */ struct MultiRobots { struct Robot **robots; /* Array of pointers to Robot */ short int current; /* Current Robot being treated -- use this carefully */ short int number; /* Number of Robots in the structure */ }; /* CreateMultiRobots create and initialyze the structure with number Robots */ struct MultiRobots *CreateMultiRobots(long int number);
/* Free the structure and the Robots */ void FreeMultiRobots(struct MultiRobots *multirobots); /* Calculate the influence of the group on the current Robot's captor (xc,yc,alpha) */ /* Used in MultiInitSensors */ short int MutualInfluence(short int xc,short int yc,double alpha, short int value,struct MultiRobots *multirobots); /* Calculate the value of IR-Distance captors of the Robots in the structure */ /* Used in MultiRobotRunFast */ void MultiInitSensors(struct Context *context,struct MultiRobots *multirobots); /* This is the most useful service. This is THE one you have to use in standart situations */ /* There is two version (Fast and Normal) */ /* The fast one (without the display of robots on the screen) use /* FastStepMultiRobots(MultiRobots *multirobots)*/ /* The other one use StepMultiRobots(MultiRobots *multirobots) */ /* You have to implement these functions in the same way that you have to do it /* for one robot */ void MultiRobotRunFast(struct Context *context,struct MultiRobots *multirobots); void MultiRobotRun(struct Context *context,struct MultiRobots *multirobots); /* nothing important */ double DistanceBetRobots(struct Robot *rob1,struct Robot *rob2); /* This service allow you to place the robots at random place in the world */ void PlaceRobots(struct Context *context,struct MultiRobots *multirobots); /* The functions you have to implement */ extern boolean FastStepMultiRobots(struct MultiRobots *multi); extern boolean StepMultiRobots(struct MultiRobots *multi); #endif
114
Pablo M. Maceri
A.10. Preguntas ms frecuentes del Simulador Khepera

A.10.1. Descargando 1) Vi el archivo tar comprimido que aparece en mi ventana... Ningn problema, elegir Guardar como en el men Archivo y tipear SIM2.tar.gz como un nombre de archivo. A.10.2. Compilando 1) Muchos problemas con el archivo khep_serial.h: tipos de datos y constantes indefinidos. Si no usa el simulador con un robot Khepera real conectado, elimine las funciones en SIM/SRC/khep_serial.c que no estn declaradas como extern y reemplace las funciones externas por funciones externas vacas. Si tiene conectado un Khepera real y tiene problemas con las constantes FLUSHHO y PENDIN, pruebe eliminar estas dos constantes (FLUSHO|PENDIN): no estoy seguro si son muy tiles. O trate de definirlas... Aqu estn las definiciones que tengo en mi /usr/include/termios.h: #define FLUSHO #define PENDIN 0x00800000 0x20000000 /* salida que se est copiando (estado) */ /* vuelve a tipear la entrada pendiente (estado) */
2) Problemas de inclusin de archivos mientras se compila y/o problemas de libreras mientras se hace el linking en mi computadora x Si no puede arreglar estos problemas, por favor pregntele a su ingeniero de sistemas o a algn experto para hace la instalacin del Simulador Khepera. 3) Tengo la versin Solaris del simulador y cuando use los ejemplos obtuve: gcc -L/usr/lib -lX11 -lm OBJ/sim.o OBJ/robot.o OBJ/world.o OBJ/graphics.o OBJ/khep_serial.o OBJ/user.o -o sim Undefined symbol first referenced in file
Pablo M. Maceri 115
socket getpeername xdrmem_create gethostbyname setsockopt getservbyname authdes_create inet_addr shutdown getsockname
/usr/lib/libX11.so /usr/lib/libX11.so /usr/lib/libX11.so /usr/lib/libX11.so /usr/lib/libX11.so /usr/lib/libX11.so /usr/lib/libX11.so /usr/lib/libX11.so /usr/lib/libX11.so /usr/lib/libX11.so
connect /usr/lib/libX11.so ld: fatal: Symbol referencing errors. No output written to sim make: *** [sim] Error 1 Agregu en LIBS: -lsocket... y funcion! (gracias a Andrs Perez)
A.10.3. Corriendo 1) El robot salta por todos lados y hasta desaparece o se va fuera del mundo. Es esto normal? El problema se debe a la definicin de la constante RAND_MAX que afecta a la funcin Rnd() en SIM/SRC/sim.c. Este problema no ocurre en todos los sistemas, slo en aquellos donde las constante RAND_MAX no est definida en el archivo de inclusin stdlib.h. Hay dos posibilidades para corregir este problema: a) Encontrar el archivo de inclusin correcto que contiene una definicin como esta: #ifdef _BSD #define RAND_MAX #else #define RAND_MAX #endif b) reemplazar 0x8000 por 2147483648 en SIM/SRC/sim.c (lnea 23) 32767 /* max value returned by rand */
2147483647
/* max value returned by rand */
116
Pablo M. Maceri
2) Cuando trato de correr sim (sim &), obtengo esto: unable to find .simrc in current directory: No such file or directory Dnde est dicho archivo? Sim debe ser compilado y llamado desde el directorio SIM/. Este directorio generalmente contiene un archivo llamado .simrc y un directorio llamado WORLD/. 3) No puede correr el cdigo en una estacin usando X11R4. El programa termina con el siguiente mensaje: X Error: BadName - font or color name does not exist Request Major code 45 () Error Serial #43 Current Serial #55 El problema descripto en la librera X11R4 viene de un recurso de fuente o color que no est definido o disponible en esta edicin. Para corregir esto, debera chequear el nombre de los colores y de las fuentes usadas en el archivo SIM/SRC/graphics.c y verificar si existen en su manual de usuario de X11R4. Si encuentra un nombre de color o de una fuente que no existe, entonces cmbielo por un color parecido a l que exista (ejemplo: lime_green - dark_green). 4) El robot real se comporta diferente al robot simulado, parece que el modelo del sensor no contiene suficiente ruido... La versin 2.0 del Simulador Khepera mejor el modelo del sensor en el sentido que los sensores tienen ms ruido que en la versin 1.0, por lo tanto son ms parecidos a los sensores reales. Yo not una buena transferencia de mis modelos simulados al robot real. De todas maneras, si quiere modificar el modelo del sensor (y agregarle ms ruido) puede mirar el cdigo y tratar de cambiar algunos valores en el archivo robot.c: en la funcin IRSensorDistanceValue(...), cambie la lnea value = (u_short)(value * (0.90 + (double)(Rnd(2000))/10000.0)); correspondiente al 10% de ruido por value = (u_short)(value * (0.80 + (double)(Rnd(4000))/10000.0)); correspondiente al 20% de ruido por
Pablo M. Maceri
117
Pero puede ser que el problema no provenga del modelo del sensor sino del tiempo de comunicacin entre el robot y la computadora: para un paso el robot simulado se muevo 5 mm a una velocidad de 10 mientras que el robot real se mueve una distancia desconocida dependiendo del tiempo de comunicacin de la conexin serial... A.10.4. Comprendiendo 1) Me podra contar ms sobre el modelo del sensor? Cada sensor barre un conjunto de 15 puntos enfrente de l. Las coordenadas de estos puntos relativas a la posicin sensor y su orientacin se encuentra en los vectores sx[] y sy[]. Los valores asociados a cada punto estn en el vector v[]:
. _ . . | | . . . | |. . . |_| . . . sensor . . .
(posicin aproximada de los puntos)
Si bajo un punto dado se encuentra un obstculo, el valor asociado a ese punto es agregado a una suma. Esta suma es el valor que retorna el sensor. De hecho es un bit ms complejo ya que los puntos enfrente del sensor estn divididos en tres reas (adelante, izquierda y derecha). Cada rea i es barrida desde el sensor hasta afuera enfrente de l, el valor del primero punto encontrado en cada rea es guardado en el vector b[i]. Luego, la suma de los valores guardados en b[i] se computan. A esta suma se le agrega ruido antes de devolverlo como el valor que retorna este sensor de distancia. Entonces, como los puntos son discretos y tienen valores fijos, el modelo es bastante grosero (discontinuidades). Para mejorarlo, se pueden usar 30 puntos en vez de 15 y ms de tres reas. Pero este sera ms costoso en clculos computacionales... 2) Me podra contar ms sobre el modelo del mundo? World-Image[16][500] es un mapa de bits binario del ambiente del robot. Est formado por reales positivos (unsigned longs), por lo tanto cada uno se representa por 32 bits. Por ello corresponde a una matriz de binarios de (16x32) x 500 = 512 x 500 en la que 1 representa la presencia de un obstculo y 0 la ausencia de un obstculo. Nota: slo se utiliza un mapa de 500 x 500, los 12 bits de la izquierda son ignorados.
118
Pablo M. Maceri
Si se quiere obtener el estado del punto X(117,253), se debe leer el valor de (WorldImage[117/32][253] & (1 << (117%32))). Si este valor es null, entonces no hay ningn obstculo presente en (117,253). Si es distinto a cero, entonces hay un obstculo en esa posicin.
Pablo M. Maceri
119
Anexo B
Escenarios
En esta anexo se presentan los distintos escenarios seleccionados para realizar los experimentos descriptos en el captulo 5. En general, se han elegido escenarios que poseen gran riqueza de obstculos y fuentes de luz ya que el sistema presenta mejor comportamiento en ambientes densos que en ambientes esparcidos. Esto puede ser explicado por el hecho que los entornos densos le proveen ms informacin al sistema con respecto a diferentes tipos de entradas sensoriales, lo que le permite aprender mejores modelos.
Figura B-1: Escenario 1
Anexo B - Escenarios
Pablo M. Maceri
121
El escenario 1 es simtrico (figura B-1), est dividido en cuatro mundos idnticos. Esto permite que el espacio de exploracin del robot sea ms limitado. Adems, estos mundos presentan un bajo nivel de densidad de obstculos y su objetivo principal es que el robot aprenda a moverse en pasillos donde el nivel de luminosidad es elevado.
El escenario 2 que se muestra en la figura B-2 es similar al escenario 1 (figura B-1) pero presenta un nivel de simetra superior. Est dividido en seis mundos idnticos y tambin puede considerarse como un escenario de aprendizaje donde el robot puede moverse por pasillos con un alto nivel de luz.
122
Pablo M. Maceri
En la figura B-3 se muestra un escenario con una complejidad mayor. No presenta simetras, hay mayor densidad de obstculos y el robot puede encontrar un mayor campo de exploracin. Este escenario posee tanto zonas de aprendizaje como reas donde el o los robots pueden aplicar su experiencia.
Pablo M. Maceri
123
El escenario 4 presenta una complejidad an mayor que el de la figura B-3. La distribucin de obstculos es menos ordenada. Este escenario puede ser til para que un robot aplique su conocimiento acumulado en este u otros mundos simulados.
124
Pablo M. Maceri
En el grfico B-5 se presenta un escenario dividido en cinco mundos idnticos. Posee una gran cantidad de pasillos donde algunos se encuentran con un alto nivel de luz y otros con un nivel muy bajo.
Pablo M. Maceri
125
El escenario 6 es el que presenta el mayor nivel de simetra ya que est dividido en ocho mundos idnticos. Estos mundos son muy simples ya que solo presentan un pasillo con un nivel de luminosidad muy alto.
126
Pablo M. Maceri
El escenario 7 tambin presenta un cierto grado de simetra aunque no est dividido. Contiene una densidad alta de obstculos y una luminosidad elevada en casi todas las reas. Presenta pasillos y caminos sin salida con gran cantidad de luz.
Pablo M. Maceri
127
El ltimo escenario, mostrado en la figura B-8, est dividido en seis mundos muy simples con un solo pasillo que presenta una gran cantidad de fuentes de luz. Este escenario puede servir para entrenar a un robot por su bajo nivel de complejidad y alta simetra.
128
Pablo M. Maceri
Anexo C
Datos Experimentales
En este anexo se muestran los datos obtenidos durante la ejecucin del diseo experimental. Para cada experiencia realizada se presenta la matriz promedio obtenida de realizar 50 experimentos. Las matrices promedio son siete que corresponden al promedio de los siguientes experimentos: a) utilizando solamente el mtodo de mutacin de teoras, b) utilizar solamente el mtodo de ponderacin de planes, c) utilizar solamente el mtodo de intercambio de operadores, d) utilizar la combinacin de los mtodos de mutacin y ponderacin, e) utilizar la combinacin de los mtodos de mutacin e intercambio, f) utilizar la combinacin de los mtodos de ponderacin e intercambio y g) utilizar la combinacin de los mtodos de mutacin, ponderacin e intercambio. Cada matriz tiene 25 filas que corresponde al muestreo del estado del sistema cada 20 ciclos, siendo la mxima cantidad de ciclos 500. Las columnas de las matrices son las siguientes: ciclo del muestreo, cantidad de situaciones, cantidad de teoras, cantidad de veces que se utiliz azar como heurstica de contingencia, cantidad de planes aplicados, cantidad de planes que finalizaron sin xito (es decir que algunas de sus acciones no llevaron a la situacin esperada) y cantidad de planes exitosos (parcial o completamente exitosos). Promedio de 50 experimentos utilizando slo el mtodo de mutacin de teoras
ciclos 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300 situaciones 5.30 7.77 9.17 10.30 11.13 11.53 12.43 13.13 13.40 13.80 14.30 14.60 14.77 15.10 15.33 teoras 9.17 15.10 18.90 21.73 24.03 25.57 27.97 29.70 30.87 32.03 33.57 34.63 35.30 36.43 37.27 azares 18.17 31.73 41.20 46.90 53.13 58.00 63.17 66.87 69.83 72.87 76.10 79.07 81.87 84.77 86.47
Pablo M. Maceri
planes 1.57 6.73 15.17 26.77 37.73 50.13 62.40 76.47 90.87 105.33 119.57 134.27 149.43 164.83 181.13
planes sin xito 1.17 5.17 12.07 21.83 31.20 42.27 53.20 65.80 78.87 92.57 105.57 119.10 133.23 147.67 163.03
planes con xito 0.24 1.21 2.76 4.50 6.30 7.90 9.44 11.00 12.55 13.75 15.20 16.65 17.84 19.00 20.16
129
Anexo C - Datos Experimentales
320 340 360 380 400 420 440 460 480 500
15.43 15.47 15.47 15.57 15.63 15.63 15.67 15.80 16.03 16.07
37.67 37.83 37.83 38.10 38.43 38.50 38.63 38.93 39.53 39.67
88.07 89.20 90.20 91.60 93.23 94.47 95.83 97.97 99.23 100.83
197.73 214.83 231.70 248.47 265.20 282.13 298.73 314.60 331.40 347.87
178.80 195.03 211.03 227.03 242.93 259.00 274.70 289.53 305.70 321.60
21.23 22.25 23.44 24.47 25.48 26.56 27.72 28.97 29.90 30.82
Promedio de 50 experimentos utilizando slo el mtodo de ponderacin de planes

ciclos 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300 320 340 360 380 400 420 440 460 480 500 situaciones 4.77 7.40 9.00 10.23 11.53 12.67 13.93 15.23 16.63 17.67 18.57 19.53 20.30 21.00 21.80 22.37 23.17 23.83 24.17 24.63 25.27 25.67 25.83 26.20 26.63 teoras 8.97 15.73 21.53 26.20 30.90 35.47 39.90 44.63 48.77 52.50 55.97 59.40 62.77 65.77 68.50 71.33 73.93 76.77 78.70 80.90 83.60 85.93 87.40 88.90 90.80 azares 19.60 38.80 58.37 77.80 96.97 116.43 135.40 155.30 174.77 193.93 213.50 233.27 252.93 272.77 292.70 312.63 332.53 351.73 371.17 390.87 410.43 429.57 448.93 468.93 488.93 planes 0.30 0.93 1.27 1.63 2.20 2.67 3.53 3.63 4.00 4.77 5.17 5.30 5.57 5.70 5.73 5.77 5.87 6.47 6.87 7.07 7.40 8.03 8.47 8.47 8.47 planes sin xito 0.17 0.57 0.90 1.00 1.33 1.73 2.50 2.60 2.90 3.57 3.93 3.97 4.20 4.30 4.30 4.30 4.33 4.77 5.03 5.13 5.30 5.73 6.00 6.00 6.00 planes con xito 0.10 0.27 0.37 0.57 0.83 0.90 1.04 1.04 1.13 1.20 1.23 1.33 1.40 1.43 1.47 1.47 1.50 1.67 1.87 1.97 2.07 2.30 2.50 2.50 2.50
Promedio de 50 experimentos utilizando slo el mtodo de intercambio de operadores

ciclos 20 40 60 80 100 120 140
130
situaciones 5.27 11.70 13.77 15.90 16.63 17.30 18.07
teoras 8.93 22.87 29.47 35.57 38.67 41.17 43.57
azares 18.17 28.47 33.63 38.10 41.67 45.10 47.47

Pablo M. Maceri
planes 1.33 9.73 22.43 35.57 49.77 64.13 79.60
planes sin xito 0.70 7.77 19.50 31.30 44.50 57.67 72.23
planes con xito 0.50 1.43 2.61 4.03 5.41 6.80 7.94
160 180 200 220 240 260 280 300 320 340 360 380 400 420 440 460 480 500
18.53 19.03 19.23 19.30 19.67 19.97 20.20 20.37 20.67 20.83 20.87 20.87 21.07 21.17 21.30 21.37 21.40 21.57
45.67 47.47 48.30 48.90 50.20 51.30 52.23 52.93 53.97 54.87 55.03 55.47 56.03 56.47 56.70 56.97 57.13 57.63
49.03 50.33 51.73 52.97 54.73 56.57 58.23 60.00 61.40 62.97 64.37 65.60 66.97 68.30 69.67 71.03 72.47 74.50
95.73 111.87 128.43 144.93 161.37 177.80 193.97 210.10 226.37 243.20 259.87 277.10 294.20 311.30 328.73 346.20 363.50 380.13
87.70 102.83 118.57 134.37 150.33 166.17 181.27 196.50 211.87 228.10 244.10 260.53 277.17 293.83 310.77 327.73 344.57 360.77
8.95 10.36 11.35 12.45 13.23 14.08 15.37 16.56 17.79 18.44 19.40 20.33 21.00 21.62 22.24 22.88 23.48 24.06
Promedio de 50 experimentos utilizando la combinacin de los mtodos de mutacin de teoras y ponderacin de planes
Pablo M. Maceri
131
Promedio de 50 experimentos utilizando la combinacin de los mtodos de mutacin de teoras e intercambio de operadores
Promedio de 50 experimentos utilizando la combinacin de los mtodos de ponderacin de planes e intercambio de operadores
ciclos 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300 320
132
situaciones 5.30 11.83 15.47 17.87 19.50 21.30 23.13 25.30 27.07 28.23 29.23 30.33 31.30 31.97 33.10 33.90
teoras 9.97 24.53 36.17 46.03 53.90 61.60 68.77 76.83 84.40 89.87 95.40 100.40 105.97 110.00 115.03 119.27
azares 19.93 38.97 57.50 76.17 94.87 113.60 132.70 152.27 171.97 191.80 211.27 230.57 250.53 270.33 289.87 309.07
Pablo M. Maceri
planes 0.07 0.83 1.93 2.70 3.70 4.77 5.50 5.93 6.17 6.30 6.73 7.27 7.30 7.50 7.87 8.53
planes sin xito 0.07 0.60 1.27 1.47 2.17 3.07 3.67 4.13 4.30 4.37 4.70 5.10 5.13 5.30 5.53 6.10
planes con xito 0.00 0.17 0.57 1.13 1.43 1.63 1.80 1.80 1.87 1.90 2.00 2.17 2.17 2.17 2.27 2.40
340 360 380 400 420 440 460 480 500
35.07 35.97 36.73 37.60 38.30 38.87 39.33 39.87 40.10
123.97 128.80 132.83 137.60 140.57 143.63 146.70 149.83 151.67
328.47 348.00 367.60 387.43 407.33 427.23 447.03 466.93 486.93
8.97 9.40 9.73 9.90 9.97 10.07 10.23 10.33 10.33
6.40 6.80 7.07 7.20 7.27 7.33 7.50 7.60 7.60
2.57 2.60 2.67 2.67 2.70 2.70 2.73 2.73 2.73
Promedio de 50 experimentos utilizando la combinacin de los mtodos de mutacin de teoras, ponderacin de planes e intercambio de operadores
Pablo M. Maceri
133
Anexo D
Documentacin del Sistema
En este anexo se presenta la documentacin del sistema. Se da una introduccin (seccin D.1), se explica la descarga y compilacin del simulador Khepera (seccin D.2), se da una explicacin sobre la instalacin de los archivos fuentes del sistema inteligente autnomo (seccin D.3), se explica la integracin del SIA al Khepera (seccin D.4), se da una explicacin de los archivos fuente (seccin D.5), se presenta el esquema de interaccin de los mdulos (seccin D.6), se explican los diagramas de estructura del sistema implementado (seccin D.7), se dan los comandos implementados (seccin D.8), se explican las estructuras de datos utilizadas (seccin D.9) y se presenta el formato de los archivos de estadsticas (seccin D.10).
D.1. Introduccin
El sistema inteligente autnomo se ha implementado sobre la plataforma de simulacin Khepera 2.0. Este simulador es un software que opera sobre un sistema operativo del tipo UNIX con la librera de interfase grfica X11. El Simulador Khepera es un paquete de distribucin gratuita que permite desarrollar controladores para el robot mvil Khepera usando los lenguajes de programacin C o C++. Incluye un editor del ambiente y una interfase grfica para el usuario. Adems, si se cuenta con un robot Khepera, permite fcilmente intercambiar entre el robot simulado y el real. Este software est principalmente destinado para la enseanza y la investigacin sobre agentes autnomos.
D.2. Descarga y compilacin del Khepera

El Simulador Khepera 2.0, de distribucin gratuita, se puede bajar de Internet en http://diwww.epfl.ch/lami/team/michel/khep-sim/. El paquete viene comprimido, generalmente con el nombre SIM2.tar.gz, el cual al descomprimirse crea la siguiente estructura de directorios:
Anexo D - Documentacin
Pablo M. Maceri
135
SIM/ CONTRIB/ DOCS/ EXAMPLES/ ROBOT/ SRC/ USER/ WORLD/ El contenido de cada directorio se puede encontrar explicado en el manual del Khepera (Anexo A). El simulador se debe compilar mediante el comando make desde el directorio raz. Este comando de UNIX utiliza el archivo makefile que contiene todas las directivas o instrucciones necesarias para la compilacin del simulador, resultando en un archivo ejecutable llamado sim que se lo debe ejecutar desde una consola de la interfase grfica X11.
D.3. Instalacin de los archivos fuente del SIA

El sistema inteligente autnomo desarrollado para esta tesis se encuentra distribuido en varios archivos fuentes. Para su instalacin se debe agregar un directorio llamado sia en el cual debern ir los siguientes archivos: aprendizaje.c controlador.c data.c intercambio.c planificador.c ponderador.c sia.c sia.h
136
Pablo M. Maceri
D.3.1. Modificacin del archivo makefile El archivo makefile ha sido modificado de la versin original (figura D-1) que viene con el paquete del Khepera con los siguientes objetivos: a) adaptarlo al sistema operativo utilizado (Linux Red Hat 6.2) y b) integrar el paquete que permite la simulacin multirobot.
#File: Makefile for Khepera Simulator (example 1) #Author: Olivier MICHEL <om@alto.unice.fr> #Date: Tue Feb 13 11:29:50 MET 1996 # # # # # # # # Copyright (c) 1995, 1996 Olivier MICHEL MAGE team, i3S laboratory, CNRS, University of Nice - Sophia Antipolis Permission is hereby granted to copy all or any part of this program for free distribution. The author's name and this copyright notice must be included in any copy. Commercial use is forbidden.
VPATH=OBJ/:SRC/:USER/ CFLAGS = -I/usr/include \ -O3 LIBS = -L/usr/lib -lX11 -lm cc = gcc $(CFLAGS) -c CC = gcc $(LIBS) sim: sim.o robot.o world.o graphics.o khep_serial.o user.o $(CC) OBJ/sim.o OBJ/robot.o OBJ/world.o OBJ/graphics.o OBJ/user.o -o sim sim.o: sim.c sim.h $(cc) SRC/sim.c -o OBJ/sim.o robot.o: robot.c robot.h $(cc) SRC/robot.c -o OBJ/robot.o world.o: world.c world.h $(cc) SRC/world.c -o OBJ/world.o graphics.o: graphics.c graphics.h $(cc) SRC/graphics.c -o OBJ/graphics.o khep_serial.o: khep_serial.c khep_serial.h gen_types.h $(cc) SRC/khep_serial.c -o OBJ/khep_serial.o user.o: user.c user.h user_info.h include.h $(cc) USER/user.c -o OBJ/user.o header.h: types.h graphics.h sim.h robot.h world.h touch SRC/header.h clean: rm -f sim OBJ/*.o Figura D-1: versin original del makefile OBJ/khep_serial.o
Pablo M. Maceri
137
D.3.1.1. Adaptacin al sistema operativo utilizado Debido a que los sistemas del tipo UNIX pueden diferir unos de otros en su estructura de directorios, su forma de instalacin y otras caractersticas, el archivo makefile debe ser adaptado de acuerdo a la configuracin del sistema operativo instalado. Para el desarrollo del sistema y su posterior utilizacin se utiliz el sistema operativo Red Hat Linux 6.2 (Kernel 2.2.14-5.0) y la librera Xfree86 3.3.6. Para este tipo de configuracin se debi cambiar en el archivo makefile la ubicacin de las libreras utilizadas por el compilador y se elimin la lnea donde se define la constante VPATH, ya que los directorios donde residen los archivos se especifican de manera explcita. Tambin y debido a que los sistemas UNIX son sensibles a maysculas y minsculas se pasaron a minsculas todas las referencias a directorios para que se pueda interpretar la estructura de directorios que gener la descompresin del paquete. D.3.1.2. Integracin del paquete multirobot El simulador viene con un paquete que permite utilizar la plataforma para la simulacin de varios robots al mismo tiempo. Para poder disponer de este paquete, que se encuentra en el directorio contrib, se agregaron las referencias necesarias en el archivo makefile para que en la compilacin se vinculen los archivos multirobots.c y multirobots.h. En la figura D-2 se muestra el contenido del archivo makefile modificado de acuerdo a los puntos D.3.1.1 y D.3.1.2.
138
Pablo M. Maceri
#File: Makefile for Khepera Simulator (example 1) #Author: Olivier MICHEL <om@alto.unice.fr> #Date: Tue Feb 13 11:29:50 MET 1996 #Modificado: Pablo Maceri <pmaceri@fi.uba.ar> , 21/05/2000 # # # # # # # # Copyright (c) 1995, 1996 Olivier MICHEL MAGE team, i3S laboratory, CNRS, University of Nice - Sophia Antipolis Permission is hereby granted to copy all or any part of this program for free distribution. The author's name and this copyright notice must be included in any copy. Commercial use is forbidden.
CFLAGS= -l/usr/include LIBS = -L/usr/X11R6/lib -lX11 -lm cc = gcc $(CFLAGS) -c CC = gcc $(LIBS) sim: makefile sim.o robot.o world.o graphics.o khep_serial.o user.o multirobots.o $(CC) obj/sim.o obj/robot.o obj/world.o obj/graphics.o obj/khep_serial.o obj/user.o obj/multirobots.o -o sim sim.o: src/sim.c src/sim.h $(cc) src/sim.c -o obj/sim.o
multirobots.o: contrib/multirobots.c contrib/multirobots.h $(cc) contrib/multirobots.c -o obj/multirobots.o robot.o: src/robot.c src/robot.h $(cc) src/robot.c -o obj/robot.o world.o: src/world.c src/world.h $(cc) src/world.c -o obj/world.o graphics.o: src/graphics.c src/graphics.h $(cc) src/graphics.c -o obj/graphics.o khep_serial.o: src/khep_serial.c src/khep_serial.h src/gen_types.h $(cc) src/khep_serial.c -o obj/khep_serial.o user.o: user/user.c user/user.h user/user_info.h src/include.h $(cc) user/user.c -o obj/user.o
header.h: src/types.h src/graphics.h src/sim.h src/robot.h src/world.h touch src/header.c clean: rm -f sim obj/*.o Figura D-2: versin modificada del makefile
Pablo M. Maceri
139
D.4. Integracin del SIA al Khepera

En el directorio user se encuentran los archivos fuentes que sirven de interfase y donde el simulador provee una serie de procedimientos a ser definidos por el programador para actuar sobre el robot. La integracin con la plataforma Khepera se realiza a travs del archivo user.c. Este archivo provee los procedimientos de enlace con el simulador. Es a travs de estos procedimientos que el programador tiene la libertad de redefinirlos o modificarlos para asignarle la funcionalidad correspondiente que permitan definir las acciones que el robot ejecutar. En la figura D-3 se muestra un esquema donde se representan los distintos archivos y como se encuentran enlazados entre ellos dentro del cdigo.
DATA.C
APRENDIZAJE.C
CONTROLADOR.C
USER.C Khepera (archivos fuente)
SIA.C
PLANIFICADOR.C
PONDERADOR.C
USER_INFO .H
USER.H
SIA.H
INTERCAMBIO.C
Figura D-3: relaciones entre los archivos del sistema
Este esquema indica la manera en que estn incluidos los distintos archivos fuente. De esta forma los mdulos de aprendizaje, controlador, planificador, ponderador e intercambio se incluyen dentro del mdulo general del sia (sia.c), ste incluye el archivo de definicin de estructuras (sia.h). Luego desde el archivo user.c se incluye el sia.c y el data.c, el cual es un pequeo modulo en el que se desarrollaron los procedimientos necesarios para que el sistema pueda almacenar en disco las teoras y situaciones aprendidas en una simulacin y luego poder ser reutilizadas en otra.
140
Pablo M. Maceri
D.5. Descripcin de los archivos fuente

D.5.1. Archivos fuente del Khepera Estos son los archivos provistos por la plataforma Khepera que residen en el directorio src y no deben ser modificados por el programador. D.5.2. Archivos porvistos para manejo del Khepera y modificados para este trabajo D.5.2.1. Archivo user.c Este es el archivo provisto por Khepera que sirve como interfase entre la plataforma y el programador. Debe ser modificado para adaptar al sistema de acuerdo al comportamiento que se quiera tener del robot. En este archivo fuente, adems de modificar los procedimientos necesarios para el funcionamiento del sistema inteligente autnomo, se definieron las variables utilizadas en el sistema. Estas son todas la variables que contienen las estructuras que necesita un robot para llevar adelante todo el proceso de aprendizaje, planificacin y control de planes en ejecucin. Las estructuras ms importantes, son las listas de situaciones y teoras, la pila de situaciones deseables, el rbol de situaciones, la lista de planes, etc. Las variables definidas son aquellas que mantienen el estado del sistema, como la situacin actual, la situacin anterior, la accin aplicada y los seteos del mismo (por ejemplo si el sistema debe usar mutacin de teoras en el aprendizaje, si debe utilizar el mdulo ponderador de planes o si debe utilizar el mdulo de intercambio de operadores, entre otros). El procedimiento StepRobot( ), que recibe como parmetro la estructura del robot, es en el que deben ocurrir todas las operaciones de entrada y salida. Es una funcin del tipo boolean que retorna false para detener la ejecucin del robot y true en caso contrario. Este procedimiento representa un ciclo de robot, es decir que es ejecutada para realizar todas las operaciones necesarias que deberan transcurrir desde la lectura de los sensores hasta la aplicacin de una accin en el entorno simulado. Por lo tanto si se quiere agregar cierta inteligencia al comportamiento del robot es dentro de este procedimiento donde se debe realizar cualquier tipo de operacin. Este procedimiento implementa un ciclo de robot del algoritmo de alto nivel presentado en la seccin 4.3 del captulo 4 donde en lneas generales realiza los siguientes pasos:
Pablo M. Maceri
141
1. LeerSensores( ) 2. RegistrarTeora( ) 3. controlador( ) 4. proximaaccin( ) 5. situacin anterior = situacin actual Entonces, un ciclo del robot comienza al leer los sensores para percibir la situacin obtenida al aplicar una accin a la situacin anterior. Luego, con estos datos llama a la funcin RegistrarTeora( ) que implementa el algoritmo de aprendizaje visto en la seccin 4.7. Despus de esto, es el controlador( ) quin se encarga de llamar al planificador( ), si es necesario, para que ste arme un plan y lo pondere mediante el ponderador( ). Estos algoritmos fueron vistos en las secciones 4.10, 4.8 y 4.9 respectivamente. Por ltimo, se selecciona la proximaaccin( ) a ejecutar y la situacin actual pasa a ser la situacin actual para poder volver a empezar el ciclo. La funcin proximaaccin( ) toma la siguiente accin del plan en ejecucin y prepara al robot para que esta accin sea ejecutada por el sistema. Existe otro procedimiento muy importante en el archivo user.c. Este es el procedimiento UserCommand( ), que recibe como parmetros la estructura del robot y un texto dentro de un string. Este procedimiento permite interactuar con el usuario cuando el sistema est en marcha. Es decir, cuando la plataforma est activa, el usuario puede ingresar un comando a travs del botn command. Este comando puede ser implementado en el procedimiento UserCommand( ) lo cual le da una gran flexibilidad a la plataforma. En la seccin D.8 de este anexo se especifican los comandos implementados. D.5.2.2. Archivo user.h El archivo user.h contiene la definicin de ciertas constantes del robot como son la velocidad de avance, el valor umbral del choque con un objeto, etc. Modificando estos valores se puede cambiar la forma en que el robot se mover sobre el simulador. D.5.2.3. User_info.h Este archivo contiene las constantes de informacin de configuracin del usuario. Se puede consultar el manual del Khepera en el anexo A para mayor informacin sobre este archivo.
142
Pablo M. Maceri
D.5.3. Archivos fuente desarrollados para este trabajo D.5.3.1. Archivo sia.c Este archivo fuente contiene procedimientos del sistema inteligente autnomo implementado que no son especficos a ningn modulo o que son procedimientos comunes a varios mdulos (utilizados por varios mdulos). D.5.3.2. Archivo sia.h Este archivo de encabezado tiene la definicin de todas las estructuras de datos utilizadas por el sistema inteligente autnomo. En la seccin D.9 de este anexo se presentan dichas estructuras. D.5.3.3. Archivo aprendizaje.c Este es el mdulo de aprendizaje del sistema inteligente autnomo. Aqu se encuentran todas la funciones necesarias para realizar el proceso de registrar teoras, mutarlas y ponderarlas. La funcin principal de este mdulo es RegistrarTeoria( ) que recibe como parmetros la situacin anterior, la accin, la situacin actual y las listas de situaciones y teoras. Con esto, el mdulo es capaz de incluir la nueva teora al sistema y de realizar las acciones correspondientes al proceso de aprendizaje explicado en la seccin 4.7. D.5.3.4. Archivo controlador.c Este archivo contiene todo el cdigo correspondiente al mdulo controlador que fue presentado en la seccin 4.10 del captulo 4. Su funcin principal es controlador( ) la cual es llamada desde user.c luego de realizar el proceso de aprendizaje. Esta funcin se encarga de decidir si la situacin obtenida era la esperada por el plan en ejecucin y en caso de que sea necesario llama al mdulo planificador para que arme un nuevo plan. Este mdulo deja al sistema en condiciones de poder aplicar una accin sobre el entorno de manera que lo lleve a una situacin mas favorable u ptima. D.5.3.4. Archivo planificador.c La funcin principal del mdulo planificador, que fue explicado en la seccin 4.8 del captulo 4, es planificador( ) y es llamada desde el mdulo controlador para que arme un plan a partir del conocimiento que posee el sistema en un instante dado. Este mdulo
Anexo D - Documentacin Pablo M. Maceri 143
tambin est encargado, luego de armar nuevos planes, de llamar al mdulo ponderador de planes para que pueda determinar si un plan es confiable o no. En caso de que lo sea, este plan es devuelto al controlador. Si el mdulo planificador no es capaz de encontrar un plan aceptable, no le devuelve nada al controlador y ste se encarga de aplicar una heurstica de contingencia (para esta implementacin slo se utiliza la heurstica de contingencia por azar). D.5.3.5. Archivo ponderador.c Como se explic en el mdulo planificador, el ponderador recibe un plan y retorna el valor de confiabilidad del mismo mediante el mtodo de ponderacin visto en la seccin 4.9. De esta manera el planificador puede decidir si el plan es aceptable o no. La funcin de este mdulo que recibe el plan a ponderar es ponderador( ). D.5.3.6. Archivo intercambio.c La funcin principal de este mdulo es intercambiar( ) que es llamada desde el archivo user.c en el momento que sea necesario el intercambio de operadores entre dos robots. Este mdulo recibe de entrada las situaciones y teoras de los dos robots y devuelve las mismas actualizadas utilizando el algoritmo definido en la seccin 4.11. D.5.3.7. Archivo data.c Este archivo contiene dos funciones: guardar_conocimiento( ) y cargar_conocimiento( ). Ambas son utilizadas desde el archivo user.c. La primera guarda en disco, al final de una simulacin, el conocimiento que ha adquirido el robot (situaciones y teoras) durante la misma. El segundo permite levantar estas situaciones y teoras guardadas en disco al inicio de otra simulacin. Las situaciones se guardan en un archivo llamado situ.dat y las teoras se guradan en el archivo llamado teo.dat. Estos archivos se graban siempre al final de una simulacin y se cargan solamente cuando est seteada en TRUE la variable CARGAR. Este mdulo slo est implementado para la simulacin de un robot, es decir que estas funciones guardan y cargan el conocimiento del primer robot en caso de simular ms de un robot simultneamente.
144
Pablo M. Maceri
D.6. Esquema de interaccin de los mdulos

En la figura D-4 se muestra un esquema que representa como interactan los archivos vistos en la seccin anterior. Cada archivo fuente est representado por un mdulo, excepto user.c que es el enlace del sistema inteligente autnomo y la plataforma Khepera. No se representa el archivo sia.c que posee funciones comunes a todos los mdulos o funciones que no son especficas de un mdulo (no se muestra para facilitar la comprensin del diagrama ya que todos los mdulos se relacionan con l).
User.c
Modulo de Aprendizaje
Modulo Controlador
Modulo de Intercambio
Mdulo de carga y descarga de conocimiento
Modulo Planificador
Modulo Ponderador Figura D-4: interaccin entre mdulos
De esta manera, el archivo user.c hace uso del mdulo de aprendizaje para adquirir el nuevo conocimiento de cada ciclo del robot. Luego, pasa invoca al mdulo controlador que decide si es necesario llamar al mdulo planificador para crear un nuevo plan. El mdulo planificador utiliza al mdulo ponderador cuando un plan requiera ser ponderado. Por ltimo el archivo user.c interacta con el mdulo de intercambio para que se encargue del proceso de intercambio de operadores cuando el sistema lo requiera y utiliza al mdulo de carga y descarga de conocimiento para almacenar en disco las situaciones y teoras de un robot.
Pablo M. Maceri
145
D.7. Diagramas de estructura

A un nivel ms funcional se presentan diagramas estructurados. En estos diagramas los rectngulos representan funciones. Las flechas que conectan las funciones representan llamadas entre ellas y sobre las flechas se indican los parmetros pasados. En la figura D5 se muestra el diagrama de estructura principal donde la funcin UserCommand( ) del archivo user.c hace la llamada a la funcin StepRobot( ) del mismo archivo. Esta llamada se hace de una manera cclica y para cada robot en caso de una simulacin multiagente. Cada una cierta cantidad de ciclos, UserCommand( ) llama a la funcin intercambiar( ) del archivo intercambio.c que realiza el proceso que intercambia las situaciones y las teoras de dos robots. Esta funcin es llamada tantas veces como sea necesaria para que todos los robots puedan adquirir el conocimiento de los dems. De esta manera se puede simular el intercambio de operadores entre los robots simulados.
UserCommand()
estructura del robot situaciones y teoras de dos robots
StepRobot()
situacin estructura del robot situacin inicial, accion y situacin final accin
intercambiar()
situacin actual y situacin esperada
plan
LeerSensores()
RegistrarTeora()
Controlador()
situaciones, teoras y situacin actual plan
proximaaccion()
planificador()
plan aceptable si/no
ponderador() Figura D-5: diagrama de estructura del sistema
146
Pablo M. Maceri
La funcin StepRobot( ) representa un ciclo o un paso del robot, esto abarca desde el momento de la percepcin del entorno hasta la ejecucin de una accin. La simulacin de varios robots simultneamente se realiza de manera asincrnica, es decir que se simula un paso por vez para cada robot. Por lo tanto, UserCommand( ) llama a StepRobot( ) una vez por cada robot en cada paso de la simulacin. En cada ciclo de un robot, representado por la funcin StepRobot( ), se llama a la funcin LeerSensores( ) del archivo sia.c que, con la estructura que maneja el simulador Khepera que representa al robot, obtiene la situacin actual del robot. A partir de la situacin actual, la situacin anterior, y la ltima accin ejecutada, StepRobot( ) llama a RegistrarTeora( ) del archivo aprendizaje.c que es la funcin principal del mdulo de aprendizaje. Esta funcin registra la nueva teora formada con la situacin anterior, la accin y la situacin actual de acuerdo al algoritmo presentado en la seccin 4.7 del captulo 4. Luego de registrar la teora, StepRobot( ) llama a la funcin controlador( ) del archivo controlador.c que implementa el algoritmo de control de planes en ejecucin del sistema inteligente autnomo descripto en la seccin 4.11 del captulo 4. Por ltimo, la funcin StepRobot( ) con el plan en ejecucin llama a la funcin proximaaccion( ) del archivo sia.c que obtiene la siguiente accin del plan en ejecucin y prepara la estructura del robot para que la plataforma pueda ejecutar dicha accin en el entorno. La funcin controlador( ) decide si continuar con el plan en ejecucin o llama a la funcin planificador( ) del archivo planificador.c que mediante el algoritmo visto en la seccin 4.9 del captulo 4 intenta armar un plan ponderndolo con la funcin ponderador( ) del archivo ponderador.c que implementa el algoritmo de ponderacin de planes explicado en la seccin 4.10 del captulo 4. Si la funcin planificador( ) no encuentra ningn plan aceptable, la funcin controlador( ) se encarga de armar un plan con una accin al azar para que sea ejecutada en el entorno. Las funciones RegistrarTeora( ) y planificador( ) pueden ser explicadas en ms detalles mediante sus propios diagramas de estructura. En la figura D-6 se muestra el diagrama de estructura para la funcin RegistrarTeora( ).
Pablo M. Maceri
147
situacin inicial, accin y situacin final
RegistrarTeora()
PyK situaciones, teoras, situacin inicial, accin y situacin final situaciones, teoras, situacin inicial, accin y situacin final
situaciones, teoras, situacin inicial, accin y situacin final
teoras, situacin inicial, accin, situacin final, P y K
insersitu()
buscar_teoria()
ponderar_teorias()
ponderar_teorias_mutar()
insertarteo()
Figura D-6: diagrama de estructura del mdulo de aprendizaje
La funcin RegistrarTeora( ) recibe como parmetros una situacin inicial, una accin y una situacin final con lo que puede formar una teora que no tiene los valores de P y K establecidos. Mediante la funcin insersitu( ) inserta la situacin inicial y la situacin final al conjunto de situaciones conocidas por el sistema. Luego, busca la teora formada en el conjunto de teoras del sistema mediante la funcin buscar_teoria( ) que devuelve los valores P y K en caso de encontrar una teora registrada igual a la teora formada, o slo devuelve el valor de K si encuentra alguna teora similar. Si encuentra una teora registrada que sea igual a la teora formada, incrementa el P y el K de la teora y pondera las teoras similares si las hay (incrementndoles el K) mediante la funcin ponderar_teorias( ). Si no existe una teora igual, pero existe alguna teora registrada que sea similar a la teora formada se inserta la teora formada con el P inicializado en 1 y el K de la teora similar con la funcin insertarteo( ), y luego, mediante la funcin ponderar_teorias_mutar( ), se incrementa el K de las teoras similares y se mutan. En el caso de que la funcin buscar_teora( ) no haya encontrado ninguna teora ni igual ni similar a la teora formada, sta se inserta en el conjunto de teoras con la funcin insertarteo( ) inicializando su P y su K en 1. En la figura D-7 se puede observar el diagrama de estructura para la funcin planificador( ). En primer lugar esta funcin, a partir del conjunto de situaciones y teoras, arma la pila de situaciones deseables mediante la funcin armopila( ) que devuelve una pila de situaciones ordenadas de mayor a menor utilidad. Luego con el tope de la pila, la situacin actual y los conjuntos de situaciones y teoras del sistema, se llama a la funcin armar_arbol( ) que intenta armar el rbol de situaciones. Con ste rbol y la situacin actual (junto con los conjuntos de situaciones y teoras del sistema) se llama a la funcin armo_plan( ) para que se encuentre el camino mnimo en rbol entre la situacin actual y la raz del rbol. En caso de que esta funcin devuelva un plan se llama a la funcin
148 Pablo M. Maceri Anexo D - Documentacin
ponderador( ) para que calcule el estimar de probabilidad del plan para determinar si es confiable o no. La funcin armo_plan( ) puede devolver ms de un plan (a travs de una lista de planes) en caso de que se encuentre ms de un camino mnimo de la misma longitud.
situaciones, teoras y situacin actual
planificador()
pila situaciones y teoras situaciones, teoras, tope y situacin actual rbol plan aceptable si/no
situaciones, teoras, rbol y situacin actual
plan
armopila()
armar_arbol()
armo_plan()
ponderador()
Figura D-7: diagrama de estructura para el mdulo planificador
D.8. Comandos implementados

A continuacin se presentan los comandos que el usuario puede ingresar cuando la plataforma est activa pulsando el botn command. Estos comandos son implementado en el procedimiento UserCommand( ) del archivo user.c y son los siguientes: robots n Ejecuta el sistema con n robots. cargar Ejecuta el sistema con un robot pero previamente cargndole en la memoria todas las situaciones y teoras aprendidas en una simulacin anterior. seguir si/no Habilita o deshabilita el modo de seguimiento del sistema. Este modo imprime por el STDERR los pasos que va ejecutando el/los robots como tambin el contenido de la listas de teoras, la lista situaciones, el rbol de situaciones, la lista de situaciones deseadas, la lista de planes y las matrices del ponderador. Este comando utiliza la variable del tipo boolean "verbose". mutar si/no
Pablo M. Maceri
149
Habilita o deshabilita la mutacin de teoras. Utilizando la variable del tipo boolean "bmutar" permite que el sistema utilice o no el algoritmo de mutacin. ponderar si/no Habilita o deshabilita la ponderacin de planes. Este comando, a travs de la variable del tipo boolean "ponderar", permite que el sistema utilice o no el algoritmo de ponderacin de planes. De esta manera, si se utiliza el comando ponderar no el sistema acta aplicando cualquier plan sin que sea ponderado. intercambiar si/no Habilita o deshabilita el intercambio de teoras. Mediante la variable del tipo boolean "bintercambiar" permite que cuando el sistema trabaja con dos o ms robots estos intercambien las teoras que han aprendido de la interaccin con el entorno si se utiliza el comando intercambiar si.
D.9. Estructuras de datos

En el archivo sia.h se definen todos los tipos de datos utilizados por el sistema inteligente autnomo implementado. A continuacin se pasa a explicar estas estructuras de datos. D.9.1. Lista de situaciones conocidas
NODOSITU
VECTOR nro. situacin SIGUIENTE
VECTOR
vector sensor vector luz vector nivel
Figura D-8: estructuras de la lista de situaciones conocidas
La lista de situaciones conocidas (figura D-8) es una lista simplemente encadenada con nodos representados por la estructura NODOSITU. Esta estructura contiene el nmero de situacin que identifica unvocamente a cada una, el puntero al nodo siguiente de la lista y el tipo de dato VECTOR en el que se puede guardar los valores que caracterizan a una situacin. Un tipo de dato VECTOR contiene los valores de distancia y luz que indican los sensores del robot para esa situacin y un nivel de luz para cada sensor (para esta implementacin se utilizaron solo tres niveles: 0, 1 y 2 donde 0 representa un nivel alto, 1 medio, y 2 un nivel bajo de luz).
150
Pablo M. Maceri
D.9.2. Lista de teoras

NODOTEORIA
TEORIA SIGUIENTE
TEORIA
nro. situacin inicial ACCION nro. situacin final p k utilidad
ACCION
valor
Figura D-9: estructuras de la lista de teoras
La lista de teoras (figura D-9) se forma tambin a travs de una lista simplemente encadenada cuyos nodos tienen la estructura NODOTEORIA. Cada nodo, adems del puntero al nodo siguiente, contiene el tipo de dato TEORIA donde se pueden almacenar todos los atributos que componen una teora. Estos son el nmero de situacin inicial y final, el valor p, el valor k, la utilidad y la accin que es un tipo de datos especial ACCION que puede tomar los valor 0, 1, 2 y 3 (que representan: no hacer nada, avanzar, girar izquierda y girar derecha respectivamente). D.9.3. Lista de situaciones deseables
NODODESE
nro. situacin utilidad SIGUIENTE
NODOAUX
nro. situacin utilidad SIGUIENTE
Figura D-10: estructuras de la lista de situaciones deseables
La lista de situaciones deseables (figura D-10), tambin es una lista simplemente encadenada con nodos representados por la estructura NODODESE. Esta estructura contiene el nmero de situacin, su utilidad asociada, y el puntero al nodo siguiente de la lista. Esta lista se ordenada descendentemente, desde la situacin de mayor utilidad a la menor. Para la implementacin se utiliz una lista auxiliar idntica a la lista de situaciones deseables. Para mayor claridad los nodos tienen la misma estructura pero se defini un tipo de datos con otro nombre (NODOAUX). Esta lista es ordenada ascendentemente para luego poder volcarla en orden inverso a la lista de situaciones deseables.
D.9.4. Arbol de situaciones
ARBO
nro. situacin HIJO
HIJO
ARBO ACCION SIGUIENTE
NODOTEORIAAUX
nro. situacin inicial ACCION nro. situacin final SIGUIENTE
ACCION
valor
Figura D-11: estructuras del rbol de situaciones
El rbol de situaciones (figura D-11) se implement con dos listas simplemente encadenadas. La primera, ARBO, representa cada nodo del rbol, que adems de la situacin tiene un puntero a la lista de hijos (HIJO). Cada nodo hijo (HIJO), guarda la accin que lleva a la situacin del nodo padre, un puntero al nodo siguiente (nodo hermano) y un puntero a un nodo ARBO que tendr el nmero de situacin de ese hijo y el puntero a la lista de sus hijos. En la implementacin se utiliz una lista auxiliar para que en el armado del rbol no se formen ciclos. En esta lista se van guardando las teoras que forman una rama del rbol y de sta manera se evita que se repitan teoras en una rama. D.9.5. Lista de planes
NODOLISPLAN
NODOPLAN SIGUIENTE
NODOPLAN
NODOAUX2
ACCION
valor
Figura D-12: estructuras de la lista de planes
Para la lista de planes (figura D-12) se utilizaron dos listas simplemente encadenadas. La primera, NODOLISPLAN, es una lista de planes de la misma longitud, y la segunda cuyos nodos son del tipo NODOPLAN representa la secuencia de acciones que componen el plan. Adems de la accin, estos nodos guardan la situacin inicial, la situacin final y un puntero al siguiente nodo.
152
Pablo M. Maceri
Se utiliz una estructura auxiliar, que es idntica a NODOPLAN, llamada NODOAUX2, en la que se va armando temporalmente cada plan para luego ser copiado a la lista de planes. D.9.6. Otras estructuras utilizadas Las dems estructuras utilizadas son las siguientes: MATRIZ, tseteos, tresu y tbase. La primera, MATRIZ, es una matriz de 255x255 que es utilizada por el mdulo ponderador de planes para realizar las operaciones entre las matrices de transicin y as calcular la confiablidad de cada plan. La estructura tseteos contiene distintas variables de configuracin del robot, entre ellas las ms utilizadas son cantniveles, que indica la cantidad mxima de niveles que puede tener el rbol de situaciones en la planificacin (seteado en 10), y rangoponde que es un valor entre 0 y 1 que indica el umbral a partir del cual se aceptan los planes ponderados (actualmente est seteado en 0.1, es decir que se elimina todo plan que tenga una confiabilidad menor al 10%). La estructura tseteos tambin contiene variables del tipo boolean que permiten configurar individualmente cada robot en el caso de simular ms de uno a la vez. Esto es que se puede indicar para cada uno por separado si se usa mutacin, ponderacin e intercambio. La estructura tresu va guardando a lo largo de la simulacin los resultados de la misma, como ser el nmero de ciclo en el que se encuentra el robot, la cantidad de situaciones y teoras registradas, los planes aplicados, la cantidad de planes con y sin xito y la cantidad de veces que se utiliz el azar. Esta estructura es utilizada para volcar cada cierto intervalo de tiempo el valor de estas variables sobre un archivo y luego realizar los grficos estadsticos para el estudio del comportamiento del sistema (ver seccin C.10). Por ltimo, tbase, es la estructura que guarda toda la base de conocimiento para cada robot simulado. Esto es, lista de situaciones y de teoras, pila de situaciones deseables, rbol de situaciones, lista de planes, accin aplicada, situacin actual, situacin anterior, entre otras.
D.10. Formato de los archivos de estadsticas

La implementacin del sistema est preparada para realizar una simulacin hasta 500 ciclos y hacer un muestreo de las variables del sistema cada 20 ciclos (esto puede ser modificado desde el archivo user.c). Este muestreo se realiza guardando cada 20 ciclos
los datos necesarios en archivos de texto en el directorio /estad para realizar las estadsticas y experimentos sobre el sistema. Los nombres de los archivos son de la forma datosn.txt donde n es el nmero del robot, es decir, se guardar un archivo para cada robot simulado (datos1.txt corresponder al robot 1, datos2.txt corresponder al robot 2, etc.). Cada lnea del archivo de texto tiene la siguiente estructura:
ciclos situaciones teorias Azares planes planes sin exito exitos
Donde ciclos es el nmero de ciclo en que se toman los valores, situaciones representa la cantidad de situaciones que adquiri el sistema hasta dicho ciclo, teorias es la cantidad de teoras formadas, azares representa la cantidad de veces que se aplic la heurstica de contingencia azar, planes indica la cantidad de planes formados por el mdulo planificador que se han aplicado en el entorno, planes sin xito indica la cantidad de veces que un plan fue abortado en alguna de sus acciones, y exitos representa la cantidad de veces que un plan ha sido exitoso. Cabe aclarar que los planes exitosos se contabilizan como la cantidad de acciones del plan que obtuvieron la situacin esperada dividido la cantidad total de acciones que forman el plan. Los valores de una misma lnea del archivo de estadsticas se encuentran separados por ; y cada simulacin comienza inicializando una lnea de encabezado con los nombres de cada campo, tambin separados por ;, para poder diferenciar los datos estadsticos de una simulacin y otra.
154
Pablo M. Maceri
Anexo E
Cdigo Fuente
En este anexo se presentan el cdigo fuente de la implementacin del sistema inteligente autnomo integrado a la plataforma Khepera. El anexo se encuentra dividido por archivos fuente comenzando por los archivos de interfase del usuario de la plataforma, user.h y user.c. Para el archivo user.c se muestran solamente las declaraciones de variables, la inclusin de archivos y las funciones StepRobt( ) y UserCommand( ). Luego se presenta el cdigo del sistema presentado para esta tesis: el archivo sia.h, que contiene la declaracin de estructuras de datos utilizadas, el archivo sia.c, con las funciones comunes a todos los mdulos, los archivos aprendizaje.c, controlador.c, planificador.c, ponderador.c e intercambio.c que contienen las funciones correspondientes a los mdulos de aprendizaje, controlador de planes en ejecucin, planificador, ponderador de planes e intercambio de operadores respectivamente, y el archivo data.c que tiene las funciones necesarias para guardar y cargar de disco el conocimiento que adquiere el sistema durante un ciclo de experimentacin en un escenario dado. Por ltimo se puede encontrar un ndice analtico de funciones que permite ubicar rpidamente cualquier funcin del sistema dentro de este anexo.
Anexo E - Cdigo fuente
Pablo M. Maceri
155
156
Pablo M. Maceri
Archivo user.h
Pablo M. Maceri
157
158
Pablo M. Maceri
Archivo: user.h Descripcin: contiene la definicin de ciertas constantes del robot como son la velocidad de avance, el valor umbral del choque con un objeto, etc. Si se modifican estos valores se puede cambiar la forma en que el robot se mueve sobre el simulador.
#include "../src/include.h" #include "user_info.h" #define FORWARD_SPEED 10 #define TURN_SPEED 5 #define COLISION_ADELANTE 750 #define COLISION_COSTADO 750 #define COLISION_MASCOSTADO 750 #define COLISION_ATRAS 750 /* velocidad de avance */ /* velocidad de giro */ /* colision adelante, sensores 2 y 3 */ /* colision sensores 1 y 4 */ /* colision sensores 0 y 5 */ /* colision atras, sensores 6 y 7 */
Pablo M. Maceri
159
160
Pablo M. Maceri
Archivo: user.c
Pablo M. Maceri
161
162
Pablo M. Maceri
Mdulo: user.c Declaracin de variables, constantes e inclusin de archivos

#define MAX_ROBOTS 10 #include "../src/include.h" #include "../contrib/multirobots.h" #include <limits.h> #include "user.h" #include "../sia/sia.h" /*================= Variables ==============*/ struct Robot* robot; int ROBOTS=2; boolean CARGAR=FALSE; boolean primeravez=TRUE; boolean azar=TRUE; boolean bmutar=FALSE; boolean ponderar=FALSE; boolean bintercambiar=FALSE; boolean verbose=FALSE; boolean verificar=TRUE; /*Archivos de resultados */ FILE *estad1,*estad2,*estad3,*estad4,*estad5,*estad6,*estad7,*estad8,*estad9,*estad10,*fdclock; boolean cerca[MAX_ROBOTS][MAX_ROBOTS]; int cant_intercambios[MAX_ROBOTS][MAX_ROBOTS]; int total_intercambios=0; /*array que contiene las bases de los robots*/ tbase bases[MAX_ROBOTS]; int turno; int longitud=0; int pas=0; int pas_intercambio[MAX_ROBOTS][MAX_ROBOTS]; /* marca en que pasado se realizo el ultimo intercambio de operadores */ /*******************************************************/ #include "../sia/sia.c" #include "../sia/data.c"
Pablo M. Maceri
163
Funcin: StepRobot() Mdulo: user.c Llama a: LeerSensores() mostrar() ContarSitu() ContarTeorias() inicializar() cargar_conocimiento() proximaaccion() RegistrarTeoria() verificar_consistencia() controlador() MostrarPlan() escribirArchivo() Entrada: estructura del robot Salida: TRUE FALSE Descripcin: esta funcin representa un ciclo de robot donde se lee el valor de los sensores, se llama a la funcin de aprendizaje para procesar la teora local formada a partir de la situacin anterior, la accin aplicada y la situacin obtenida. Luego llama al controlador para que decida si es necesario volver a planificar y por ltimo se selecciona la proxima accin a ejecutar. Devuelve TRUE si se sigue con la ejecucin del robot o FALSE en caso de detener la ejecucin.
boolean StepRobot(struct Robot *robot) { int i; NODOLISPLAN* plan; DrawStep(); LeerSensores(&(bases[turno].actual) , robot); longitud=-1; if (verbose) { fprintf (stderr , "\n--------------------+"); fprintf (stderr , "\nPaso: %d Robot: %d |",pas,turno+1); fprintf (stderr , "\n--------------------+"); fprintf (stderr , "\nSituant: "); mostrar(bases[turno].situant); fprintf (stderr,"accion: %d\n",bases[turno].acc.valor); fprintf (stderr , "Actual: "); mostrar(bases[turno].actual); fprintf(stderr,"\nciclos;situaciones;teorias;azares;planes;planes sin exito;exitos\n"); fprintf(stderr,"%d;%d;%d;%d;%d;%d;%f\n\n",pas,ContarSitu(bases[turno].cabsitu),ContarTe orias(bases[turno].cabteor), bases[turno].resu.CantidadAzares,bases[turno].resu.CantidadPlanes,bases[turno].resu.Can tidadPlanesSinExito,bases[turno].resu.CantidadTotalExitos); } if (primeravez) { if (verbose) { fprintf (stderr, "Inicializando punteros ...\n"); fprintf (stderr, "Valor de cabteor y su direccion %X \n",bases[turno].cabteor); } inicializar(&(bases[turno].cabteor),&(bases[turno].topedese),&(bases[turno].cabarbo),&(bas es[turno].cablisplan), &(bases[turno].cabsitu),&(bases[turno]).resu,&(bases[turno].estado));
164
Pablo M. Maceri
if ((turno==0)&&(CARGAR==TRUE)) cargar_conocimiento(&(bases[turno].cabteor),&(bases[turno].cabsitu)); proximaaccion (&(bases[turno].cablisplan),robot,&(bases[turno].acc),&(bases[turno].estado)); if (turno==(ROBOTS-1)) primeravez = FALSE; bases[turno].situant = bases[turno].actual; bases[turno].accionant = bases[turno].acc; return(TRUE); } /* Formula la teora con Si,Accion,Sf*/ bases[turno].situinicial=bases[turno].situant; bases[turno].acc=bases[turno].accionant; bases[turno].situfinal=bases[turno].actual; /* Registra la teora */ if (verbose) { fprintf (stderr, "Entro a RegistrarTeoria ...\n"); fprintf (stderr, "RegistrarTeoria= entro cabteor y su direccion %X %X %X %X \n",bases[turno].cabteor,&(bases[turno].cabteor),bases[turno].cabsitu, &(bases[turno].cabsitu)); } RegistrarTeoria(bases[turno].situinicial,bases[turno].situfinal,bases[turno].acc, &(bases[turno].cabteor),&(bases[turno].cabsitu)); if (verbose) { fprintf (stderr, "RegistrarTeoria= salgo cabteor y su direccion %X %X %X %X \n",bases[turno].cabteor, &(bases[turno].cabteor),bases[turno].cabsitu,&(bases[turno].cabsitu)); fprintf (stderr, "Salgo de RegistrarTeoria ...\n"); } if (verificar) if (!(verificar_consistencia(&(bases[turno].cabteor),bases[turno].cabsitu))) { fprintf(stderr,"\nLa lista de teorias es inconsistente!!!!\n"); exit(-1); } if (bases[turno].estado.azar) { if (verbose) { fprintf (stderr, "Estoy actuando por Azar ...\n"); } proximaaccion (&(bases[turno].cablisplan),robot,&(bases[turno].acc),&(bases[turno].estado)); bases[turno].situant = bases[turno].actual; bases[turno].accionant = bases[turno].acc; if (verbose) { fprintf (stderr, "La accion a ejecutar es %d \n",bases[turno].acc.valor); } return(TRUE); } /***************************************************************************/ controlador(&(bases[turno].cablisplan), &(bases[turno].topedese), bases[turno].cabteor, &(bases[turno].cabarbo), bases[turno].cabsitu, bases[turno].situinicial, bases[turno].situfinal, &(bases[turno].resu),&(bases[turno].estado)); /***************************************************************************/
Anexo E - Cdigo fuente Pablo M. Maceri 165
if (verbose) fprintf(stderr,"Lista de planes antes %X\n",bases[turno].cablisplan); if ((bases[turno].cablisplan)!=NULL) { plan=bases[turno].cablisplan; while (plan!=NULL) { if (verbose) MostrarPlan(plan->info); plan=plan->sig; } } proximaaccion (&(bases[turno].cablisplan),robot,&(bases[turno].acc),&(bases[turno].estado)); if (verbose) fprintf(stderr,"Lista de planes despues %X\n",bases[turno].cablisplan); if ((bases[turno].cablisplan)!=NULL) { plan=bases[turno].cablisplan; while (plan!=NULL) { if (verbose) MostrarPlan(plan->info); plan=plan->sig; } } bases[turno].situant = bases[turno].actual; bases[turno].accionant = bases[turno].acc; /* grabo las estadisticas */ if (pas%20==0) escribirArchivo(turno); return(TRUE); }
166
Pablo M. Maceri
Funcin: UserCommand() Mdulo: user.c Llama a: cantidadRobots() abrirArchivos() MostrarListaTeorias() MostrarListaSituaciones() verificar_consistencia() intercambiar() cerrarArchivos() guardar_conocimiento() Entrada: estructura del robot y texto con el comando a ejecutar Descripcin: este procedimiento implenta los comando que puede ejecutar el usuario a travs del botn command de la plataforma. Aqu se implementan los comandos para fijar las variables de configuracin del sistema. Tambin se encuentra la implementacin de los comandos que permiten simular uno o ms robots con lo cual este procedimiento llama de manera cclica a la funcin StepRobot() que representa un ciclo de robot y controla el intercambio de operadores en caso de que el sistema lo requiera.
void UserCommand(struct Robot *robot,char *text) { int i,j; struct MultiRobots *multi; boolean stop = FALSE; boolean pasaron=FALSE; if ((strcmp(text,"1")==0)||(strcmp(text,"2")==0)|| (strcmp(text,"3")==0)||(strcmp(text,"4")==0)|| (strcmp(text,"5")==0)||(strcmp(text,"6")==0)|| (strcmp(text,"7")==0)||(strcmp(text,"8")==0)|| (strcmp(text,"9")==0)||(strcmp(text,"10")==0)||(strcmp(text,"cargar")==0)) { WriteComment("Demonstration"); srand(getpid()); pas=0; ROBOTS=cantidadRobots(text); abrirArchivos(); /*inicializo variables*/ for (i=0;i<ROBOTS;i++) for (j=0;j<ROBOTS;j++) { cerca[i][j]=FALSE; pas_intercambio[i][j]=0; cant_intercambios[i][j]=0; } primeravez=TRUE; ShowUserInfo(1,1); multi = CreateMultiRobots(ROBOTS); PlaceRobots(context,multi); DrawWorldSquare(context->World); while (pas<500) { MultiRobotRun(context,multi); if (StopCommand()) {
stop = TRUE; break; } /* chequeo por si hay que hacer intercambios */ for (i=0;i<ROBOTS;i++) for (j=0;j<ROBOTS;j++) { /* se fija si pasaron mas de 50 ciclos o si pasaron mas de 100 pasadas desde el ultimo intercambio de operadores y si es asi intercambia si estan cerca*/ if ((pas_intercambio[i][j]==0)&&(pas>19)) pasaron=TRUE; else pasaron=(pas-pas_intercambio[i][j])>19; //if ((cerca[i][j]==TRUE)&&(pasaron)&&(j!=i)) if (((pas-1)%20==0)&&(pasaron)&&(j!=i)&&(bintercambiar)) { total_intercambios++; cant_intercambios[i][j]++; cant_intercambios[j][i]++; pas_intercambio[i][j]=pas; pas_intercambio[j][i]=pas; if (verbose) { fprintf(stderr,"\n***Teorias Robot %d antes de intercambiar operadores***\n",i+1); MostrarListaTeorias(bases[i].cabteor); fprintf(stderr,"\n***Situaciones Robot %d antes de intercambiar operadores***\n",i+1); MostrarListaSituaciones(bases[i].cabsitu); fprintf(stderr,"\n***Teorias Robot %d antes de intercambiar operadores***\n",j+1); MostrarListaTeorias(bases[j].cabteor); fprintf(stderr,"\n***Situaciones Robot %d antes de intercambiar operadores***\n",j+1); MostrarListaSituaciones(bases[j].cabsitu); } if (verificar) { if (!(verificar_consistencia(&(bases[i].cabteor),bases[i].cabsitu))) { fprintf(stderr,"\nLa lista de teorias del Robot %d es inconsistente!!!!\n",i+1); stop = TRUE; break; } if (!(verificar_consistencia(&(bases[j].cabteor),bases[j].cabsitu))) { fprintf(stderr,"\nLa lista de teorias del Robot %d es inconsistente!!!!\n",j+1); stop = TRUE; break; } } intercambiar(&(bases[i].cabteor),&(bases[i].cabsitu),&(bases[j].cabteor),&(bases[j].cabsitu)); if (verbose)
168 Pablo M. Maceri Anexo E - Cdigo fuente
{ fprintf(stderr,"\n***Teorias Robot %d despues de intercambiar operadores***\n",i+1); MostrarListaTeorias(bases[i].cabteor); fprintf(stderr,"\n***Teorias Robot %d despues de intercambiar operadores***\n",j+1); MostrarListaTeorias(bases[j].cabteor); } if (verificar) { if (!(verificar_consistencia(&(bases[i].cabteor),bases[i].cabsitu))) { fprintf(stderr,"\nLa lista de teorias del Robot %d es inconsistente!!!!\n",i+1); stop = TRUE; break; } if (!(verificar_consistencia(&(bases[j].cabteor),bases[j].cabsitu))) { fprintf(stderr,"\nLa lista de teorias del Robot %d es inconsistente!!!!\n",j+1); stop = TRUE; break; } } fprintf(stderr,"\nFin del intercambio de operadores entre Robot %d y Robot %d\n",i+1,j+1); fprintf(stderr,"\nContinuando en 3 ..."); //sleep(1); fprintf(stderr," 2 ..."); //sleep(1); fprintf(stderr," 1 segundo ..."); //sleep(1); fprintf(stderr," listo!\n\n"); } } /* fin for */ } /* fin ciclo infinito */ if (stop) WriteComment("break"); else WriteComment("Done"); turno=1;DrawStep(); turno=0;DrawStep(); cerrarArchivos(); guardar_conocimiento(&(bases[0].cabteor),&(bases[0].cabsitu)); MostrarListaSituaciones(bases[0].cabsitu); MostrarListaTeorias(bases[0].cabteor); FreeMultiRobots(multi); } else if (strcmp(text,"cargar")==0) {
CARGAR=TRUE; } else if (strcmp(text,"seguir si")==0) { verbose=TRUE; } else if (strcmp(text,"seguir no")==0) { verbose=FALSE; } else if (strcmp(text,"mutar si")==0) { bmutar=TRUE; } else if (strcmp(text,"mutar no")==0) { bmutar=FALSE; } else if (strcmp(text,"ponderar si")==0) { ponderar=TRUE; } else if (strcmp(text,"ponderar no")==0) { ponderar=FALSE; } else if (strcmp(text,"intercambiar si")==0) { bintercambiar=TRUE; } else if (strcmp(text,"intercambiar no")==0) { bintercambiar=FALSE; } else if (strcmp(text,"reestablecer")==0) { CARGAR=FALSE; ponderar=TRUE; bmutar=TRUE; bintercambiar=TRUE; verbose=FALSE; } else WriteComment("unknown command"); }
170
Pablo M. Maceri
Archivo sia.h
Pablo M. Maceri
171
172
Pablo M. Maceri
Archivo: sia.h Descripcin: archivo de encabezado que contiene la definicin de todas las estructuras de datos utilizadas para la implementacin del sistema.
/*Cantidad de hijos de cada nodo del arbol*/ const int canthijos = 32767; /*El tipo vector representa el campo visual del Robot*/ typedef struct vector { int sensor[8]; int luz[8]; int nivel[8]; /* valor del nivel de luz: 2 - poca luz (menor a 100) 1 - luz intermedia (entre 100 y 400) 0 - mucha luz (>400) */ int x; int y; } VECTOR; /* El tipo accion representa todas las acciones que son realizables por el Robot. 0 - Representa NO HACER NADA, es decir inaccion del Robot. 1 - Representa AVANZAR una posicion en la direccion en que esta situado el Robot 2 - Representa GIRAR A LA IZQUIERDA 3 - Representa GIRAR A LA DERECHA */ typedef struct accion { int valor; } ACCION; /*El tipo teoria representa una teoria local formulada por el Robot SI : Es un vector de campo visual que indica la situacion inicial sobre la que se aplica la ACCION de la teoria AC : Es la Accion fisica que ejecuta el Robot para pasar a otra situacion SF : Es el vector de campo visual que representa la situacion obtenida luego de aplicar la accion a la situacion inicial(SI) P : Cantidad de veces que la teoria fue utilizada con Exito (Cuantas teorias locales son Identicas(es decir tienen el mismo estado inicial y el mismo estado final y la misma accion)) K : Cantidad de veces que la teoria fue utilizada (Cuantas teorias locales son similares(es decir tienen el mismo estado inicial y la misma accion pero distinto estado final)) U : Indica la utilidad de la teoria. Es directamente proporcional a la diferencia de luz existente entre la SI y la SF. se utiliza la siguiente formula para su calculo : U = (s1+s2+s3+s4+s5+s6+s7+s8) / 1024*8 siendo sn la cantidad de luz del sensor n. */ typedef struct teoria { unsigned int si;
ACCION ac; unsigned int sf; int p; int k; float u; int x; int y; } TEORIA; typedef struct nodoteoria { TEORIA te; struct nodoteoria * sig; }NODOTEORIA; /*Lista de estados del sensor, o situaciones conocidas*/ typedef struct nodositu { VECTOR situ; unsigned int nro; struct nodositu * sig; } NODOSITU; /*Pila de Situaciones Deseables*/ typedef struct nododese { unsigned int dese; float ut; struct nododese * sig; }NODODESE; /*Arbol de Situaciones. Se definie lo siguiente: En cada nodo principal del arbol (arbo) tengo la situacion final y un puntero a una lista de hijos. En esta lista de hijos tengo en cada nodo una situacione inicial que mediante una accion me conduce a la situacion final del nodo anterior. Dicha accion constituye el rotulo del nodo(hijo).*/ /*Esta estructura define: info:Es el numero que representa la situacion final de una teoria, el vector de sensado del Robot correspondiente lo obtenemos cruzando este campo contra la lista de situaciones conocidas. punhijo: Puntero al primer nodo de la lista de hijos*/ typedef struct arbo { unsigned int info; struct hijo * punhijo; } ARBO; /*Esta estructura define: info: puntero a un nodo principal del arbol de situaciones Esa situacion va ser la situacion inicial del nodo principal anterior. rotulo: Es la accion que aplico a esta situacion inicial para llegar a la situacion final almacenada en el nodo principal anterior. sig : Puntero a otro nodo de tipo hijo */ typedef struct hijo { ARBO *info;
ACCION rotulo; struct hijo *sig; } HIJO; /*Estructura que soporta la lista auxiliar de situaciones mas utiles ya ordenadas*/ typedef struct nodoaux { unsigned int info; float ut; struct nodoaux * sig; } NODOAUX; /*Esta lista guarda las teorias que se fue usando para armar el arbol de situaciones y asi poder verificar que no se formen ciclos*/ typedef struct nodoteoriaaux { unsigned int si; ACCION ac; unsigned int sf; struct nodoteoriaaux * sig; }NODOTEORIAAUX; /*Esta lista guarda el plan que se crea en el modulo Planificador del sistema experto.( Implementa una pila para utilizarla en el modulo Controlador de planes en ejecucion ) Sus campos son : si,sf : Este campo tiene el numero de situacion que corresponde al vector de sensado del robot. Este numero se obtiene cruzando el vector contra la lista de situaciones conocidas y es asignado dinamicamente a medida que el Robot se enfrenta a nuevas situaciones acc : Es la accion a ejecutar en este paso sig : es un puntero al proximo paso */ typedef struct nodoplan { unsigned int si; ACCION acc; unsigned int sf; struct nodoplan * sig; } NODOPLAN; /*Voy a crear una estructura de lista de pilas de planes para que guarde los planes generados en el modulo Planificador que tengan el mismo tamao. Estos seran utilizados cuando se descarte algun plan por efectos del modulo Ponderador, luego se utiliza el siguiente plan de esta lista de planes de igual longitud Sus campos son : info : contiene el puntero a la pila del plan generado sig : apunta al proximo nodo de la lista */ typedef struct nodolisplan { NODOPLAN* info; struct nodolisplan * sig; } NODOLISPLAN; /* Lista auxiliar del modulo planificador. Se utiliza en la creacion de planes alternativos */
Pablo M. Maceri
175
typedef struct nodoaux2 { unsigned int si; ACCION acc; unsigned int sf; struct nodoaux2 * sig; } NODOAUX2; /*Este registro guarda el seteo del robot : Guardo en tres variables la posicion del robot dentro de la matriz de entorno y su angulo respecto de un eje de origen tomado como la vertical. Esto va a ser utilizado en la simulacion del mecanismo de sensado del Robot, para poder mapear el campo visual del mismo sobre la matriz de Entorno. muta : se utiliza para que el experimentador decida si trabaja con mutacion de teorias. pondera : se utiliza para que el experimentador decida si usa el modulo ponderador. rangoponde : aca se ingresa el rango bajo el cual se descartan los planes poco confiables. ponelimi : se utiliza para que el experimentador decida si pone un limite para descartar teorias. descteoria : se pone el limite(p/k) bajo el cual empezamos a descartar teorias para evitar la saturacion de la memoria. actcurio : se utiliza para que el experimentador decida si el robot va a actuar por curiosidad o no. azar : se utiliza para que el experimentador decida si el robot va a actuar por azar o no. limitetiempo : guarda el tiempo total de simulacion. siplan : guarda si se utiliza el modulo planificador. cantint : guarda la cantidad de puntos para los graficos estadisticos. nombre : guarda el nombre del seteo. */ typedef struct { boolean muta; int algmuta; boolean pondera; int algponde; boolean siplan; int algplani; float rangoponde; boolean ponelimi; float descteoria; boolean azar; boolean curio; unsigned int limitetiempo; unsigned int cantint; int cantniveles; } tseteos; /*Estructura que guarda los resultados de la simulacion */ typedef struct { unsigned int CantidadPlanes; unsigned int Pasada; unsigned int CantidadPlanesSinExito; unsigned int CantidadTeorias;
unsigned int CantidadSituaciones; unsigned int CantidadAzares; float CantidadTotalExitos; unsigned int LongitudPlanActual; unsigned int CantidadExitos; } tresu; /* Tipo de MATRIZ */ #define CANTMAT 255 typedef float MATRIZ [CANTMAT][CANTMAT] ; /*estructura que contienes todas las estructuras que utiliza un robot*/ typedef struct base { ACCION acc,accionant; NODODESE *topedese; NODOTEORIA *cabteor; NODOSITU *cabsitu; ARBO *cabarbo; NODOLISPLAN *cablisplan; VECTOR actual,situant,situinicial,situfinal,situabus; boolean exitoso; tresu resu; tseteos estado; int contnododese; int contnodoaux; int conthijo; int contarbo; boolean verboseponde; float longtot; unsigned int situesperada; boolean ejecutandoPlan; } tbase;
Pablo M. Maceri
177
178
Pablo M. Maceri
Archivo sia.c
Pablo M. Maceri
179
180
Pablo M. Maceri
Funcin: girarder() Mdulo: sia.c Es llamada desde: proximaaccion() Entrada: estructura del robot Salida: estructura del robot actualizada Descripcin: asigna al motor los valores para girar a la derecha
void girarder(struct Robot *robot) { int speed; robot->Alpha= robot->Alpha - (30*M_PI)/180.0; /*gira 30 grados a derecha*/ }
Pablo M. Maceri
181
Funcin: girarizq() Mdulo: sia.c Es llamada desde: proximaaccion() Entrada: estructura del robot Salida: estructura del robot actualizada Descripcin: asigna al motor los valores para girar a la izquierda
void girarizq(struct Robot *robot) { int speed; robot->Alpha= robot->Alpha + (30*M_PI)/180.0; /*gira 30 grados a izquierda*/ }
182
Pablo M. Maceri
Funcin: avanzar() Mdulo: sia.c Es llamada desde: proximaaccion() Entrada: estructura del robot Salida: estructura del robot actualizada Descripcin: asigna al motor los valores para avanzar
void avanzar(struct Robot *robot) { robot->Motor[LEFT].Value = FORWARD_SPEED; robot->Motor[RIGHT].Value = FORWARD_SPEED; }
/* avanzar
*/
Pablo M. Maceri
183
Funcin: proximaaccion() Mdulo: sia.c Llama a: girarder() girarizq() avanzar() Es llamada desde: StepRobot() Entrada: lista de planes en ejecucin, estructura del robot, seteos del sistema Salida: accin a ejecutar, estructura del robot actualizada Descripcin: ejecuta la proxima accin del plan en ejecucin o una accin al azar si es la primera vez
void proximaaccion(NODOLISPLAN** cablisplan,struct Robot *robot, ACCION *acc,tseteos* estado) { double aux; NODOPLAN *aux2; if ((estado->azar) || primeravez) { aux=(double)rand()/(double)RAND_MAX; if ( aux < .33 ) acc->valor=3; else if ( aux < .66 ) acc->valor=2; else acc->valor=1; } else { bases[turno].situesperada=((*cablisplan)->info)->sf; acc->valor= ((*cablisplan)->info)->acc.valor; aux2=(*cablisplan)->info; (*cablisplan)->info=aux2->sig; free(aux2); } switch (acc->valor) { case 1: avanzar(robot); break; case 2: girarder(robot); break; case 3: girarizq(robot); break; } }
184
Pablo M. Maceri
Funcin: LeerSensores() Mdulo: sia.c Llama a: llenar_nivel() Es llamada desde: StepRobot() Entrada: estructura del robot Salida: vector situacin Descripcin: Lee los sensores del robot y asigna dichos valores de la estructura de datos del robot a un vector situacin
void LeerSensores(VECTOR *act, struct Robot *rob) { int i,colision; for (i=0;i<=7;i++) { switch(i) { case 0: case 5: colision=COLISION_MASCOSTADO; break; case 1: case 4: colision=COLISION_COSTADO; break; case 2: case 3: colision=COLISION_ADELANTE; break; default: colision=COLISION_ATRAS; break; } act->sensor[i]=rob->IRSensor[i].DistanceValue > colision; act->luz[i]=rob->IRSensor[i].LightValue; } llenar_nivel(act); }
Pablo M. Maceri
185
Funcin: inicializar() Mdulo: sia.c Descripcin: Inicializa las variables y punteros a usar
void inicializar(NODOTEORIA** cabteor, NODODESE** topedese,ARBO** cabarbo, NODOLISPLAN** cablisplan,NODOSITU** cabsitu,tresu* resu,tseteos* estado) { *cabteor=NULL; *topedese=NULL; *cabarbo=NULL; *cablisplan=NULL; *cabsitu=NULL; estado->muta=TRUE; estado->algmuta=1; estado->pondera=TRUE; estado->algponde=1; estado->siplan=TRUE; estado->algplani=1; estado->rangoponde=0.1; estado->ponelimi=FALSE; estado->descteoria=0; estado->azar=FALSE; estado->curio=FALSE; estado->limitetiempo=100; estado->cantint=20; estado->cantniveles=5; resu->CantidadPlanes=0; resu->Pasada=0; resu->CantidadPlanesSinExito=0; resu->CantidadTeorias=0; resu->CantidadSituaciones=0; resu->CantidadAzares=0; resu->CantidadTotalExitos=0; resu->LongitudPlanActual=0; resu->CantidadExitos=0; bases[turno].contnododese=0; bases[turno].contnodoaux=0; bases[turno].conthijo=0; bases[turno].contarbo=0; bases[turno].ejecutandoPlan=FALSE; }
186
Pablo M. Maceri
Funcin: cruza() Mdulo: sia.c Llama a: situ_sig() iguales() situ_vacio() Es llamada desde: buscar_teoria() insertarteo() ponderar_teorias() ponderar_teorias_mutar() controlador() Entrada: lista de situaciones conocidas y vector situacin a buscar Salida: nmero de situacin Descripcin: devuelve el numero de situacion dentro de la lista de situaciones conocidas. Devuelve 0 si no la encuentra
unsigned int cruza(NODOSITU* cabsitu,VECTOR dato) { boolean encontre; unsigned int cruza_result; encontre=FALSE; while ((!situ_vacio(cabsitu)) && (! encontre)) if (iguales(cabsitu->situ,dato)) encontre=TRUE; else situ_sig(&cabsitu); if (encontre==TRUE) cruza_result=cabsitu->nro; else cruza_result=0; return cruza_result; }
Pablo M. Maceri
187
Funcin: cruza2() Mdulo: sia.c Llama a: situ_sig() situ_vacio() Es llamada desde: ponderar_teorias_mutar() recalcular_utilidades() intercambiar() copiarteorias() Entrada: lista de situaciones conocidas y nmero de situacin a buscar Salida: vector situacin Descripcin: devuelve en el parametro dato el vector situacion dentro de la lista de situaciones conocidas. Devuelve 0 si no la encontro
int cruza2(NODOSITU* cabsitu,int situ,VECTOR* dato) { boolean encontre; encontre=FALSE; while ((!situ_vacio(cabsitu)) && (! encontre)) if ((cabsitu->nro)==situ) encontre=TRUE; else situ_sig(&cabsitu); *dato=cabsitu->situ; if (encontre==TRUE) return situ; else return 0; }
188
Pablo M. Maceri
Funcin: iguales() Mdulo: sia.c Es llamada desde: encsitu() encsitu_actualizar_luz() intercambiar() cruza() Entrada: dos vectores situacin Salida: devuelve TRUE o FALSE Descripcin: Devuelve TRUE si el contenido de los sensores es igual en ambos parametros
boolean iguales(VECTOR uno, VECTOR otro) { boolean distinto; int i; boolean iguales_result; i=0; distinto=FALSE; while ((i<8) && (! distinto)) { if (uno.sensor[i] != otro.sensor[i]) distinto=TRUE; else i=i+1; } iguales_result=! distinto; return iguales_result; }
Pablo M. Maceri
189
Funcin: mostrar() Mdulo: sia.c Es llamada desde: StepRobot() RegistrarTeoria() ponderar_teorias_mutar() Entrada: vector situacin Descripcin: imprime el contenido del vector recibido como parametro
void mostrar (VECTOR si) { fprintf (stderr , "Vector con = %d %d %d %d %d %d %d %d ", si.sensor[0], si.sensor[1] , si.sensor[2] , si.sensor[3] , si.sensor[4] , si.sensor[5] , si.sensor[6] , si.sensor[7] ); fprintf (stderr , "nivel = %d %d %d %d %d %d %d %d ", si.nivel[0], si.nivel[1] , si.nivel[2] , si.nivel[3] , si.nivel[4] , si.nivel[5] , si.nivel[6] , si.nivel[7] ); fprintf (stderr , "luz = %d %d %d %d %d %d %d %d \n", si.luz[0], si.luz[1] , si.luz[2] , si.luz[3] , si.luz[4], si.luz[5] , si.luz[6] , si.luz[7] ); }
190
Pablo M. Maceri
Funcin: teo_vacio() Mdulo: sia.c Es llamada desde: MostrarListaTeorias() creolistaorde() ContarTeorias() Entrada: lista de teoras Salida: TRUE o FALSE Descripcin: Devuelve TRUE si el puntero que recibe es NULL, sino devuelve FALSE
boolean teo_vacio(NODOTEORIA* cabteo) { boolean teo_vacio_result; if (cabteo==NULL) teo_vacio_result=TRUE; else teo_vacio_result=FALSE; return teo_vacio_result; }
Pablo M. Maceri
191
Funcin: teo_sig() Mdulo: sia.c Es llamada desde: ContarTeorias() Entrada: lista de teoras Salida: lista de teoras actualizada Descripcin: avanza al siguiente elemento en la lista de teorias conocidas
void teo_sig(NODOTEORIA** cabteor) { *cabteor=(*cabteor)->sig; }
192
Pablo M. Maceri
Funcin: situ_vacio() Mdulo: sia.c Es llamada desde: MostrarListaSituaciones() cruza() cruza2() ContarSitu() Salida: lista de situaciones Entrada: TRUE o FALSE Descripcin: devuelve TRUE si el puntero que recibe es NULL, sino devuelve FALSE
boolean situ_vacio(NODOSITU* cabsitu) { boolean situ_vacio_result; if (cabsitu==NULL) situ_vacio_result=TRUE; else situ_vacio_result=FALSE; return situ_vacio_result; }
Pablo M. Maceri
193
Funcin: ContarTeorias() Mdulo: sia.c Llama a: teo_vacio() teo_sig() Es llamada desde: StepRobot() Entrada: lista de teoras Salida: cantidad de teoras en la lista Descripcin: devuelve la cantidad de teorias en la lista de teoras
int ContarTeorias (NODOTEORIA * cabteor) { int i=0; NODOTEORIA * aux; aux=cabteor; while (! teo_vacio(aux)) { teo_sig(&aux); i++; } return i; }
194
Pablo M. Maceri
Funcin: ContarSitu() Mdulo: sia.c Llama a: situ_sig() situ_vacio() Es llamada desde: StepRobot() Entrada: lista de situaciones Salida: cantidad de situaciones en la lista Descripcin: cuenta la cantidad de situaciones conocidas
int ContarSitu (NODOSITU * cabsitu) { int i=0; NODOSITU * aux; aux=cabsitu; while (! situ_vacio(aux)) { situ_sig(&aux); i++; } return i; }
Pablo M. Maceri
195
Funcin: desapiloplan() Mdulo: sia.c Es llamada desde: controlador() Entrada: lista de planes Salida: lista de planes actualizada Descripcin: saca un elemento de la pila de accion de un plan que esta en la primera posicion de la lista de planes. Libera la memoria
void desapiloplan(NODOLISPLAN** cablisplan) { NODOPLAN* aux; NODOPLAN* aux2; if (verbose) fprintf(stderr, "Valor de cablisplan antes de desapilar %X \n",*cablisplan ); if (verbose) fprintf(stderr, "Valor de cablisplan->info antes de desapilar %X y cablisplan->sig %X\n",(*cablisplan)->info,(*cablisplan)->sig ); aux=(*cablisplan)->info; if (aux!=NULL) { if (((*cablisplan)->sig)!=NULL) (*cablisplan)->info=(*cablisplan)->sig->info; *cablisplan=(*cablisplan)->sig; while(aux!=NULL) { aux2=aux; aux=aux->sig; free(aux2); } } }
196
Pablo M. Maceri
Funcin: llenar_nivel() Mdulo: sia.c Es llamada desde: encsitu_actualizar_luz() LeerSensores() Entrada: vector situacin Salida: vector situacin actualizado Descripcin: llena el vector nivel de luz de acuerdo a los valores del vector luz de la situacion, 0 es oscuridad, 1 es con luz, y 2 es mucha luz
void llenar_nivel(VECTOR *act) { int i; for (i=0;i<=7;i++) { if ((act->luz[i])>400) act->nivel[i]=0; else if ((act->luz[i])>100) act->nivel[i]=1; else act->nivel[i]=2; } }
Pablo M. Maceri
197
Funcin: abrirArchivos() Mdulo: sia.c Es llamada desde: UserCommand() Descripcin: abre los archivos de estadisticas necesarios y graba para cada uno la primera linea con los ttulos
int abrirArchivos() { int i; fprintf(stdout,"Abrir archivos\n"); fdclock=fopen("estad/clock.txt","w"); fprintf(fdclock,"ciclos;hora\n"); fprintf(stdout,"ciclos;hora\n"); fprintf(stdout,"0;%d\n",time(NULL)); fprintf(fdclock,"0;%d\n",time(NULL)); for (i=1;i<=ROBOTS;i++) switch (i) { case 1: estad1=fopen("estad/datos1.txt","a"); fprintf(estad1,"\nciclos;situaciones;teorias;azares;planes;planes sin exito;exitos\n"); break; case 2: estad2=fopen("estad/datos2.txt","a"); fprintf(estad2,"\nciclos;situaciones;teorias;azares;planes;planes sin exito;exitos\n"); break; case 3: estad3=fopen("estad/datos3.txt","a"); fprintf(estad3,"\nciclos;situaciones;teorias;azares;planes;planes sin exito;exitos\n"); break; case 4: estad4=fopen("estad/datos4.txt","a"); fprintf(estad4,"\nciclos;situaciones;teorias;azares;planes;planes sin exito;exitos\n"); break; case 5: estad5=fopen("estad/datos5.txt","a"); fprintf(estad5,"\nciclos;situaciones;teorias;azares;planes;planes sin exito;exitos\n"); break; case 6: estad6=fopen("estad/datos6.txt","a"); fprintf(estad6,"\nciclos;situaciones;teorias;azares;planes;planes sin exito;exitos\n"); break; case 7: estad7=fopen("estad/datos7.txt","a"); fprintf(estad7,"\nciclos;situaciones;teorias;azares;planes;planes sin exito;exitos\n"); break; case 8: estad8=fopen("estad/datos8.txt","a"); fprintf(estad8,"\nciclos;situaciones;teorias;azares;planes;planes sin exito;exitos\n"); break; case 9: estad9=fopen("estad/datos9.txt","a"); fprintf(estad9,"\nciclos;situaciones;teorias;azares;planes;planes sin exito;exitos\n"); break;
198
Pablo M. Maceri
case 10: estad10=fopen("estad/datos10.txt","a"); fprintf(estad10,"\nciclos;situaciones;teorias;azares;planes;planes sin exito;exitos\n"); break; } }
Pablo M. Maceri
199
Funcin: cerrarArchivos() Mdulo: sia.c Es llamada desde: UserCommand() Descripcin: cierra los archivos de estadisticas utilizados
int cerrarArchivos() { int i; fprintf(stdout,"Cerrar archivos\n"); fclose(fdclock); for (i=1;i<=ROBOTS;i++) switch (i) { case 1: fclose(estad1); break; case 2: fclose(estad2); break; case 3: fclose(estad3); break; case 4: fclose(estad4); break; case 5: fclose(estad5); break; case 6: fclose(estad6); break; case 7: fclose(estad7); break; case 8: fclose(estad8); break; case 9: fclose(estad9); break; case 10: fclose(estad10); break; } }
200
Pablo M. Maceri
Funcin: escribirArchivo() Mdulo: sia.c Es llamada desde: StepRobot() Entrada: turno Descripcin: graba una linea de estadistica en el archivo que corresponda al turno
int escribirArchivo(int turno) { if (turno==(ROBOTS-1)) { fprintf(fdclock,"%d;%d\n",pas,time(NULL)); fprintf(stdout,"%d;%d\n",pas,time(NULL)); } switch (turno+1) { case 1: fprintf(estad1,"%d;%d;%d;%d;%d;%d;%f\n",pas,ContarSitu(bases[turno].cabsitu),ContarTeorias(b ases[turno].cabteor), bases[turno].resu.CantidadAzares,bases[turno].resu.CantidadPlanes,bases[turno].resu.Can tidadPlanesSinExito,bases[turno].resu.CantidadTotalExitos); break; case 2: fprintf(estad2,"%d;%d;%d;%d;%d;%d;%f\n",pas,ContarSitu(bases[turno].cabsitu),ContarTeorias(b ases[turno].cabteor), bases[turno].resu.CantidadAzares,bases[turno].resu.CantidadPlanes,bases[turno].resu.Can tidadPlanesSinExito,bases[turno].resu.CantidadTotalExitos); break; case 3: fprintf(estad3,"%d;%d;%d;%d;%d;%d;%f\n",pas,ContarSitu(bases[turno].cabsitu),ContarTeorias(b ases[turno].cabteor), bases[turno].resu.CantidadAzares,bases[turno].resu.CantidadPlanes,bases[turno].resu.Can tidadPlanesSinExito,bases[turno].resu.CantidadTotalExitos); break; case 4: fprintf(estad4,"%d;%d;%d;%d;%d;%d;%f\n",pas,ContarSitu(bases[turno].cabsitu),ContarTeorias(b ases[turno].cabteor), bases[turno].resu.CantidadAzares,bases[turno].resu.CantidadPlanes,bases[turno].resu.Can tidadPlanesSinExito,bases[turno].resu.CantidadTotalExitos); break; case 5: fprintf(estad5,"%d;%d;%d;%d;%d;%d;%f\n",pas,ContarSitu(bases[turno].cabsitu),ContarTeorias(b ases[turno].cabteor), bases[turno].resu.CantidadAzares,bases[turno].resu.CantidadPlanes,bases[turno].resu.Can tidadPlanesSinExito,bases[turno].resu.CantidadTotalExitos); break;
case 6: fprintf(estad6,"%d;%d;%d;%d;%d;%d;%f\n",pas,ContarSitu(bases[turno].cabsitu),ContarTeorias(b ases[turno].cabteor), bases[turno].resu.CantidadAzares,bases[turno].resu.CantidadPlanes,bases[turno].resu.Can tidadPlanesSinExito,bases[turno].resu.CantidadTotalExitos); break; case 7: fprintf(estad7,"%d;%d;%d;%d;%d;%d;%f\n",pas,ContarSitu(bases[turno].cabsitu),ContarTeorias(b ases[turno].cabteor), bases[turno].resu.CantidadAzares,bases[turno].resu.CantidadPlanes,bases[turno].resu.Can tidadPlanesSinExito,bases[turno].resu.CantidadTotalExitos); break; case 8: fprintf(estad8,"%d;%d;%d;%d;%d;%d;%f\n",pas,ContarSitu(bases[turno].cabsitu),ContarTeorias(b ases[turno].cabteor), bases[turno].resu.CantidadAzares,bases[turno].resu.CantidadPlanes,bases[turno].resu.Can tidadPlanesSinExito,bases[turno].resu.CantidadTotalExitos); break; case 9: fprintf(estad9,"%d;%d;%d;%d;%d;%d;%f\n",pas,ContarSitu(bases[turno].cabsitu),ContarTeorias(b ases[turno].cabteor), bases[turno].resu.CantidadAzares,bases[turno].resu.CantidadPlanes,bases[turno].resu.Can tidadPlanesSinExito,bases[turno].resu.CantidadTotalExitos); break; case 10: fprintf(estad10,"%d;%d;%d;%d;%d;%d;%f\n",pas,ContarSitu(bases[turno].cabsitu),ContarTeorias( bases[turno].cabteor), bases[turno].resu.CantidadAzares,bases[turno].resu.CantidadPlanes,bases[turno].resu.Can tidadPlanesSinExito,bases[turno].resu.CantidadTotalExitos); break; } }
202
Pablo M. Maceri
Funcin: cantidadRobots() Mdulo: sia.c Es llamada desde: UserCommand() Entrada: string con la cantidad de robots Salida: entero con la cantidad de robots Descripcin: convierte el string recibido por parmetro a un entero que es la cantidad de robots del sistema
int cantidadRobots(char *text) { if (strcmp(text,"1")==0) return 1; else if (strcmp(text,"2")==0) return 2; else if (strcmp(text,"3")==0) return 3; else if (strcmp(text,"4")==0) return 4; else if (strcmp(text,"5")==0) return 5; else if (strcmp(text,"6")==0) return 6; else if (strcmp(text,"7")==0) return 7; else if (strcmp(text,"8")==0) return 8; else if (strcmp(text,"9")==0) return 9; else if (strcmp(text,"10")==0) return 10; else if (strcmp(text,"cargar")==0) { CARGAR=TRUE; return 1; } }
Pablo M. Maceri
203
204
Pablo M. Maceri
Archivo aprendizaje.c
Pablo M. Maceri
205
206
Pablo M. Maceri
Funcin: RegistrarTeoria() Mdulo: aprendizaje.c Llama a: insersitu() buscar_teoria() insertarteo() MostrarListaTeorias() ponderar_teorias() ponderar_teorias_mutar() recalcular_utilidades() mostrar() Es llamada desde: StepRobot() Entrada: situacin inicial, accin, situacin final, lista de teoras y lista de situaciones Salida: lista de situaciones y teoras actualizada Descripcin: mdulo de aprendizaje, registra y pondera una teora
void RegistrarTeoria(VECTOR si, VECTOR sf, ACCION acc, NODOTEORIA** dir_cabteor, NODOSITU** dir_cabsitu) { boolean encontre; int knuevo,pnuevo,resultado; if (verbose) fprintf (stderr , "REGISTRAR TEORIA \n"); if (verbose) MostrarListaTeorias(*dir_cabteor); if (verbose) { fprintf (stderr , "Entro en insersitu con ... \n"); mostrar (si); } insersitu(dir_cabsitu,si); if (verbose) { fprintf (stderr , "Entro en insersitu con ... \n"); mostrar (sf); } insersitu(dir_cabsitu,sf); /* busca la teoria en la lista de teorias conocidas */ resultado=buscar_teoria(*dir_cabteor,*dir_cabsitu,si,acc,sf,&knuevo,&pnuevo); /* Si resultado=2, existe una teora igual */ if (resultado==2) { /* incrementa el P y K de la teoria igual e incrementa el K de las similares si las hay */ ponderar_teorias(dir_cabteor,*dir_cabsitu,si,acc,sf); } /* Si resultado=1, existe teoria similar pero no igual*/ else if (resultado==1) { /* Incorpora la teora nueva incrementando el knuevo (que es el k de la similar) */ insertarteo(dir_cabteor,si,acc,sf,knuevo+1,1,*dir_cabsitu); /* Pondera las teoras similares y muta */ ponderar_teorias_mutar(dir_cabteor,*dir_cabsitu,si,acc,sf,bmutar); } /* Si resultado=0, no existe una teora igual ni similar*/ else if (resultado==0) { /* registra la teoria con p=1 y k=1 */ pnuevo=1;
knuevo=1; insertarteo(dir_cabteor,si,acc,sf,knuevo,pnuevo,*dir_cabsitu); } if (verbose) MostrarListaTeorias(*dir_cabteor); recalcular_utilidades(dir_cabteor,*dir_cabsitu); if (verbose) MostrarListaTeorias(*dir_cabteor); }
208
Pablo M. Maceri
Funcin: insersitu() Mdulo: aprendizaje.c Llama a: MostrarListaSituaciones() encsitu_actualizar_luz() Es llamada desde: RegistrarTeoria() ponderar_teorias_mutar() intercambiar() copiarteorias() Entrada: lista de situaciones, vector situacin a insertar Salida: lista de situaciones actualizada Descripcin: inserta una situacion en la lista de situaciones
void insersitu(NODOSITU **dir_cabsitu, VECTOR dato) { NODOSITU * cab; unsigned int cant; if (! encsitu_actualizar_luz(dir_cabsitu,dato,&cant)) { if (verbose) fprintf (stderr , "No encontre situacion. La agrego como %d \n",cant+1); if (*dir_cabsitu == NULL) { if (verbose) fprintf (stderr , "Hago el pedido de memoria por primera vez ... \n"); (*dir_cabsitu) =(NODOSITU*) malloc(sizeof(NODOSITU)); (*dir_cabsitu)->sig=NULL; (*dir_cabsitu)->situ=dato; (*dir_cabsitu)->nro=cant+1; } else { cab=*dir_cabsitu; while (cab->sig != NULL) { cab=cab->sig; } if (verbose) fprintf (stderr , "Hago el pedido de memoria ... \n"); cab->sig=(NODOSITU*) malloc(sizeof(NODOSITU)); if (verbose) fprintf (stderr , "Ya tengo la memoria ... \n"); cab->sig->sig=NULL; cab->sig->situ=dato; cab->sig->nro=cant+1; } } if (verbose) MostrarListaSituaciones(*dir_cabsitu); }
Pablo M. Maceri
209
Funcin: MostrarListaSituaciones() Mdulo: aprendizaje.c Llama a: situ_sig() situ_vacio() Es llamada desde: UserCommand() insersitu() intercambiar() Entrada: lista de situaciones conocidas Descripcin: imprime el contenido de situaciones conocidas.
void MostrarListaSituaciones (NODOSITU * cabsitu) { int i; NODOSITU * aux; aux=cabsitu; while (! situ_vacio(aux)) { fprintf(stderr,"Posicion %d ", aux->nro); for( i = 0; i < 8; i ++) { fprintf(stderr,"%d ", aux->situ.sensor[i]); } fprintf(stderr," nivel: "); for( i = 0; i < 8; i ++) { fprintf(stderr,"%d ", aux->situ.nivel[i]); } fprintf(stderr," luz: "); for( i = 0; i < 8; i ++) { fprintf(stderr,"%d ", aux->situ.luz[i]); } fprintf(stderr,"\n"); situ_sig(&aux); } }
210
Pablo M. Maceri
Funcin: situ_sig() Mdulo: aprendizaje.c Es llamada desde: MostrarListaSituaciones() encsitu() encsitu_actualizar_luz() cruza() cruza2() ContarSitu() Entrada: puntero de lista de situaciones Salida: puntero actualizado Descripcin: avanza al siguiente elemento en la lista de situaciones conocidas
void situ_sig(NODOSITU** cabsitu) { *cabsitu=(*cabsitu)->sig; }
Pablo M. Maceri
211
Funcin: encsitu() Mdulo: aprendizaje.c Llama a: situ_sig() iguales() Entrada: lista de situaciones conocidas, vector situacin Salida: TRUE o FALSE y el nmero de posicin de la situacin encontrada Descripcin: busca la situacion recibida como dato en el segundo parametro y devuelve TRUE si la encontro mas el numero de posicion dentro de la lista de situaciones en el tercer parametro
boolean encsitu(NODOSITU* cabesitu, VECTOR dato, unsigned int* cant) { boolean encontre; boolean encsitu_result; encontre=FALSE; *cant=0; while ((cabesitu!=NULL) && (! encontre)) if (iguales(cabesitu->situ,dato)) encontre=TRUE; else { situ_sig(&cabesitu); *cant=*cant+1; } encsitu_result=encontre; return encsitu_result; }
212
Pablo M. Maceri
Funcin: encsitu_actualizar_luz() Mdulo: aprendizaje.c Llama a: situ_sig() iguales() llenar_nivel() Es llamada desde: insersitu() Entrada: lista de situaciones conocidas, vector situacin Salida: TRUE o FALSE y el nmero de posicin de la situacin encontrada Descripcin: igual que encsitu() pero ademas si encuentra la situacion actualiza los valores de la luz calculando un promedio con la nueva situacion
boolean encsitu_actualizar_luz(NODOSITU** cabsitu, VECTOR dato, unsigned int* cant) { boolean encontre; boolean encsitu_result; NODOSITU* cab=*cabsitu; int i; div_t prom; encontre=FALSE; *cant=0; while ((cab!=NULL) && (! encontre)) if (iguales(cab->situ,dato)) { encontre=TRUE; for (i=0;i<8;i++) { prom=div(cab->situ.luz[i] + dato.luz[i],2); cab->situ.luz[i]=prom.quot; } llenar_nivel(&(cab->situ)); } else { situ_sig(&cab); *cant=*cant+1; } encsitu_result=encontre; return encsitu_result; }
Pablo M. Maceri
213
Funcin: buscar_teoria() Mdulo: aprendizaje.c Llama a: cruza() Es llamada desde: RegistrarTeoria() ponderar_teorias_mutar() intercambiar() Entrada: listas de teoras y de situaciones, situacin inicial, accin situacion final Salida: devuelve 0 si no existe una teoria ni similar ni igual registrada, 1 si existe una teoria similar registrada (y no existe igual) y guarda el k en el parametro knuevo, y 2 si existe una teoria igual registrada y guarda el p en el parametro pnuevo Descripcin: busca una teora en la lista de teoras registradas
int buscar_teoria(NODOTEORIA* cab,NODOSITU* cabsitu, VECTOR si, ACCION acc, VECTOR sf,int *knuevo,int *pnuevo) { boolean igual,similar; int buscoi,buscof,resul; igual=FALSE; similar=FALSE; if (verbose) fprintf (stderr , "Entro a buscar_teoria \n"); buscoi=cruza(cabsitu,si); buscof=cruza(cabsitu,sf); while (cab!=NULL) { if (cab->te.si==buscoi) { if (cab->te.ac.valor==acc.valor) { similar=TRUE; *knuevo=cab->te.k; if (cab->te.sf==buscof) { igual=TRUE; *pnuevo=cab->te.p; } } } cab=cab->sig; } if (igual==TRUE) resul=2; else if (similar==TRUE) resul=1; else resul=0; if (verbose) fprintf (stderr , "Salgo de buscar_teoria con %d , p=%d, k=%d \n",resul,*pnuevo,*knuevo); return resul; }
214
Pablo M. Maceri
Funcin: insertarteo() Mdulo: aprendizaje.c Llama a: calculoutil() MostrarListaTeorias() cruza() Es llamada desde: RegistrarTeoria() ponderar_teorias_mutar() intercambiar() copiarteorias() Entrada: listas de teoras y situaciones, situacin inicial, accin, situacin final, p y k Salida: lista de teoras actualizada Descripcin: agrega un nuevo nodo a la lista de teorias.
void insertarteo(NODOTEORIA** dir_cabteor, VECTOR si, ACCION acc, VECTOR sf, int knuevo, int pnuevo, NODOSITU* cabsitu) { NODOTEORIA * cab; if (*dir_cabteor ==NULL) { (*dir_cabteor) =(NODOTEORIA*) malloc(sizeof(NODOTEORIA)); (*dir_cabteor)->te.si=cruza(cabsitu,si); (*dir_cabteor)->te.ac=acc; (*dir_cabteor)->te.sf=cruza(cabsitu,sf); (*dir_cabteor)->te.p=pnuevo; (*dir_cabteor)->te.k=knuevo; (*dir_cabteor)->te.u=calculoutil(si,sf); (*dir_cabteor)->sig=NULL; } else { cab=*dir_cabteor; while (cab->sig!=NULL) cab=cab->sig; cab->sig =(NODOTEORIA*) malloc(sizeof(NODOTEORIA)); cab=cab->sig; cab->te.si=cruza(cabsitu,si); cab->te.ac=acc; cab->te.sf=cruza(cabsitu,sf); cab->te.p=pnuevo; cab->te.k=knuevo; cab->te.u=calculoutil(si,sf); cab->sig=NULL; } }
Pablo M. Maceri
215
Funcin: calculoutil() Mdulo: aprendizaje.c Es llamada desde: insertarteo() recalcular_utilidades() Entrada: dos vectores situacin Salida: devuelve un real entre 1 y 1 Descripcin: calcula la utilidad de una teora segn la cantidad de luz ambiente que tiene la situacin final. Si el nivel de luz es alto retorna un valor cercano a 1, si la situacin final se encuentra en la oscuridad devuelve un valor cercano a 1.
float calculoutil(VECTOR a, VECTOR b) { int suma1=0,i=0; float calc_result; //suma los 8 sensores, aunque en el manual dice que cada uno //toma valores entre 50 y 500, en realidad pude observar que //toma valores entre 0 y 550 for( i = 0; i < 8; i ++) { suma1=suma1+ b.luz[i]; } //la suma total tiene un rango de 0 (mucha luz) a 4400 (oscuridad) //entonces lo transformo a un rango de -2200 (oscuridad) a 2200 (mucha luz) calc_result=2200-suma1; //ahora lo mapeo al rango -1 a 1 calc_result=calc_result/2200; if (verbose) fprintf (stderr , "Resultado=%f \n",calc_result); return calc_result; }
216
Pablo M. Maceri
Funcin: MostrarListaTeorias() Mdulo: aprendizaje.c Llama a: teo_vacio() Es llamada desde: UserCommand() RegistrarTeoria() insertarteo() intercambiar() Entrada: lista de teoras registradas Descripcin: imprime el contenido de la lista de teorias
void MostrarListaTeorias (NODOTEORIA * cabteor) { int i=1; NODOTEORIA * aux; aux=cabteor; while (! teo_vacio(aux)) { fprintf(stderr,"Teoria %2d = ",i); fprintf(stderr," %2d -> %2d -> %2d p:%d k:%d u:%f \n",aux->te.si,aux>te.ac.valor,aux->te.sf,aux->te.p, aux->te.k,aux->te.u); teo_sig(&aux); i++; } }
Pablo M. Maceri
217
Funcin: ponderar_teorias() Mdulo: aprendizaje.c Llama a: cruza() Es llamada desde: RegistrarTeoria() ponderar_teorias_mutar() Entrada: listas de teoras y situaciones, situacin inicial, accin, situacin final Salida: lista de teoras actualizada Descripcin: incrementar el p y el k de una teoria e incrementa el k de las similares
void ponderar_teorias(NODOTEORIA** dir_cabteor,NODOSITU* cabsitu, VECTOR si,ACCION acc, VECTOR sf) { unsigned buscoi, buscof; NODOTEORIA *cab=*dir_cabteor; if (verbose) fprintf (stderr , "Entro a ponderar_teorias \n"); buscoi=cruza(cabsitu,si); buscof=cruza(cabsitu,sf); while (cab!=NULL) { if (cab->te.si==buscoi) { if (cab->te.ac.valor==acc.valor) { cab->te.k=cab->te.k+1; if (cab->te.sf==buscof) { cab->te.p=cab->te.p+1; } } } cab=cab->sig; } }
218
Pablo M. Maceri
Funcin: ponderar_teorias_mutar() Mdulo: aprendizaje.c Llama a: insersitu() buscar_teoria() insertarteo() ponderar_teorias() mutar_situacion() cruza() cruza2() mostrar() Es llamada desde: RegistrarTeoria() Entrada: listas de teoras y situaciones, situacin inicial, accin, situacin final Salida: lista de teoras actualizada Descripcin: busca las teoras similares incrementando el k y mutandolas. Luego incorpora la teora. Se llama a s misma para hacer lo mismo con las teoras mutadas pero sin volverlas a mutar.
void ponderar_teorias_mutar(NODOTEORIA** dir_cabteor,NODOSITU* cabsitu, VECTOR si,ACCION acc, VECTOR sf, boolean mutar) { unsigned buscoi,buscof; int resul,knuevo,pnuevo; VECTOR sit,smutada; NODOTEORIA *cab=*dir_cabteor; boolean terminar=FALSE; /* lo uso para que cuando llegue a la teoria que inserto no siga porque si inserto una nueva teoria mutante le va a seguir sumando el k y esta mal */ if (verbose) fprintf (stderr , "Entro a ponderar_teorias_mutar con cab=%X y mutar=%d\n",cab,mutar); buscoi=cruza(cabsitu,si); buscof=cruza(cabsitu,sf); while ((cab!=NULL)&&(terminar==FALSE)) { if (cab->te.si==buscoi) { if (cab->te.ac.valor==acc.valor) { if (cab->te.sf==buscof) terminar=TRUE; else { /* incrementa el k de la teoria similar */ cab->te.k=cab->te.k+1; /* si corresponde muta e inserta la situacion mutada */ /* hace una retraccion en donde los bits que no coinciden de las dos situaciones finales los invierte */ if (mutar==TRUE) { if (verbose) fprintf (stderr , "Muta\n"); cruza2(cabsitu,cab->te.sf,&sit); mutar_situacion(sf,sit,&smutada); if (verbose) mostrar(si); if (verbose) fprintf (stderr , "accion:%d\n",acc.valor); if (verbose) mostrar(smutada);
insersitu(&cabsitu,smutada); /* busca la teoria mutante en la lista de teorias conocidas */ resul=buscar_teoria(*dir_cabteor,cabsitu,si,acc,smutada,&knuevo,&pnuevo); /* Si resul=2, existe una teora igual */ if (resul==2) { ponderar_teorias(dir_cabteor,cabsitu,si,acc,smutada); } /* Si resul=1, existe teoria similar */ else if (resul==1) { /* Incorpora la teora nueva */ insertarteo(dir_cabteor,si,acc,smutada,knuevo+1,1,cabsitu); /* Pondera las teoras similares */ ponderar_teorias_mutar(dir_cabteor,cabsitu,si,acc,smutada,FALSE); } } } } } cab=cab->sig; } if (verbose) fprintf (stderr , "Salgo de ponderar_teorias_mutar con cab=%X y mutar=%d\n",cab,mutar); }
220
Pablo M. Maceri
Funcin: mutar_situacion() Mdulo: aprendizaje.c Es llamada desde: ponderar_teorias_mutar() Entrada: dos vectores situacin Salida: vector situacin que es el resultado de la mutacin Descripcin: muta dos vectores situaciones de manera que para cada posicin si tienen el mismo valor se deja igual, sino se le asigna un valor al azar (0 1)
void mutar_situacion(VECTOR s1, VECTOR s2, VECTOR *smutada) { int i; double aux; for (i=0;i<8;i++) { if (s1.sensor[i]==s2.sensor[i]) (*smutada).sensor[i]=s1.sensor[i]; /* es igual a s2 tambien */ else { aux=(double)rand()/(double)RAND_MAX; if (aux<=.5) (*smutada).sensor[i]=0; else /* <=1 */ (*smutada).sensor[i]=1; } (*smutada).luz[i]=s1.luz[i]; (*smutada).nivel[i]=s1.nivel[i]; } }
Pablo M. Maceri
221
Funcin: verificar_consistencia() Mdulo: aprendizaje.c Es llamada desde: StepRobot() UserCommand() Entrada: lista de teoras y lista de situaciones Salida: TRUE o FALSE Descripcin: chequea que los p y los k de la lista de teorias verifique que para teorias similares las suma de sus p sea igual al k de cualquiera de ellas
boolean verificar_consistencia(NODOTEORIA** dir_cabteor,NODOSITU* cabsitu) { int si1, sf1,si2,sf2; ACCION ac1,ac2; NODOTEORIA *cabteor1=*dir_cabteor; NODOTEORIA *cabteor2=*dir_cabteor; boolean ok=TRUE; int k,p,iguales; if (verbose) fprintf (stderr , "Entro a verificar_consistencia \n"); while ((cabteor1!=NULL)&&(ok==TRUE)) { cabteor2=*dir_cabteor; iguales=0; p=0; k=cabteor1->te.k; si1=cabteor1->te.si; ac1.valor=cabteor1->te.ac.valor; while (cabteor2!=NULL) { si2=cabteor2->te.si; ac2.valor=cabteor2->te.ac.valor; if (si1==si2) { if (ac1.valor==ac2.valor) { p=p+cabteor2->te.p; if (cabteor1->te.sf==cabteor2->te.sf) { iguales++; if (iguales>1) ok=FALSE; } } } cabteor2=cabteor2->sig; } if (verbose) fprintf (stderr , "p=%d k=%d iguales=%d\n",p,k,iguales); if (p!=k) ok=FALSE; cabteor1=cabteor1->sig; }
return ok; }
Pablo M. Maceri
223
Funcin: recalcular_utilidades() Mdulo: aprendizaje.c Llama a: calculoutil() cruza2() Es llamada desde: RegistrarTeoria() intercambiar() Entrada: lista de teoras y lista de situaciones Salida: listas de teoras y situaciones actualizadas Descripcin: vuelve a calcular la utilidad para cada una de las teorias
void recalcular_utilidades(NODOTEORIA** dir_cabteor,NODOSITU* cabsitu) { NODOTEORIA *cab=*dir_cabteor; VECTOR si,sf; if (verbose) fprintf (stderr , "Recalculando utilidades... \n"); while (cab!=NULL) { cruza2(cabsitu,cab->te.si,&si); cruza2(cabsitu,cab->te.sf,&sf); if (verbose) fprintf(stderr,"util antes:%f ",cab->te.u); cab->te.u=calculoutil(si,sf); if (verbose) fprintf(stderr,"despues:%f\n",cab->te.u); cab=cab->sig; } if (verbose) fprintf (stderr , "Fin recalculando utilidades \n"); }
224
Pablo M. Maceri
Archivo controlador.c
Pablo M. Maceri
225
226
Pablo M. Maceri
Funcin: controlador() Mdulo: controlador.c Llama a: planificador() MostrarPlan() cruza() desapiloplan() Es llamada desde: StepRobot() Entrada: lista de teoras,lista de situaciones, lista de planes, vector situacin actual Descripcin: mdulo controlador. Si existe un plan en ejecucin y la situacin actual es la situacin esperada por el plan contina con la ejecucin del mismo, sino llama al planificador para volver a planificar. Si el planificador no devuelve ningn plan se crea un plan con una accin al azar.
void controlador(NODOLISPLAN** cablisplan, NODODESE** topedese, NODOTEORIA* cabteor, ARBO** cabarbo, NODOSITU* cabsitu, VECTOR situinicial, VECTOR actual,tresu* resu,tseteos* estado) { double aux; ACCION acc; int sa; float exitos,longi; int i; NODOPLAN * nuevonodo; NODOPLAN * anterior; NODOLISPLAN* cablisplanaux; if (verbose) fprintf(stderr, "Entro en Controlador ...\n" ); cablisplanaux=*cablisplan; while (cablisplanaux!=NULL) { if (verbose) MostrarPlan(cablisplanaux->info); cablisplanaux=cablisplanaux->sig; } sa=cruza(cabsitu,actual); /* Si existe un plan en ejecucin */ if (bases[turno].ejecutandoPlan==TRUE) { if (verbose) fprintf(stderr, "Estoy ejecutando un plan... \n" ); /* Si estoy en la situacin esperada por el plan */ if (sa==bases[turno].situesperada) /* si el plan no termino sigue, sino lo contabiliza como exitoso */ if (((*cablisplan)!=NULL) && ((*cablisplan)->info != NULL)) { if (verbose) fprintf(stderr, "El plan sigue ... exitos: %d , total exitos: %2f\n",resu->CantidadExitos,resu->CantidadTotalExitos); resu->CantidadExitos=(resu->CantidadExitos)+1; return; } else { resu->CantidadTotalExitos=(resu->CantidadTotalExitos)+1;
if (verbose) fprintf(stderr, "El plan termino ... total exitos: %2f\n",resu->CantidadTotalExitos); } /* sino aborta el plan */ else { (resu->CantidadPlanesSinExito)++; exitos=resu->CantidadExitos; longi=resu->LongitudPlanActual; resu->CantidadTotalExitos=(resu->CantidadTotalExitos)+(exitos/longi); if (verbose) fprintf(stderr, "Se aborta el plan! sin exito: %d , total exitos: %2f\n",resu->CantidadPlanesSinExito,resu->CantidadTotalExitos); } } /* ac llega si termino el plan, abort el plan o no existe plan */ resu->CantidadExitos=0; resu->LongitudPlanActual=0; /* planifica */ planificador(cabarbo,cabsitu,cablisplan,cabteor,topedese,sa,resu,estado);
if (((*cablisplan) == NULL) || ((*cablisplan)->info == NULL)) { /*******************************************************************/ /* Al entrar aqui no pudo armar ningun plan bueno, por lo tanto */ /* usa plan de contingencia. */ /*******************************************************************/ if (verbose) fprintf(stderr, "Planifico por azar \n" ); if ((*cablisplan) == NULL) *cablisplan= (NODOLISPLAN*) malloc(sizeof(NODOLISPLAN)); (*cablisplan)->info= (NODOPLAN*) malloc(sizeof(NODOPLAN)); resu->CantidadAzares++; bases[turno].ejecutandoPlan=FALSE; if ((*cablisplan)->info==NULL) { if (verbose) fprintf (stderr,"Sonamos antes ..."); exit(1); } (*cablisplan)->sig= NULL; aux=(double)rand()/(double)RAND_MAX; if ( aux < .1 ) acc.valor=3; else if ( aux < .2 ) acc.valor=2; else acc.valor=1; ((*cablisplan)->info)->acc=acc; ((*cablisplan)->info)->si=1; ((*cablisplan)->info)->sf=1; ((*cablisplan)->info)->sig=NULL; anterior=(*cablisplan)->info; if (verbose) MostrarPlan (anterior); (*cablisplan)->info=anterior; } else
{ resu->CantidadPlanes++; bases[turno].ejecutandoPlan=TRUE; } if (verbose) fprintf(stderr, "Salgo del Controlador ...\n" ); cablisplanaux=*cablisplan; while (cablisplanaux!=NULL) { if (verbose) MostrarPlan(cablisplanaux->info); cablisplanaux=cablisplanaux->sig; } }
Pablo M. Maceri
229
230
Pablo M. Maceri
Archivo planificador.c
Pablo M. Maceri
231
232
Pablo M. Maceri
Funcin: planificador() Mdulo: planificador.c Llama a: ponderador() armopila() desapilodese() MostrarArbol() borrararbol() borroteoriasaux() insertar_teoriaaux() armo_plan() borrolista() borroaux2() BuscarTeoriaDese() Es llamada desde: controlador() Entrada: lista de situaciones, lista de teoras y situacin actual Salida: lista de planes Descripcin: mdulo planificador donde se arma la lista de situaciones deseable. Con cada situacin deseable se trata de encontrar un plan aceptable armando el rbol de situaciones y luego ponderando el plan encontrado.
void planificador(ARBO** cabarbo, NODOSITU* cabsitu, NODOLISPLAN** cablisplan,NODOTEORIA* cabteor,NODODESE** topedese,int situactual,tresu* resu,tseteos* estado) { NODOTEORIAAUX* cabteoraux=NULL; int cantramas=0; int longplan; NODOAUX2* cabaux=NULL; NODOTEORIA* teordese; int longaux=0; NODOLISPLAN* cablisplanaux; boolean descartar=TRUE; if (verbose) fprintf(stderr,"Estoy en planificador con Situacion Actual: %d\n",situactual); longitud=0; resu->CantidadExitos=0; resu->LongitudPlanActual=0; /* borro el plan si existe */ if (*cablisplan != NULL) borrolista(cablisplan,&longplan); /* borro el arbol de situaciones */ if (verbose) fprintf(stderr,"Entro en BorrarArbol...\n"); borrararbol(cabarbo); /* borro la pila de situaciones deseables */ if (verbose) fprintf(stderr,"Entro en borropiladese...\n"); borropiladese(topedese); /* Armo la pila de situaciones deseables */ if (verbose) fprintf(stderr,"Entro a armar pila de situaciones deseables.\n"); armopila(cabteor,topedese,cabsitu); if (verbose) fprintf(stderr,"Salgo de armar pila de situaciones deseables.\n"); /* Mientras existan situaciones deseables y no existe una situacin objetivo */ while ((!desevacia(*topedese))&&(*cablisplan==NULL)&&(descartar==TRUE)) { if (verbose) fprintf(stderr,"Tomo el tope de la pila de situaciones deseables: %d\n",(*topedese)->dese); BuscarTeoriaDese(cabteor,*topedese,&teordese);
/* si no estoy ya en la situacin objetivo, trato de armar planes */ if (situactual!=teordese->te.sf) { /* Creo la lista auxiliar para evitar ciclos al armar el arbol */ cabteoraux=(NODOTEORIAAUX*) malloc(sizeof(NODOTEORIAAUX)); cantramas=0; cabteoraux->si=0; cabteoraux->sf=0; cabteoraux->sig=NULL; insertar_teoriaaux(teordese->te.si,teordese->te.ac.valor,teordese>te.sf,cabteoraux); /* Tomo como raiz del arbol la cima de la pila */ *cabarbo=(ARBO*) malloc(sizeof(ARBO)); /*creo el nodo raiz*/ (bases[turno].contarbo)++; (*cabarbo)->info=teordese->te.si; (*cabarbo)->punhijo=NULL; /* armo el arbol de situaciones */ if (verbose) fprintf(stderr,"Entro a armar arbol de situaciones con *cabarbo=%X cabsitu=%X cabteor=%X cabteoraux=%X (*topedese)->dese=%X cantramas=%d.\n",*cabarbo,cabsitu,cabteor,cabteoraux,(*topedese)->dese,cantramas); armar_arbol(cabarbo,cabsitu,cabteor,cabteoraux,teordese>te.si,&cantramas,situactual); if (verbose) fprintf(stderr,"Salgo de armar arbol de situaciones con situactual=%d y cabarbo->info=%d.\n",situactual,(*cabarbo)->info); if (verbose) fprintf(stderr,"y con *cabarbo=%X cabsitu=%X cabteor=%X cabteoraux=%X (*topedese)->dese=%X cantramas=%d.\n",*cabarbo,cabsitu,cabteor,cabteoraux,(*topedese)>dese,cantramas); borroteoriasaux(&cabteoraux); if (verbose) fprintf (stderr, "Estructura del arbol:\n"); if (verbose) MostrarArbol(*cabarbo,0); longaux=0; longplan=65535; if (verbose) fprintf(stderr, "Entrando a ArmoPlan con %X %d %X %X %X %d %d \n",*cabarbo,situactual,(*cabarbo)->punhijo, cablisplan,cabaux,longplan,longaux ); armo_plan(*cabarbo,situactual,(*cabarbo)>punhijo,cablisplan,&cabaux,&longplan, &longaux); borroaux2(&cabaux); } else { if (verbose) fprintf (stderr, "Ya me encuentro en la situacion objetivo.\n"); } /* si pudo armar un plan hay situacion objetivo y le agrega la accin de la primera teora*/ if (*cablisplan != NULL) { if (verbose) { fprintf (stderr, "Hizo un plan !!!"); }
AgregarAccion(cablisplan,teordese); longplan=longplan+1; bases[turno].longtot=bases[turno].longtot+longplan; if (verbose) { cablisplanaux=*cablisplan; while (cablisplanaux!=NULL) { MostrarPlan(cablisplanaux->info); cablisplanaux=cablisplanaux->sig; } cablisplanaux=NULL; } } /* sino pudo armar un plan pero la situacin actual es la inicial de la teoria deseable, crea un plan con la accion de la teora deseable */ else if ((*cablisplan == NULL)&&(situactual==teordese->te.si)&&(situactual!=teordese>te.sf)) { if (verbose) fprintf (stderr, "No Hizo un plan pero agrega teoria deseable!!!"); *cablisplan=(NODOLISPLAN*) malloc(sizeof(NODOLISPLAN)); (*cablisplan)->sig=NULL; longplan=1; (*cablisplan)->info=(NODOPLAN*) malloc(sizeof(NODOPLAN)); (*cablisplan)->info->si=teordese->te.si; (*cablisplan)->info->sf=teordese->te.sf; (*cablisplan)->info->acc.valor=teordese->te.ac.valor; (*cablisplan)->info->sig=NULL; } /* si llega ac con un plan lo pondera */ if (*cablisplan != NULL) { /* pondera planes */ if (ponderar) { if (*cablisplan==NULL) { if (verbose) fprintf(stderr, "La cabeza de lista de planes es Nula\n" ); descartar=TRUE; } else descartar=FALSE; if (estado->pondera==TRUE) { if (!descartar) { descartar=ponderador((*cablisplan)->info, cabsitu, &(estado>rangoponde), cabteor); } while ((descartar) && ((*cablisplan)!=NULL)) { desapiloplan(cablisplan);
if ((*cablisplan)!=NULL) descartar=ponderador((*cablisplan)->info, cabsitu, &(estado->rangoponde), cabteor); } if (descartar==TRUE) { if (verbose) fprintf(stderr,"Los planes armados con situacion deseable %d no son confiables (se descartan)\n",(*topedese)->dese); if (verbose) fprintf (stderr, "Borro el arbol de situaciones.\n"); borrararbol(cabarbo); longplan=65535; if (verbose) fprintf (stderr, "Desapilo...\n"); desapilodese(topedese); } } } } /* sino pudo armar un plan prueba con la prxima situacin deseable */ else { if (verbose) fprintf(stderr,"No se pudo armar un plan con situacion deseable: %d\n",(*topedese)->dese); if (verbose) fprintf (stderr, "Borro el arbol de situaciones.\n"); borrararbol(cabarbo); longplan=65535; if (verbose) fprintf (stderr, "Desapilo...\n"); desapilodese(topedese); } } if (verbose) fprintf(stderr,"\nSaliendo del planificador\n"); cablisplanaux=*cablisplan; while (cablisplanaux!=NULL) { if (verbose) MostrarPlan(cablisplanaux->info); cablisplanaux=cablisplanaux->sig; } cablisplanaux=NULL; resu->LongitudPlanActual=longplan; }
236
Pablo M. Maceri
Funcin: armopila() Mdulo: planificador.c Llama a: creolistaorde() MostrarListaOrdenada() pasoapila() borrolistaaux() Es llamada desde: planificador() Entrada: lista de teoras, lista de situaciones Salida: lista de situaciones deseables Descripcin: arma la pila de situaciones deseables
void armopila(NODOTEORIA* cate,NODODESE** tode,NODOSITU* cabsitu) { NODOAUX* cabaux; cabaux=NULL; if (verbose) fprintf(stderr, " Entro en CreoListaOrde .\n" ); if (verbose) fprintf(stderr, " con %X %X %X \n",cate,&cabaux,cabsitu); creolistaorde(cate,&cabaux,cabsitu); if (verbose) fprintf(stderr, " Entro en PasoAPila ...\n" ); pasoapila(cabaux,tode,cabsitu); if (verbose) MostrarListaOrdenada (cabaux); if (verbose) fprintf(stderr, " Entro en BorroListaAux .\n" ); borrolistaaux(&cabaux); }
Pablo M. Maceri
237
Funcin: creolistaorde() Mdulo: planificador.c Llama a: insertoaux() MostrarListaOrdenada() teo_vacio() Es llamada desde: armopila() Entrada: lista de situaciones y lista de teoras Salida: lista auxiliar de situaciones ms tiles Descripcin: crea la lista auxiliar de situaciones ms tiles ordenadas
void creolistaorde(NODOTEORIA* cate,NODOAUX** cabaux,NODOSITU* cabsitu) { if (teo_vacio(cate)) *cabaux=NULL; else { while (!teo_vacio(cate)) { /*una situacion es deseable si es situacion inicial o final de una teoria que tiene un nivel de utilidad positiva*/ if (cate->te.u>0) { if (verbose) fprintf(stderr, " Entro en InsertoAux con %X %X %X \n",cate,cabaux,cabsitu); if (verbose) MostrarListaOrdenada(*cabaux); /* inserto la situacion final */ insertoaux(cate,cabaux,cabsitu,cate->te.sf); if (verbose) fprintf(stderr, " Salgo de InsertoAux con %X %X %X \n",cate,cabaux,cabsitu); if (verbose) MostrarListaOrdenada(*cabaux); } teo_sig(&cate); } } }
238
Pablo M. Maceri
Funcin: insertoaux() Mdulo: planificador.c Llama a: modiutil() encontre() posiciono() Es llamada desde: creolistaorde() Entrada: lista de teoras, lista de situaciones, lista auxiliar de situaciones deseables y nmero de situacin a insertar Salida: lista auxiliar de situaciones deseables actualizada Descripcin: inserta un nodo en la lista auxiliar de situaciones deseables ordenadas
void insertoaux(NODOTEORIA* cate,NODOAUX** cabeza,NODOSITU* cabsitu,int situdese) { NODOAUX* punt2; NODOAUX* puntero; NODOAUX* pteroant; float ut; /* si la lista auxiliar est vacia, lo inserta directamente */ if (verbose) fprintf(stderr, " Estoy en InsertoAux con %X %X %X \n",cate,cabeza,cabsitu); if (*cabeza == NULL) { if (verbose) fprintf(stderr, " Creo el primer elemento de la lista.\n"); *cabeza=(NODOAUX*) malloc(sizeof(NODOAUX)); (bases[turno].contnodoaux)++; (*cabeza)->sig=NULL; (*cabeza)->info=situdese; (*cabeza)->ut=cate->te.u; } else { /*si es el 1ero de todos devuelvo NULL, me posiciono en la lista de auxiliares en el anterior de utilidad menor*/ /* si ya existe en la lista le cambia la utilidad */ if (verbose) fprintf(stderr, " Ya existe la cabeza de la lista.\n"); if (encontre(*cabeza,situdese,&puntero,cabsitu)) { if (verbose) fprintf(stderr, " Lo encontre.\n"); modiutil(cabeza,puntero,&(cate->te.u)); if (verbose) fprintf(stderr, " Lo modifique.\n"); } /* si no existe en la lista, se posiciona e inserta */ else { pteroant=posiciono(*cabeza,&(cate->te.u)); if (pteroant==NULL) { /* Este es el caso que inserto el elemento adelante de la cabeza original creada, es por eso que se modifica la */ if (verbose) fprintf(stderr, " Agrego un elemento al principio.\n"); pteroant=(NODOAUX*) malloc(sizeof(NODOAUX)); (bases[turno].contnodoaux)++; pteroant->sig=*cabeza; *cabeza=pteroant; (*cabeza)->info=situdese; (*cabeza)->ut=cate->te.u;
} else { if (verbose) fprintf(stderr, " corresponde.\n"); punt2=pteroant->sig; pteroant->sig=(NODOAUX*) malloc(sizeof(NODOAUX)); (bases[turno].contnodoaux)++; pteroant->sig->info=situdese; pteroant->sig->ut=cate->te.u; pteroant->sig->sig=punt2; } } } } Agrego un elemento donde
240
Pablo M. Maceri
Funcin: modiutil() Mdulo: planificador.c Llama a: posiciono() MostrarListaOrdenada() Es llamada desde: insertoaux() Entrada: lista auxiliar de situaciones deseables, situacin u utilidad a modificar Saldia: lista auxiliar de situaciones deseables actualizada Descripcin: modifica la utilidad de una situacion
void modiutil(NODOAUX** cabaux,NODOAUX* punelem,float* util) { NODOAUX* pteroaux; NODOAUX* punt2; NODOAUX* micab; if (verbose) fprintf (stderr," Estoy en ModiUtil con %X %X %f \n",cabaux,punelem,util);
/* modifica la utilidad si es mayor a la actual */ if (*util>punelem->ut) { /* se posiciona en la lista auxiliar */ if (verbose) fprintf (stderr," Me posiciono\n"); pteroaux=posiciono(*cabaux,util); if (verbose) fprintf (stderr," Me posicione en %X\n",pteroaux); /*si la posicion buscada da igual a la actual debo modificarle la utilidad solamente ya que esta ordenado todavia, sino tengo que crear el nodo ordenado y despues borro al anterior*/ if (pteroaux==punelem) punelem->ut=*util; else { /*Lo insertamos */ if (verbose) { fprintf(stderr, "Muestro la lista antes de insertar.\n"); MostrarListaOrdenada(*cabaux); } punt2=pteroaux->sig; (pteroaux->sig)=(NODOAUX*) malloc(sizeof(NODOAUX)); (bases[turno].contnodoaux)++; (pteroaux->sig)->info=punelem->info; (pteroaux->sig)->ut=*util; (pteroaux->sig)->sig=punt2; if (verbose) { fprintf(stderr, "Muestro la lista despues de insertar y antes de borrar.\n"); MostrarListaOrdenada(*cabaux); } /*Borramos el anterior*/ /*Si el elemento a borrar es el 1ero de la lista*/ if ((*cabaux)==punelem) { micab=*cabaux; *cabaux=(*cabaux)->sig;
if (verbose) fprintf (stderr," Voy a liberar 1ro %X \n",micab); free(micab); (bases[turno].contnodoaux)--; if (verbose) fprintf (stderr," Ya libere el 1ro.\n"); } else { micab=*cabaux; while ((micab->sig != punelem) && (micab->sig != NULL)) micab=micab->sig; if (micab->sig != NULL) { micab->sig=punelem->sig; /*le asigno el siguiente elemento del que borre */ if (verbose) fprintf (stderr," %X \n",punelem); free(punelem); (bases[turno].contnodoaux)--; if (verbose) fprintf (stderr," Ya libere el elemento N.\n"); } } if (verbose) { fprintf(stderr, "Muestro la lista despues de insertar y despues de borrar.\n"); MostrarListaOrdenada(*cabaux); } } } } Voy a liberar un elemento
242
Pablo M. Maceri
Funcin: encontre() Mdulo: planificador.c Llama a: aux_vacio() Es llamada desde: insertoaux() Entrada: lista auxiliar de situaciones deseables, nmero de situacin a encontrar y lista de situaciones Salida: TRUE o FALSE y puntero a la situacin encontrada Descripcin: devuelve TRUE si encuentra la situacion sitfin en la lista auxiliar de situaciones deseables. Devuelve el puntero al nodo
boolean encontre(NODOAUX* cabeza,unsigned int sitfin,NODOAUX** puntero, NODOSITU* cabsitu) { boolean enc; boolean encontre_result; enc=FALSE; if (verbose) fprintf (stderr, " Estoy en Encontre con %X %d %X %X\n",cabeza,sitfin,puntero, cabsitu); while ((! aux_vacio(cabeza)) && (! enc)) { if (cabeza->info==sitfin) enc=TRUE; else aux_sig(&cabeza); } if (enc) *puntero=cabeza; encontre_result=enc; if (verbose) fprintf (stderr, " Salgo de Encontre con %X %d %X %X\n",cabeza,sitfin,puntero, cabsitu); if (verbose) fprintf (stderr, " y Encontre %d\n",enc); return encontre_result; }
Pablo M. Maceri
243
Funcin: aux_sig() Mdulo: planificador.c Entrada: la lista auxiliar de situaciones deseables Salida: la lista auxiliar de situaciones deseables actualizada Descripcin: avanza una posicion el la lista auxiliar de situaciones deseables
void aux_sig(NODOAUX** cabaux) { *cabaux=(*cabaux)->sig; }
244
Pablo M. Maceri
Funcin: aux_vacio() Mdulo: planificador.c Es llamada desde: encontre() posiciono() Entrada: lista auxiliar de situaciones deseables ordenada Salida: TRUE o FALSE Descripcin: verifica si est vaca la lista auxiliar
boolean aux_vacio(NODOAUX* cabaux) { boolean aux_vacio_result; if (cabaux==NULL) aux_vacio_result=TRUE; else aux_vacio_result=FALSE; return aux_vacio_result; }
Pablo M. Maceri
245
Funcin: posiciono() Mdulo: planificador.c Llama a: aux_vacio() MostrarListaOrdenada() Es llamada desde: insertoaux() modiutil() Entrada: lista auxiliar de situaciones deseable ordenada y utilidad buscada Salida: puntero al nodo encontrado Descripcin: busca el primer nodo cuya utilidad sea menor o igual a la utilidad pasada por parmetro
NODOAUX* posiciono(NODOAUX* cabaux,float* u) { NODOAUX* aux; NODOAUX* posiciono_result; aux=cabaux; if (*u <= aux->ut) posiciono_result=NULL; else { if (verbose) MostrarListaOrdenada(aux); if (verbose) fprintf(stderr," Busco utilidad %1.3f \n",*u); while (! aux_vacio(aux->sig)) { if (verbose) fprintf(stderr," Dentro de posiciono %1.3f %X \n",aux->ut, aux); if ((aux->sig)->ut >= *u) break; /* aux_sig(&aux);*/ aux=aux->sig; } if (verbose) fprintf(stderr," Termine el WHILE %X \n",aux); posiciono_result=aux; if ((verbose) && (aux!=NULL)) fprintf(stderr," La encontre en %X con %d %1.3f \n",aux, aux->info, aux->ut); } return posiciono_result; }
246
Pablo M. Maceri
Funcin: MostrarListaOrdenada() Mdulo: planificador.c Es llamada desde: armopila() creolistaorde() modiutil() posiciono() Entrada: lista auxiliar de situaciones deseables Descripcin: imprime el contenido de situaciones Ordenadas por su utilidad
void MostrarListaOrdenada (NODOAUX * cabsitu) { int i; NODOAUX * aux; aux=cabsitu; while (! (aux == NULL)) { fprintf(stderr,"Situacion %d Utilidad %1.3f Memoria %X Siguiente %X\n",aux>info,aux->ut,aux,aux->sig); aux=aux->sig; } }
Pablo M. Maceri
247
Funcin: pasoapila() Mdulo: planificador.c Llama a: borrolistaaux() Es llamada desde: armopila() Entrada: lista auxiliar de situaciones deseables y lista de situaciones Salida: pila de situaciones deseables Descripcin: pasa la lista auxiliar de deseables a la pila de situaciones deseables
void pasoapila(NODOAUX* cabaux,NODODESE** tope,NODOSITU* cabsitu) { NODODESE* aux; while (!aux_vacio(cabaux)) { aux=(NODODESE*) malloc(sizeof(NODODESE)); (bases[turno].contnododese)++; aux->dese=cabaux->info; aux->ut=cabaux->ut; aux->sig=*tope; *tope=aux; aux_sig(&cabaux); } if (cabaux!=NULL) borrolistaaux(&cabaux); }
248
Pablo M. Maceri
Funcin: borropiladese() Mdulo: planificador.c Llama a: borropilarecu() Entrada: pila de situaciones deseables Salida: pila de situaciones deseables vaca Descripcin: borra pila de situaciones deseables llamando a la funcin recursiva
void borropiladese(NODODESE** topedese) { if ((*topedese)!=NULL) { if ((*topedese)->sig!=NULL) borropilarecu((*topedese)->sig); free(*topedese); (bases[turno].contnododese)--; *topedese=NULL; } }
Pablo M. Maceri
249
Funcin: borropilarecu() Mdulo: planificador.c Llama a: borropilarecu() Es llamada desde: borropiladese() borropilarecu() Entrada: pila de situaciones deseables Salida: pila de situaciones deseables vaca Descripcin: borra pila de situaciones deseables en forma recursiva
void borropilarecu (NODODESE* topedese) { if (topedese->sig!=NULL) borropilarecu(topedese->sig); free(topedese); if (verbose) fprintf(stderr," Libero memoria NODODESE"); (bases[turno].contnododese)--; }
250
Pablo M. Maceri
Funcin: desapilodese() Mdulo: planificador.c Es llamada desde: planificador() Entrada: pila de situaciones deseables Salida: pila de situaciones deseables actualizada Descripcin: elimina el primer elemento de la pila de situaciones deseables
void desapilodese (NODODESE** topedese) { NODODESE* aux; aux=*topedese; *topedese=(*topedese)->sig; free(aux); (bases[turno].contnododese)--; }
Pablo M. Maceri
251
Funcin: borrolistaaux2() Mdulo: planificador.c Llama a: borrolistaaux2() Es llamada desde: borrolistaaux2() borrolistaaux() Entrada: lista auxiliar de situaciones deseables Salida: lista auxiliar de situaciones deseables vaca Descripcin: borra la lista auxiliar de situaciones deseables recursivamente
void borrolistaaux2(NODOAUX* cabaux) { if (cabaux->sig!=NULL) borrolistaaux2(cabaux->sig); free(cabaux); (bases[turno].contnodoaux)--; }
252
Pablo M. Maceri
Funcin: borrolistaaux() Mdulo: planificador.c Llama a: borrolistaaux2() Es llamada desde: armopila() pasoapila() Entrada: lista auxiliar de situaciones deseables Salida: lista auxiliar de situaciones deseables vaca Descripcin: borra la lista auxiliar de situaciones deseables recursivamente
void borrolistaaux(NODOAUX** cabaux) { if ((*cabaux)!=NULL) { if ((*cabaux)->sig!=NULL) borrolistaaux2((*cabaux)->sig); free(*cabaux); (bases[turno].contnodoaux)--; *cabaux=NULL; } }
Pablo M. Maceri
253
Funcin: armar_arbol() Mdulo: planificador.c Llama a: armar_arbol() nivelteoriasaux() teorianorepetida() borroteoriasaux() insertar_teoriaaux() Es llamada desde: armar_arbol() Entrada: lista de situaciones, lista de teoras, situacin deseable, situacin actual Salida: arbol de situaciones Descripcin: arma el arbol de situaciones a partir de la situacin deseable pasada y con las situaciones y teoras conocidas
void armar_arbol(ARBO** cabarbo,NODOSITU* cabsitu, NODOTEORIA* cabteor,NODOTEORIAAUX* cabteoraux, unsigned int situacion,unsigned int* cantramas,int situactual) { unsigned int cruzadosi,cruzadosf; int cruzadoac; HIJO* punaux; NODOTEORIA* cate; boolean sigo; int hijos; int niv; cate=cabteor; while (cate!=NULL) { if (situacion==cate->te.sf) { cruzadosi=cate->te.si; cruzadosf=cate->te.sf; cruzadoac=cate->te.ac.valor; niv=nivelteoriasaux(cabteoraux); if (niv<=bases[turno].estado.cantniveles) { if (teorianorepetida(cruzadosi,cruzadoac,cruzadosf,cabteoraux)) { if ((*cabarbo)->punhijo==NULL) { (*cabarbo)->punhijo=(HIJO *) malloc(sizeof(HIJO)); (bases[turno].conthijo)++; hijos=1; punaux=(*cabarbo)->punhijo; sigo=TRUE; } else { punaux=(*cabarbo)->punhijo; while (punaux->sig!=NULL) { punaux=punaux->sig; hijos=hijos+1; } if (hijos<=cantidadhijos(niv)) { punaux->sig=(HIJO *) malloc(sizeof(HIJO));
(bases[turno].conthijo)++; sigo=TRUE; punaux=punaux->sig; } else sigo=FALSE; } //if ((sigo)&&(situactual!=cate->te.si)) if (sigo) { punaux->info=(ARBO *) malloc(sizeof(ARBO)); (bases[turno].contarbo)++; punaux->info->info=cruzadosi; punaux->info->punhijo=NULL; punaux->rotulo=cate->te.ac; punaux->sig=NULL; insertar_teoriaaux(cruzadosi,cruzadoac,cruzadosf,cabteoraux); /* Invoco recursivamente con info^.info */ armar_arbol(&(punaux>info),cabsitu,cabteor,cabteoraux,cate->te.si,cantramas,situactual); /*Borro el ultimo elemento de la lista auxiliar para controlar los ciclos*/ borroteoriasaux(&cabteoraux); } } *cantramas=*cantramas+1; if (verbose) fprintf (stderr, "Armo arbol de nivel:%d niv,*cantramas); } } cate=cate->sig; } }
rama:%d\n",
Pablo M. Maceri
255
Funcin: MostrarArbol() Mdulo: planificador.c Llama a: MostrarArbol() Es llamada desde: planificador() MostrarArbol() Entrada: arbol de situaciones Descripcin: imprime el arbol de situaciones recursivamente
void MostrarArbol(ARBO* cabarbo,int nivel) { ARBO *arbol; HIJO *hijo; arbol=cabarbo; if (arbol!=NULL) { fprintf (stderr, "NIVEL:%d NODO:%d\n", nivel,arbol->info); hijo=arbol->punhijo; while (hijo!=NULL) { fprintf (stderr, "NIVEL:%d NODO:%d HIJO:%d ACCION:%d\n", nivel,arbol->info,hijo->info>info,hijo->rotulo); MostrarArbol(hijo->info,nivel+1); hijo=hijo->sig; } }
256
Pablo M. Maceri
Funcin: borroarbolrecur() Mdulo: planificador.c Llama a: borroarbolrecur() Es llamada desde: borroarbolrecur() borrararbol() Entrada: rbol de situaciones Salida: rbol de situaciones vaco Descripcin: borra el arbol de situacionese de forma recursiva
void borroarbolrecur(ARBO* cabarbo,HIJO* punhijo) { ARBO* aux; if (cabarbo!=NULL) { if (punhijo!=NULL) { aux=cabarbo; cabarbo=punhijo->info; borroarbolrecur(cabarbo,cabarbo->punhijo); cabarbo=aux; if (punhijo->sig !=NULL) { borroarbolrecur(cabarbo,punhijo->sig); if (punhijo==cabarbo->punhijo) { free(cabarbo); (bases[turno].contarbo)--; } free(punhijo); (bases[turno].conthijo)--; } else { if (punhijo==(cabarbo->punhijo)) { free(cabarbo); (bases[turno].contarbo)--; } free(punhijo); (bases[turno].conthijo)--; } } else { free(cabarbo); (bases[turno].contarbo)--; } } }
Pablo M. Maceri
257
Funcin: borrararbol() Mdulo: planificador.c Llama a: borroarbolrecur() Es llamada desde: planificador() Entrada: rbol de situaciones Salida: rbol de situaciones vaco Descripcin: borra el arbol de situaciones llamando a la funcin recursiva
void borrararbol(ARBO** cabarbo) { if (*cabarbo != NULL) borroarbolrecur(*cabarbo,(*cabarbo)->punhijo); *cabarbo=NULL; }
258
Pablo M. Maceri
Funcin: desevacia() Mdulo: planificador.c Entrada: pila de situaciones deseables Salida: TRUE o FALSE Descripcin: verifica si la pila de situaciones deseables est vacia
boolean desevacia(NODODESE* topepila) { boolean desevacia_result; if (topepila==NULL) desevacia_result=TRUE; else desevacia_result=FALSE; return desevacia_result; }
Pablo M. Maceri
259
Funcin: nivelteoriasaux() Mdulo: planificador.c Es llamada desde: armar_arbol() Entrada: lista auxiliar de teoras Salida: cantidad de elementos en la lista auxiliar de teoras Descripcin: cuenta la cantidad de elementos en la lista auxiliar de teorias
int nivelteoriasaux(NODOTEORIAAUX* cabteoraux) { int cont; int nivel_result; cont=0; while (cabteoraux!=NULL) { cont=cont+1; cabteoraux=cabteoraux->sig; } nivel_result=cont; return nivel_result; }
260
Pablo M. Maceri
Funcin: teorianorepetida() Mdulo: planificador.c Es llamada desde: armar_arbol() Entrada: lista auxiliar de teoras, situacin inicial, accin y situacin final Salida: TRUE FALSE Descripcin: busca una teoria en la lista auxiliar de teorias
boolean teorianorepetida(unsigned int si,int ac,unsigned int sf,NODOTEORIAAUX* cabteoraux) { boolean encontre; boolean norepetida_result; encontre=FALSE; while ((! encontre) && (cabteoraux!=NULL)) if ((cabteoraux->si==si)&&(cabteoraux->sf==sf)&&(cabteoraux->ac.valor==ac)) encontre=TRUE; else cabteoraux=cabteoraux->sig; norepetida_result=!encontre; return norepetida_result; }
Pablo M. Maceri
261
Funcin: borroteoriasaux() Mdulo: planificador.c Es llamada desde: planificador() armar_arbol() Entrada: puntero a lista auxiliar de teoras Salida: lista auxiliar de teoras vaca Descripcin: borra la lista auxiliar de teorias
void borroteoriasaux(NODOTEORIAAUX** cabteoraux) { NODOTEORIAAUX* cabteoraux2; if (*cabteoraux!=NULL) { if ((*cabteoraux)->sig==NULL) { free(*cabteoraux); *cabteoraux=NULL; } else { cabteoraux2=*cabteoraux; while (cabteoraux2->sig->sig!=NULL) cabteoraux2=cabteoraux2->sig; free(cabteoraux2->sig); cabteoraux2->sig=NULL; } } }
262
Pablo M. Maceri
Funcin: insertar_teoriaaux() Mdulo: planificador.c Es llamada desde: planificador() armar_arbol() Entrada: lista auxiliar de teoras, situacin inicial, accin y situacin final Salida: lista auxiliar de teoras actualizada Descripcin: inserta un elemento en la lista auxiliar de teorias
void insertar_teoriaaux(unsigned int si,int ac,unsigned int sf,NODOTEORIAAUX* cabteoraux) { if ((cabteoraux->si!=si)&&(cabteoraux->sf!=sf)) { while(cabteoraux->sig!=NULL) cabteoraux=cabteoraux->sig; cabteoraux->sig=(NODOTEORIAAUX*) malloc(sizeof(NODOTEORIAAUX)); cabteoraux->sig->si=si; cabteoraux->sig->sf=sf; cabteoraux->sig->ac.valor=ac; cabteoraux->sig->sig=NULL; } else { cabteoraux->si=si; cabteoraux->sf=sf; cabteoraux->ac.valor=ac; cabteoraux->sig=NULL; }
Pablo M. Maceri
263
Funcin: cantidadhijos() Mdulo: planificador.c Entrada: nivel Salida: cantidad mxima de hijos para ese nivel Descripcin: calcula la cantidad mxima de hijos de un nivel
int cantidadhijos(int nivel) { int cantidadhijos_result; if (nivel<6) cantidadhijos_result=canthijos-2*(nivel-1); else cantidadhijos_result=2; return cantidadhijos_result; }
264
Pablo M. Maceri
Funcin: armo_plan() Mdulo: planificador.c Llama a: armo_plan() insertoultaux() pasaraplan() borroultlisaux2() Es llamada desde: planificador() armo_plan() Entrada: rbol de situaciones, nmero de situacin actual Salida: lista de planes Descripcin: recursivamente va recorriendo el rbol de situaciones y agrega planes a la lista de planes. Si no consigue armar ningn plan la lista de planes queda en null
void armo_plan(ARBO* cabarbo,unsigned int nrosituact, HIJO* punhijo, NODOLISPLAN** cablisplan, NODOAUX2** cabaux, int* longplan, int* longaux) { ARBO* aux; boolean nofunciono; if (cabarbo!=NULL) { if (punhijo!=NULL) { insertoultaux(cabaux,(punhijo->info)->info,punhijo->rotulo,cabarbo->info,longaux); if (verbose) fprintf(stderr, " Pregunto situacion %d %d long=%d\n",nrosituact,(punhijo->info)->info,*longaux); if (nrosituact==(punhijo->info)->info) { if (verbose) fprintf(stderr, " Entro en pasaraplan con %X %X %d %d %d\n",*cabaux,cablisplan, *longaux,*longplan,nofunciono); pasaraplan(*cabaux,cablisplan,*longaux,longplan,&nofunciono); if (verbose) fprintf(stderr, " Salgo de pasaraplan con %X %X %d %d %d\n",*cabaux,cablisplan, *longaux,*longplan,nofunciono); borroultlisaux2(cabaux,longaux); if ((punhijo->sig!=NULL) && (! nofunciono)) { aux=cabarbo; armo_plan(cabarbo,nrosituact,punhijo>sig,cablisplan,cabaux,longplan,longaux); cabarbo=aux; } } else { aux=cabarbo; cabarbo=punhijo->info; armo_plan(cabarbo,nrosituact,cabarbo>punhijo,cablisplan,cabaux,longplan,longaux); cabarbo=aux; borroultlisaux2(cabaux,longaux); if (punhijo->sig !=NULL) { aux=cabarbo; punhijo=punhijo->sig;
armo_plan(cabarbo,nrosituact,punhijo,cablisplan,cabaux,longplan,longaux); cabarbo=aux; //borroultlisaux2(cabaux,longaux); } } } } }
266
Pablo M. Maceri
Funcin: insertoultaux() Mdulo: planificador.c Es llamada desde: armo_plan() Entrada: lista de plan auxiliar, situacin inicial, accin y situacin auxiliar Salida: lista de plan auxiliar actualizada Descripcin: agrega una teora al final de la lista de plan auxiliar aumentando su longitud
void insertoultaux (NODOAUX2** cabaux,unsigned int ante, ACCION ac, unsigned int conse, int* cantelem) { NODOAUX2* cab; if (*cabaux==NULL) { *cabaux=(NODOAUX2*) malloc(sizeof(NODOAUX2)); (*cabaux)->si=ante; (*cabaux)->acc=ac; (*cabaux)->sf=conse; (*cabaux)->sig=NULL; } else { cab=*cabaux; while (cab->sig!=NULL) cab=cab->sig; cab->sig=(NODOAUX2*) malloc(sizeof(NODOAUX2)); cab->sig->si=ante; cab->sig->acc=ac; cab->sig->sf=conse; cab->sig->sig=NULL; } *cantelem=*cantelem+1; }
Pablo M. Maceri
267
Funcin: pasaraplan() Mdulo: planificador.c Llama a: borrolista() borroplan() Es llamada desde: armo_plan() Entrada: lista de planes, plan auxiliar Salida: lista de planes actualizada Descripcin: agrega un plan a la lista de planes
void pasaraplan(NODOAUX2* cabaux,NODOLISPLAN** cablisplan,int longaux, int* longplan,boolean* nofunciono) { if (*longplan < longaux) /*no hago nada*/ *nofunciono=TRUE; else /* mayor o igual*/ { *nofunciono=FALSE; if (*longplan > longaux) /*es mayor => lo suplanto al plan directamente*/ { borrolista(cablisplan,longplan); copiolista(cablisplan,cabaux,longplan,longaux); } else /*son iguales => inserto en la lista de listas*/ copiolista(cablisplan,cabaux,longplan,longaux); } }
268
Pablo M. Maceri
Funcin: borrolista() Mdulo: planificador.c Llama a: borroplan() Es llamada desde: planificador() pasaraplan() Entrada: lista de planes Salida: lista de planes vaca Descripcin: borra la lista de planes y sus planes
void borrolista(NODOLISPLAN** cablisplan,int* longplan) { NODOLISPLAN* cab; NODOLISPLAN* cab2; if (*cablisplan!=NULL) { cab=*cablisplan; cab2=(*cablisplan)->sig; while (cab2!=NULL) { borroplan(cab->info); free(cab); cab=cab2; cab2=cab2->sig; } borroplan(cab->info); free(cab); } *cablisplan=NULL; *longplan=0; }
Pablo M. Maceri
269
Funcin: borroplan() Mdulo: planificador.c Es llamada desde: pasaraplan() borrolista() Entrada: plan Salida: plan vaco Descripcin: borra el contenido de un plan liberando la memoria
void borroplan(NODOPLAN* punaux) { NODOPLAN* cab; NODOPLAN* cab2; if (punaux!=NULL) { cab=punaux; cab2=punaux->sig; while (cab2!=NULL) { free(cab); cab=cab2; cab2=cab2->sig; } free(cab); } }
270
Pablo M. Maceri
Funcin: copiolista() Mdulo: planificador.c Llama a: apilar2() Entrada: lista de planes, plan auxiliar Salida: lista de planes actualizada Descripcin: copia un plan en la lista de planes
void copiolista(NODOLISPLAN** cablisplan,NODOAUX2* cabaux,int* longplan, int longaux) { NODOLISPLAN *cab; cab=*cablisplan; if (cab==NULL) { *cablisplan=(NODOLISPLAN*) malloc(sizeof(NODOLISPLAN)); (*cablisplan)->sig=NULL; *longplan=longaux; cab=*cablisplan; } else { while (cab->sig!=NULL) cab=cab->sig; cab->sig=(NODOLISPLAN*) malloc(sizeof(NODOLISPLAN)); cab->sig->sig=NULL; cab=cab->sig; } cab->info=NULL; while (cabaux!=NULL) { cab->info=apilar2(cabaux,cab->info); cabaux=cabaux->sig; } }
Pablo M. Maceri
271
Funcin: apilar2() Mdulo: planificador.c Es llamada desde: copiolista() Entrada: plan y plan auxiliar Salida: plan actualizado Descripcin: agrega una elemento a un plan
NODOPLAN* apilar2(NODOAUX2* cabaux,NODOPLAN* pila) { NODOPLAN* aux; NODOPLAN* apilar2_result; aux=NULL; if (pila!=NULL) aux=pila; pila=(NODOPLAN*) malloc(sizeof(NODOPLAN)); pila->si=cabaux->si; pila->acc=cabaux->acc; pila->sf=cabaux->sf; pila->sig=aux; apilar2_result=pila; return apilar2_result; }
272
Pablo M. Maceri
Funcin: apilar3() Mdulo: planificador.c Entrada: plan y plan auxiliar Salida: plan actualizado Descripcin: agrega una elemento a un plan pero al final de la lista
void apilar3(NODOAUX2* cabaux,NODOPLAN* pila) { NODOPLAN* aux; NODOPLAN* aux2; NODOPLAN* apilar2_result; aux=pila; /* a esta funcion nunca puede llegar un plan vacio porque solo se llama cuando el plan ya esta armado*/ if (verbose) fprintf(stderr,"\nAgrego la ultima accion al plan: %d -> ",aux->acc); while (aux->sig!=NULL) { aux=aux->sig; if (verbose) fprintf(stderr,"%d -> ",aux->acc); } if (verbose) fprintf(stderr,"\n"); aux2=(NODOPLAN*) malloc(sizeof(NODOPLAN)); aux2->si=cabaux->si; aux2->acc=cabaux->acc; aux2->sf=cabaux->sf; aux2->sig=NULL; aux->sig=aux2; }
Pablo M. Maceri
273
Funcin: borrorecuultlisaux() Mdulo: planificador.c Llama a: borrorecuultlisaux() Es llamada desde: borrorecuultlisaux() borroultlisaux() Entrada: plan auxiliar Salida: plan auxiliar vaco Descripcin: borra los elementos de un plan auxiliar recursivamente
void borrorecuultlisaux(NODOAUX2* cabaux) { if (cabaux != NULL) { if (cabaux->sig != NULL) /* si el siguiente es NULL entonces este es*/ borrorecuultlisaux(cabaux->sig); /* el ultimo elemento*/ free(cabaux); } }
274
Pablo M. Maceri
Funcin: borroultlisaux() Mdulo: planificador.c Llama a: borrorecuultlisaux() Entrada: plan auxiliar Salida: plan auxiliar vaco Descripcin: borra un plan auxiliar
void borroultlisaux(NODOAUX2** cabaux,int* longaux) { if ((*cabaux) != NULL) { *longaux=*longaux-1; if ((*cabaux)->sig != NULL) borrorecuultlisaux((*cabaux)->sig); free(*cabaux); *cabaux=NULL; } }
Pablo M. Maceri
275
Funcin: borroultlisaux2() Mdulo: planificador.c Es llamada desde: armo_plan() Entrada: plan auxiliar Salida: plan auxiliar actualizado Descripcin: borra el ultimo elemento de un plan auxiliar
void borroultlisaux2(NODOAUX2** cabaux,int* longaux) { NODOAUX2* aux; NODOAUX2* aux2; if ((*cabaux) != NULL) { *longaux=*longaux-1; aux=*cabaux; if (aux->sig==NULL) { free(aux); *cabaux=NULL; } else { while (aux->sig!= NULL) { aux2=aux; aux=aux->sig; } aux2->sig=NULL; free(aux); } } }
276
Pablo M. Maceri
Funcin: borrorecuaux2() Mdulo: planificador.c Llama a: borrorecuaux2() Es llamada desde: borrorecuaux2() borroaux2() Entrada: plan auxiliar Salida: plan auxiliar vaco Descripcin: borra un plan auxiliar recursivamente
void borrorecuaux2 (NODOAUX2* cabeza) { if (cabeza->sig!=NULL) borrorecuaux2(cabeza->sig); free(cabeza); }
Pablo M. Maceri
277
Funcin: borroaux2() Mdulo: planificador.c Llama a: borrorecuaux2() Es llamada desde: planificador() Entrada: plan auxiliar Salida: plan auxiliar vaco Descripcin: borra un plan auxiliar llamando a la funcin recursiva
void borroaux2(NODOAUX2** cab) { if ((*cab)!=NULL) { if ((*cab)->sig!=NULL) borrorecuaux2((*cab)->sig); free(*cab); *cab=NULL; } }
278
Pablo M. Maceri
Funcin: MostrarPlan() Mdulo: planificador.c Es llamada desde: StepRobot() controlador() Entrada: lista de planes Descripcin: muestra el contenido de un plan
void MostrarPlan (NODOPLAN * cabezaplanes) { int i=0; NODOPLAN * aux; aux=cabezaplanes; fprintf (stderr , "Plan = "); while (aux != NULL) { fprintf (stderr , " (%d)%d(%d) -> ",aux->si,aux->acc.valor,aux->sf); i++; aux=aux->sig; } fprintf (stderr , " Total %3d \n ",i); }
Pablo M. Maceri
279
Funcin: BuscarTeoriaDese() Mdulo: planificador.c Es llamada desde: planificador() Entrada: lista de teoras, pila de situaciones deseable Salida: puntero a la teora encontrada Descripcin: busca la teoria que tiene asociada la utilidad y la situacion inicial pasada por parametro en el nodo situacion deseable
void BuscarTeoriaDese (NODOTEORIA* cabteor,NODODESE* dese,NODOTEORIA** punteor) { boolean enc=FALSE; while ((cabteor!=NULL)&&(!enc)) { if ((cabteor->te.sf==dese->dese)&&(cabteor->te.u==dese->ut)) { (*punteor)=cabteor; enc=TRUE; } cabteor=cabteor->sig; } }
280
Pablo M. Maceri
Funcin: AgregarAccion() Mdulo: planificador.c Llama a: apilar3() Es llamada desde: planificador() Entrada: lista de planes, teora asociada a la situacin deseable Salida: lista de planes actualizada Descripcin: le agrega al plan la accion que se le aplica a la situacion deseable usada para armar el plan
void AgregarAccion(NODOLISPLAN** cablisplan,NODOTEORIA* teordese) { NODOAUX2 auxplan; NODOLISPLAN* cab; cab=*cablisplan; while (cab!=NULL) { auxplan.si=teordese->te.si; auxplan.sf=teordese->te.sf; auxplan.acc=teordese->te.ac; auxplan.sig=NULL; apilar3(&auxplan,cab->info); cab=cab->sig; } }
Pablo M. Maceri
281
282
Pablo M. Maceri
Archivo ponderador.c
Pablo M. Maceri
283
284
Pablo M. Maceri
Funcin: ponderador() Mdulo: ponderador.c Llama a: contarsitu() buscositfin() crearmat() MostrarMatriz() copiarmat() multiplicar() Es llamada desde: planificador() Entrada: plan, lista de situaciones, lista de teoras y rango para descartar planes Salida: TRUE FALSE Descripcin: mdulo ponderador. Calcula el estimador de probabilidad para un plan. Devuelve TRUE si el plan es aceptable
boolean ponderador(NODOPLAN* cabplan,NODOSITU* cabsitu,float *rango, NODOTEORIA* cabteor) { /*Variables utilizadas en el ponderador */ unsigned int sitini,sitfin; unsigned int cantsitu; int i,j; NODOPLAN* cabplanini; float num; MATRIZ mat1,mat2,mat3,mataux; boolean ponderador_result; if (verbose) fprintf (stderr , "Entrando al ponderador con cabplan=%X cabsitu=%X rango=%1.3f cabteor=%X\n",cabplan,cabsitu,*rango,cabteor); if (cabplan==NULL) return(FALSE); cantsitu=contarsitu(cabsitu); cabplanini=cabplan; sitfin=buscositfin(cabplan); while (cabteor != NULL) { switch (cabteor->te.ac.valor) { case 1: crearmat(mat1,cabplan,cantsitu,cabteor,cabsitu); break; case 2: crearmat(mat2,cabplan,cantsitu,cabteor,cabsitu); break; case 3: crearmat(mat3,cabplan,cantsitu,cabteor,cabsitu); break; } cabteor=cabteor->sig; } if (verbose) MostrarMatriz(mat1,cantsitu); if (verbose) MostrarMatriz(mat2,cantsitu); if (verbose) MostrarMatriz(mat3,cantsitu); if (verbose) fprintf (stderr , "He cargado las matrices\n"); switch (cabplan->acc.valor) {
case 1: copiarmat(mat1,cantsitu,mataux); break; case 2: copiarmat(mat2,cantsitu,mataux); break; case 3: copiarmat(mat3,cantsitu,mataux); break; } cabplan=cabplan->sig; while (cabplan != NULL) { switch (cabplan->acc.valor) { case 1: multiplicar(mat1,cantsitu,mataux); break; case 2: multiplicar(mat2,cantsitu,mataux); break; case 3: multiplicar(mat3,cantsitu,mataux); break; } cabplan=cabplan->sig; } cabplan=cabplanini; sitini=cabplan->si; if (verbose) MostrarMatriz(mataux,cantsitu); num=mataux[sitini][sitfin]; if (verbose) { fprintf (stderr , "Saliendo del ponderador\n"); fprintf (stderr , "Valor de ponderacion (num) %f rango %f \n", num,*rango); } if (num >= *rango) ponderador_result=FALSE; else ponderador_result=TRUE; if (verbose) fprintf (stderr , " El ponderador retorna resultado= %d\n", ponderador_result); return ponderador_result; }
286
Pablo M. Maceri
Funcin: contarsitu() Mdulo: ponderador.c Es llamada desde: ponderador() Entrada: lista de situaciones Salida: nmero de la ltima situacin en la lista de situaciones Descripcin: busca el nmero de la ltima situacin en la lista de situaciones
unsigned int contarsitu(NODOSITU* cabsitu) { unsigned int contarsitu_result; if (cabsitu==NULL) contarsitu_result=0; else { while (cabsitu->sig!=NULL) cabsitu=cabsitu->sig; contarsitu_result=cabsitu->nro; } return contarsitu_result; }
Pablo M. Maceri
287
Funcin: buscositfin() Mdulo: ponderador.c Es llamada desde: ponderador() Entrada: plan Salida: nmero de situacin Descripcin: busca la ltima situacin final de un plan
unsigned int buscositfin(NODOPLAN* cabplan) { while (cabplan->sig != NULL) cabplan=cabplan->sig; return cabplan->sf; }
288
Pablo M. Maceri
Funcin: crearmat() Mdulo: ponderador.c Es llamada desde: ponderador() Entrada: plan, lista de teoras y lista de situaciones Salida: matriz de transicin Descripcin: crea la matriz y asigna el valor p/k a la posicin si,sf
void crearmat(MATRIZ mat,NODOPLAN* cabplan,unsigned int cantsitu, NODOTEORIA* cabteor,NODOSITU* cabsitu) { float aux; int i,j; if (cabteor->te.k == 0) aux= 0; else aux=(float)(cabteor->te.p)/cabteor->te.k; i=cabteor->te.si; j=cabteor->te.sf; mat[i][j]=aux; }
Pablo M. Maceri
289
Funcin: MostrarMatriz() Mdulo: ponderador.c Es llamada desde: ponderador() Entrada: matriz de transicin Descripcin: imprime el contenido de la matriz
void MostrarMatriz(MATRIZ mat,unsigned int cantsitu) { int i,j; fprintf (stderr, "Conternido de la Matriz ===============\n"); for( i= 1; i <= cantsitu; i ++) { for( j= 1; j <= cantsitu; j ++) fprintf (stderr," %1.3f ", mat[j][i]); fprintf (stderr,"\n"); } fprintf (stderr, "=======================================\n"); }
290
Pablo M. Maceri
Funcin: copiarmat() Mdulo: ponderador.c Es llamada desde: ponderador() Entrada: dos matrices de transicin Salida: segunda matriz actualizada Descripcin: copia el contenido de la primera matriz en la segunda
void copiarmat(MATRIZ mat,unsigned int cantsitu, MATRIZ mataux) { int i,j; for( i=1; i <= cantsitu; i ++) { for( j=1; j <= cantsitu; j ++) mataux[i][j]=mat[i][j]; } }
Pablo M. Maceri
291
Funcin: multiplicar() Mdulo: ponderador.c Es llamada desde: ponderador() Entrada: dos matrices de transicin Salida: segunda matriz actualizada Descripcin: Multiplica dos matrices y devuelve el resultado en la segunda
void multiplicar(MATRIZ mat,unsigned int cantsitu,MATRIZ mataux) { int i,j; MATRIZ resu; for( i= 1; i <= cantsitu; i ++) { for( j= 1; j <= cantsitu; j ++) resu[i][j]=0; } for( i= 1; i <= cantsitu; i ++) { for( j= 1; j <= cantsitu; j ++) resu[i][j]=resu[i][j]+mataux[i][j]*mat[j][i]; } for( i= 1; i <= cantsitu; i ++) { for( j= 1; j <= cantsitu; j ++) mataux[i][j]=resu[i][j]; } }
292
Pablo M. Maceri
Archivo intercambio.c
Pablo M. Maceri
293
294
Pablo M. Maceri
Funcin: intercambiar() Mdulo: intercambio.c Llama a: insersitu() MostrarListaSituaciones() buscar_teoria() insertarteo() MostrarListaTeorias() recalcular_utilidades() borrosituaciones() borroteorias() copiarteorias() cruza2() iguales() Es llamada desde: UserCommand() Entrada: lista de teoras y lista de situaciones de dos sistemas Salidas: listas actualizadas Descripcin: mdulo de intercambio de operadores
void intercambiar(NODOTEORIA** dir_cabteor1,NODOSITU** dir_cabsitu1,NODOTEORIA** dir_cabteor2,NODOSITU** dir_cabsitu2) { VECTOR si1, sf1,si2,sf2; ACCION ac1,ac2; NODOTEORIA *cabteor1=*dir_cabteor1; NODOTEORIA *cabteor2=*dir_cabteor2; NODOTEORIA *cabteor=NULL; NODOSITU *cabsitu1=*dir_cabsitu1; NODOSITU *cabsitu2=*dir_cabsitu2; NODOSITU *cabsitu=NULL; int k,p,knuevo,pnuevo,buscar; if (verbose) fprintf (stderr , "Entro a intercambiar operadores \n"); /* Lo primero que hago es insertar todas las situaciones de las dos listas para que calcule el promedio de la luz en caso de que alguna sea igual */ if (verbose) fprintf (stderr , "Inserto las situaciones del 1...\n"); while (cabsitu1!=NULL) { insersitu(&cabsitu,cabsitu1->situ); cabsitu1=cabsitu1->sig; } if (verbose) fprintf (stderr , "Inserto las situaciones del 2...\n"); while (cabsitu2!=NULL) { insersitu(&cabsitu,cabsitu2->situ); cabsitu2=cabsitu2->sig; } cabsitu1=*dir_cabsitu1; cabsitu2=*dir_cabsitu2; if (verbose) fprintf (stderr , "Inserto las teorias...\n"); /* Vuelco las del robot 1 */ while (cabteor1!=NULL) { cruza2(cabsitu1,cabteor1->te.si,&si1); cruza2(cabsitu1,cabteor1->te.sf,&sf1);
ac1.valor=cabteor1->te.ac.valor; cabteor2=*dir_cabteor2; /*la busco en las teorias del robot 2*/ buscar=buscar_teoria(cabteor2,cabsitu2,si1,ac1, sf1,&knuevo,&pnuevo); /*si existe una igual se suman los p*/ if (buscar==2) p=cabteor1->te.p + pnuevo; /*sino queda el mismo p*/ else p=cabteor1->te.p; /*si existe una teoria igual o similar se suman los k*/ if (buscar!=0) k=cabteor1->te.k + knuevo; /*sino queda el mismo k*/ else k=cabteor1->te.k; /*inserto la teoria*/ insertarteo(&cabteor,si1,ac1,sf1,k,p,cabsitu); cabteor1=cabteor1->sig; } /* Vuelco las del robot 2 si no existen todavia*/ cabteor1=*dir_cabteor1; cabteor2=*dir_cabteor2; while (cabteor2!=NULL) { cruza2(cabsitu2,cabteor2->te.si,&si2); cruza2(cabsitu2,cabteor2->te.sf,&sf2); ac2.valor=cabteor2->te.ac.valor; /*me fijo que no exista*/ buscar=buscar_teoria(cabteor,cabsitu,si2,ac2,sf2,&knuevo,&pnuevo); if (buscar!=2) { /*la busco en las teorias del robot 1*/ buscar=buscar_teoria(cabteor1,cabsitu1,si2,ac2, sf2,&knuevo,&pnuevo); /*si existe una igual se suman los p*/ if (buscar==2) p=cabteor2->te.p + pnuevo; /*sino queda el mismo p*/ else p=cabteor2->te.p; /*si existe una teoria igual o similar se suman los k*/ if (buscar!=0) k=cabteor2->te.k + knuevo; /*sino queda el mismo k*/ else k=cabteor2->te.k; /*inserto la teoria*/ insertarteo(&cabteor,si2,ac2,sf2,k,p,cabsitu); }
cabteor2=cabteor2->sig; } /******* volcar cabteor a cabteor1 y cabteor2 *******/ recalcular_utilidades(&cabteor,cabsitu); if (verbose) fprintf (stderr , "copio la nueva lista a las viejas \n"); if (verbose) MostrarListaTeorias(cabteor); if (verbose) MostrarListaSituaciones(cabsitu); borrosituaciones(dir_cabsitu1); if (verbose) MostrarListaSituaciones(*dir_cabsitu1); borroteorias(dir_cabteor1); if (verbose) MostrarListaTeorias(*dir_cabteor1); borrosituaciones(dir_cabsitu2); if (verbose) MostrarListaSituaciones(*dir_cabsitu2); borroteorias(dir_cabteor2); if (verbose) MostrarListaTeorias(*dir_cabteor2); copiarteorias(&cabteor,&cabsitu,dir_cabteor1,dir_cabsitu1); copiarteorias(&cabteor,&cabsitu,dir_cabteor2,dir_cabsitu2); borrosituaciones(&cabsitu); borroteorias(&cabteor); recalcular_utilidades(dir_cabteor1,*dir_cabsitu1); recalcular_utilidades(dir_cabteor2,*dir_cabsitu2); if (verbose) fprintf (stderr , "Salgo de intercambiar operadores \n"); }
Pablo M. Maceri
297
Funcin: borrosituaciones() Mdulo: intercambio.c Llama a: borrosituacionesrecu() Es llamada desde: intercambiar() Entrada: lista de situaciones Salida: lista de situaciones vaca Descripcin: borra una lista de situaciones llamando a la funcin recursiva
void borrosituaciones(NODOSITU** cabsitu) { if (verbose) fprintf (stderr , "Entro a borrar situaciones... \n"); if ((*cabsitu)!=NULL) { if ((*cabsitu)->sig!=NULL) borrosituacionesrecu((*cabsitu)->sig); free(*cabsitu); *cabsitu=NULL; } }
298
Pablo M. Maceri
Funcin: borrosituacionesrecu() Mdulo: intercambio.c Es llamada desde: borrosituaciones() Entrada: lista de situaciones Salida: lista de situaciones vaca Descripcin: borra una lista de situaciones liberando la memoria recursivamente
void borrosituacionesrecu(NODOSITU *cabsitu) { if (cabsitu->sig!=NULL) borrosituacionesrecu(cabsitu->sig); free(cabsitu); }
Pablo M. Maceri
299
Funcin: borroteorias() Mdulo: intercambio.c Llama a: borroteoriasrecu() Es llamada desde: intercambiar() Entrada: lista de teoras Salida: lista de teoras vaca Descripcin: borra una lista de teorias llamando a la funcin recursiva
void borroteorias(NODOTEORIA** cabteor) { if (verbose) fprintf (stderr , "Entro a borrar teorias... \n"); if ((*cabteor)!=NULL) { if ((*cabteor)->sig!=NULL) borroteoriasrecu((*cabteor)->sig); free(*cabteor); *cabteor=NULL; } }
300
Pablo M. Maceri
Funcin: borroteoriasrecu() Mdulo: intercambio.c Es llamada desde: borroteorias() Entrada: lista de teoras Salida: lista de teoras vaca Descripcin: borra una lista de teorias recursivamente liberando la memoria
void borroteoriasrecu(NODOTEORIA *cabteor) { if (cabteor->sig!=NULL) borroteoriasrecu(cabteor->sig); free(cabteor); }
Pablo M. Maceri
301
Funcin: copiarteorias() Mdulo: intercambio.c Llama a: insersitu() insertarteo() cruza2() Es llamada desde: intercambiar() Entrada: lista de teoras y lista de situaciones de dos sistemas Salida: lista de teoras y lista de situaciones del segundo sistema actualizada Descripcin: copia una lista de teorias a otra
void copiarteorias(NODOTEORIA** dir_cabteor1,NODOSITU** dir_cabsitu1,NODOTEORIA** dir_cabteor2,NODOSITU** dir_cabsitu2) { VECTOR si,sf; ACCION ac; NODOTEORIA *cabteor1=*dir_cabteor1; NODOSITU *cabsitu1=*dir_cabsitu1; if (verbose) fprintf (stderr , "Entro a copiar teorias... \n"); while (cabteor1!=NULL) { cruza2(cabsitu1,cabteor1->te.si,&si); cruza2(cabsitu1,cabteor1->te.sf,&sf); ac.valor=cabteor1->te.ac.valor; insersitu(dir_cabsitu2,si); insersitu(dir_cabsitu2,sf); insertarteo(dir_cabteor2,si,ac,sf,cabteor1->te.k,cabteor1->te.p ,*dir_cabsitu2); cabteor1=cabteor1->sig; } if (verbose) fprintf (stderr , "Salgo de copiar teorias... \n"); }
302
Pablo M. Maceri
Archivo data.c
Pablo M. Maceri
303
304
Pablo M. Maceri
Funcin: guardar_conocimiento() Mdulo: data.c Llama a: ContarTeorias() Es llamada desde: StepRobot() UserCommand() Entrada: lista de teoras y lista de situaciones del sistema Descripcin: guarda la lista de teoras y la lista de situaciones de un sistema en disco para que pueda luego ser cargado con la funcin cargar_conocimiento( )
int guardar_conocimiento(NODOTEORIA **dir_cabteo,NODOSITU **dir_cabsitu) { int fdteo,fdsitu,n,cant; NODOTEORIA *cabteo; NODOSITU *cabsitu; cabteo=*dir_cabteo; cabsitu=*dir_cabsitu; fdteo = open("data/teo.dat",O_WRONLY | O_TRUNC | O_CREAT,0600); if (fdteo==-1) { printf("Error al abrir el archivo de teorias para escritura!!!\n"); exit(-1); } cant=ContarTeorias(cabteo); n=write(fdteo,&cant,sizeof(cant)); if (n!=sizeof(cant)) { printf("Error al escribir cantidad de teorias !!!\n"); close(fdteo); exit(-1); } while (cabteo!=NULL) { n=write(fdteo,cabteo,sizeof(*cabteo)); if (n!=sizeof(*cabteo)) { printf("Error al escribir teoria !!!\n"); close(fdteo); exit(-1); } cabteo=cabteo->sig; } close(fdteo); fdsitu = open("data/situ.dat",O_WRONLY | O_TRUNC | O_CREAT,0600); if (fdsitu==-1) { printf("Error al abrir el archivo de situaciones para escritura!!!\n"); exit(-1); }
cant=ContarSitu(cabsitu); n=write(fdsitu ,&cant,sizeof(cant)); if (n!=sizeof(cant)) { printf("Error al escribir cantidad de situaciones !!!\n"); close(fdsitu); exit(-1); } while (cabsitu!=NULL) { n=write(fdsitu ,cabsitu,sizeof(*cabsitu)); if (n!=sizeof(*cabsitu)) { printf("Error al escribir situacion !!!\n"); close(fdsitu); exit(-1); } cabsitu=cabsitu->sig; } close(fdsitu); return(0); }
306
Pablo M. Maceri
Funcin: cargar_conocimiento() Mdulo: data.c Llama a: ContarTeorias() Es llamada desde: StepRobot() Entrada: lista de teoras y lista de situaciones del sistema Salida: lista de teoras y lista de situaciones del sistema actualizada Descripcin: carga las listas de teoras y de situaciones de un sistema desde un archivo de disco que fueron previamente guardadas con la funcin gurdar_conocimiento( )
int cargar_conocimiento(NODOTEORIA **dir_cabteo,NODOSITU **dir_cabsitu) { int fdteo,fdsitu,n,cant,i; NODOTEORIA *cabteo; NODOSITU *cabsitu; NODOTEORIA teo; NODOSITU situ; fdteo = open("data/teo.dat",O_RDONLY,0); if (fdteo==-1) { printf("Error al abrir el archivo de teorias para lectura!!!\n"); exit(-1); } n=read(fdteo,&cant,sizeof(cant)); if (n!=sizeof(cant)) { printf("Error al leer cantidad de teorias!!!\n"); close(fdteo); exit(-1); } i=0; n=read(fdteo,&teo,sizeof(teo)); if (n!=sizeof(teo)) { printf("Error al leer teoria!!!\n"); close(fdteo); exit(-1); } (*dir_cabteo) =(NODOTEORIA*) malloc(sizeof(NODOTEORIA)); (*dir_cabteo)->te.si=teo.te.si; (*dir_cabteo)->te.ac=teo.te.ac; (*dir_cabteo)->te.sf=teo.te.sf; (*dir_cabteo)->te.p=teo.te.p; (*dir_cabteo)->te.k=teo.te.k; (*dir_cabteo)->te.u=teo.te.u; (*dir_cabteo)->sig=NULL; i++; cabteo=*dir_cabteo; while (cant>i) { n=read(fdteo,&teo,sizeof(teo)); if (n!=sizeof(teo))
{ printf("Error al leer teoria %d!!!\n",i); close(fdteo); exit(-1); } cabteo->sig =(NODOTEORIA*) malloc(sizeof(NODOTEORIA)); cabteo=cabteo->sig; cabteo->te.si=teo.te.si; cabteo->te.ac=teo.te.ac; cabteo->te.sf=teo.te.sf; cabteo->te.p=teo.te.p; cabteo->te.k=teo.te.k; cabteo->te.u=teo.te.u; cabteo->sig=NULL; i++; } close(fdteo); fdsitu = open("data/situ.dat",O_RDONLY,0); if (fdsitu==-1) { printf("Error al abrir el archivo de situaciones para lectura!!!\n"); exit(-1); } n=read(fdsitu,&cant,sizeof(cant)); if (n!=sizeof(cant)) { printf("Error al leer cantidad de situaciones!!!\n"); close(fdsitu); exit(-1); } i=0; n=read(fdsitu,&situ,sizeof(situ)); if (n!=sizeof(situ)) { printf("Error al leer situacion!!!\n"); close(fdsitu); exit(-1); } (*dir_cabsitu) =(NODOSITU*) malloc(sizeof(NODOSITU)); (*dir_cabsitu)->situ=situ.situ; (*dir_cabsitu)->nro=situ.nro; (*dir_cabsitu)->sig=NULL; i++; cabsitu=*dir_cabsitu; while (cant>i) { n=read(fdsitu,&situ,sizeof(situ)); if (n!=sizeof(situ)) { printf("Error al leer situacion %d!!!\n",i); close(fdsitu); exit(-1);
} cabsitu->sig =(NODOSITU*) malloc(sizeof(NODOSITU)); cabsitu=cabsitu->sig; cabsitu->situ=situ.situ; cabsitu->nro=situ.nro; cabsitu->sig=NULL; i++; } close(fdsitu); return(0); }
Pablo M. Maceri
309
310
Pablo M. Maceri
Indice Analtico de Funciones

abrirArchivos, 198 AgregarAccion, 281 apilar2, 272 apilar3, 273 armar_arbol, 254 armo_plan, 265 armopila, 237 aux_sig, 244 aux_vacio, 245 avanzar, 183 borrararbol, 258 borroarbolrecur, 257 borroaux2, 278 borrolista, 269 borrolistaaux, 253 borrolistaaux2, 252 borropiladese, 249 borropilarecu, 250 borroplan, 270 borrorecuaux2, 277 borrorecuultlisaux, 274 borrosituaciones, 298 borrosituacionesrecu, 299 borroteorias, 300 borroteoriasaux, 262 borroteoriasrecu, 301 borroultlisaux, 275 borroultlisaux2, 276 buscar_teoria, 214 BuscarTeoriaDese, 280 buscositfin, 288 calculoutil, 216 cantidadhijos, 264 cantidadRobots, 203 cargar_conocimiento, 307 cerrarArchivos, 200
Anexo E - Cdigo fuente Pablo M. Maceri
contarsitu, 287 ContarSitu, 195 ContarTeorias, 194 controlador, 227 copiarmat, 291 copiarteorias, 302 copiolista, 271 crearmat, 289 creolistaorde, 238 cruza, 187 cruza2, 188 desapilodese, 251 desapiloplan, 196 desevacia, 259 encontre, 243 encsitu, 212 encsitu_actualizar_luz, 213 escribirArchivo, 201 girarder, 181 girarizq, 182 guardar_conocimiento, 305 iguales, 189 inicializar, 186 insersitu, 209 insertar_teoriaaux, 263 insertarteo, 215 insertoaux, 239 insertoultaux, 267 intercambiar, 295 LeerSensores, 185 llenar_nivel, 197 modiutil, 241 mostrar, 190 MostrarArbol, 256 MostrarListaOrdenada, 247 MostrarListaSituaciones, 210
311
MostrarListaTeorias, 217 MostrarMatriz, 290 MostrarPlan, 279 multiplicar, 292 mutar_situacion, 221 nivelteoriasaux, 260 pasaraplan, 268 pasoapila, 248 planificador, 233 ponderador, 285 ponderar_teorias, 218 ponderar_teorias_mutar, 219
posiciono, 246 proximaaccion, 184 recalcular_utilidades, 224 RegistrarTeoria, 207 situ_sig, 211 situ_vacio, 193 StepRobot, 164 teo_sig, 192 teo_vacio, 191 teorianorepetida, 261 UserCommand, 167 verificar_consistencia, 222
312
Pablo M. Maceri

Maceri Tesisingenieriainformatica

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Maceri Tesisingenieriainformatica

Enviado por

Direitos autorais:

Formatos disponíveis

APRENDIZAJE AUTOMATICO BASADO EN INTERCAMBIO DE OPERADORES EN SISTEMAS INTELIGENTES AUTONOMOS TESIS DE GRADO EN INGENIERIA INFORMATICA FACULTAD DE INGENIERIA UNIVERSIDAD

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

2.1. GINKO: Una arquitectura integrada para aprendizaje y planificacin en robtica

Lecturas de los sensores

Modelo del mundo

Figura 2-1: arquitectura del sistema GINKO

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

2.2. PRODIGY: una arquitectura integrada para planificacin y aprendizaje

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Interfase de usuario EBL SOLUCIONADOR DE PROBLEMAS Lineal / No lineal

Figura 2-2: arquitectura del sistema PRODIGY

2.3. Un Anlisis de Soar como una Arquitectura Integrada

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Figura 2-3: arquitectura del nivel de smbolos del sistema Soar

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

2.4. LIVE: una arquitectura para aprendizaje del entorno

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Creador Ejecutor Monitor Reactor

AMBIENTE Figura 2-4: arquitectura de LIVE

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

2.5. Dyna: una Arquitectura Integrada para Aprendizaje, Planificacin y Reaccin

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

2.6. Sistema de Christiansen

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

2.7. Sistema de Hayes-Roth

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

PLANES PLANIFICACION Y PROYECCION ESPECTATIVAS

EJECUCION DEL PLAN

JUSTIFICACION DEL PLAN

TEORIAS CON ERRORES

DIAGNOSTICO DEL PLAN

Figura 2-6: arquitectura del sistema propuesto por Hayes-Roth

Invalidacin: desechar las situaciones que nieguen las predicciones de la teora.

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

2.8. Sistema Inteligente Autnomo

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

PERCEPCION DEL ENTORNO

ALMACENAMIENTO SITUACIONES Y EXPERIENCIAS

PLAN EN EJECUCION Y SITUACION ESPERADA

SUBOBJETIVO NO SELECCION DE SUBOJETIVO PLAN CONSTRUCCION DEL PLAN

SI EL PLAN EXISTE NO SELECCIONAR ACCION POR CURIOSIDAD

SI EL PLAN EXISTE NO SELECCIONAR ACCION POR AZAR

ACCION HACER CADA ACCION DEL PLAN

Figura 2-7: arquitectura del sistema inteligente autnomo

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

Aprendizaje Automtico Basado en Intercambio de Operadores en Sistemas Inteligentes Autnomos

3.2. Integracin SIA-Khepera

3.3. El problema de la extensin del modelo del SIA

3.4. Interaccin entre intercambio de operadores y otras estrategias