fumo: fuzzy moway

FUMO: FUZZY MOWAY

UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMÁTICA

Tecnologías y Sistemas de Información

TECNOLOGÍA ESPECÍFICA DE

COMPUTACIÓN

TRABAJO FIN DE GRADO

FUMO: FUzzy MOway

Autor: Sergio Martínez Municio

Director: Dr. Luis Jiménez Linares

Septiembre, 2014

Sergio Martínez Municio

Ciudad Real – Spain

E-mail: [email protected]

c© 2014 Sergio Martínez Municio

Permission is granted to copy, distribute and/or modify this document under the terms of the GNUFree Documentation License, Version 1.3 or any later version published by the Free SoftwareFoundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copyof the license is included in the section entitled "GNU Free Documentation License".Se permite la copia, distribución y/o modificación de este documento bajo los términos de laLicencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada porla Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta incluida enel apéndice titulado «GNU Free Documentation License».Muchos de los nombres usados por las compañías para diferenciar sus productos y servicios sonreclamados como marcas registradas. Allí donde estos nombres aparezcan en este documento, ycuando el autor haya sido informado de esas marcas registradas, los nombres estarán escritos enmayúsculas o como nombres propios.

i

TRIBUNAL:

Presidente:

Vocal:

Secretario:

FECHA DE DEFENSA:

CALIFICACIÓN:

PRESIDENTE VOCAL SECRETARIO

Fdo.: Fdo.: Fdo.:

iii

Resumen

El mundo de la robótica móvil está en pleno auge. La continua evolución tecnológica su-frida en este campo ha contribuido a su capacidad de asumir tareas cada vez más complejas.La variedad de tipos, junto con una reducción de los costes, han permitido su uso en labo-res docentes o de investigación. Para el desarrollo de dichas tareas, la Inteligencia Artificialconstituye un campo en el que se engloban diferentes áreas de conocimiento que promuevendotar de comportamientos más inteligentes a la hora de tomar las decisiones, siendo una delas que más repercusión está teniendo en los últimos años la Lógica difusa, pues proponeun modelo formal que permite tratar con la incertidumbre inherente al pensamiento humano,gozando de gran éxito en el marco del control automático de procesos.

En este área se asienta el presente Trabajo Fin de Grado, cuyo objetivo principal radicaen el desarrollo de un sistema que permita la construcción de un motor de inferencia difusobasado en una red RETE para la toma de decisiones de tal manera que la información delentorno sea obtenida de manera dinámica por un pequeño robot móvil.

FUMO es un sistema desarrollado mediante el uso de tecnologías libres que facilita ladefinición del motor de inferencia mediante el uso de un lenguaje descriptivo de alto nivel(FCL) de sintaxis reducida, con la capacidad de realimentar al usuario ante la presencia deerrores. Además, es capaz de proporcionar un sistema de comunicación por radiofrecuenciaque permite establecer una comunicación bidireccional con el robot empleado como caso deestudio (mOway).

Gracias a estas posibilidades, posee la capacidad de convertir el robot en autónomo, puesla red es representable a bajo nivel haciendo un uso eficiente de la memoria, además deproveer mecanismos de depuración que permiten saber en cualquier momento qué valoreshan sido empleados en el proceso de inferencia difusa.

V

Abstract

The world of mobile robotics is booming. Technological developments in this field hascontributed to perform more a more complex tasks. A wide variety of types, together witha reduction costs, have allowed its use on teaching and researching. Artificial Intelligenceincludes different areas of knowledge in order to provide smart behaviour when making de-cisions. Fuzzy Logic is one of the most relevant knowledge areas, because it suggest a formaltheory in order to lay the foundation for the treatment of uncertainty and vagueness.

The current project is envolved in this knowledge area. The main aim consists on deve-lopment of fuzzy inference engine based on pattern matching network called RETE. Thus,information is dinamically captured from environment by the robot.

FUMO is a system developed using free tools. Definition of fuzzy inference rule engineis done through high level descriptive language (FCL) reduced syntax. This language pro-vide the capability of feedback to the users in case of errors. Furthermore, it implements aradiofrecuency communication system that provides a bidirectional communication betweencomputer and robot.

Thanks to these posibilities, can be converted in autonomous robot, because the networkcan be translated from high level to low level making an efficient use of available memory.Moreover, it provides a debugging mechanism in order to know what values have been usedin the inference process.

VII

Agradecimientos

Llegó el momento. Parece que fue ayer cuando me veía preguntando donde estaba elaulario y ahora me encuentro escribiendo las que serán las últimas líneas que cierren unciclo tan bonito como agotador.

En primer lugar, dar las gracias a mi familia, y especialmente a mis padres, que han sido losque más han estado a mi lado, por todo su cariño y apoyo incondicional durante estos largosaños, pues siempre me han demostrado que están y estarán ahí para todo lo que necesite.Tengo claro que sin ellos, esto no hubiese sido posible.

También, a todos los compañeros y amigos que han contribuido a que mi estancia en laUniversidad haya sido mejor y más agradable.

Y por supuesto a mi director de proyecto, Luis Jiménez, primero por introducirme en estemundo tan apasionante que desconocía completamente contribuyendo aún más a que sientaespecial curiosidad por adentrarme en el fantástico mundo de la Inteligencia Artificial, ysegundo por su continuo apoyo, paciencia infinita y dedicación durante los largos meses deduración del proyecto.

Sergio Martínez Municio.

IX

Índice general

Resumen V

Abstract VII

Agradecimientos IX

Índice general XI

Índice de tablas XV

Índice de figuras XVII

Índice de listados XIX

Listado de acrónimos XXI

1. Introducción 1

1.1. Lógica difusa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Robótica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Justificación del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Objetivos 7

2.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3. Antecedentes 11

3.1. Teoría de Conjuntos Difusos . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1. Conceptos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.2. Operaciones básicas . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.3. Otras Operaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.4. Propiedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

XI

3.1.5. Operaciones básicas generalizadas . . . . . . . . . . . . . . . . . . 15

3.1.5.1. Normas Triangulares (T-Normas) . . . . . . . . . . . . . 16

3.1.5.2. T-Conormas o S-Normas . . . . . . . . . . . . . . . . . 16

3.1.5.3. Complemento difuso . . . . . . . . . . . . . . . . . . . 17

3.1.6. Otras definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.7. Funciones de Pertenencia . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.7.1. Función Trapezoidal∏

. . . . . . . . . . . . . . . . . . 18

3.1.7.2. Función Trapezoidal L . . . . . . . . . . . . . . . . . . . 19

3.1.7.3. Función Trapezoidal Γ . . . . . . . . . . . . . . . . . . . 19

3.1.7.4. Función Singleton . . . . . . . . . . . . . . . . . . . . . 19

3.1.7.5. Función Sigmoidal . . . . . . . . . . . . . . . . . . . . . 19

3.1.7.6. Función Triangular . . . . . . . . . . . . . . . . . . . . 19

3.1.7.7. Función Normalizada (Campana Gauss) . . . . . . . . . 20

3.1.7.8. Función Rectangular o Intervalo . . . . . . . . . . . . . 20

3.1.8. Variables lingüísticas . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.9. Reglas Difusas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.9.1. Operadores de Implicación . . . . . . . . . . . . . . . . 22

3.1.10. Mecanismos de Inferencia . . . . . . . . . . . . . . . . . . . . . . 24

3.1.10.1. Método de Mamdani . . . . . . . . . . . . . . . . . . . . 24

3.1.10.2. Método Takagi-Sugeno-Kang . . . . . . . . . . . . . . . 26

3.2. Mini-Robots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.1. mOway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1.1. Orígenes . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1.2. Controlador . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1.3. Sistema Motriz y Grupo de sensores e indicadores . . . . 30

3.2.1.4. Sistema de alimentación y Módulo RF . . . . . . . . . . 31

3.2.1.5. Programación . . . . . . . . . . . . . . . . . . . . . . . 31

3.3. Motor de Inferencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.3.1. Red RETE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.3.1.1. Partes de la red . . . . . . . . . . . . . . . . . . . . . . . 34

3.3.1.2. Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4. Método 37

4.1. Metodología de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2. Aplicación de la Metodología . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.1. Iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

xii

4.2.2. Calendario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3. Otras consideraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3.1. Líneas de código . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.3.2. Coste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.4. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.4.1. Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.4.2. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.4.3. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5. Resultados 53

5.1. Visión General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.2. Perspectiva de Alto nivel . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2.1. Módulo BinaryHeap . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2.1.1. Montículo binario . . . . . . . . . . . . . . . . . . . . . 62

5.2.2. Módulo Utils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2.3. Módulo de Gráficos . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.2.4. Módulo FuzzyInference . . . . . . . . . . . . . . . . . . . . . . . 70

5.2.5. Módulo ReteNetwork . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2.6. Módulo de Procesamiento de Lenguaje . . . . . . . . . . . . . . . 78

5.2.7. Módulo Moway . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.3. Perspectiva de Bajo nivel . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.3.1. Firmware mOway . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.3.2. RETE de bajo nivel . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6. Conclusiones y Propuestas 99

6.1. Objetivos alcanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

6.2. Propuestas de trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . 102

A. Manual de Usuario 107

A.1. Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

A.2. Guía de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

A.3. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

A.4. Compilación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

A.5. Guía de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

A.5.1. Ejecutar la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . 109

A.5.2. Uso de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . 110

xiii

B. Fuzzy Control Language 115

C. Gramática EBNF 137

D. Analizador léxico 141

E. Ejemplo RETE 145

E.1. Base de reglas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

E.2. Infiriendo resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

E.2.1. Etapa de fuzzyficación . . . . . . . . . . . . . . . . . . . . . . . . 147

F. mOway Sensores y Actuadores 151

F.1. Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

F.2. Sensores con incrementos . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

F.3. Actuadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

F.4. Actuadores con incrementos . . . . . . . . . . . . . . . . . . . . . . . . . 153

G. Código Fuente 155

H. GNU Free Documentation License 157

H.0. PREAMBLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

H.1. APPLICABILITY AND DEFINITIONS . . . . . . . . . . . . . . . . . . . 157

H.2. VERBATIM COPYING . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

H.3. COPYING IN QUANTITY . . . . . . . . . . . . . . . . . . . . . . . . . . 158

H.4. MODIFICATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

H.5. COLLECTIONS OF DOCUMENTS . . . . . . . . . . . . . . . . . . . . . 159

H.6. AGGREGATION WITH INDEPENDENT WORKS . . . . . . . . . . . . 160

H.7. TRANSLATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

H.8. TERMINATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

H.9. FUTURE REVISIONS OF THIS LICENSE . . . . . . . . . . . . . . . . . 160

H.10.RELICENSING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Referencias 163

xiv

Índice de tablas

3.1. Ejemplo op. básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2. T-Normas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3. T-Conormas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4. Operadores difusos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1. Diferencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2. Calendario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3. Estadísticas del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.4. Coste del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.1. Tratamiento de excepciones . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.2. Tabla de Palabras Reservadas . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.3. Tabla de Pares de algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . 98

F.1. Lista de asociaciones de sensores . . . . . . . . . . . . . . . . . . . . . . . 152

F.2. Lista de asociaciones de sensoresd . . . . . . . . . . . . . . . . . . . . . . 152

F.3. Lista de asociaciones de actuadores . . . . . . . . . . . . . . . . . . . . . 153

F.4. Lista de asociaciones de actuadoresd . . . . . . . . . . . . . . . . . . . . . 153

XV

Índice de figuras

1.1. Modus Ponens y CRI respectivamente . . . . . . . . . . . . . . . . . . . . 2

1.2. Diferencia de enfoques difuso y nítido . . . . . . . . . . . . . . . . . . . . 3

1.3. Sistema difuso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1. Funciones de pertenencia más usuales . . . . . . . . . . . . . . . . . . . . 21

3.2. Tipos de Sistemas Difusos (FLC) . . . . . . . . . . . . . . . . . . . . . . . 23

3.3. Inferencia Mamdani con defuzzificación centro de gravedad discreta (An-drew Kusiak - UIOWA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4. Inferencia Sugeno de orden cero (Andrew Kusiak - UIOWA) . . . . . . . . 27

3.5. Arquitectura Harvard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.6. Memoria PIC18F86J50 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1. Ciclo de Desarrollo iterativo en espiral . . . . . . . . . . . . . . . . . . . . 39

5.1. Perspectiva general de la arquitectura . . . . . . . . . . . . . . . . . . . . . 54

5.2. Diagrama de casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.3. Diagrama de Clases general . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.4. Diagrama de clases BinaryHeap . . . . . . . . . . . . . . . . . . . . . . . 60

5.5. Montículo Binario de mínimos . . . . . . . . . . . . . . . . . . . . . . . . 62

5.6. Representación gráfica de los nodos . . . . . . . . . . . . . . . . . . . . . 70

5.7. Diagrama de clases del módulo de inferencia . . . . . . . . . . . . . . . . 71

5.8. Diagrama de clases del sub-módulo de normas . . . . . . . . . . . . . . . . 74

5.9. Diagrama de clases del módulo ReteNetwork . . . . . . . . . . . . . . . . 75

5.10. Diagrama de clases Moway . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.11. Diagrama de Secuencia de comandos . . . . . . . . . . . . . . . . . . . . . 90

5.12. Estructuras involucradas en RETE de bajo nivel . . . . . . . . . . . . . . . 96

A.1. Contenido del fichero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

E.1. Motor de inferencias de la base de conocimientos . . . . . . . . . . . . . . 148

XVII

http://user.engineering.uiowa.edu/~comp/public/fuzzy_logic_2.pdf



Índice de listados

3.1. Uso de Overlays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1. Constructor de colas de prioridad . . . . . . . . . . . . . . . . . . . . . . . 61

5.3. Trunca un valor decimal a precision decimales . . . . . . . . . . . . . . . . 63

5.4. Separación de un valor decimal en parte entera y decimal . . . . . . . . . . 64

5.5. Signaturas de funciones que dan formato a la salida . . . . . . . . . . . . . 65

5.6. Comprobación de directorio . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.7. Comprobación de fichero . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.8. Compilación de la red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.9. Generación del grafo en formato visual . . . . . . . . . . . . . . . . . . . . 68

5.10. Formatos admitidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.11. Definición de conjunto difuso . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.12. Cálculo del centro de gravedad en Funciones Trapezoidales . . . . . . . . . 72

5.13. Ejemplo de Regla con etiquetas distintas . . . . . . . . . . . . . . . . . . . 76

5.14. Ejemplo de regla incorrecta resultante . . . . . . . . . . . . . . . . . . . . 76

5.15. Ejemplo de declaración de variables . . . . . . . . . . . . . . . . . . . . . 81

5.16. Ejemplo de definición de variables . . . . . . . . . . . . . . . . . . . . . . 81

5.17. Ejemplo de definición de reglas . . . . . . . . . . . . . . . . . . . . . . . . 81

5.18. Ejemplo de definición de opciones . . . . . . . . . . . . . . . . . . . . . . 82

5.19. Ejemplo de definición de opciones . . . . . . . . . . . . . . . . . . . . . . 82

5.20. Rutina de envío de bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.21. Rutina de recepción de bytes . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.22. Estructuras que albergan datos relacionados . . . . . . . . . . . . . . . . . 92

5.2. TAD Montículo Binario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

D.1. Especificación léxica del lenguaje . . . . . . . . . . . . . . . . . . . . . . 141

E.1. Base de Reglas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

F.1. Ejemplo de declaración de variables incrementadas . . . . . . . . . . . . . 151

XIX

Listado de acrónimos

IEEE Instituto de Ingeniería Eléctrica y Electrónica

JESS Java Expert System Shell

CLIPS Language Integrated Production System

API Interfaz de programación de aplicaciones

CASE Computer Aided Software Engineering

IEC International Electrotechnical Commission

XXI

CAPÍTULO

1

Introducción

L A Inteligencia Artificial, desde su aparición en los años 50, ha intentado comprender laforma de raciocinio humano con el propósito de construir sistemas que realicen tareas

que normalmente requieren de la inteligencia humana. El razonamiento humano tiende atratar con componentes donde impera la incertidumbre, debido a que la información conla que se trabaja puede ser imprecisa o vaga. Este hecho constituye uno de los problemasfundamentales a los que se ha enfrentado y prestado más atención la Inteligencia Artificialdesde sus inicios.

Para observar las sutiles diferencias entre ambos conceptos consideremos el enunciado «Elpaciente tose bastante». Por una parte, estamos ante una proposición vaga puesto que nopodemos saber si realmente el paciente está tosiendo, y por otra,ante una proposición im-

precisa, puesto que depende del criterio de cada cual la determinación del valor que recibebastante.

A lo largo de la historia, han surgido varios enfoques que permiten hacer razonamientos conincertidumbre, destacando principalmente dos: aquellos que se basan en modelos probabilís-ticos, como son las redes bayesianas, y los que se basan en modelos posibilísticos, como esla lógica difusa.

La principal diferencia entre ambas aproximaciones radica en que la primera se encuentraadherida al axioma del tercero excluido, el cual afirma que para toda proposición p, ya seap o ¬p deben ser verdaderas, excluyendo cualquier variable intermedia que pueda ser cierta;mientras que la segunda no está sujeta a tal axioma, permitiendo la existencia de variablesintermedias que puedan ser valoradas como ciertas con un grado de pertenencia [RBP02],permitiendo tratar con eventos que no tienen fronteras perfectamente definidas (nítidos).

1

2 CAPÍTULO 1. INTRODUCCIÓN

1.1 Lógica difusaLa lógica difusa se engloba dentro de las lógicas multivaluadas proponiendo un modeloformal que permite manejar la imprecisión y ambigüedad con la que el ser humano piensasoportando modos de razonamiento aproximados en lugar de exactos. Así, el razonamientoaproximado puede verse como un procedimiento para obtener conclusiones partiendo dehechos imprecisos (mecanismo de inferencia).

La lógica clásica empleaba para inferir resultados la regla del silogismo, la cual dice que sitenemos una regla del modo A → B y tenemos el hecho A, entonces podemos concluir B;sin embargo, para el tratamiento de valores aproximados, la regla de inferencia clásica no esválida pues al tratar con información exacta, es muy probable que la hipótesis no coincidacon el antecedente de la regla de modo que no podríamos obtener (inferir) ningún resultado.Por esta razón, fue necesario introducir un nuevo método que generalizase el modus ponens

tradicional denominado Regla composicional de inferencia (CRI) (Fig. 1.1).

Figura 1.1: Modus Ponens y CRI respectivamente

El concepto de lógica difusa fue acuñado por el ingeniero Lofti A. Zadeh en 1965 mediantela publicación del artículo «Fuzzy Sets» en la revista Information and Control. El profesorZadeh no estaba conforme con la limitada capacidad de expresividad de los conjuntos clá-sicos (crisp sets), por lo que en un afán de eliminar esta limitación, presentó los conjuntosdifusos (fuzzy sets), pudiendo ser considerados como una generalización de los primeros.

La teoría clásica de conjuntos considera que un elemento dado o pertenece a un conjunto o ensu defecto, pertenece a su conjunto complementario (solo pueden tomar un valor: 0 - (Falso)

o 1 - (Verdadero)). Además, afirma que un elemento que pertenece a un conjunto no puedepertenecer simultáneamente a otro. Por el contrario, la teoría de conjuntos difusos rechazaestas ideas y propone diferentes grados de pertenencia de un elemento dado a cierto conjuntoen los que la transición de la pertenencia a la no pertenencia se realiza de manera gradual(pueden tomar cualquier valor real del intervalo [0,1]), permitiendo además pertenenciasparciales a distintos conjuntos (Fig. 1.2).

Este valor de certeza parcial se puede apreciar en el enunciado «Hoy hace calor», reflejandola ambigüedad con la que típicamente tiende a expresarse el hombre. Considerando única-mente esta premisa, si bien no podemos saber con certeza cuantos grados hacen, sí se puedeconjeturar que ésta está por encima de los 30 grados, aunque es un hecho intrínseco del cri-terio de cada persona. De este modo, bajo un enfoque clásico, se determinaría un umbral de

CAPÍTULO 1. INTRODUCCIÓN 3

Figura 1.2: Diferencia de enfoques difuso y nítido

pertenencia a partir del cual, toda temperatura que esté por encima supondrá que hace calory toda temperatura que esté por debajo supondrá que hace frío. Sin embargo, este hecho notiene porqué ser cierto. Por el contrario, bajo un enfoque difuso, los límites entre qué consi-derar calor y qué considerar frío no están bien definidos, obteniendo respuestas mucho máscercanas a lo que dicta el sentido común.

Este nuevo punto vista propuesto por el profesor Zadeh suponía una revolución demasiadogrande y la comunidad científica lo miraba con cierto escepticismo, en gran parte debidoal término fuzzy (difuso) que tiene una connotación peyorativa en inglés, y también fue ob-jeto de gran controversia, ya que no terminaban de aceptar esa «ruptura» radical con losfundamentos de lógica clásica; sin embargo, gracias a este nuevo enfoque, se consiguieronmanipular conceptos del lenguaje que hasta entonces, era impensable.

Los sistemas difusos resultan especialmente útiles cuando la complejidad del problema aresolver es muy alta y no existe un modelo matemático preciso que lo resuelva, o cuando enun proceso se encuentra inmerso conocimiento vago. El propio Zadeh destaca en su Principio

de Incompatibilidad [Zad73] que a medida que la complejidad del sistema crece es más

difícil ser preciso a la hora de modelar su comportamiento. Así, un sistema difuso (Fig.1.3) estará compuesto por una base de reglas que codificará el conocimiento disponible delproblema y un motor de inferencias que proporcionará los resultados obtenidos.

La lógica difusa, a pesar de su juventud, goza de buena salud. En los últimos años, aplicacio-nes basadas en este enfoque han ido implantándose en distintas áreas de conocimiento, comola medicina, las finanzas o la industria, siendo éste campo donde más éxito ha gozado, másconcretamente en el control automático de procesos. Cada vez es más habitual encontraraparatos electrónicos domésticos que hacen uso de ella: lavadoras, aparatos de aire acon-

dicionado, cámaras fotográficas y de video, etc. También hay que destacar su contribuciónen la creación de nuevas disciplinas como la Ingeniería del Conocimiento, cuyo objetivo se


Figura 1.3: Sistema difuso

centra en el desarrollo de sistemas expertos, que basan su funcionamiento en el conocimientoobtenido por medio de un experto.

1.2 RobóticaEl éxito que ha cosechado en los últimos años la lógica difusa se puede equiparar con elincipiente auge de la robótica, constituyendo un campo que está en continuo crecimiento ycon expectativas de crecer aun más en un futuro cercano.

La tendencia de reducción de tamaño de los dispositivos electrónicos junto con una dismi-nución del costo del prototipo ha contribuido al surgimiento de los mini-robots.

Los mini-robots son pequeños dispositivos hardware autónomos y móviles que pueden desem-peñar diversas tareas de complejidad media con gran solvencia. Cuando hablamos de auto-

nomía estamos haciendo referencia tanto a la autosuficiencia energética como a la capacidadde tomar decisiones por sí solo. En este último aspecto, se pueden destacar dos tipos de con-troladores: controlador proporcional-integral-derivativo (PID) y el más reciente y novedosocontrolador lógico difuso.

Si bien el primero es el más utilizado en maquinaria industrial ya que son altamente fia-bles y proporcionan tiempos de respuesta rápidos, son incapaces de tratar con problemas nolineales, siendo muy comunes en los procesos industriales, pues basan su funcionamientoen modelos matemáticos lineales 1, por lo que adecuar los parámetros de este tipo de con-troladores a un estado óptimo de ejecución puede resultar muy complicado (Principio de

Incompatibilidad) [FFUA+99, US14].

Por esta razón, surge el segundo tipo, cuyo objetivo era proporcionar a los controladoresmás flexibilidad a cambios y dotarlos de mayor robustez (tolerancia a datos imprecisos), yaque resultan sencillos de mantener y conceptualmente son más fáciles de entender, pues el

1Un sistema no lineal no satisface el principio de superposición, de manera que la salida obtenida no esdirectamente proporcional a las entradas del mismo.

CAPÍTULO 1. INTRODUCCIÓN 5

conocimiento es proporcionado en base a reglas escritas en lenguaje natural guiadas por elpropio sentido común (información inexacta) en vez de números (información exacta).

1.3 Justificación del trabajoComo se ha comentado a lo largo del presente capítulo, tenemos por un lado una herramientamatemática que nos permite modelar aspectos vagos o inciertos presentes en un entorno tancambiante como es el mundo real, y por otro, el auge vivido en la electrónica de consumo hapropiciado que en los últimos años aparezcan, cada vez más, pequeños dispositivos móvilesautónomos que nos permiten interactuar con el entorno que nos rodea, resultando interesanteintentar que ambos conceptos converjan hacia un mismo camino.

Es por todo esto que, lo que se propone en el presente trabajo es la realización de un sistemaque incorpore módulos de comportamiento basados en lógica difusa sobre un mini-robot mó-vil autónomo con el propósito que sea de especial utilidad en distintos ámbitos de aplicación:investigación y docencia.

En materia de docencia puede ser utilizado como una mera introducción al mundo de larobótica autónoma inteligente en los centros educativos o contribuir a afianzar las competen-cias propias de asignaturas afines, como pueden ser los sistemas basados en el conocimiento

(SBC) o la Inteligencia Artificial (IA). Del mismo modo, al abstraer al usuario de aspec-tos arquitecturales propios del dispositivo, puede centrar todo su tiempo y dedicación en eldesarrollo de un modelo de comportamiento en base al conocimiento introducido pudiendoobservar el efecto que produce en un entorno real, fomentando el interés de los alumnos entrabajar con este tipo de equipos.

Por otra parte, en materia de investigación, el sistema desarrollado puede ser empleado comopequeño prototipo que sirva como base a otros proyectos de mayor envergadura o comoentorno de pruebas a escala según el contexto de la investigación.

1.4 Estructura del documentoEste documento ha sido estructurado según las indicaciones de la normativa de trabajos finde grado de la Escuela Superior de Informática de la Universidad de Castilla-La Mancha,estando constituido en los siguientes capítulos:

En el capítulo 1 se expone una breve presentación de los temas sobre los que se en-marca el presente trabajo.

En el capítulo 2 se hará una descripción del objetivo principal que se pretende abor-dar así como una serie de objetivos más específicos que deberá resolver el softwaredesarrollado. Así mismo, también se tendrán en cuenta las limitaciones y el materialnecesario para su desarrollo.

En el capítulo 3 se profundizará en los temas introducidos en el capítulo 1 como son


la teoría de conjuntos difusos, motor de inferencia utilizado y posibles alternativaspropuestas, así como trabajos realizados en las áreas de conocimiento inmersas en esteproyecto y demás herramientas empleadas.

En el capítulo 4 se explicará la solución adoptada para el problema. Además, se de-finirá la metodología de desarrollo empleada y se describirán los recursos empleados,tanto software como hardware.

En el capítulo 5 se describirá la aplicación de la metodología descrita en el capítulo 3y se mostrarán todos los resultados obtenidos. Para que sea más descriptivo, se acom-pañará de distintos diagramas y se explicará con detalle los aspectos más relevantes dela construcción del sistema.

En el capítulo 6 se discutirán las conclusiones obtenidas tras la finalización del desa-rrollo y se propondrán una serie de líneas de trabajo futuro para continuar mejorandoel sistema desarrollado.

CAPÍTULO

2

Objetivos

2.1 Objetivo general

E N la actualidad existen diversas herramientas para la construcción de sistemas de infe-rencia basados en lógica difusa, como por ejemplo la herramienta Xfuzzy, desarrolla-

da por el Instituto de Microelectrónica de Sevilla que proporciona mecanismos para definirun sistema difuso, simular el comportamiento del sistema desarrollado e incluso generardescripciones en lenguaje de alto nivel (C, C++, JAVA) para implementaciones software ohardware. Así mismo existen otras menos potentes y sofisticadas como son FuzzyLite (C++)o JFuzzylogic (JAVA) que también nos permiten diseñar y probar el comportamiento quetendrá el sistema difuso.

Los sistemas difusos obtenidos mediante este tipo de herramientas permiten ser probadosmediante simulaciones guiadas por software, por lo que existe cierta carencia a la hora deextrapolar las pruebas a dispositivos reales. Por esta razón, el desarrollo del presente Tra-bajo Fin de Grado pretende resolver dicha carencia mediante la construcción de un sistemadidáctico para el uso de razonamiento aproximado, de manera que pueda ser aplicado sobreun pequeño robot móvil autónomo.

2.2 Objetivos específicos

A continuación se expondrán una serie de objetivos más específicos proporcionando unavisión más detalla del proyecto:

Utilización de un sistema físico sobre el que poder probar el sistema desarrollado.Éste sistema deberá ser de bajo costo, móvil y autónomo con el objetivo de poder llegaral mayor número de usuarios. Como caso de estudio, se hará uso de un mini-robotmOway, de la empresa Bizintek Innova S.L, aunque debe permitir, con un númeropequeño de modificaciones, poder ser adaptado a cualquier otro robot que cumpla lascaracterísticas expuestas en este punto. Éstas modificaciones atenderán principalmente

7

http://www.fuzzylite.com/

http://jfuzzylogic.sourceforge.net/html/index.html

8 CAPÍTULO 2. OBJETIVOS

al mecanismo de comunicación empleado por el robot escogido así como al conjuntode sensores y actuadores disponibles, dejando intacta la parte correspondiente a lageneración del motor de inferencias.

Construcción de un lenguaje específico del dominio (DSL) 1 que facilite la crea-ción del sistema difuso. Deberá ser capaz de ofrecer al usuario la posibilidad de crearvariables que serán utilizadas para construir un sistema de reglas difusas. El resultadode compilar este lenguaje será un fichero binario .rete que contendrá el motor de infe-rencia difusa. Así mismo, también re-alimentará al usuario mostrando posibles erroresque hayan podido ocurrir durante el proceso de compilación además de su localizaciónen el fuente.

Garantizar un funcionamiento óptimo en distribuciones GNU/Linux. Se desarro-llará un sistema que sea completamente funcional en plataformas GNU/Linux; sin em-bargo, debe ser lo suficientemente flexible en caso de querer llevarla a otra plataforma,como Microsoft Windows. Para ello, se hace uso de estándares y tecnologías multipla-taforma (JAVA) evitando en la medida de lo posible llamadas a función exclusivas delsistema operativo.

Desarrollo de un sistema de comunicación por radio-frecuencia (RF). Haciendouso de la herramienta libusb, se creará un controlador a nivel de usuario para poderinteractuar con el mOway. Se partirá de una especificación en alto nivel escrita paraMicrosoft Windows en C++ traduciéndola a lenguaje (JAVA) de modo que pueda serejecutada en GNU/Linux.

Construcción del motor de inferencia difusa a bajo nivel. El sistema, a partir delmotor de inferencia obtenido de la fase de compilación del lenguaje, deberá ser capazde traducirlo a nivel de Byte con el propósito de embeberlo en un mini-robot.

Distintos modos de ejecución. El sistema debe permitir al usuario poder cambiar laejecución en cualquier momento. Ofrecerá tres modos distintos:

1. Ejecutar el sistema en modo automático, de manera que el mini-robot será capazde tomar sus propias decisiones en función del entorno y del motor de inferenciasembebido, siendo completamente autónomo.

2. Ejecutar el sistema en modo manual, de manera que el mini-robot dependerá delmotor de inferencias alojado en el computador. Así, de este modo, se puede vercomo una disposición cliente-servidor, donde el cliente sería el mini-robot y elservidor el computador.

3. Ejecutar un comando manual, centrado principalmente en la obtención de in-formación del entorno (valor de los sensores de obstáculos, valor del sensor de

temperatura, etc) de manera que el mini-robot finalizará la ejecución en curso y

1Son lenguajes de programación especializados en un dominio de aplicación particular.

CAPÍTULO 2. OBJETIVOS 9

ejecutará el comando seleccionando.

Desarrollo del sistema haciendo uso de herramientas open-source. Tanto el desa-rrollo como la gestión documental (documentación, repositorios, etc) del proyecto sellevará a cabo utilizando tecnologías libres.

Depuración del sistema. Debe permitir al usuario poder obtener el valor de los sen-sores y actuadores así como los valores almacenados por el motor de inferencia enun instante dado con el objetivo de comprobar el correcto funcionamiento del procesode inferencia. Independientemente el modo de ejecución, se permitirán los siguientesmodos:

1. Obtener sensores y actuadores, retornando los valores obtenidos por los sensorespara hacer la inferencia y el valor que han tomado los actuadores para llevar acabo el comportamiento en un instante dado.

2. Obtener valores del motor de inferencia, proporcionando todos los valores inter-medios almacenados por el motor en un instante dado.

3. Obtener sensores y actuadores y valores del motor de inferencia, obteniendo unacombinación de los dos métodos anteriores.

Desarrollar una aplicación interactiva en modo ascii. La finalidad del proyecto esconseguir que un robot móvil sea capaz de actuar de manera autónoma de acuerdo alas decisiones inferidas a partir del entorno y su base de conocimientos, por lo queno se precisa de una interfaz gráfica de usuario. Así, para que el resultado final nodesmerezca, se hará uso de arte ascii 2 para que la interacción con el usuario sea lomás agradable posible.

Facilidad de uso. Se pretende llegar al mayor número de usuarios, desde los másavanzados hasta los más nóveles, por lo que se ha hecho un gran esfuerzo en facilitarla usabilidad de la aplicación abstrayendo de elementos irrelevantes. Así mismo, seproporcionará un completo manual de usuario detallando todos los aspectos usablesdel sistema.

2Medio artístico que utiliza recursos computarizados fundamentados en los caracteres de impresión ascii.http://es.wikipedia.org/wiki/Arte ASCII

http://es.wikipedia.org/wiki/Arte_ASCII

CAPÍTULO

3

Antecedentes

E N el presente capítulo se ahondará más en las áreas de conocimiento involucradas en larealización del presente Trabajo Fin de Grado. Además, se expondrán aspectos técni-

cos del dispositivo móvil a utilizar como caso de estudio del presente proyecto y una brevejustificación del porqué de su elección.

3.1 Teoría de Conjuntos DifusosCon frecuencia, se encuentran en el mundo real clases (conjuntos) de objetos que no tienendefinidos criterios de pertenencia. Tal es el caso de «el conjunto de hombres altos», «el

conjunto de temperaturas cálidas» o «el conjunto de las mujeres guapas», no constituyenconjuntos de términos en el sentido matemático habitual, pues existe un estatus ambiguo quepermita definir un criterio para clasificar los elementos a dichos conjuntos [Zad65].

En los conjuntos clásicos, la transición entre la pertenencia y no pertenencia de un elementoal conjunto es abrupta, mientras que en los conjuntos difusos, se realiza de manera gra-

dual. Esta última idea contrasta con los conjuntos clásicos porque en estos, un elementono es miembro a menos que su pertenencia al conjunto tenga asignado el valor «1». Por elcontrario, en los conjuntos difusos, un elemento puede pertenecer al mismo tiempo a otrosconjuntos del mismo dominio pues su pertenencia puede tener otro valor distinto de «1»[RBP02].

3.1.1 Conceptos básicosCon el propósito de facilitar la comprensión de ciertos conceptos propios de esta disciplinaal lector, pues serán utilizados en el capítulo 5, se hace notorio explicarlos desde un puntode vista formal. Además, para que no resulte demasiado teórico, se acompañarán con brevesejemplos.

Definición 3.1.1 (Universo de Discurso). El universo de discurso o dominio, denotado porU, es el rango de todos los valores posibles que puede tomar una entrada del sistema difuso.

11

12 CAPÍTULO 3. ANTECEDENTES

Ejemplo 1. El universo de discurso altura, que cuantifica elementos en base a su altura encm. viene determinado por altura = [0,220].

Definición 3.1.2 (Conjunto Difuso). Un conjunto difuso A de un universo de discurso U estácaracterizado por una función de membresía µA(x) que asocia a cada punto en X un númeroreal del intervalo [0,1], donde el valor de µA(x) en x representa el «grado de pertenencia»de x en A [Zad65].

Partiendo de la definición anterior, formalmente, un conjunto difuso es igual a su funciónde pertenencia µA(x) [BB95] y puede representarse de diferentes maneras. La forma másdirecta partiendo de la definición es representarlo como un conjunto de pares ordenados, taly como se aprecia en la ecuación 3.1.

A = (x, µA(x)|x ∈ U) (3.1)

Además es posible, dependiendo del tipo de dominio, es decir, de si éste es discreto y finito ocontinuo e infinito, definirlo como se aprecia en las ecuaciones 3.2 y 3.3 respectivamente.

A = µA(x0)/x0 + µA(x1)/x1 + ...+ µA(xn)/xn =n∑

xi∈U

µA(xi)/xi (3.2)

donde el término µA(xi)/xi, con i = 1, 2, 3, ..., n, significa que µA(xi) es el grado de perte-

nencia de xi en el conjunto A.

A =

∫U

µA(x)/x (3.3)

Ejemplo 2. Sea alturamedia un subconjunto del universo de discurso del ejemplo 1, definidocomo sigue: alturamedia = [170, 180]. Un conjunto difuso A queda definido como sigue:

Según (3.1): A = {(170, 0), (175, 1), (180, 0)}.

Según (3.2): A = {0/170 + 1/175 + 0/180}.

Según (3.3): A =∫ 180

170(µA(x)

x), con x ∈ [170, 180].

Definición 3.1.3 (Función de Pertenencia). Se denomina función de pertenencia de un con-junto difuso A sobre un universo de discurso U, denotado por µA : U → [0, 1], a la funciónque asocia a cada elemento x ∈ U , un valor x′ ∈ [0, 1]. Dicho valor recibe el nombre degrado de pertenencia.

Ejemplo 3. Sea el conjunto difuso A = {(180, 1)}. Definimos la función de pertenencia

singleton de A como sigue:

CAPÍTULO 3. ANTECEDENTES 13

µA(x) =

{1 si x = 180;

0 si x 6= 180.

Más adelante, en la sección 3.1.7 se verán más tipos de funciones ampliamente utilizadas.

Así, si dado un elemento x′ ∈ [0, 1] toma el valor «0», querrá decir que dicho elementono pertenece al conjunto A; por otro lado, si toma el valor «1», querrá decir que dichoelemento pertenece totalmente al conjunto A. Cualquier otro valor x′i|0 < x′i < 1, coni = 1, 2, 3, ..., n, diremos que pertenece en cierto grado al conjunto A.

3.1.2 Operaciones básicasLas operaciones básicas de los conjuntos clásicos son también aplicables a los conjuntosdifusos [RBP02]:

La unión de dos conjuntos difusos A(x) y B(x), con x ∈ U , es otro conjunto difusocuya función de pertenencia viene determinada por:

µA∪B(x) = µA(x) ∨ µB(x) = max{µA(x), µB(x)} (3.4)

Es equivalente a la operación OR del algebra booleana.

La intersección de dos conjuntos difusos A(x) y B(x), con x ∈ U , es otro conjuntodifuso cuya función de pertenencia viene determinada por:

µA∩B(x) = µA(x) ∧ µB(x) = min{µA(x), µB(x)} (3.5)

Es equivalente a la operación AND del algebra booleana.

El complemento de un conjunto difuso A(x), con x ∈ U , es otro conjunto difuso cuyafunción de pertenencia viene determinada por:

µA(x) = 1− µA(x) (3.6)

Es equivalente a la operación NOT del algebra booleana.

Ejemplo 4. Consideremos los conjuntos difusos (alta, media, baja) que definen la variablevelocidad (Tabla 3.1).

Por (3.4), tenemos queC = µalta∪media(x), con x ∈ [0, 100], es igual a {(x1/0), (0/10),

(0,1/20), (0,9/40), (0,7/60), (1/100)}, siendo x1 = max{µA(0), µB(0)} = max{0, 0}= 0.Con el resto de pertenencias habría que hacerlo de manera análoga.


Por (3.5),tenemos queC = µalta∩media(x), con x ∈ [0, 100], es igual a {(x1/0), (0/10),

(0/20), (0/40), (0,3/60), (0/100)}, siendo x1 = min{µA(0), µB(0)} = min{0, 0} =

0.

Por (3.6), tenemos queC = µalta(x), con x ∈ [0, 100], es igual a {(x1/0), (1/10), (1/20),

(1/40), (0,7/60), (1/100)}, siendo x1 = {1− µA(0)} = {1− 0} = 1.

3.1.3 Otras OperacionesIgualdad: Dos conjuntos difusos A y B son iguales, denotado como A = B, sí y solosi para todo x ∈ U , siendo U el universo de discurso, se cumple [BB95]:

µA(x) = µB(x) (3.7)

Inclusión: El conjunto difuso A está incluido en el conjunto difuso B, denotado comoA ⊆ B, sí y solo si para todo x ∈ U , siendo U el universo de discurso, se cumple[BB95]:

µA(x) ≤ µB(x) (3.8)

Subconjunto Propio: El conjunto difuso A es un subconjunto propio del conjuntodifuso B, denotado como A ⊂ B, cuando A es un subconjunto de B, y A 6= B [BB95]:

{µA(x) ≤ µB(x) para cada x ∈ U,µA(x) < µB(x) para al menos un x ∈ U

(3.9)

siendo U el universo de discurso.

Diferencia: Dados dos conjuntos difusos A y B, la diferencia de A y B, denotado comoA − B es otro conjunto difuso cuya función de pertenencia viene determinada por[BB95]:

µA−B(x) = min(µA(x), µB(x)) (3.10)

Ejemplo 5. Sea el conjunto difuso A = {(180, 1)} y el conjunto difuso B = {(180, 1)}.

Por (3.7), tenemos que A = B, pues µA(x) = µB(x).

Por (3.8), tenemos que A ⊆ B, pues µA(x) ≤ µB(x).

Por (3.9), tenemos que A ⊂ B, pues µA(x) = 1 y µB(x) = 1, 1 = 1.

Por (3.10), tenemos que A−B es igual al conjunto C = µA−B(180) = {(0/180)}.


3.1.4 PropiedadesExisten dos grupos de propiedades: aquellas que son cumplidas por ambas teorías, y aquellasque son exclusivas de los conjuntos difusos. Comenzaremos por las comunes [BB95]:

Conmutativa

{A ∩B = B ∩ AA ∪B = B ∪ A

(3.11)

Idempotencia

{A ∪ A = A

A ∩ A = A(3.12)

Asociativa

{(A ∪B) ∪ C = A ∪ (B ∪ C)

(A ∩B) ∩ C = A ∩ (B ∩ C)(3.13)

Distributiva

{A ∪ (B ∩ C) = (A ∪B) ∩ (A ∪ C)

A ∩ (B ∪ C) = (A ∩B) ∪ (A ∩ C)(3.14)

Leyes de De Morgan

{A ∪B = A ∩BA ∩B = A ∪B

(3.15)

Doble Negación: A = A (3.16)

Por otra parte, hay dos propiedades que sólo cumplen los conjuntos difusos, ya que éstospermiten solapamiento entre un conjunto A y su complementario A [RBP02], situación queviola los fundamentos de la teoría clásica de conjuntos:

Ley del tercero excluido: A ∪ A 6= U (3.17)

Ley de la contradicción: A ∩ A 6= ∅ (3.18)

La ausencia de las leyes del tercero excluido hacen que los conjuntos difusos sean menosespecíficos que los conjuntos crisp, resultando más adecuados para describir la informaciónen términos vagos o imprecisos [BB95].

3.1.5 Operaciones básicas generalizadasLas operaciones introducidas en el apartado 3.1.2 pueden ser generalizadas para utilizarlasen los conjuntos difusos. De este modo, si restringimos el rango de pertenencia que un ele-mento arbitrario puede tener en un conjunto difuso al intervalo [0,1], que es el mismo quese emplea en los conjuntos clásicos, entonces las operaciones mostradas anteriormente se


comportan igual en ambos enfoques clásico y difuso.

3.1.5.1. Normas Triangulares (T-Normas)

Estas funciones (Tabla 3.2) constituyen la forma generalizada de la intersección clásica.

Una norma triangular o T-Norma, es una aplicación T : [0, 1]x[0, 1] → [0, 1] que cumplelas siguientes propiedades [Jag95]:

1. Elemento unitario: T (a, 1) = a.

2. Monotonicidad: Si a ≤ c ∧ b ≤ d, entonces T (a, b) ≤ T (c, d).

3. Conmutatividad: T (a, b) = T (b, a).

4. Asociatividad: T (T (a, b), c) = T (a, T (b, c)).

De este modo, la función de pertenencia generalizada de la intersección queda definida delsiguiente modo:

µA∩B(x) = T [µA(x), µB(x)] (3.19)

Las normas triangulares satisfacen la siguiente restricción [Jag95]:

Tw ≤ T (a, b) ≤ min(a, b) (3.20)

donde, a Tw se le conoce como el producto drástico y queda definido como:

Tw(a, b) =

a, si b = 1

b, si a = 1

0, en otro caso.

(3.21)

3.1.5.2. T-Conormas o S-Normas

Estas funciones (Tabla 3.3) constituyen la forma generalizada de la unión clásica.

Una T-Conorma o S-Norma, es una aplicación S : [0, 1]x[0, 1] → [0, 1] que cumple lassiguientes propiedades [Jag95]:

1. Elemento neutro: S(a, 0) = a.

2. Monotonicidad: Si a ≤ c ∧ b ≤ d, entonces S(a, b) ≤ S(c, d).

3. Conmutatividad: S(a, b) = S(b, a).

4. Asociatividad: S(S(a, b), c) = S(a, S(b, c)).


De este modo, la función de pertenencia generalizada de la unión queda definida del siguientemodo:

µA∪B(x) = S [µA(x), µB(x)] (3.22)

Las normas triangulares satisfacen la siguiente restricción [Jag95]:

max(a, b) ≤ S(a, b) ≤ Sw (3.23)

donde, a Sw se le conoce como la suma drástica y queda definida como:

Sw(a, b) =

a, si b = 0

b, si a = 0

1, en otro caso.

(3.24)

3.1.5.3. Complemento difuso

Estas funciones constituyen la forma generalizada del complemento clásico.

El complemento A de un conjunto difuso A, es una aplicación c : [0, 1]→ [0, 1] que cumplelas siguientes propiedades [Jag95]:

1. Condición límite: c(0) = 1 ∧ c(1) = 0.

2. Monotonicidad: Si a > b, entonces c(a) < c(b).

3. Involutividad: c(c(a)) = a.

De este modo, la función de pertenencia generalizada del complemento queda definida delsiguiente modo:

µA(x) = c(a) = 1− a. (3.25)

Otra función complemento generalizada utilizada ampliamente es el λ−complemento de Su-geno [Jag95]:

µAλ

(x) =1− µA(x)

1− λµA(x)(3.26)

3.1.6 Otras definicionesSi bien muchos conceptos propios de la teoría clásica de conjuntos pueden extrapolarse a lateoría de conjuntos difusos, éstos incorporan otros nuevos [Zad74]:


El soporte de un conjunto difuso A es un conjunto de puntos del universo de discursoU, para los cuales, la función de pertenencia µA(x) es positiva:

soporte(A) = {x ∈ U | µA(x) > 0} (3.27)

La altura de un conjunto difuso A es el valor más grande de la función de pertenenciaµA(x) que lo define:

altura(A) = {supremox∈U

µA(x)} (3.28)

El punto de cruce de un conjunto difuso A es un conjunto de puntos del universo dediscurso U, para los cuales, la función de pertenencia µA(x) es 0.5:

PuntoCruce(A) = {x ∈ U | µA(x) = 0,5} (3.29)

El núcleo de un conjunto difuso A es un conjunto de puntos del universo de discursoU, para los cuales, la función de pertenencia µA(x) es 1:

Kernel(A) = {x ∈ U | µA(x) = 1} (3.30)

3.1.7 Funciones de Pertenencia

Las funciones de pertenencia o membresía indican el grado de pertenencia de un elementox a un conjunto difuso dado A [Zad74] además de constituir una forma de representacióngráfica de los mismos. En la literatura es habitual encontrarse con las funciones expuestasen los siguientes sub-apartados (Fig 3.1). Tienden a escogerse funciones simples ya quesimplifican los cálculos y no pierden exactitud.

3.1.7.1. Función Trapezoidal∏

La función trapezoidal viene definida por medio de cuatro coordenadas, de manera quea ≤ b ≤ c ≤ d. Su representación analítica se puede apreciar en la ecuación (3.31):

µA(x) =

0, si x < ax−ab−a , si a ≤ x ≤ b

1, si b ≤ x ≤ cd−xd−c , si c ≤ x ≤ d

0, si d < x

(3.31)


3.1.7.2. Función Trapezoidal L

La función trapezoidal L constituye un caso particular de la función trapezoidal, pues vienedefinida por medio de cuatro coordenadas, de manera que (a = b = −∞) ∧ (c ≤ d). Surepresentación analítica se puede apreciar en la ecuación (3.32):

µA(x) =

0, si x > dd−xd−c , si c ≤ x ≤ d

1, si x < c

(3.32)

3.1.7.3. Función Trapezoidal Γ

La función trapezoidal Γ constituye un caso particular de la función trapezoidal, pues vienedefinida por medio de cuatro coordenadas, de manera que (a ≤ b) ∧ (c = d = ∞). Surepresentación analítica se puede apreciar en la ecuación (3.33):

µA(x) =

0, si x < ax−ab−a , si a ≤ x ≤ b

1, si x > b

(3.33)

3.1.7.4. Función Singleton

La función singleton es aquella cuyo soporte es una única coordenada y cuya altura es1, siendo ésta la más simple de todas. Su representación analítica se puede apreciar en laecuación (3.34):

µA(x) =

{0, si x 6= a

1, si x = a(3.34)

3.1.7.5. Función Sigmoidal

La función sigmoidal suele ser empleada a la hora de representar la función de activaciónen redes neuronales [ZB02]. Su representación analítica se puede apreciar en la ecuación(3.35):

µA(x) =1

1 + e−x(3.35)

3.1.7.6. Función Triangular

La función triangular viene definida por medio de tres coordenadas, de manera que a ≤m ≤ b, siendo m el punto central de la función. Su representación analítica se puede apreciar


en la ecuación (3.36):

µA(x) =

0, si x ≤ ax−am−a , si a ≤ x ≤ mb−xb−m , si m < x < b

0, si x ≥ b

(3.36)

3.1.7.7. Función Normalizada (Campana Gauss)

La función gaussiana viene definida por un valor central ′c′ y la desviación típica ′σ′, demanera que cuanto mayor sea σ, mayor será la superficie de la campana. Su representaciónanalítica se puede apreciar en la ecuación (3.37):

µA(x) = e−(x−cσ

)2 (3.37)

3.1.7.8. Función Rectangular o Intervalo

La función triangular viene definida por medio de cuatro coordenadas, de manera que (a =

b) ≤ (c = d). Su representación analítica se puede apreciar en la ecuación (3.38):

µA(x) =

0, si x < a

1, si a ≤ x ≤ c

0, si x > d

(3.38)

3.1.8 Variables lingüísticasUna variable lingüística es una variable cuyos valores son palabras o sentencias en un len-guaje natural o artificial (etiquetas lingüísticas). De este modo, resultan especialmente útilescuando existen fenómenos demasiado complejos de definir o cuando no existe una defini-ción susceptible de ser definida en términos cuantitativos [Zad75]. Más formalmente, puededefinirse una variable lingüística tal y como se describe en la definición 3.1.4.

Definición 3.1.4 (Variable Lingüística). Una variable lingüística está caracterizada por unaquíntupla [Zad75]

(N, T (N), U,G,M)

N es el nombre de la variable.

T(N), o simplemente T, es el conjunto de términos, es decir, el conjunto de valoreslingüísticos (etiquetas lingüísticas) de N.

U es el universo de discurso.


Valor

Gra

do d

e pe

rten

enci

a

0 10 20 30

0

0.25

0.5

0.75

1

Trapezoidal

(a) Trapezoidal

Valor

Gra

do d

e pe

rten

enci

a

0 10 20 30

0

0.25

0.5

0.75

1L

(b) Trapezoidal L

Valor

Gra

do d

e pe

rten

enci

a

0 10 20 30

0

0.25

0.5

0.75

1

R

(c) Trapezoidal Γ

Valor

Gra

do d

e P

erte

nenc

ia

0 10 20 30

0

0.25

0.5

0.75

1

Singleton

(d) Singleton

Valor

Gra

do d

e pe

rten

enci

a

-30 -20 -10 0 10 20 30

0

0.25

0.5

0.75

1

Sigmode

(e) Sigmoide

Valor

Gra

do d

e P

erte

nenc

ia

0 10 20 30

0

0.25

0.5

0.75

1

Triangular

(f) Triangular

Valor

Gra

do d

e pe

rtene

ncia

-30 -20 -10 0 10 20 30

0

0.25

0.5

0.75

1

Gauss

(g) Gauss

Valor

Gra

do d

e P

erte

nenc

ia

-1 0 1

0

0.25

0.5

0.75

1

Rectangular

(h) Rectangular

Figura 3.1: Funciones de pertenencia más usuales

G es una gramática libre de contexto que genera un conjunto de términos de valoreslingüísticos de T(N).

M es una regla semántica que asocia a cada elemento de N su significado M(X), dondeM(X) constituye un subconjunto difuso en U.

Así mismo, los símbolos terminales de la gramática G incluyen [GG14]:

Términos primarios: bajo, alto...

Modificadores: muy, más, bastante...

Conectivas lógicas: Normalmente son not, and y or.

Ejemplo 6. Empleando la definición formal empleada por Zadeh, una variable linguisticaquedaría definida tal que así:

V ariable =< (V elocidad, T (V elocidad) = alta+media+ baja, [0, 100],G,

M(alta) = [75, 100],M(media) = [40, 80],M(baja) = [0, 45]) > .

donde G generaría los términos lingüísticos de T(Velocidad), o lo que es lo mismo, alta,


media y baja.

3.1.9 Reglas DifusasLas reglas difusas son formas condicionales, compuestas por un antecedente y un conse-cuente, del tipo IF-THEN que encapsulan el conocimiento disponible. Por esta razón, re-ciben el nombre de base de conocimiento o base de reglas. En su forma más simple (regla

difusa atómica) adopta la forma expuesta en (3.39), aunque puede adoptar formas más com-plejas (regla difusa compuesta) (3.40) haciendo uso de las operaciones básicas definidas en3.1.2.

IF a is A THEN b is B. (3.39)

IF a is A AND a′ is A′ THEN b is B. (3.40)

En general, un conjunto de reglas difusas quedan definidas en (3.41).

Ri : IF a1 is Ai1 conec an is Ain︸︷︷︸Antecedente

THEN b is Bi︸︷︷︸Consecuente

, i = 1, 2, ..., K. (3.41)

donde conec será una operación básica: and, or, not.

Tanto el antecedente como el consecuente están formados por variables lingüísticas quellevan asociadas conjuntos difusos, aunque tal y como se verá en el apartado siguiente, de-pendiendo del mecanismo de inferencia a utilizar, el consecuente puede estar formado poruna función lineal.

Ejemplo 7. En la regla difusa (3.42), los términos temperatura y ventilador representan lavariable lingüística, mientras que Alta y Rápido representan el conjunto difuso.

IF temperatura is Alta THEN ventilador is Rapido. (3.42)

Un sistema difuso, dependiendo del número de entradas y salidas que compongan su basede conocimiento, puede quedar divido en tres tipos [RJ00]: una entrada - una salida (SI-SO), múltiples entradas - una salida (MISO) y múltiples entradas - múltiples salidas(MIMO) (Fig. 3.2).

3.1.9.1. Operadores de Implicación

Como se adelantó en el capítulo 1, el razonamiento aproximado se basa en una generalizacióndel silogismo clásico denominado modus ponens generalizado. Bajo este nuevo enfoque, adiferencia del método de inferencia clásico, se pueden inferir resultados a partir de premisas


Velocidad Alta Media Baja0 0 0 110 0 0 0.820 0 0.1 0.740 0 0.9 0.260 0.3 0.7 0100 1 0 0

Tabla 3.1: Ejemplo op. básicas

T-Norma Operación

Mínimo min(µA(x), µB(x))

Producto Algebraico µA(x) ∗ µB(x)

T-Norma de Lukasiewicz max(0, µA(x) + µB(x)− 1)

Tabla 3.2: Algunas T-Normas utilizadas

T-Conorma Operación

Máximo max(µA(x), µB(x))

Suma Algebraica (probabilística) µA(x) + µB(x)− µA(x) ∗ µB(x)

Suma limitada min(1, µA(x) + µB(x))

Tabla 3.3: Algunas T-Conormas utilizadas

Sistema difusox out

(a) SISO

Sistema difuso

x

outy

...

(b) MISO

Sistema difuso

x out1

y out2

......

(c) MIMO

Figura 3.2: Tipos de Sistemas Difusos (FLC)


parcialmente verdaderas.

La operación de implicación clásica queda definida mediante las operaciones básicas denegación, unión e intersección:

p→ q ⇔

{(p ∧ q) ∨ ¬p¬p ∨ q

(3.43)

Así, partiendo de las equivalencias anteriores, se pueden deducir expresiones para definir laimplicación difusa:

T (p→ q) = µA→B(x, y)⇔

{max{min{µA(x), µB(y)}, 1− µA(x)}max{1− µA(x), µB(y)}

(3.44)

En general, cualquier expresión equivalente a la implicación clásica es válida como opera-dor de implicación difuso. Este hecho, ha dado lugar a numerosos operadores (Tabla 3.4)[Ros09], aunque los que más éxito han tenido en la ingeniería han sido los dos últimos:Mamdani y Larsen.

Operador

Zadeh max{min{µA(x), µB(y)}, 1− µA(x)}Kleene-Dienes max{µB(y), 1− µA(x)}Lukasiewicz min{1, {1− µA(x) + µB(y)}}Mamdani min{µA(x), µB(y)}Larsen {µA(x) ∗ µB(y)}

Tabla 3.4: Operadores implicación difusos

3.1.10 Mecanismos de InferenciaEl presente proyecto se enmarca dentro el ámbito de los sistemas de control. En este con-texto, podemos destacar dos enfoques clásicos: Mamdani y Takagi-Sugeno-Kang (TSK)[OV07].

3.1.10.1. Método de Mamdani

Éste enfoque (Fig. 3.3) es el más común en la práctica y en la literatura. Surgió como unprimer intento (1974) de control de una máquina de vapor empleando un conjunto de reglaslingüísticas obtenidas de las experiencia de los operadores humanos. Realizar un sistema deinferencia siguiendo este método requiere de los siguientes pasos [OV07][Ian12]:

1. Determinar el conjunto de reglas que codifica el conocimiento disponible. Este co-nocimiento puede extraerse de un experto, constituyendo entonces un sistema experto,de una máquina, etc.


2. Fuzzyficación (o borrosificación): Haciendo uso de las funciones de pertenencia(véase § 3.1.7), determinar el grado de pertenencia de las entradas nítidas (crisp) acada uno de los conjuntos difusos.

3. Evaluar las reglas: Haciendo uso de las entradas fuzzyficadas, aplicarlas a los ante-cedentes de las reglas difusas. Si una regla difusa dada es compuesta (i.e antecedenteunido por conectores AND-OR), el operador difuso se emplea para obtener un únicovalor que representará el valor de verdad del antecedente (véase § 3.1.2).

4. Correlacionar el antecedente con su consecuente (Implicación): El valor de verdad

obtenido en el punto anterior es aplicado a la función de pertenencia del consecuente.Existen dos alternativas ampliamente utilizadas:

a) Truncar: «corta» la función de pertenencia del consecuente a la altura del valor

de verdad del antecedente (implicación de Mamdani).

b) Escalar: la función de pertenencia del consecuente se ajusta multiplicando el va-

lor de verdad del antecedente por todos sus grados de pertenencia (implicaciónde Larsen).

Figura 3.3: Inferencia Mamdani con defuzzificación centro de gravedad discreta (AndrewKusiak - UIOWA)

5. Agregación: Las funciones de pertenencia de todos los consecuentes de cada una delas reglas, previamente truncadas o escaladas, son combinadas en un único conjuntodifuso.

6. Defuzzyficación (o desborrosificación): Consiste en proceso inverso de la fuzzyfica-

ción. El controlador necesita un valor crisp, por lo que es necesario, partiendo delconjunto agregado del paso anterior, obtenerlo mediante alguno de los siguientes mé-todos [Ros09]:

a) Método del máximo: rápido pero solamente es preciso en funciones de salida




«puntiagudas»:

µC(z∗) ≥ µC(z), ∀z ∈ Z (3.45)

donde z∗ es el valor defuzzificado.

b) Método del centroide (centro de área o centro de gravedad):

z∗ =

∫µc(z) ∗ z dz∫µc(z) dz

(3.46)

c) Método del centroide discreto:

z∗ =

∑µc(z) ∗ z∑µc(z)

(3.47)

donde cada z es un elemento del dominio de discurso que define el conjuntodifuso.

d) Método del promedio ponderado: es el más utilizado en aplicaciones difusasademás de ser uno de los más eficientes. Sin embargo, suele estar restringido afunciones de pertenencia simétricas.

z∗ =

∑µc(z) ∗ z∑µc(z)

(3.48)

donde z es el centroide de cada función de pertenencia.

e) Método de media de los máximos: se toman los valores cuyas funciones de per-tenencia alcanzan el máximo y se realiza la media entre ellos.

z∗ =a+ b

2(3.49)

donde a y b son los valores máximos de pertenencia.

3.1.10.2. Método Takagi-Sugeno-Kang

En esencia, el procedimiento (Fig. 3.4) con este método es exactamente igual al anterior, conla única diferencia que, en este caso, no es necesaria la etapa de defuzzificación o desborro-

sificación, pues nos proporciona directamente como salida para el controlador un valor nofuzzy, esto es, nítido o crisp.

Una regla de inferencia siguiendo este esquema adopta la siguiente forma [Ros09]:

IF x is A AND y is B THEN z is z = f(x,y).

donde x,y y z son variables linguisticas, A y B conjuntos difusos, y f(x,y) una función poli-nómica que depende de las entradas. Existen dos casos particulares dentro de este esquema


en función del tipo de función empleada en el consecuente: a) cuando f(x,y) es constante, el

esquema recibe el nombre de modelo sugeno de orden-cero, siendo éste un caso especial

del esquema Mamdani en el que el consecuente de cada regla viene dado por un conjunto

singleton; b) cuando f(x,y) es una función lineal de x e y, recibe el nombre de modelo su-geno de primer-orden. De estos dos, el método más comúnmente usado es el modelo TSK

de orden cero.

Figura 3.4: Inferencia Sugeno de orden cero (Andrew Kusiak - UIOWA)

3.2 Mini-RobotsEn el capítulo 2 se comentaba la idea de aplicar el sistema desarrollado sobre un mini-robotque cumpliese los siguientes requisitos: autónomo, móvil y de bajo costo. En el mercadoes posible encontrar diferentes alternativas [Rob14]:

Lego mindstorms NXT: gobernado por un ladrillo inteligente NXT, compuesto porun procesador ARM7 de 32 bits con capacidad de comunicación inalámbrica por blue-

tooth, posee la capacidad de incorporarle múltiples sensores (sensores de presión, óp-

ticos, de ultrasonidos, etc) además de poder adoptar cualquier forma gracias a lasmúltiples piezas Lego disponibles.

Fischertechnik ROBO TX Explorer: gobernado por un controlador ROBO TX, com-puesto por un procesador ARM9 de 32 bits funcionando a una frecuencia de 200 Mhzcon 8 MB de memoria RAM, tiene la capacidad de incorporarle multitud de senso-



res (sensor de distancia ultrasónico, seguidor de líneas infrarrojo, fotorresistor, etc)además de moverse gracias al grupo de motores que incorpora.

Otros: Lego mindstorms EV3, Robotis OLLO explorer, etc.

En las siguientes secciones, únicamente nos centraremos en el dispositivo empleado.

3.2.1 mOwayLa motivación tras la cual se esconde la elección de este dispositivo en detrimento de los co-mentados anteriormente fue el hecho de ser muy manejable y estar completamente ensambla-do, amén de que las otras opciones, aún siendo más potentes y versátiles, son sensiblementemás costosas y requerían de ensamblaje.

3.2.1.1. Orígenes

mOway es un robot compacto de reducidas dimensiones, ganándose a raíz de ello el ape-lativo de «robot de bolsillo», programable, diseñado para moverse con agilidad y eleganciaen un entorno real, tiene su principal desempeño en las áreas de la docencia y la investiga-ción. Desde su aparición, allá por el 2007, ha sufrido una serie de mejoras en su hardware(microcontrolador más potente, LED de freno, micrófono,posibilidad de incorporarle distin-

tos «gadgets» a través de su bahía de expansión, como una cámara, etc) [S.L10]. En estasección, nos centraremos en la revisión del 2010.

3.2.1.2. Controlador

El mOway está gobernado por un microcontrolador PIC18F86J50, perteneciente a la familiade 8 bits de gama media, de la empresa Microchip Technology trabajando a una frecuencia de4Mhz. Implementa una arquitectura de tipo Harvard (Fig. 3.5), lo que significa que el espaciode memoria se encuentra separado en dos regiones denominadas memoria de programa ymemoria de datos estática RAM. De este modo, al usar buses 1 de datos e instrucciones

separados, permite el acceso concurrente a los dos espacios de memoria.

Respecto al ciclo de instrucción [Inc09], la entrada del reloj es internamente dividida porcuatro (Q1 a Q4) para generar cuatro relojes que no se solapan. De este modo, la familiaPIC18F8XJXX posee una CPU segmentada. Un ciclo de instrucción está compuesto por loscuatro ciclos de reloj comentados anteriormente. La captura de la instrucción (InstructionFetch - IF) necesita de un ciclo de instrucción, mientras que la decodificación (InstructionDecode - ID) y ejecución (Execute - EX) requieren de otro ciclo de instrucción.

Así, el ciclo de captura comienza incrementando el contador de programa en Q1. Acto se-guido, la instrucción se almacena en un registro de instrucción en el mismo ciclo Q1. Pos-teriormente se decodifica y ejecuta en los restantes ciclos Q2, Q3 y Q4. Así, la memoria de

1Un bus es un sistema de comunicación que transfiere datos entre componentes electrónicos del dispositivoempleado.


programa es leída durante el ciclo Q2 y escrita durante el ciclo Q4.

En los siguientes apartados se comentarán brevemente aspectos técnicos de la organizaciónde la memoria en el PIC (Fig. 3.6).

Memoria de Programa Memoria de Datos RAM

CPU

Figura 3.5: Arquitectura Harvard

Memoria de Programa

Consiste en una memoria flash de solo lectura de 64 KiloBytes donde se encuentran almace-nadas las instrucciones que ejecutará el microcontrolador.

En las posiciones más bajas (0x000 a 0xFFF) se encuentra el cargador de programa o bootloa-

der, cuyo propósito es facilitar la descarga del programa desarrollado vía puerto mini-usb.Esto provoca que los vectores de reset, empleado por el contador de programa 2 para en-contrar la primera instrucción a ejecutar tras un reinicio del dispositivo, e interrupciones,empleado por el contador de programa para encontrar la instrucción de salto condicional ala zona del programa que requiere atención [Pér07], típicamente localizados en esas primerasposiciones, 0x00 para reset, 0x08 y 0x18 para int. de alta y baja prioridad respectivamente,tengan que ser «remapeados» a la siguiente zona libre, ubicada en el rango 0x1000 a 0x1029[Inc09].

Ambas secciones de memoria se encuentran protegidas, lo que significa que al compilar elprograma desarrollado, el compilador no podrá almacenar ningún tipo de dato en ellas.

Memoria de Datos

Consiste en una memoria RAM de 4096 Bytes divididos en 16 bancos de 256 Bytes, de loscuales, sólo están disponibles para el usuario 3904 Bytes. A su vez, la memoria se contie-ne dos tipos de registros especiales: registros de propósito general o GPR y registros defunciones especiales o SFR.

2Contiene la dirección de la instrucción a ejecutar.


Los registros SFR son utilizados por la CPU para almacenar el estado del controlador y de lasfunciones de los periféricos, mientras que los registros GPR son empleados almacenar datosde usuario. Además, para permitir un acceso rápido los registros SPR y a la parte baja delbanco 0 de GPR sin utilizar un puntero que apunta al banco de memoria o BSR, implementaun banco de acceso directo denominado access bank, permitiendo que los registros másutilizados puedan ser accedidos en un único ciclo.

El banco de acceso directo está compuesto por los primeros 96 Bytes de memoria (0x00 a0x5F) del banco 0, también denominado access ram, y los últimos 160 Bytes (0x60 a 0xFF)del banco 15. La access ram está compuesta por registros de propósito general, mientras quelos últimos 160 Bytes albergan los SFR del dispositivo mapeado en memoria, pudiendo seraccedidas mediante una dirección de 8 bits [Inc09].

0x000

0x100

0xFFF

Access Ram (0x00 - 0x5F)gpr0 (0x60 - 0xFF)

Figura 3.6: Memoria PIC18F86J50

3.2.1.3. Sistema Motriz y Grupo de sensores e indicadores

El sistema motriz está compuesto por un grupo servo-motor comandado a través del proto-colo I2C, mediante el cual se mandan tramas de una duración de 350 µs, que otorga diversasfuncionalidades [S.L10]: control de velocidad de cada motor, control de tiempo de cada

comando, control de distancia recorrida, control de ángulo cuando existe rotación y cuen-

takilómetros general. A su vez, se encarga de controlar los motores liberando de esta tarea almicrocontrolador.

En lo que respecta al conjunto de sensores e indicadores, éstos se encuentran conectadosdirectamente a distintos pines del microcontrolador. Se enumerarán un subconjunto de ellosrecomendando al lector consultar el manual de usuario para obtener mayor detalle acerca deellos:

Luces led: equipa cuatro luces (frontal, superior bicolor y trasera) conectados a pinesdigitales del PIC.

Sensores de línea: equipa dos optoacopladores CNY70 de Vishay, conectados a los


puertos analógicos RA2 y RA5 del PIC, de reflexión de luz infrarroja para detectar latonalidad del suelo, situados en la parte inferior delantera del robot.

Sensores de Obstáculos: equipa cuatro receptores PT100F0MP de Sharp, conectadosa los puertos analógicos RA1,RA3,RF5 y RF6 del PIC, de reflexión de luz infrarroja(emitida por dos fuentes KPA3010-F3C de Kingbright) para detectar la presencia deobstáculos situados en la parte frontal del robot.

El funcionamiento de los dos últimos sensores es muy similar: la fuente de luz infrarrojagenera un pulso de luz de una duración variable que, en caso de la cantidad de luz reflejadao ante la presencia de un obstáculo respectivamente, rebota contra los receptores empleandouna etapa de filtrado y amplificación de la señal, tras la cual, el microcontrolador puedecuantificarla.

3.2.1.4. Sistema de alimentación y Módulo RF

El robot posee un sistema de alimentación compuesto por una batería recargable de polí-meros de litio con una duración media de 90 minutos, que variará en función del tiempoque se empleen los sensores o motores. Las cargas, de 2 horas aproximadamente, se reali-zan mediante un puerto mini-usb-B situado en la parte trasera del robot directamente desdecualquier equipo.

Por otro lado, en lo que respecta a la comunicación inhalámbrica con el robot, este modeloañade la posibilidad de acoplarle un módulo de radio-frecuencia BZI-RF2GH4, a su bahíade expansión, situada en la parte superior del chasis, pudiendo comunicarse con el micro-controlador a través del bus SPI incorporado. Sus principales características se resumen enbajo consumo, velocidad de transimisión entre 1 y 2 Mbps y frecuencia de trabajo de 2.4

Ghz.

3.2.1.5. Programación

El mOway puede ser programado en «tres» lenguajes de programación: ensamblador, C18

y uno propietario llamado mOwayGUI. En cualquier caso, tanto el primero como el segundoposeen sendas librerías para el manejo de los periféricos disponibles en el robot.

En palabras de los creadores del robot, el uso de uno u otro lenguaje queda determinado enlos criterios expuestos a continuación:

Ensamblador: «interesante cuando la longitud del programa es extensa o cuando el

tiempo de respuesta es crítico».

C18: «interesante cuando se realizan tareas sencillas o de complejidad media así

como para empezar a trabajar rápidamente con el mOway». Sin embargo, «no es

recomendable cuando el tiempo de respuesta es crítico».


mOwayGUI: «recomendable cuando no se tienen nociones de programación así como

para realizar tareas sencillas o de complejidad media».

En el siguiente apartado se estudiará con cierto detalle el lenguaje utilizado para el desarrollodel firmware de este proyecto.

C18

MPLAB C18, de aquí en adelante C18, es un compilador optimizado de ANSI C para lafamilia de microcontroladores PIC18, el cual, difiere del estandarizado en aquellos aspec-tos donde el estándar choca a la hora de ofrecer un soporte eficiente al microcontrolador[Inc05].

C18 soporta los mismos tipos de datos enteros y de coma flotante, en versiones con signoy sin él, que la versión estándar además de añadir un nuevo tipo denominado short long

int o long short int, aunque con los rangos de representación debidamente ajustados a laarquitectura. Respecto a los tipos de coma flotante, hace uso del estándar IEEE 754, con untamaño de 32 bits. Por otro lado, el formato de ordenación de bytes en valores multi-byte

(endianness), C18 almacena los datos en formato little-endian, o lo que es equivalente, losbytes menos significativos en las posiciones más bajas.

En lo que a tipos de almacenamiento y calificadores respecta, C18 incorpora los mismos queel ANSI además de añadir otros nuevos:

Overlay: sólo puede ser asignado a variables locales, las cuales, por defecto, sonauto. Trata de ahorrar memoria empleando la misma localización de memoria paraalmacenar variables con overlay siempre y cuando las funciones donde están definidasno se activen a la vez, i.e ambas en ejecución simultáneamente (Listado 3.1) .

1 int f (void) {2 overlay int x = 1;3 return x;4 }

6 int g (void) {7 overlay int y = 1;8 return y;9 }

Listado 3.1: Uso de Overlays

far: puede almacenarse en cualquier posición de memoria de programa y memoria dedatos.

near: en memoria de programa se ubicará en los primeros 64K, mientras que enmemoria de datos, sólo en la access ram (ver. § 3.2.1.2).


ram/rom: debido a las regiones separadas de memoria utilizadas en los PIC, C18requiere extensiones que permita identificar en qué región debe almacenarse un datoconcreto. El modificador ram, aplicado por defecto en la declaración de variables,denota que el dato debe ir en memoria de datos, mientras que el modificador romdenota que debe ir en memoria de programa.

3.3 Motor de InferenciaUno de los elementos clave a la hora de construir un sistema difuso es decidir la mane-ra por la cual se propagarán los resultados a través de las reglas para que puedan inferirseresultados. En la actualidad, existen dos estrategias para inferir (i.e deducir) resultados par-tiendo de reglas que codifican una base de conocimiento: encadenamiento hacia adelante yencadenamiento hacia atrás.

En el mecanismo de encadenamiento hacia adelante, también denominado dirigido por da-

tos, se parte de un conjunto de hechos para intentar deducir nuevos hechos mediante el dis-

paro de reglas de la base de reglas. Consta de los siguientes pasos [yRC14]: determinar el

conjunto de reglas aplicables, seleccionar una de esas reglas y disparar la regla. El meca-nismo finaliza cuando no hay más reglas a las que aplicar los hechos con los que deducir losresultados.

Por contra, en el mecanismo de encadenamiento hacia atrás, también denominado dirigi-

do por objetivos, partiendo de un objetivo inicial, se intenta probar dicho objetivo a partirde sus premisas; sin embargo, puede no existir tal satisfacibilidad del objetivo, por lo quepuede demorarse bastante en percatarse de ello [Rom14]. Un lenguaje que hace uso de estemecanismo es PROLOG, ya que infiere resultados empleando un algoritmo de prueba porrefutación denominado SLD.

El sistema desarrollado en el presente trabajo hace uso de un algoritmo basado en el primerenfoque denominado RETE, sobre el cual, se hará una breve introducción en la siguientesección.

3.3.1 Red RETEUna implementación ingenua de un algoritmo que permita inferir resultados podría consistiren comprobar los antecedentes de cada regla con cada uno de los hechos de la base deconocimiento, disparando la regla si es necesario. Para sistemas formados por unas pocasreglas puede servir; sin embargo, para sistemas reales que implican miles de reglas donde, asu vez, cada regla puede contener miles de hechos a comprobar es muy ineficiente.

Como solución para intentar mejorar esa ineficiencia surge RETE, el cual se enmarca dentrode los mecanismos de encadenamiento hacia delante. RETE consiste en una red de reco-nocimiento de patrones presentada por el profesor Dr. Charles Forgy en su tesis doctoral de1979 que permite reducir el tiempo necesario para decidir qué reglas deben ser activadas en


cada ciclo de inferencia (conjunto conflicto almacenando resultados obtenidos en iteracionesanteriores [jes14]. Su funcionamiento se basa en dos suposiciones [Mor14]:

1. La memoria es muy grande y no sufre variaciones ostensibles entre cada ciclo, de

modo que mucha información sigue siendo útil para ciclos futuros.

2. Las condiciones de muchas reglas son similares y estáticas, de manera que procesa

las reglas antes de ser utilizadas localizando sub-condiciones comunes entre reglas de

manera que no sean redundantes.

El algoritmo construye una red de nodos almacenando el estado del proceso de empareja-

miento de un ciclo a otro, de manera que solo es necesario re-computar cambios en el casode que los hechos se vean modificados. En cada nuevo ciclo de inferencia, la lista de hechos

puede cambiar (e.g en un instante dado, el hecho edad es igual a 60; en otro instante, seha visto modificado y ahora es igual a 45), dando lugar a reglas, cuyos patrones no podíansatisfacerse anteriormente, ahora sí.

Ejemplo 8. Si consideramos como hechos: temperatura = 45, humedad = 50, y como basede reglas: R1: si temperatura >30 y humedad = 50 % entonces ventilador = 100 %.

Bajo un enfoque ingenuo, en un bucle continuo se comprobarían los hechos con la regla. Enla primera iteración se dispara. En la segunda iteración, los hechos no han cambiado, pero sevuelven a comparar, sin provocar el disparo de la regla. Y así sucesivamente.

Bajo el enfoque Rete, se ejecuta un ciclo que provoca el disparo de la regla. Al siguienteciclo, como los hechos no han cambiado, no es necesario hacer cálculos nuevos, pues no seva a volver a disparar la misma regla.

3.3.1.1. Partes de la red

La red Rete es un grafo acíclico dirigido compuesto por nodos que representan patrones enlas condiciones de cada una de las reglas. Estos nodos actúan como filtros, comprobandolos tokens de entrada, es decir, la combinación de hechos que emparejan con una parte delas condiciones de una producción o regla [Doo95]; propagando por el resto de nodos sóloaquellos tokens que han pasado el filtro.

La conforman dos tipos de nodos: alfa y beta. Los nodos alfa, también llamados nodos

de una entrada, realizan pruebas sobre hechos individuales, mientras que los beta, tambiénllamados nodos de dos entradas, comprueban la relación existente entre las variables delantecedente de cada regla. Además, cada nodo lleva asociada una memoria denominada me-

moria alfa y memoria beta respectivamente, las cuales mantendrán los hechos que han sidoemparejados en los distintos ciclos. Por esta razón se dice que sacrifica memoria con tal

de incrementar la velocidad de procesamiento [Mat14]. Del mismo modo, si varias reglascontienen el mismo patrón (e.g temperatura = 30), entonces compartirán el mismo nodo alfa


dentro de la red, por lo que se evita la posible redundancia que pueda existir en la base dereglas.

Haciendo una analogía con las bases de datos relacionales, podemos ver como una operaciónSELECT al proceso de seleccionar un hecho de la lista de hechos disponibles para someterloal filtro de los nodos alfa, de modo que si lo pasa, es decir, si el hecho empareja con la condi-ción definida en el nodo alfa de una producción cualquiera, para posteriormente almacenarloen la memoria alfa correspondiente. Por otro lado, se puede ver como una operación JOIN

al proceso de comprobar la consistencia entre la unión de distintas variables que conformanel antecedente de una regla.

Más adelante, en el capítulo 5, cuando se explique con detenimiento el proceso de creación dela red en el sistema elaborado, se propondrá un ejemplo gráfico con el objetivo de esclarecertodos los conceptos introducidos en la presente sección.

3.3.1.2. Usos

En la actualidad existen ciertas herramientas enfocadas al desarrollo de sistemas expertos osistemas basados en reglas que implementan RETE como mecanismo de inferencia.

La más destacada es el lenguaje CLIPS, creado en 1985, empleado en ámbitos industrialesy academicos, pues es rápido, eficiente y gratuito. Otras herramientas son Drools, la cualpermite crear un sistema de gestión de reglas de negocio y JESS, éstos últimos escritos enJAVA.

CAPÍTULO

4

Método

A La hora de plantearse un desarrollo de esta envergadura, surge la necesidad de haceruna elección cuidadosa de una metodología que guíe el desarrollo del proyecto. En el

presente capítulo se explicará el método de trabajo escogido y se describirán y detallarán elconjunto de herramientas, tanto hardware como software, empleadas en la construcción delmismo.

4.1 Metodología de DesarrolloEl carácter investigador del trabajo propuesto no permitía identificar todos los requisitosdesde el comienzo del mismo pues podían sufrir variaciones a lo largo del proceso. Por estarazón, se hacía necesaria una metodología basada en la adaptabilidad más que en la previsi-bilidad que permitiese incorporar nuevos requisitos o modificaciones en los ya establecidos.El desarrollo ágil se erigía entonces como el mejor candidato de todos los enfoques existen-tes.

De este modo, la metodología empleada está basada en una metodología de desarrollo ágildenominada eXtreme Programming (XP), siguiendo un modelo iterativo en espiral. Estosignifica que el desarrollo se compone de una serie de ciclos o iteraciones de preferiblementecorta duración, en las cuales se sigue un modelo en espiral compuesto de las siguientesdisciplinas:

Análisis de Requisitos: En esta fase, se acuerdan los requisitos que debe satisfacer elproducto entre el cliente, i.e director del presente trabajo, y desarrollador, i.e autor delmismo; se modifican, si es necesario, requisitos de artefactos funcionales obtenidosen iteraciones anteriores con el objetivo de refinar el sistema final, y se planificará lasiguiente fase de desarrollo. De esta manera, si el resultado obtenido en una iteraciónanterior es satisfactorio, se incrementa la funcionalidad del sistema conforme a losnuevos requisitos acordados; en otro caso, se revisa el artefacto creado y se llevan acabo las modificaciones pertinentes en base a las sugerencias del cliente.

37

38 CAPÍTULO 4. MÉTODO

Diseño: Una vez acordados los requisitos en la fase anterior, se realiza un diseñopreliminar y sencillo, a partir del cual, se procederá a su implementación. Dada lanaturaleza adaptable de la metodología a emplear, no resulta adecuado invertir grancantidad de tiempo en realizar un diseño pormenorizado y exhaustivo, porque los re-quisitos pueden variar a lo largo del desarrollo, lo que puede conllevar a rehacer parteso incluso la totalidad del mismo. De este modo, a medida que se añaden o modificanrequisitos, se modifica el diseño preliminar adicionando las nuevas características, porlo que, el diseño completo y definitivo será obtenido al final del proceso de desarrollodel proyecto.

Implementación: En esta fase, acorde al diseño realizado en la fase anterior, se llevaa cabo la implementación del artefacto.

Pruebas: Una vez obtenido un primer artefacto, se procederá a probarlo. En cadaiteración, se llevan a cabo pruebas unitarias de caja negra para comprobar que fun-ciona de acuerdo a los requisitos establecidos. Así mismo, dichas pruebas constituyentambién pruebas de regresión, dado que la funcionalidad del sistema está en constan-te crecimiento, hay que cerciorarse que lo que ya está hecho continúa funcionandocorrectamente. Por último, una vez se tiene el sistema completo, será sometido a prue-

bas unitarias de caja blanca, para comprobar qué zonas del sistema se ejecutan concada caso de prueba y evitar redundancia en éstos últimos (probar supuestos ya proba-dos). Éstas últimas cesarán cuando se alcance un umbral mínimo, consensuado con elcliente, del 75 % de sentencias recorridas, lo que implicará que se habrá alcanzado elmínimo de calidad exigido.

La elección de un modelo en espiral en contraposición del tradicional enfoque incremental

asociado a las metodologías iterativas, radica en la posibilidad de «volver atrás» en la secuen-cia de fases realizadas, permitiéndonos revisar todo lo llevado hasta la fecha. El propósitode uso de dicho modelo consiste en evitar pasar por alto pequeños fallos no perceptibles enfases tempranas que originen un fallo más grande en una fase de desarrollo avanzada delmismo.

Por otra parte, como aproximación a eXtreme Programming, se ha tomado en cuenta lassiguientes características: integración máxima del cliente en el proyecto mediante la planifi-

cación de reuniones cada dos semanas aproximadamente, donde se mostraban los progresos

obtenidos y se planificaban los sucesivos hitos y verificación de la funcionalidad implemen-

tada mediante pruebas a la conclusión de cada iteración. Del mismo modo, comparte lossiguientes valores que identifican a esta metodología [XP214]: comunicación continua con elcliente, retroalimentación con el software por medio de pruebas y simplicidad limitándonosa hacer lo que toca en cada momento.

A modo de resumen, los motivos que han llevado a escoger esta metodología se puedenresumir en los siguientes puntos:

CAPÍTULO 4. MÉTODO 39

Análisis de Requisitos Diseño

ImplementaciónPruebas

Artefacto

Iteración 1

Análisis de Requisitos Diseño

ImplementaciónPruebas

Sistema Final

Iteración N

Figura 4.1: Ciclo de Desarrollo iterativo en espiral

Al estar basado en una metodología ágil, se otorga mayor prioridad a la obtención deresultados.

El continuo cambio de requisitos requería de una planificación poco rígida y que noresultase complicado integrarlos en el proceso de desarrollo.

El empleo de iteraciones cortas, implica una mayor frecuencia de entregables que pue-den ser revisados conjuntamente con el cliente, minimizando riesgos.

El cliente está involucrado desde el principio, permitiendo atender mejor las propuestasrealizadas o cambios durante todo el proceso de desarrollo.

4.2 Aplicación de la MetodologíaEn esta sección se muestra la división del proceso de desarrollo seguido en iteraciones, mos-trando los hitos alcanzados en cada una de ellas así como otros detalles que resulten relevan-tes de mencionar. Por otra parte, en el siguiente capítulo se explicará con detalle el procesode construcción involucrado en cada una de las iteraciones.

En primer lugar, se mantuvieron una serie de reuniones con el director del proyecto donde sesentaron las bases sobre las que empezar el desarrollo. Se decidió que las sucesivas etapas seirían planificando en función de los objetivos que mayores riesgos entrañaran. Por esta razón,


se comenzó por el motor de inferencias, ya que constituye el núcleo del sistema propuesto.Seguidamente se implementó el algoritmo que propagaría los resultados a través del motorde inferencia (RETE) y por último se desarrolló tanto la interfaz de comunicación como elfirmware del mini-robot escogido como caso de estudio. Además se establecieron una seriede requisitos preliminares que debía cumplir la arquitectura de FUMO:

1. El algoritmo que propague los resultados por la red debe emplear estructuras de datossimples que puedan ser portadas a bajo nivel.

2. La red RETE de alto nivel no debe ser excesivamente compleja pues se debe portar anivel byte de manera sencilla y eficiente.

3. La red RETE de bajo nivel (i.e embebida en el robot) debe ocupar una única regióncontigua de memoria.

4. La red generada debe poder ser representada gráficamente y ser almacenada en unarchivo si el usuario así lo estima oportuno.

4.2.1 IteracionesEl desarrollo ha sido estructurado en un total de 9 iteraciones, las cuales se describirán enlos siguientes apartados.

Iteración 1 (20-Febrero a 4-Marzo)

Con esta iteración arrancó el desarrollo de FUZZY MOWAY, durante la cual se creó la es-tructura básica de directorios que albergaría el proyecto. Desde el primer momento se tuvoclaro que en el desarrollo estaban involucrados dos lenguajes distintos (C18 y Java). Con elpropósito de agilizar y facilitar la codificación y el proceso de compilación de los programas,se decidió emplear diversos entornos de desarrollo (ver § 4.4.3), los cuales ya generan unaestructura básica, por lo que se decidió mantenerla y cualquier cambio de archivos o directo-rios se haría sobre ella. Además, se creó un fichero Makefile que automatizase la construccióndel parser, pues constituye una tarea tediosa debido a la cantidad de ficheros intermedios acompilar.

Una vez establecido lo básico, se concretó el método de inferencias a seguir. Éste debía sereficiente y ser capaz de procesar muchas reglas difusas con múltiples entradas y/o salidas(ver § 3.1.9). Además había que tener en cuenta que el algoritmo a utilizar debía ser lo su-ficientemente sencillo de portar a la arquitectura del robot. Por todo ello, y tras hacer unabúsqueda minuciosa sobre qué sistemas pudieran resultar más adecuados para este propósi-to, se decidió que se emplearía una red de nodos forward chaining denominada RETE. Trasésto, se procedió a hacer un estudio exhaustivo de la misma con el fin de comprender sufuncionamiento.

Como resultado de esta primera iteración no se obtuvo ningún artefacto funcional de la apli-


cación, si bien sirvió como base a seguir en las sucesivas iteraciones.

En definitiva, en esta primera iteración, se creó el esqueleto mínimo necesario para albergarel proyecto y se decidió el mecanismo con el que poder inferir los resultados.

Iteración 2 (8-Marzo a 11-Marzo)

Tras decidir cómo abordar la realización del motor de inferencias en la iteración anterior, enésta se comenzó el desarrollo del mismo. Más concretamente, se empezó por el diseño dellenguaje que debía permitir al usuario especificar la base de conocimiento de una manerarápida, sencilla e intuitiva, además de poder generar el motor de inferencias. En un primermomento, se pensó en crear un lenguaje de diseño propio adaptado a las necesidades delproblema; sin embargo, el uso de estándares constituye uno de los objetivos principales acumplir por el sistema, por lo que se desechó esta idea temporalmente en aras de encontraralgún estándar que ya propusiese un lenguaje para este propósito. Tras una laboriosa bús-queda, se encontró un proyecto publicado por la IEC en 1997 denominado IEC1131-7 (ver.anexo B) que propone una especificación completa para la creación de lenguajes de controlde sistemas difusos (FCL).

En este punto ya se tenía claro como se iban a obtener los resultados (vía RETE) partiendodel conocimiento definido, y como se iba a proporcionar dicho conocimiento de modo quepudiese ser entendido por el sistema (vía FCL).

Para poder llevar a cabo la implementación del lenguaje FCL se estudió el uso de bibliotecasde generación automática de analizadores léxicos y sintácticos. Teniendo en cuenta que ellenguaje utilizado para la implementación iba a ser Java, se optó por JFlex para realizar ellexer y por CUP para realizar el parser, por lo que resultó necesario hacer acopio de losconocimientos adquiridos en la asignatura de Procesadores de Lenguajes.

De esta manera, se empezó con el diseño del analizador léxico. Ésta primera aproxima-ción sería muy básica y se centró el esfuerzo en que el reconocimiento de tokens 1 fuesecorrecto.

Así pues, como resultado de esta iteración se obtuvo un fichero .jflex capaz de reconocer lossímbolos pertenecientes al lenguaje, además de una especificación para generar lenguajesempleados en controladores difusos.

Iteración 3 (12-Marzo a 25-Marzo)

Partiendo del analizador léxico y del estándar obtenidos en la iteración anterior, se realizó unaprimera versión del analizador sintáctico y de la tabla de palabras reservadas involucradasen el lenguaje.

Esta primera aproximación del analizador sintáctico tenía que ser capaz de reconocer un

1Son elementos que aparecen en el lenguaje fuente que poseen un significado propio


lenguaje FCL y arrojar por pantalla los posibles errores léxico-sintácticos que pudiesen ha-ber.

El estándar empleado propone una especificación completa para el desarrollo de un sistemade inferencia difuso de tipo mamdani. El enfoque seguido en este proyecto se correspondíacon un sistema de inferencia TSK de orden cero (ver. § 3.1.10.2 para más información) enel que se infieren los resultados mediante una red de propagación de valores, por lo queciertas características del estándar no serían necesarias en el software propuesto, como sonlos métodos de defuzzificación o los métodos de acumulación. Por esta razón, se generó undocumento que contiene la gramática utilizada en el lenguaje de FUMO en formato EBNF

disponible en el anexo C.

En resumen, ambos lenguajes son en esencia el mismo, con diferencias realmente sutiles(Tabla 4.1).

Proyecto de estandarización IEC1131 Versión compliance

VAR_INPUT SENSORVAR_OUTPUT ACTUATOREND_VAR END_SENSOR / END_ACTUATORtemperatura: INT; temperatura(sensor o actuador): INT;METHOD: (método de defuzz); No requeridoDEFAULT:= (valor entero); Opcional, aunque no se tiene en cuentaRANGE:= (0 .. 10); Opcional, aunque no se tiene en cuentaACT:= (método de activación); No requeridoACCU:= (método de acumulación); No requerido

Tabla 4.1: Diferencias entre lenguajes

Por otra parte, todo lenguaje posee ciertas palabras propias de su definición que deben estarlimitadas a dicho ámbito. Para el tratamiento de dichas palabras se escogió diseñar una tablade palabras reservadas, de manera que cuando el analizador léxico reconociese un token dellenguaje, se comprobase si éste se correspondía o no con una palabra reservada y aplicarle eltratamiento oportuno. Dado que dicha tabla sólo sirve para comprobar si un token pertenece ono a ella, se decidió emplear como estructura de datos para su implementación una hash map,pues proporcionan tiempos aproximadamente constantes en las operaciones de búsqueda einserción.

A modo de resumen, en esta iteración se diseñó la gramática definitiva en base al proyectode estándar, se implementó e integró junto al analizador léxico el analizador sintáctico yse implementó una tabla de palabras reservadas para determinar el conjunto de tokens quepertenece al lenguaje para poder tratarlos como tal.


Iteración 4 (26-Marzo a 3-Abril)

Al comienzo de esta iteración ya se tenía un pequeño programa funcional que permitía com-pilar un lenguaje FCL. En este punto, se comenzó a diseñar las estructuras semánticas queserían necesarias para poder obtener el motor de inferencia, o lo que es lo mismo, la red denodos RETE. Con el propósito de mantener el código organizado y bien estructurado, se optópor desarrollar la arquitectura del sistema en forma de módulos, que irían incrementándoseen sucesivas iteraciones:

Módulo del Lenguaje: Está compuesto por los ficheros analex.jflex, que contiene elanalizador léxico; parser.cup, que contiene el analizador sintáctico; la clase Confi-

guración.java, que proporciona una serie de métodos para capturar todos los erroresobtenidos en la fase de compilación y la clase TablaPReservadas.java, que contiene latabla hash con todas las palabras reservadas del lenguaje.

Módulo Moway: En este punto solamente contiene las clases actuadores.java y sen-

sores.java, que no son más que tipos enumerados con el conjunto de sensores y actua-dores que incorpora el robot empleado como caso de estudio. Se valoró la posibilidadde suministrar esta información al parser por medio de ficheros de texto, de maneraque no se requiriese una nueva compilación en caso de cambios; sin embargo, estainformación resulta crítica para obtener un funcionamiento correcto de la red, por loque se decidió que la responsabilidad fuese en exclusiva del programador.

Módulo fuzzyInference: Contiene las clases necesarias para generar conjuntos difu-sos: desde funciones de pertenencia hasta las normas con las que operar los valores encada uno de ellos.

Módulo retenetwork: Contiene clases que permiten generar los nodos involucradosen la red RETE, así como sus memorias alfa y beta. Se optó por una estructura auto-contenida, en el sentido de que cada nodo alfa o beta manejase únicamente sus datos ysólo tuviese acceso en forma de referencias a sus antecesores y/o sucesores inmediatos.

Por tanto, durante esta iteración se centró el esfuerzo en crear toda la jerarquía de clasesnecesaria para poder realizar el analizador semántico. Si bien en esta iteración no se gene-ró ningún artefacto funcional nuevo, la labor desempeñada resultó crítica para agilizar eldesarrollo del resto de fases.

Iteración 5 (5-Abril a 4-Junio)

Sin duda fue la iteración más larga de todo el proceso de desarrollo. Se centraron todoslos esfuerzos en la creación del analizador semántico, partiendo del artefacto logrado en laiteración no 3, el cual debía proporcionarnos un fichero binario .rete que codificaría la redRETE.

Para su consecución, se implementaron las clases Simbolo.java y TablaSimbolos.java, incor-


poradas al módulo de lenguaje, empleadas para almacenar información intermedia requeridaen el proceso de análisis semántico a medida que se avanzaba en la etapa de análisis. Éstaúltima, al igual que la de palabras reservadas, se implementó en forma de tabla hash, ya quepermite realizar búsquedas e inserciones rápidas en promedio.

Se realizaron multitud de comprobaciones semánticas para intentar validar el máximo nú-mero de situaciones de entrada posibles: desde comprobar la re-declaración de variables

a comprobar el uso de actuadores o sensores fuera de su ámbito. Por otro lado, dado queuno de los objetivos marcados consistía en obtener retroalimentación del proceso de aná-lisis, se hizo un esfuerzo considerable por capturar todos los errores (léxicos, sintácticos ysemánticos) que pudiesen acontecer, mostrando por pantalla sus localizaciones y una brevedescripción acerca de cómo poder solventarlos.

Además se estableció un mecanismo de recuperación del error en zonas concretas del len-guaje (bloque de fuzzificación y desfuzzificación), lo que permite proseguir con el análisisen caso de error sintáctico.

Por tanto, a modo de resumen, tras la finalización de esta iteración se consiguió un artefactocapaz de procesar completamente una base de conocimiento y generar a partir de ella elmotor de inferencia, y se diseñó un nuevo módulo capaz de generar un fichero gráfico querepresenta la red obtenida de la fase de compilación.

Iteración 6 (7-Junio a 12-Junio)

En esta iteración se continuó aumentando la funcionalidad del artefacto obtenido en la itera-ción anterior, y conforme al criterio establecido al principio del presente capítulo, se continuócon el algoritmo que debía propagar los resultados por la red.

Se diseñó un montículo binario con memoria estática acotada mediante el cual, se deci-diría qué nodos son susceptibles de actualizar. La red fue diseñada de modo que los nodossiguiesen un orden parcial en base a un identificador único, de manera que:

ID(Nodonivel(P)) < ID′(Nodonivel(P′)) si nivel(P) < nivel(P′) ∧

ID(Nodonivel(P)) > ID′(Nodonivel(P′)) si nivel(P) > nivel(P′)

Así, el orden de los nodos quedaría establecido del siguiente modo:

Nivel 0: Serían los nodos alfa.

Nivel 1: Nodos beta con padres de nivel 0 o constante.

Nivel 2: Nodos beta con al menos un padre de nivel 1 y el otro con nivel menor o igualque 1.

Nivel n: Nodos beta con al menos un padre de nivel (n-1) y el otro con nivel menor oigual que (n-1).


De este modo, el montículo binario irá atendiendo los nodos en base al menor identificadorde nodo, de modo que el recorrido del grafo se asemeja a un recorrido en anchura o por

niveles.

Para proseguir con la arquitectura modular, se creó uno nuevo denominado BinaryHeap quealbergaría las clases relacionadas: BinaryHeap.java, que consiste en una interfaz que definelos métodos básicos de uso; PrioQueue.java, que implementa los métodos de la interfaz, yBinaryHeapException.java para el tratamiento de excepciones.

Tras esto, se diseñó el algoritmo de propagación, que será abordado debidamente en el si-guiente capítulo, y se añadió otro módulo a la arquitectura denominado Utiles, que contieneuna clase del mismo nombre con métodos estáticos que facilitan ciertas tareas como truncar

un decimal, obtener una salida con formato, etc.

Por último, en esta iteración se abordó la generación de la red, obtenida del proceso decompilación, en formato gráfico, pudiendo apreciar los nodos involucrados así como lasreferencias entre ellos. Para ello, se creó un nuevo módulo denominado Gráficos, que in-corpora las clases necesarias para poder representarla gráficamente, gracias a la herramientaGraphviz2,permitiendo los formatos .jpg, .bmp, .png, .svg.


Al término de la iteración anterior, se obtuvo un artefacto capaz de inferir resultados partien-do de una base de conocimiento definida en un lenguaje descriptivo (FCL). Existen herra-mientas que justamente hacen esto (ver capítulo 2), por lo que a partir de aquí se abordó laincorporación al robot empleado como caso de estudio: mOway.

El trabajo sobre el robot se planificó en dos etapas: interfaz de comunicación RF y firmware.En esta iteración se abordó la primera de ellas.

Para su creación, se partió de un trabajo previo realizado en un Trabajo Fin de Carrera de-nominado Desarrollo arquitectura de control de robots móviles basada en radiofrecuencia

y su aplicación al robot Moway. Básicamente lo que proponía era una biblioteca que imple-mentase un sistema de comunicación inalámbrica vía radiofrecuencia entre un mOway y uncomputador. Estaba escrita en C++ y fue diseñada para ser funcional en sistemas MicrosoftWindows.

Por tanto, el trabajo realizado en esta iteración consistió en traducir dicha biblioteca a Javapara que fuese funcional en sistemas GNU/Linux. En un primer momento, se decidió emplearla misma librería (libusb-0.1), en versión GNU/Linux y adaptada a Java, que fue utilizada enel proyecto anterior; sin embargo, los resultados no eran los esperados, por lo que se decidióutilizar otra librería de más alto nivel que encapsula la interfaz de llamadas de la libreríalibusb-1.0 escrita en C de manera que sean accesibles en Java.

2http://www.graphviz.org/


De esta manera, se generaron las clases ModuloRF.java, haciendo uso del patrón de diseñofachada, encapsula la lógica necesaria para interaccionar de manera sencilla con el receptorinalámbrico que se comunicará con el robot; Comandos.java, consiste en una interfaz queincorpora las direcciones hexadecimales de los comandos soportados en la comunicación yMoway.java, encargada de proveer el API de llamadas para interactuar con el robot. Todasellas fueron añadidas al módulo Moway, comentado en la iteración 4.


El desarrollo del proyecto ya estaba tocando a su fin. Hasta ahora se disponía de un motorde inferencia completamente funcional y un sistema de comunicación por radiofrecuenciaadaptado al robot utilizado.

En esta iteración se abordaría la implementación del firmware integrado en el robot, el cualdebía proporcionar acceso a todos los sensores y actuadores integrados así como ser capazde resolver las peticiones hechas desde el computador por radiofrecuencia.

Al igual que en el caso anterior, se partía de un pequeño programa que permitía hacer loque se pretendía. El trabajo realizado se ceñiría únicamente a depurar el funcionamiento delmismo además de incorporar y remover cierta funcionalidad que no sería útil en el sistemaque se propone.

Iteración 9 (1-Julio a 27-Julio)

Una vez se tuvo el programa que permitía una comunicación mínima entre robot y compu-tador, llegó el momento de incorporar el motor de inferencia difuso generado en las iteracio-nes anteriores.

En primer lugar, y teniendo en cuenta que el software carecería de interfaz gráfica, era ne-cesario crear un procedimiento que permitiese aceptar peticiones de teclado por parte delusuario de modo no bloqueante. Para ello, se creó la clase InterfazThreads.java en el mó-dulo Moway, la cual implementa el patrón de diseño command. En el siguiente capítulo seabordará con más detalle su implementación.

En segundo lugar, gracias al cuidado que se tuvo en el desarrollo de todos los elementosinvolucrados en el motor de inferencia de alto nivel, su «traducción» a bajo nivel resultaríasumamente sencilla.

De este modo, se comenzó con la implementación del montículo binario. Su transcripción fuecasi inmediata, con la única diferencia en aspectos sintácticos que difieren en los lenguajesempleados. Posteriormente se implementaron todas las estructuras de bajo nivel necesarias,es decir, arrays de memoria estática que debían almacenar la red RETE así como los valoresarrojados por los sensores y actuadores en un momento dado, además de todo lo necesariopara la creación de conjuntos difusos.


Para lograrlo se hizo necesaria la modificación del mapa de memoria del PIC18F86J50,agrupando varios bloques de memoria de 256Bytes hasta alcanzar un total de 2048Bytes paraalmacenar la red. Para los otros arrays no fue necesaria agrupación alguna pues su tamañosería muy inferior respecto al tamaño máximo de cada banco de memoria. De este modo, lared de bajo nivel sería construida en el lado del computador partiendo de la de alto nivel, yposteriormente mandarla por radiofrecuencia al robot, quedando almacenada en el área dememoria especificada anteriormente.

Además se implementó el algoritmo de propagación de resultados partiendo de su equiva-lente en alto nivel. Su funcionamiento sería exactamente el mismo, con la salvedad de suimplementación, que estaría orientada a byte en vez de a objetos.

En esta iteración ya se consideraba que el desarrollo del software había finalizado, y a partirde aquí se continuó generando la documentación relativa al presente Trabajo Fin de Gradoasí como al manual de usuario.

4.2.2 Calendario

La duración total de desarrollo del presente Trabajo Fin de Grado se resume en la tabla 4.2.Conviene advertir que la excesiva duración de ciertas iteraciones al principio del proceso,viene motivada por la imposibilidad del autor de dedicarse a tiempo completo en el desarrollodel proyecto a causa de otros compromisos académicos ineludibles. Una vez finalizadoséstos, se le ha dedicado una media de 30-35 horas semanales, viéndose incrementadas en lasúltimas fechas para poder cumplir con los plazos acordados.

No de Iteración Fecha de Inicio Fecha de Fin

1 20-Febrero-2014 04-Marzo-20142 08-Marzo-2014 11-Marzo-20143 12-Marzo-2014 25-Marzo-20144 26-Marzo-2014 03-Abril-20145 05-Abril-2014 04-Junio-20146 07-Junio-2014 12-Junio-20147 14-Junio-2014 17-Junio-20148 21-Junio-2014 30-Junio-20149 01-Julio-2014 27-Julio-2014

Tabla 4.2: Duración de Iteraciones

4.3 Otras consideraciones

En esta sección se mostrará a título meramente informativo cierta información estadística delproyecto, así como una estimación del coste que ha supuesto su desarrollo.


4.3.1 Líneas de códigoPara obtener las líneas de código totales escritas, se ha hecho uso de la herramienta cloc3. Enla tabla 4.3 se puede apreciar los resultados obtenidos.

Lenguaje Archivos Líneas en blanco Comentarios TotalJava 49 1910 4985 7633

Make 1 7 0 18C 1 449 691 1137

Total 51 2366 5676 8788

Tabla 4.3: Estadísticas del proyecto

4.3.2 CosteEl desarrollo del presente Trabajo Fin de Grado comenzó el día 20 de Febrero de 2014 y seprolongó hasta el día 27 de Julio de 2014, a los cuales hay que sumar una serie de reunionesprevias con el director del proyecto donde se establecieron un conjunto de requisitos premi-liminares además de diferentes alternativas sobre como se podría enfocar el desarrollo delmismo.

Desde el día 20 de Febrero hasta el 28 de Mayo se tuvo que compaginar la actividad acadé-mica normal con el desarrollo del proyecto, por lo que la dedicación durante esos no pudoser total. Una vez finalizado dicho periodo, se han mantenido una media constante de 30-35horas semanales. Así pues, suponiendo en época lectiva una dedicación semanal de 15 horas,hacen un total de 555 horas de trabajo aproximadamente. Suponiendo que un analista/diseña-dor/programador/gestor de la documentación de Java tiene un salario estándar de 25 e/hora,hace un total de 13875e a los que hay que sumarle el valor del ordenador personal y elrobot empleado como caso de estudio (Tabla 4.4).

Recurso Cantidad Precio unitario TotalSalario desarrollador 1 25e/hora 13875eOrdenador personal 1 600e 600emOway kit deluxe 1 299e 299e

Total 14774e

Tabla 4.4: Coste del proyecto

4.4 HerramientasEn la presente sección se enumerarán los recursos hardware y software que han sido emplea-dos en el desarrollo del presente trabajo.

3http://sourceforge.net/projects/cloc/


4.4.1 LenguajesEs importante destacar dos planteamientos a la hora de programar el sistema: enfoque de

bajo nivel y enfoque de alto nivel. Teniendo esto claro, se pasan a enumerar los lenguajes deprogramación utilizados:

Java: Es el lenguaje empleado en la gran mayoría del proyecto. Con él se ha im-plementado toda la parte de alto nivel del mismo. Se ha optado por Java por ser unlenguaje orientado a objetos, permitiendo una mayor abstracción y modularización enla implementación, y multi-plataforma, abriendo la posibilidad de trasladar el softwaredesarrollado a otro sistema operativo con el único requisito de tener instalada la jvm4.Además, provee un mecanismo de recolección de basura, inhibiendo al programadorde estar pendiente de liberar memoria tras usarla, lo que permite agilizar el desarrollode código.

C18: Este lenguaje ha sido empleado para la realización del firmware del robot. Basadoen la versión ansi C, genera código optimizado para la familia de microcontroladoresPIC18. Con él, se ha implementado un sistema que permite controlar el robot por me-dio de radiofrecuencia así como el motor de inferencia difusa a bajo nivel con el quepoder llevar a cabo la toma de decisiones otorgándole mayor autonomía e independen-cia.

4.4.2 HardwareLa totalidad del proyecto se ha llevado a cabo en un computador personal portátil ASUSX50GL, provisto de un procesador Intel Core2Duo P7350 a 2Ghz con una memoria ram de4GB. A su vez, integra una tarjeta gráfica NVIDIA 8200M.

Como entorno de pruebas real, se ha empleado un mini-robot mOway modelo del 2010,compuesto por un microcontrolador PIC18F86J50 a 4Mhz con 64KB de memoria flash romy 4KB de memoria ram. Para la comunicación entre PC-robot se ha utilizado un módulo deradiofrecuencia BZI-RF2GH4, provisto por el fabricante del robot, en combinación con unreceptor usb que permite una comunicación bidireccional entre ambas plataformas.

Por último, como sistema de control de versiones se ha utilizado un servidor remoto propie-dad de Atlassian Software5, con el que poder gestionar el código y documentación generadaa lo largo del desarrollo.

4.4.3 SoftwareEn esta sección se listarán todas las herramientas y bibliotecas requeridas en el desarrollodel presente Trabajo Fin de Grado.

4Máquina virtual de Java5https://bitbucket.org/


Sistema Operativo

Ubuntu: Sobre él se ha desarrollado la totalidad del proyecto. Se ha empleado laversión 12.04 LTS por ser una distribución muy fácil de usar y con garantía de recibirsoporte hasta el año 2017.

Software de Desarrollo

NetBeans IDE: Entorno de desarrollo integrado, versión 7.3, con el que se ha desa-rrollado todo lo relacionado con la parte de alto nivel escrita en Java: generación de

la red, sistema de comunicación con el robot, motor de inferencia, etc. Se ha optadopor él porque brinda un entorno agradable e intuitivo además de brindar una enormeintegración con las aplicaciones escritas en Java.

MPLAB IDE X: Basado en el anterior, es el entorno propio de Microchip para laprogramación de sus microcontroladores. Se ha utilizado para desarrollar el códigoembebido en el robot, ya que permite agilizar la escritura de código, mediante auto-completado y el uso de atajos de teclado, así como la compilación del mismo. Se hautilizado la versión 1.90.

Make: Esta herramienta incorporada en toda distribución GNU/Linux agiliza tareasque son repetitivas para el usuario. En concreto, se ha utilizado para la compilación dearchivos involucrados en la creación del analizador léxico-sintáctico: .jflex, .cup y losintermedios .java generados al compilar los anteriores.

Sublime Text 2: Editor de texto multiplataforma y gratuito, ha sido empleado paracodificar todo lo relacionado con el lenguaje FCL encargado de generar el motor deinferencia. Se optó por él por el uso de características avanzadas como resaltado de

sintaxis o autocompletado además de su facilidad de uso. Se ha utilizado la versión2.0.2.

Bibliotecas

libusb-1.0: Biblioteca escrita en C que permite acceder a dispositivos USB de manerasencilla, gracias a una API completa de alto nivel.

usb4Java: Se ha empleado para la creación del sistema de comunicación entre el roboty el PC a través del transmisor inalámbrico USB que acompañaba al robot (RFUsb).Esta biblioteca, basada en la anterior, proporciona la misma funcionalidad permitiendoel acceso a dispositivos USB desde aplicaciones escritas en Java. Es necesario tenerinstalada la versión nativa escrita en C para hacer funcionar ésta. Se ha empleado laversión 1.2.0.

JFlex: Se ha empleado para construir el analizador léxico involucrado en la especifi-cación de la base de reglas. El principal motivo de su elección es porque genera código


Java, por lo que permite una integración total con el sistema a desarrollar. Se ha utili-zado la versión 1.4.3.

CUP: Se ha empleado para construir el analizador sintáctico involucrado en la espe-cificación de la base de reglas. El motivo de su elección es porque está desarrolladopara proporcionar una perfecta integración con JFlex para construir un parser comple-to además de generar, al igual que el anterior, código escrito en Java. Se ha utilizadola versión 0.11a.

JUnit: Se trata de un framework que permite realizar pruebas de unidad sobre softwareescrito en Java. Se ha empleado la versión 4.10.

lib_sen/mot_moway.h: Librerías provistas por la propietaria del robot que propor-cionan una serie de funciones para manipular el conjunto de sensores y actuadoresintegrados en el mismo desde lenguaje C.

Documentación y Gráficos

LATEX: Es un lenguaje que permite generar documentos técnicos con un acabado profe-sional. Se ha hecho uso de la plantilla esi-tfg6 para la escritura de la documentación delpresente Trabajo Fin de Grado mediante la distribución Tex-Live versión 2012. Conesta plantilla también se adjuntaba un fichero Makefile que facilitaba la compilación ygeneración del archivo definitivo.

Texmaker: Editor de LATEX utilizado para escribir la documentación. Se ha utilizadola versión 4.11.

Gimp: Herramienta que permite la manipulación de gráficos empleada para editarciertas figuras incluídas en la documentación. Se ha empleado la versión 2.6.12.

Inkscape: Es una herramienta de gráficos vectoriales empleada para generar ciertasfiguras incorporadas en la documentación. Se ha utilizado la versión 0.48.3.1.

LabPlot: Herramienta que permite la creación y edición de gráficas de manera senci-lla. Se ha utilizado la versión 1.6.0.

Visual Paradigm: Herramienta CASE vertical que permite gestionar los aspectos téc-nicos del proyecto (análisis, diseño, ...). Con ella, se han generado todos los diagramascontenidos en la presente documentación. Se ha utilizado la versión 11.0.

UmlGraph.jar: Plugin para NetBeans que permite insertar en el javadoc, generadomediante la documentación previa del código, diagramas de clases, lo que permitetener una visión más clara y compacta de las relaciones existentes entre clases. Se hautilizado la versión 5.7.

6https:/ /bitbucket.org/arco group/esi-tfg


Cliente de Control de Versiones

Git: Es un software de control de versiones (Git) con el que poder gestionar y sincro-nizar los avances realizados sobre el proyecto de manera local con el servidor remoto.Se ha utilizado la versión 1.7.9.5.

CAPÍTULO

5

Resultados

E N este capítulo se detalla la arquitectura modular seguida en el desarrollo de FUMO.Como ya se ha adelantado en capítulos anteriores, el presente proyecto se desglosó en

dos enfoques: enfoque de alto nivel y enfoque de bajo nivel. El modelo expositivo del pre-sente capítulo comenzará explicando y detallando los aspectos de diseño e implementaciónde los módulos arquitecturales de alto nivel, expuestos de menor a mayor complejidad, fina-lizando con todos los aspectos relacionados con el firmware desarrollado para el mini-robotempleado como caso de estudio.

5.1 Visión General

Si bien en el capítulo anterior se anticiparon los módulos que conformarían la arquitectura delsistema propuesto, en éste se resumirán los módulos definitivos dando una breve descripciónde los mismos:

Módulo de Procesamiento de Lenguaje: encargado del procesamiento del lenguajedescriptivo FCL.

Módulo de control: proporciona toda la lógica necesaria para permitir comunicar elrobot y el computador.

Módulo de Inferencia: proporciona toda la lógica necesaria para la creación de con-juntos difusos (variables lingüísticas, t-normas, t-conormas, etc), que a posteriori seránempleados por el parser para generar la red.

Módulo de Gráficos: genera una representación gráfica de la red empleada en el motorde inferencias.

Módulo ReteNetwork: proporciona todas las herramientas necesarias para poder ge-nerar una red RETE además de proveer un algoritmo de propagación de valores através de ella.

53

54 CAPÍTULO 5. RESULTADOS

Módulo de procesamiento dellenguaje

Analizador Léxico

Analizador Sintáctico

TablaPalabrasReservadas

TabladeSímbolos

Lenguaje

RETEConfiguración de Errores

Módulo ReteNetwork

Nodo

alfa beta

gamma

Algoritmo RETE

Submódulo de normas

T-Normas

T-Conormas

FuzzySet

FuncionesPertenencia

Módulo de Inferencia

Módulo BinaryHeap

TAD monticulo

Cola de Prioridad

Usuario

Módulo de Gráficos

Graphviz

Módulo de Utilidades

Módulo de comunicación conmini-robot

Gestión del Programa (Command)

Interfaz de comunicación RF

Sensores Actuadores

API mOway

Figura 5.1: Perspectiva general de la arquitectura

Módulo de utilidades: proporciona una serie de procedimientos que encapsulan dis-tintas funcionalidades.

Módulo BinaryHeap: permite la creación de colas de prioridad genéricas con memo-ria estática de manera sencilla, empleando un montículo binario para ello.

Además se acompaña un diagrama de casos de uso general de la aplicación con una brevedescripción de cada uno de ellos, y un diagrama de clases también general, con el que sepretende dar una perspectiva general de las clases involucradas. En cada uno de los apartadosse dará una versión un poco más detallada de los aspectos más importantes de cada uno delos módulos involucrados así como algunos métodos que revistan mayor importancia.

Diagrama de Casos de UsoEn la figura 5.2 se muestra el diagrama de casos de uso general de FUMO, donde unaespecificación breve de cada uno de ellos puede verse en las siguientes líneas.

Definir Nombre. El usuario puede asignar un nombre a una variable linguistica oconjunto difuso. Dicho nombre no está restringido a longitudes o contenido, si bienno pueden coexistir varias variables o conjuntos difusos con el mismo nombre. Esta

CAPÍTULO 5. RESULTADOS 55

acción se lleva a cabo al momento de definir las reglas que constituirán el motor deinferencias.

Definir Puntos. El usuario establece los puntos de pertenencia que definen al conjuntodifuso. Los puntos son insertados vía parser como un conjunto de pares ordenados(ecuación 3.1), estando limitados en número y en rango, es decir, sólo existirán tantospares como puntos defina la función de pertenencia elegida, y el valor está acotado alrango de representación del sensor o actuador escogido. Esta acción se lleva a cabo almomento de definir las reglas que constituirán el motor de inferencias.

Definir Etiqueta Lingüística. Este caso de uso permite definir etiquetas lingüísticas(i.e, conjuntos difusos) partiendo de los casos de uso anteriores. Esta acción se lleva acabo al momento de definir las reglas que constituirán el motor de inferencias.

Añadir Etiqueta Lingüística. Este caso de uso requiere del anterior para su imple-mentación, pues para añadir una etiqueta lingüística primero debe haber sido creada.Permite añadir a una variable lingüística dada un conjunto no limitado de etiquetas lin-güísticas. Esta acción se lleva a cabo al momento de definir las reglas que constituiránel motor de inferencias.

Asociar un sensor. Este caso de uso permite al usuario asociar a una variable lingüís-tica un sensor del mOway, de manera que al realizar el proceso de inferencia, el valorentero obtenido por dicho sensor sea el que se proceda a fuzzyficar para propagarlo porel resto de la red. Una variable asociada a un sensor será una variable de entrada ytendrá asociado un nodo alfa en la red RETE. Esta acción se lleva a cabo al momentode definir las reglas que constituirán el motor de inferencias.

Asociar un actuador. Similar al anterior, permite al usuario asociar a una variablelingüística un actuador del mOway, indicando qué valor tomará a la hora de ejecutaruna acción. Una variable asociada a un actuador será una variable de salida y tendráasociado un nodo gamma en la red RETE. Esta acción se lleva a cabo al momento dedefinir las reglas que constituirán el motor de inferencias.

Asociación mOway. Establece la correspondiente asociación entre la variable y elcorrespondiente sensor - actuador. Esta acción se lleva a cabo al momento de definirlas reglas que constituirán el motor de inferencias.

Asociar Rango. Cada sensor y actuador tiene su propio dominio de discurso, de modoque este caso de uso establece automáticamente, partiendo de la asociación previa-mente establecida entre variable y sensor - actuador, el rango de valores permitidos ala hora de especificar los pares de puntos que definen un conjunto difuso. Esta acciónse lleva a cabo al momento de definir las reglas que constituirán el motor de inferen-cias.

Definir Variable Lingüística. Este caso de uso permite la definición de una variable


linguistica, con su nombre, dominio, conjuntos difusos y función asociada. Para ello,requiere de los casos de uso descritos con anterioridad. Esta acción se lleva a cabo almomento de definir las reglas que constituirán el motor de inferencias.

Crear Regla Difusa. Este caso de uso permite al usuario definir un conjunto de reglasdifusas partiendo de la definición de variables lingüísticas obtenida de casos de usosanteriores. El usuario tiene la posibilidad de definir reglas MIMO, MISO o SISO (ver§ 3.1.9). Esta acción se lleva a cabo al momento de definir las reglas que constituiránel motor de inferencias.

Modificar Regla Difusa. Partiendo de una regla difusa ya creada, el usuario puedemodificarla del mismo modo que la creó. Esta acción se lleva a cabo al momento dedefinir las reglas que constituirán el motor de inferencias.

Generar red RETE. El usuario, una vez ha definido el conjunto de reglas difusas,puede compilar el lenguaje para obtener la red RETE. El resultado de la compilaciónserá un fichero binario .rete. Además, proporciona al usuario una lista de errores im-plicados en el proceso de compilación sólo en el caso de que existan. Esta acción selleva a cabo en el momento en que se ha terminado de definir el conocimiento a travésde las reglas difusas.

Generar gráfico RETE. Este caso de uso permite al usuario generar una representa-ción de la red RETE obtenida tras el proceso de compilación. Por defecto, el formatode dicha red será svg. Esta acción puede llevarse a cabo en cualquier momento sí ysólo sí se ha podido cargar una red (i.e generarla y usarla) en el sistema.

Comando Simple: Este caso de uso permite al usuario enviar una orden al robot,como puede ser conectar, desconectar, etc. Más adelante se mostrarán todos los co-mandos disponibles. Esta acción puede llevarse a cabo desde el primer momento quese inicia la aplicación, sin necesidad de tener una red RETE. De este modo, se puedeobtener información del entorno percibido mediante lectura de sus distintos sensoresasí como ejecutar actuadores simples como pueden ser las luces, de manera análoga acómo lo hace la aplicación oficial, aunque en ningún caso se ha pretendido hacer unareproducción total de ésta última.

Comando manual: Este caso de uso permite al usuario seleccionar una funcionalidadconcreta respecto a la ejecución de la red de forma cliente-servidor, pues el proceso deinferencia se lleva a cabo en el computador (servidor), y la ejecución de las accionestomadas a partir de él en el robot (cliente). Esta acción sólo es posible si hay una redcargada en el sistema y se ha establecido una comunicación entre las dos arquitecturas.

Comando automático: Ídem al anterior, sólo que en este caso la toma de decisionesse lleva a cabo también el robot, dejando el lado del servidor únicamente para tareas dedepuración; es decir, solicitar información acerca del estado de la red y del conjunto


de sensores - actuadores en un momento determinado.

Enviar Comando a Robot: Este caso de uso es el encargado de mandar alguno de loscomandos establecidos en los tres casos de uso anteriores al robot.

Depurar red RETE: El usuario, independientemente el modo de ejecución, tiene laposibilidad de obtener el estado de la red en un momento dado. Esta acción sólo esposible si hay una red cargada en el sistema y se ha establecido una comunicaciónentre las dos arquitecturas.

Depurar sensores y actuadores: Ídem al caso anterior, sólo que en vez de obtener elestado de la red, lo que se obtiene son los valores mediante los cuales se ha realizadoel proceso de inferencias.

Depurar Todo: Consistente en una combinación de la funcionalidad de los dos casosde uso anteriores.

Enviar comando a PC: Este caso de uso se encarga del envío de comandos (informa-ción de depuración o acuses de recibo [ACK]) entre el mOway y la aplicación.

Finalizar Sesión: Este caso de uso permite al usuario finalizar la ejecución de manerasegura. Intenta, si es posible, desconectarse del robot, finalizando los hilos de ejecu-ción y liberando la memoria ocupada. Esta acción puede llevarse a cabo en cualquiermomento desde el inicio de la aplicación.

5.2 Perspectiva de Alto nivelEn esta sección se explicará la funcionalidad de las clases involucradas en cada uno de losmódulos además de dar una perspectiva de la necesidad de cada uno de ellos.

5.2.1 Módulo BinaryHeapTras decidir qué método de inferencias se iba a utilizar, surgió la incógnita sobre cómo seiban a propagar los resultados a través de la red. Finalmente se decidió abordarlo medianteuna cola de prioridad de mínimos que desencolaría nodos en función de un identificadorúnico asociado a los mismos, de tal manera que:

desencolar(Nodo(x))⇔ ∃Nodo(x′) ∈ cola : min(x, x′) = x

Java ya posee una estructura de datos idéntica para acometer esto; sin embargo, hay que teneren cuenta que dicha estructura había que portarla al firmware del robot. Por esta razón sedecidió hacer una implementación propia basada en un montículo binario estático; es decir,la cantidad de memoria reservada para la cola quedaría fijada en tiempo de compilación.

El motivo por el cual se decidió que no permitiese en tiempo de ejecución solicitar másmemoria en caso de copar la que tiene disponible, fue para evitar complicaciones a la hora


De

finir

No

mb

re

Añ

ad

irE

tiqu

eta

sLingüísticas

Asociar

Actu

ad

or

Asociar

Sensor

Asociaciónm

Ow

ay

Asociar

Rango

De

finir

Va

riab

leLingüística

De

finir

Puntos

De

finir

Etiq

ue

taLingüística

Crear

Regla

Difu

sa

Modificar

Regla

Difu

sa

Generar

Red

RE

TE

Co

mp

ilar

Red

Co

ma

nd

oS

imp

le

Com

andoR

ET

Em

an

ua

l

De

purarsensore

sy

actu

ad

ore

s

Com

andoR

ET

Ea

uto

má

ticaE

nvia

rC

om

an

do

aR

ob

ot

De

pu

rar

tod

o

Depurar

redR

ET

E

En

viar

Co

ma

nd

oa

PC

Mandar

Red

Finalizar

Sesión

Ge

ne

rar

Gráfico

RE

TE

mO

wa

y

Usuario

<<

Inc

lud

e>

>

<<

Inc

lud

e>

>

<<

Inc

lud

e>

>

VisualP

aradigmfor

UM

LS

tandardE

dition(Com

puterS

cienceS

hool)

Figura5.2:D

iagrama

decasos

deU

so


Nodo

(retenetwork)

<<enumeration>>

Mode_t

(retenetwork)

ReteAlgoritm

o(retenetwork)

Gamma

(retenetwork)

<<enumeration>>

TipoBeta

(retenetwork)

RegDefuzz

(retenetwork)

Beta

(retenetwork)

Alfa

(retenetwork)

PrioQueue

(BinaryHeap)

BinaryHeapException

(BinaryHeap)

<<Interface>>

BinaryHeap

(BinaryHeap)

GraficoException

(Graficos)

Grafico

(Graficos)

GraphViz

(Graficos)

<<enumeration>>

Form

atos

(Graficos) <<enumeration>>

Sensores

(Moway)

<<enumeration>>

Tipo

(Moway::Moway)

<<enumeration>>

Rueda

(Moway::Moway)

<<enumeration>>

Rotacion

(Moway::Moway)

<<enumeration>>

Direccion

(Moway::Moway)

<<enumeration>>

Sentido

(Moway::Moway)

Moway

(Moway)

ModuloRF

(Moway)

<<enumeration>>

Actuadores

(Moway)

InterfazT

hreads

(Moway)

<<enumeration>>

Mode_

Exe

c(Moway)

<<Interface>>

Comandos

(Moway)

sym

(Lenguaje)

Sim

bolo

(Lenguaje)

<<enumeration>>

Tipo

(Lenguaje::CUP$parser$actions)

<<enumeration>>

Error

(Lenguaje::CUP$parser$actions)

parser

(Lenguaje)

Configuracion

(Lenguaje)

analex

(Lenguaje)

Semantica

(Lenguaje)

LenguajeException

(Lenguaje)

TablaSim

bolos

(Lenguaje)

TablaPReservadas

(Lenguaje)

Pro

d(fuzzyInference::Normas::TNorma)

BDif

(fuzzyInference::Normas::TNorma)

Min

(fuzzyInference::Normas::TNorma)

Max

(fuzzyInference::Normas::TConorma)

BSum


ASum


<<enumeration>>

Tipo

(fuzzyInference::Normas::Norma)

Norm

a(fuzzyInference::Normas)

FRectangular

(fuzzyInference)

FuzzySet

(fuzzyInference)

Funcio

nPertenencia

(fuzzyInference)

FSingleton

(fuzzyInference)

Rango

(fuzzyInference)

Punto

(fuzzyInference)

VariableLinguistica

(fuzzyInference)

FTriangular

(fuzzyInference)

FTrapezo

idal

(fuzzyInference)

utiles

(Utils)

X:Comparable<X>

X:Comparable<X>

X

X

1

-betas

*

-norm

a

1

1

1

-parser

1

1

2

1

-operacion

1

-etis

*

-pertenencia

1

-nodos

1

1

-r

tipoVariable

1

1

-padre

1*

-gammas

1

-vl

1

l1

1

-rete

1

-state

1

-tbeta

1

31

4

1

*-etiquetasLing

1-eti

-eti 1

-etiquetas

*

CUP$parser$actions

(Lenguaje)

VisualParadigmforUMLStandardEdition(Com

puterScience

Shool)

Figu

ra5.

3:D

iagr

ama

deC

lase

sge

nera

l


-heap : X[]-idx : int-DEFAULT_INITIAL_CAPACITY : int = 50

+PrioQueue(capacity : int)+PrioQueue()+isEmpty() : boolean+add(elem : X) : void+remove() : X+size() : int+contains(e : X) : boolean+hashCode() : int+equals(obj : Object) : boolean+toString() : String-swap(a : int, b : int) : void+clear() : void-indexOf(o : Object) : int

PrioQueue

+BinaryHeapException(message : String)BinaryHeapException

+isEmpty() : boolean+add(e : X) : void+remove() : X+size() : int+contains(e : X) : boolean+toString() : String+equals(e : Object) : boolean

<< In te r face>>BinaryHeap

X : Comparable<X>

X

Visual Paradigm for UML Standard Edition(Computer Science Shool)

Figura 5.4: Diagrama de clases BinaryHeap

de trasladarla al robot. El microcontrolador PIC no proporciona un área de memoria dinámica(heap) por defecto, por lo que hubiese sido necesario implementar subrutinas para dicho fin,sumado a la memoria del robot, que es del orden de mil veces más pequeña que la de uncomputador, entrañaría más perjuicios que beneficios.

Por otra parte, con el propósito de independizar la interfaz de la implementación, se diseñóun Tipo Abstracto de Datos (TAD) con las operaciones que estarían permitidas (listado5.2). Así, únicamente se especifica qué hay que hacer y no cómo, pudiendo aumentar laimplementación o crear varias clases que implementen el TAD para crear colas de prioridadde distintos tipos de datos: int, float, objetos, etc.

En este caso concreto, se ha creado una clase genérica llamada PrioQueue que implementalas operaciones de la interfaz, especificándose el tipo de dato que contendrá en el momento enque se haga uso de ella. Además, cada elemento contenido en ella debe poder ser comparadocon el resto, de modo que sirva los elementos de acuerdo a la prioridad escogida. Esto se halogrado forzando a que el tipo parametrizado sea un subtipo de la interfaz Comparable dela forma siguiente:

1 public class PrioQueue <X extends Comparable <X>> implementsBinaryHeap <X>

De esta manera tan sencilla, forzamos a que cualquier tipo por el que esté compuesta la cola


de prioridad pueda compararse con el resto de elementos de la misma, pudiendo establecerun cierto orden parcial entre sus elementos.

Por otro lado, la cola de prioridad tendrá reservada por defecto una memoria de 50·(tipo_dato)Bytes, donde tipo_dato será un tipo int, pues únicamente se almacenarán referencias a losnodos de la red, en forma de identificador único entero.

Esta memoria puede ser modificada fácilmente o bien modificando el valor de la constanteque asigna la capacidad por defecto:

1 private static final int DEFAULT_INITIAL_CAPACITY = 50;

o bien al momento de crear una nueva instancia de la cola de prioridad, quedando establecidamediante un parámetro en el constructor:

2 public PrioQueue(int capacity){3 if(capacity < 1)4 throw new IllegalArgumentException ();

6 heap = (X[]) (new Comparable[capacity ]);7 idx = 0;8 }

Listado 5.1: Constructor de colas de prioridad

Además, durante su diseño, se identificaron posibles errores derivados de su uso, los cualesfueron resueltos mediante excepciones. Gracias a su uso, se puede separar el código «nor-mal» del encargado de manejar los errores, lo que ayuda a mantener un código más legibley limpio, y lo más importante, poder continuar con el flujo normal de ejecución del progra-ma. Si bien Java proporciona un amplio abanico de excepciones para controlar casi todoslos eventos anómalos posibles, fue necesario crear una especificación propia, denominadaBinaryHeapException, para poder tratar situaciones tales como: cola llena, vacía, etc. En latabla 5.1 se resumen los métodos que emplean excepciones y el motivo por el cual se hacenecesario su uso.

Signatura Problema Excepción

public PrioQueue(int capacity) capacity <1 IllegalArgumentExceptionpublic X remove() Cola vacía BinaryHeapException

public void add(X elem)elem = null NullPointerExceptionCola llena BinaryHeapException

Tabla 5.1: Tratamiento de excepciones


5.2.1.1. Montículo binario

Normalmente, la implementación de colas de prioridad suele llevarse a cabo mediante eluso de montículos binarios, principalmente porque son estructuras de datos eficientes, cuyasoperaciones de inserción y eliminación tienen tiempo logarítmico (Θ(logn)).

Definición 5.2.1. Un montículo binario es un árbol binario completo cuyos elementos si-guen un criterio parcial de ordenación (propiedad de montículo), el cual puede ser:

1. Criterio de mínimos (min-heap):

∀i 6= raiz, v[padre(i)] ≤ v[i]. (5.1)

2. Criterio de máximos (max-heap):

∀i 6= raiz, v[padre(i)] ≥ v[i]. (5.2)

de manera que la raíz contendrá siempre el menor (o mayor) valor dependiendo del criterioescogido.

Dado que un montículo es un árbol binario completo, pueden ser implementados de maneraeficiente mediante el uso de arrays, puesto que las inserciones de los nodos de un mismo nivelse realizan de izquierda a derecha en posiciones consecutivas [Dat14]. De esto se desprendeque si el array v es de 0 .. N-1 posiciones, entonces el padre viene dado por v[i] = b i−1

2c, y

sus hijos izquierdo y derecho por v[i] = v[i+ 1] y v[i] = v[i+ 2] respectivamente.

Un ejemplo de montículo binario y su representación mediante arrays en memoria puedeverse en la figura 5.5.

1

3 4

5 9 6

1 3 4 5 9 6

0 1 2 3 4 5 ...idx(i)

v

2i+22i+1

Figura 5.5: Montículo Binario de mínimos


Operación de Inserción

La inserción de elementos se pueden resumir en los siguientes pasos:

El elemento se inserta en la última posición del arreglo, que se corresponde con laprimera posición libre.

Se comprueba si cumple la propiedad de montículo:

• Si lo cumple, no se hace nada.

• Si no lo cumple, es necesario restaurarla intercambiando el nuevo elemento consu padre tantas veces sea necesario (percolate up).

Operación de Eliminación

La eliminación de elementos se pueden resumir en los siguientes pasos:

Se elimina el nodo raíz del montículo, dado que contiene el elemento buscado (depen-diendo del criterio será el mínimo o máximo), y se reemplaza por el último elementodel mismo pues no puede vacía dicha posición ya que se perdería la estructura de árbol.

Al igual que antes, se comprueba si cumple la propiedad de montículo:

• Si lo cumple, no se hace nada.

• Si no lo cumple, es necesario restaurarla intercambiando la nueva raíz con elmenor (o mayor) de sus hijos tantas veces sea necesario (percolate down).

5.2.2 Módulo UtilsDurante el desarrollo de FUMO se comprobó que había una serie de tareas que aumentabanla cantidad de código, además de resultar repetitivo. Por ejemplo, truncar un valor decimal,requiere de largas líneas de código, lo que resta interpretabilidad y legibilidad al mismo.

Por esta razón, se decidió crear el presente módulo, que está compuesto una clase denomi-nada Utils que contiene una serie de métodos estáticos que desempeñan distintas funciones.Dado que los métodos contienen una funcionalidad independiente entre sí, no tenía muchosentido tener que crear una instancia de clase para poder tener acceso a ellos. En los siguien-tes subapartados se pueden apreciar los métodos y una breve descripción de los mismos:

Truncar

Permite truncar un valor decimal a una precisión de precisión decimales, siendo normal-mente dicha precisión de dos números decimales. Su principal utilidad radica a la hora defuzzyficar los valores enteros procedentes de los sensores. En este proceso, es habitual queal acotar el valor entero al intervalo [0, 1] adquiera demasiados decimales innecesarios.

1 public static double trunca(double valor , int precision){2 if(valor > 0)


3 return newBigDecimal(String.valueOf(valor)).setScale(precision ,BigDecimal.ROUND_FLOOR).doubleValue ();

4 else5 return new

BigDecimal(String.valueOf(valor)).setScale(precision ,BigDecimal.ROUND_CEILING).doubleValue ();

7 }

Listado 5.3: Trunca un valor decimal a precision decimales

Separar Decimal

Permite separar un número decimal con una precisión de dos decimales, guardando en by-te[0] la parte entera, y en byte[1] la parte decimal truncada a dos decimales. Un valor fuzzy

típicamente será decimal. Al trasladar la red de alto nivel a bajo nivel, ésta se agrupa enun array de bytes, por lo que intentar almacenar en él un valor decimal (4 Bytes) tal cual,conllevaría pérdida de información, lo que se traduce en inferencias erróneas.

1 public static byte[] separarDecimal(double decimal){2 byte [] res = new byte [2];

4 res[0] = (byte) (((int)decimal) & 0xFF); //Parte entera5 res[1] = (byte) (trunca(decimal -res[0], 2) * 100);

7 return res;8 }

Listado 5.4: Separación de un valor decimal en parte entera y decimal

Fecha y Hora

Devuelve una cadena con la fecha y hora actual en formato dd/mm/yyyy, donde d se refiereal día de la semana, m al mes, e yyyy al año. Su uso es meramente informativo y es empleadoal mostrar por pantalla información de depuración (ver. 5.2.2) del estado de la red para saberel momento exacto en el que se llevó a cabo.

1 public static String fechayhora (){2 Date date = new Date();

4 DateFormat fechayhora = newSimpleDateFormat("dd/MM/yyyy HH:mm:ss");

5 return fechayhora.format(date);6 }


Salida con Formato

Tal y como se mencionó en el capítulo 2, la finalidad del proyecto es conseguir que un robotmóvil sea capaz de actuar de manera autónoma de acuerdo a las decisiones inferidas a partirdel entorno y su base de conocimientos, por lo que no se precisa de una interfaz gráfica deusuario.

Sin embargo, un mínimo de interacción entre el hombre y la máquina es necesario. Por ello,para que dicha interacción no resultase tampoco excesivamente anodina o desagradable, sedesarrollaron diversos métodos que muestran los datos en arte ascii.

En el siguiente listado se muestran las signaturas de los métodos, pues su contenido noresulta relevante, ya que únicamente contiene llamadas de impresión de datos por salidaestándar.

1 /*éMtodos de ódepuracin */2 public static void formatSalida(int [] sensores , byte

[] actuadores) throws NegativeArraySizeException3 public static void formatSalida2(int [] rete_network , int

alfas , int betas , int gammas , int start) throwsNegativeArraySizeException

4 public static void formatSalida3(int [] sensores) throwsNegativeArraySizeException

5 public static void formatSalida4(Nodo <Alfa > [] alfas ,Nodo <Beta > [] betas , Nodo <Gamma > [] gammas) throwsNegativeArraySizeException

6 /*óInteraccin por teclado */7 public static void showMenu ()

Listado 5.5: Signaturas de funciones que dan formato a la salida

formatSalida muestra por pantalla los valores de los sensores y actuadores recogidos delrobot en un momento dado; formatSalida2 muestra el estado de la red de bajo nivel en unmomento dado; formatSalida3 muestra sólo el valor de los sensores con los que se estáninfiriendo resultados en un momento dado (sólo en alto nivel); formatSalida4 muestra elestado de la red de alto nivel en un momento dado; y showMenu muestra un menú con lasopciones disponibles.

Existencia de archivos y directorios

Comprueban si un path introducido por parámetro es un archivo o un directorio, tal y comose refleja en los siguientes listados. Su uso se limita a la hora de parsear el lenguaje y generarel archivo que contiene la red, donde se comprueba que la ruta es correcta.

1 public static boolean existeDirectorio(String dir){2 File f = new File(dir);


3 return f.exists () && f.isDirectory ();4 }

Listado 5.6: Comprobación de directorio

1 public static boolean existeFichero(String dir){2 File f = new File(dir);3 return f.exists () && f.isFile ();4 }

Listado 5.7: Comprobación de fichero

Compilación y carga de la Red

Este método se encarga de todo el proceso de compilación del lenguaje FCL para generarla red RETE. El parámetro sem recibe una instancia de la clase Semántica, la cual seráabordada más adelante en el módulo lenguaje. Las listas de flags, alfas, betas y gammas

almacenarán parámetros necesarios para la configuración del robot (identificador del robotpara conectarnos con el), y los nodos alfa, beta y gamma que conforman la red, los cualesserán usados para el algoritmo de propagación.

En lo que a su funcionamiento respecta, primero es necesario introducir las rutas absolutasdonde queremos guardar el fichero que contendrá la red (.rete); del fichero de texto plano quecontiene el lenguaje FCL a compilar (.txt), y desde donde se cargarán los datos contenido enel fichero .rete que contiene la red creada anteriormente.

Si el proceso de compilación no ha sufrido errores (léxicos, sintácticos o semánticos), en-tonces los parámetros de tipo lista comentados anteriormente albergarán la red utilizada parainferir resultados. Del mismo modo, también se notifican posibles fallos leves presentes enel lenguaje que no resultan críticos para la generación de la red.

1 public static void compilarRed(Semantica sem ,ArrayList <Integer > flags ,

2 ArrayList <Nodo <Alfa >> alfas ,3 ArrayList <Nodo <Beta >> betas ,4 ArrayList <Nodo <Gamma >> gammas) throws Exception{

6 Scanner leer = new Scanner(System.in);

8 String rutas;9 System.out.println("Introduce la ruta para guardar el

binario: ");10 rutas = leer.next();

12 sem = new Semantica(rutas);


13 System.out.println("Introduce la ruta absoluta al fichero acompilar: ");

14 rutas = leer.next();

16 sem.parsear(rutas);

18 System.out.println("Introduce la ruta absoluta al fichero aobtener los datos: ");

19 rutas = leer.next();

21 Nodo <Alfa > alfa [];22 Nodo <Beta > beta [];23 Nodo <Gamma > gamma [];24 ArrayList <Integer > flag;

26 if(Configuracion.getErrores ().isEmpty () &&Configuracion.getErrorLexico ().isEmpty ()){

27 try (ObjectInputStream ois = new ObjectInputStream(newFileInputStream(

28 rutas))) {29 flag = (ArrayList <Integer >) ois.readObject ();30 alfa = (Nodo <Alfa > []) ois.readObject ();31 beta = (Nodo <Beta > []) ois.readObject ();32 gamma = (Nodo <Gamma > []) ois.readObject ();33 }

35 //Lo añadimos36 alfas.addAll(Arrays.asList(alfa));37 betas.addAll(Arrays.asList(beta));38 gammas.addAll(Arrays.asList(gamma));

40 for(int i = 0; i < flag.size(); i++)41 flags.add(flag.get(i));

43 }else{44 for(int i = 0; i <

Configuracion.getErrorLexico ().size(); i++)45 System.err.println(Configuracion.getErrorLexico ().get(i));

47 for(int i = 0; i < Configuracion.getErrores ().size();i++)

48 if(! Configuracion.getErrores ().get(i).equals("Error: El analizador no se puede recuperar delerror."))

49 System.err.println(Configuracion.getErrores ().get(i));50 }


52 /* Mostramos warnings si los hubiese */53 for(int i = 0; i < Configuracion.getWarnings ().size(); i++)54 System.err.println(Configuracion.getWarnings ().get(i));55 }

Listado 5.8: Compilación de la red

Generar Grafo de la Red

Una de las posibilidades que tiene el usuario es poder generar una representación gráficade la red obtenida del proceso de compilación si ésta no ha sufrido errores. Ésta función seencarga justamente de esto. Sólo es necesario pasarle como parámetro el array que contienelos nodos alfas (obtenido con la función anterior), pues mediante un simple recorrido enprofundidad podemos obtener el resto de la red.

En lo que a su funcionamiento respecta, primero se comprueba si el parámetro que contienelos nodos alfas es nulo, y en ese caso, se obvia. Un caso de este estilo sólo puede darse,desde el punto de vista del usuario, en caso de intentar generar la representación gráfica sintener previamente una red cargada en el sistema; sin embargo, esta situación es avisada porel programa principal en forma de error, de manera que no entraña ningún riesgo para laestabilidad del software.

Por contra, si este no es nulo, se introduce la ruta y el nombre del fichero que lo contendrá.El formato de salida de dicho fichero será svg1, ya que arroja unos resultados de calidad muyaltos, incluso si se redimensiona la imagen. Como se puede apreciar en la línea 13, es posiblemediante código cambiar el formato de salida de la imagen por alguno de los mostrados enel listado 5.10, aunque como se ha comentado, se recomienda el establecido por defecto(svg).

1 public static void generarGrafo(Nodo <Alfa >[] alfas) throwsException{

2 Scanner leer = new Scanner(System.in);3 String ruta , salida;4 if(alfas != null){5 Grafico grafo = new Grafico(alfas);

7 System.out.println("Introduce la ruta absoluta dedestino: ");

8 ruta = leer.next();

10 System.out.println("Introduce el nombre que tendra: ");11 salida = leer.next();

13 grafo.construyeGrafo(ruta , salida , Formatos.svg);

1Scalable Vector Graphics


14 }15 }

Listado 5.9: Generación del grafo en formato visual

1 public enum Formatos {2 bmp , svg , png , jpeg;3 }

Listado 5.10: Formatos admitidos

5.2.3 Módulo de GráficosEste módulo contiene toda la lógica necesaria para construir, partiendo de una red RETE,su representación gráfica. En este punto, surgieron cuestiones acerca de qué herramienta sepodía utilizar y qué formatos de imagen debía soportar.

La respuesta fue fácil. Su representación se lleva a cabo mediante un paquete de herramientasde visualización de grafos denominada Graphviz [Gra14]. Más concretamente, se emplea unlenguaje descriptivo denominado DOT, el cual proporciona una manera simple de represen-tar grafos dirigidos mediante texto plano, además de permitir almacenar dicha representaciónen sendos formatos como svg, pdf o png entre otros. Por tanto, con una única herramientapodíamos resolver la problemática planteada al comienzo de esta sección.

Así pues, una vez escogido el mecanismo de representación de la red, el principal escollo quehabía que superar era la correcta generación del archivo .dot, pues éste debía generarse demanera automática cada vez que el usuario lo decidiese. Para poder lograrlo, fue necesarioun estudio de dicho lenguaje para saber cómo funcionaba.

Sintaxis DOT empleada

Si bien el lenguaje DOT ofrece amplias posibilidades para la generación de grafos, única-mente nos centramos en un subconjunto de ellas, especificadas a continuación:

Comienzo de un bloque: Dentro de él se especificará el grafo.

1 digraph G{ }

Ajuste del tamaño de fuente de los nodos:

1 node [fontsize = 10];

Mantener los nodos del mismo tipo nivelados:

1 {rank=same; ...}


Definir una transición entre nodos:

1 nodo1 -> nodo2;

Modificar color, forma y estilo dependiendo del tipo de nodo:

1 nodoAlfa [fillcolor=lightblue ,style=filled ,shape=house ];

2 nodoBeta [fillcolor=springgreen , style=filled ];3 nodoGamma[fillcolor=yellow , style=filled ,

shape=doublecircle ];

Establecer una etiqueta identificadora del nodo: Permite a su vez mostrar en elgráfico dicha etiqueta como nombre dentro del nodo.

1 nodo [label=id];

Algoritmo de Generación

Tras el estudio acerca de su funcionamiento, se codificó el algoritmo encargado de generarel grafo visualmente. Su generación estuvo basada en dos premisas: los nodos debían tener

colores y formas distintas para identificarlos fácilmente (Fig. 5.6), y se debía mantener cierto

orden entre nodos del mismo tipo.

NodogammaNodo alfa Nodo beta

Figura 5.6: Representación gráfica de los nodos

De esta manera, el algoritmo de representación consiste en recorrer cada uno de los no-dos alfa, y éstos a su vez, expandirlos en profundidad hasta llegar a un nodo gamma (nodoterminal). Dependiendo el tipo de nodo encontrado en el recorrido, se le asocia una formadeterminada y un color característico (Fig. 5.6).

5.2.4 Módulo FuzzyInferenceEste módulo es uno de los más sencillos e importantes del sistema. Sencillo porque carecede algoritmos complejos, e importante porque se encarga de proveer clases que permitenespecificar conjuntos difusos además de las operaciones inherentes a ellos, que más tardeserán utilizadas por el parser.

Un conjunto difuso va a quedar definido mediante un nombre y una función de pertenenciaasociada:


fuzzyInference

-serialVersionUID : long = -5265228552759009071L-der : Punto-puntos : int[]-izq : Punto

+FRectangular(izq : Punto, der : Punto)+fuzzyficar(x : int) : double+cog_eti() : double+hashCode() : int+equals(obj : Object) : boolean

FRectangular

-serialVersionUID : long = 9194578091046059965L-nombre : String-pertenencia : FuncionPertenencia-cog : double

+FuzzySet(nombre : String, pertenencia : FuncionPertenencia)+hashCode() : int+equals(obj : Object) : boolean

FuzzySet

-serialVersionUID : long = 2399088933993626888L

+fuzzyficar(x : int) : double+cog_eti() : double+getPuntos() : int []+equals(e : Object) : boolean+hashCode() : int

FuncionPertenencia

-serialVersionUID : long = -2235719131970887565L-puntos : int[]-punto : Punto

+FSingleton(punto : Punto)+fuzzyficar(valor : int) : double+cog_eti() : double+hashCode() : int+equals(obj : Object) : boolean

FSingleton

-serialVersionUID : long = -3485386885349301241L-limInferior : int-limSuperior : int

+Rango(limInferior : int, limSuperior : int)+Rango()+hashCode() : int+equals(obj : Object) : boolean+toString() : String+checkSensor(e : Sensores) : Rango+checkActuator(a : Actuadores) : Rango

Rango

-serialVersionUID : long = 6669972096472471480L-x : int-y : int

+Punto(x : int, y : int)+hashCode() : int+equals(obj : Object) : boolean

Punto

-serialVersionUID : long = 1155283622042230616L-nombre : String-funcionAsociada : X-r : Rango-etiquetas : FuzzySet

+VariableLinguistica(nombre : String, r : Rango, etiquetas : ArrayList<FuzzySet>, funcionAsociada : X)+addEtiqueta(fs : FuzzySet) : boolean+getEtiquetas() : ArrayList<FuzzySet>+setEtiquetas(etiquetas : ArrayList<FuzzySet>) : void+hashCode() : int+equals(obj : Object) : boolean+perteneceEtiqueta(eti : String) : boolean+getEtiqueta(eti : String) : FuzzySet

VariableLinguistica

X

-serialVersionUID : long = -5815610747460796171L-puntos : int[]-izq : Punto-m : Punto-der : Punto

+FTriangular(izq : Punto, m : Punto, der : Punto)+fuzzyficar(x : int) : double+cog_eti() : double+hashCode() : int+equals(obj : Object) : boolean

FTriangular-serialVersionUID : long = -5121174404547194782L-puntos : int[]-a : Punto-b : Punto-c : Punto-d : Punto

+FTrapezoidal(a : Punto, b : Punto, c : Punto, d : Punto)+fuzzyficar(x : int) : double+cog_eti() : double+hashCode() : int+equals(obj : Object) : boolean

FTrapezoidal

- r1

-etiquetas

*

-pertenencia

1

2 -der1


Figura 5.7: Diagrama de clases del módulo de inferencia

1 public FuzzySet ( String nombre , FuncionPertenencia pertenencia ) {2 this . nombre = nombre ;3 this . pertenencia = pertenencia ;4 this .cog = ( pertenencia != null ? pertenencia . cog_eti () :

Double . MIN_VALUE );5 }

Listado 5.11: Definición de conjunto difuso

Existen diversos tipos de funciones de pertenencia tal y como se explicó en el capítulo 3.FUMO permitirá el siguiente subconjunto de ellas: Singleton, Triangular, Trapezoidal,TrapezoidalL, TrapezoidalR y Rectangular. Todas estas clases tienen el mismo comporta-miento, si bien cada una de ellas, lo materializa de distinto modo; dicho de otra forma, todasellas realizan la misma operación, si bien el contenido de dicha operación difiere. Para evitar


código redundante y perder legibilidad del mismo, se ha diseñado una clase abstracta deno-minada FuncionPertenencia que es extendida por las anteriores. Los métodos que debenre-implementar son los siguientes:

fuzzyficar(int x): Devuelve un valor decimal con el resultado de fuzzyficar un valorentero pasado por parámetro. El contenido de estas funciones consiste en la definiciónexpuesta en el capítulo 3 (ver. § 3.1.7).

cog_eti(): Devuelve el centro de gravedad de un conjunto difuso.

get_puntos(): Devuelve un array de tantas posiciones como puntos sean necesariosdependiendo de la función de pertenencia, con el valor de las coordenadas en «x» delos mismos. Esta información que a priori puede parecer innecesaria, es empleada a lahora definir los conjuntos difusos a bajo nivel.

Como se ha comentado en el capítulo 3, el mecanismo de inferencia empleado consiste en elmétodo TSK de orden cero, en el que el consecuente de cada regla viene dado por conjuntosdifusos singletons. El sistema propuesto propone el uso de reglas en cuyo consecuente pue-den existir conjuntos difusos definidos mediante otra función de pertenencia distinta a lossingletons. Por esta razón, resulta necesaria la función cog_eti() expuesta anteriormente.

Dicha función «traslada» una función de pertenencia no singleton a un único punto de sudominio (en el eje «x»), consistente en el centro de masas del área definida. Para su cálculo,se hace uso de la ecuación 3.47. Dicho cálculo puede llevarse a cabo en tiempo de compi-lación, con la consiguiente liberación de carga del sistema, pues tenemos la certeza que entiempo de ejecución, la definición de un conjunto se mantendrá invariable.

En el listado 5.12 se muestra el código que permite calcular el centro de gravedad de lasfunciones trapezoidales, si bien el resto de ellas siguen el mismo criterio, con la salvedad delos límites del bucle, que estarán acotados en función de sus coordenadas.

1 public double cog_eti () {2 double pertenencia;3 double numerador = 0;4 double denominador = 0;

6 for(int i = a.getX(); i <= d.getX(); i++){7 pertenencia = fuzzyficar(i);8 numerador = numerador + (pertenencia * i);9 denominador += pertenencia;

10 }

12 return Utils.utiles.trunca (( numerador / denominador) ,2);13 }

Listado 5.12: Cálculo del centro de gravedad en Funciones Trapezoidales


De acuerdo a la teoría de conjuntos difusos, para representar el conocimiento vago o impre-

ciso se emplean variables lingüísticas. En este caso, una variable lingüística queda definidamediante un nombre, empleado como identificador de la variable; un rango, que determinael dominio de discurso del conjunto de sensores y actuadores de manera transparente para elusuario; una lista de etiquetas, que particionan el dominio de discurso en tantos conjuntosdifusos como se hayan definido, y una asociación explícita del sensor o actuador escogi-do.

Como se acaba de comentar, el dominio de discurso de una variable no puede ser modificado,sino que va implicito en el sensor o actuador empleado. En un primer momento, se valoró laposibilidad de ceder la responsabilidad al usuario; sin embargo, en este caso no reviste granutilidad y sí puede entrañar varios problemas:

Rangos incorrectos. Intentar establecer un dominio de discurso para una variable cuyaasociación, ya sea un sensor o un actuador, no ofrece tanta resolución.

Incremento de comprobaciones semánticas. Consecuencia directa del anterior, pueshabría que tener en cuenta demasiados casos, lo que se traduce en mayor tiempo decompilación.

Fruto de esta decisión, se consiguieron grandes ventajas respecto al usuario final:

Facilidad de uso. Pues la sintaxis del lenguaje disminuye, lo que implica menos com-plicación de cara al usuario.

Mayor productividad. El usuario únicamente se limita a desarrollar su base de cono-cimiento, sin tener que perder tiempo en peculiaridades del lenguaje.

Menos propenso a errores absurdos. Si se intentase utilizar un elemento físico delrobot que tiene un rango de valores que no coincide en absoluto con el rango de re-presentación definido por el usuario, el compilador no podría generar la red. Dado queel sistema propuesto tiene unos rangos bien definidos, errores de este tipo pueden serevitados, pues resultan incómodos y en ocasiones, difíciles de encontrar.

Para terminar con esta parte, sólo queda comentar el método de representación de conjun-tos difusos. Éstos se definen mediante un conjunto finito de pares ordenados (x,y), dondela variable x representa la coordenada en el eje de abcisas, y la variable y la pertenencia dex a dicho conjunto, valiendo «0» en caso de no pertenencia, y «1» en caso de pertenencia(ver. § 3.1.1 para más información). Para poder representarlo en memoria, se hace uso dela clase Punto, la cual permite agrupar coordenadas de la forma presentada aquí. Su imple-mentación es tremendamente simple, pues consta únicamente de un constructor que aceptalos parámetros comentados y los clásicos métodos de acceso y modificación de valores.

Su uso queda restringido a la hora de escribir los conjuntos difusos mediante el lenguajedescriptivo, pues se realiza una traducción directa a memoria de la coordenadas introduci-das.


Sub-Módulo Normas

Normas

TNorma

TConorma

ASUMBSUMMAXBDIFMINPROD

<<enumera t i on>>Tipo -serialVersionUID : long = -5880848071822178161L

+opera(pertA : double, pertB : double) : double+complementario() : Norma+getTipo() : Tipo+equals(o : Object) : boolean+hashCode() : int

Norma

-serialVersionUID : long = -8046571945521321101L


Prod-serialVersionUID : long = -5377187538940791795L


BDif-serialVersionUID : long = 8487615343006935470L


Min



Max-serialVersionUID : long = 2036671922512291408L


BSum



ASum


Figura 5.8: Diagrama de clases del sub-módulo de normas

Una de las características que debe poseer cualquier sistema de inferencia difusa es la po-sibilidad de hacer operaciones con conjuntos difusos. Justamente de esto se encarga estemódulo, pues define una serie de operaciones que permiten operar entre conjuntos, las cua-les son tomadas directamente del proyecto de estándar IEC 1131, pudiéndose ver resumidasen las tablas 3.3, que definen las TConormas, y 3.2, que definen las TNormas.

En lo que respecta a su implementación (Fig. 5.8), se ha seguido un enfoque similar a las


retenetwork

-serialVersionUID : long = 1362009809509729198L-nodo : X

+Nodo(nodo : X)+hashCode() : int+equals(obj : Object) : boolean

Nodo

NONEINIT

<<enumera t i on>>Mode_t

-reglasActivas : StringBuffer-alfas : Nodo<Alfa>[]-betas : Nodo<Beta>[]-gammas[] : Nodo<Gamma>[]-list_actualizar : PrioQueue<Integer>-numerador[] : double[]-denominador[] : double[]-sensores[] : int[]-actuadores[] : byte[]

+ReteAlgoritmo()+ReteAlgoritmo(alfas : Nodo<Alfa> [], betas : Nodo<Beta> [], gammas : Nodo<Gamma> [])+setSensoresbyPos(sensores : int [], inic : int, length : int) : void+setActuadoresbyPos(actuadores : byte [], inic : int, length : int) : void+expandir(mode : Mode_t) : void+resetReglasActivas() : void+reset() : void+getGammas() : Nodo<Gamma> []+setGammas(gammas : Nodo<Gamma> []) : void+getSensores() : int []+setSensores(sensores : int []) : void+getActuadores() : byte []

ReteAlgoritmo

-serialVersionUID : long = -2463019918361477053L-regla : String-activado : boolean-valor : double-id : int-etis : RegDefuzz-padre : Nodo<Beta>

+Gamma(regla : String, activado : boolean)+Gamma(eti : RegDefuzz)+addEtiqueta(eti : RegDefuzz) : boolean+getEtis() : ArrayList<RegDefuzz>+setEtis(etis : ArrayList<RegDefuzz>) : void+isActivado() : boolean+hashCode() : int+equals(obj : Object) : boolean+compareTo(o : Gamma) : int

Gamma

ANDORNONE

<<enumera t i on>>TipoBeta

-serialVersionUID : long = -8327357576355879753L-eti : FuzzySet-vl : VariableLinguistica

+RegDefuzz(vl : VariableLinguistica, eti : FuzzySet)+hashCode() : int+equals(obj : Object) : boolean

RegDefuzz

-serialVersionUID : long = 7060161656865948735L-valor : double-not : boolean-nivel : int-operacion : Norma-id : int-tbeta : TipoBeta-padreIzq : Nodo<Beta>-padreDer : Nodo-sucesores : Nodo

+Beta(tbeta : TipoBeta, padreIzq : Nodo<Beta>, padreDer : Nodo, nivel : int, operacion : Norma)+Beta(tbeta : TipoBeta, operacion : Norma, nivel : int)+getSucesores() : ArrayList<Nodo>+addSucesor(n : Nodo) : boolean+removeSucesor(n : Nodo) : boolean+isNot() : boolean+hashCode() : int+equals(obj : Object) : boolean+compareTo(o : Beta) : int

Beta-serialVersionUID : long = 7184427400211265218L-id : int-cambiado : boolean-valor : double-not : boolean-vl : VariableLinguistica<Sensores>-sucesores : Nodo-eti : FuzzySet

+Alfa(vl : VariableLinguistica<Sensores>, eti : FuzzySet)+Alfa(vl : VariableLinguistica<Sensores>, eti : FuzzySet, not : boolean)+addSucesor(n : Nodo<Beta>) : boolean+removeSucesor(n : Nodo<Beta>) : boolean+perteneceSucesor(n : Nodo<Beta>) : boolean+isNot() : boolean+setValor(valor : int) : void+resetValor(valor : double) : void+isCambiado() : boolean+hashCode() : int+equals(obj : Object) : boolean+compareTo(o : Alfa) : int+getSucesores() : ArrayList<Nodo<Beta>>

AlfaX : Comparable<X>

-etis*

*

-gammas[]

*

1 -padre-sucesores

1

-tbeta1


Figura 5.9: Diagrama de clases del módulo ReteNetwork

funciones de pertenencia. Mediante una clase abstracta denominada Norma, se define elprototipo de función que deben implementar todas las clases que extiendan de esta. Dentrode este sub-módulo, se definen dos paquetes que agrupan las operaciones en T-Normas yen T-Conormas, de modo que si se desea añadir una nueva operación, simplemente debeextender la clase abstracta y almacenarla en su paquete correspondiente. Los métodos a re-implementar son los siguientes:

opera(double x, double y): Realiza la operación definida entre dos conjuntos difusos.

complementario(): No confundir con la operación del complementario difuso. Eneste caso su utilidad es meramente semántica, pues a la hora de escribir reglas difusas,es posible aplicarlas el operador de De Morgan, obteniendo su complementario. Porejemplo, si tenemos A AND B, al aplicar De Morgan obtenemos la negación de lasvariables y el complemento de la operación A OR B.

5.2.5 Módulo ReteNetworkEste módulo tiene como principal finalidad proveer clases que permita construir redes RETE.Es importante resaltar que los nodos de la red sólo tratan con valores fuzzy, o lo que es lomismo, valores que oscilan en el rango [0,1]. Esta restricción viene impuesta por una decisiónde diseño, pues se determinó, que lo más adecuado era no mezclar conceptos (valores difusosy nítidos), y tratar únicamente con valores difusos, pues su propósito es inferir resultados quetratan con este tipo de información.

Como se vio en el capítulo 3, la especificación original de RETE está formada por un con-


junto de nodos alfa y beta. La implementación que se propone en el presente trabajo respectadicha especificación. Los nodos alfa, carecen de entrada y tienen n salidas, las cuales forzo-samente deben referenciar a un nodo beta. Por su parte, los nodos beta poseen dos entradasy tienen hasta n salidas, las cuales forzosamente deben referenciar o bien a otro nodo beta

o a un nodo gamma.

Un nodo gamma representa el consecuente de una regla difusa. Está compuesto por una úni-ca entrada proveniente de un nodo beta. De este modo, tendremos un grafo perfectamenteconstruido en el que cada nodo juega un papel diferenciado.

Los nodos alfa se encargan de encapsular las variables lingüísticas de entrada, o lo que eslo mismo, los sensores del mOway. De esta forma, quedan definidos mediante una variable

linguistica, una etiqueta linguistica y un «flag» que indica si dicho nodo es negado o no.En este punto, el lector posiblemente se esté preguntando porqué identificarlo mediante unavariable y una etiqueta si ésta última ya está incorporada en la primera. La respuesta es muysencilla.

Uno de los requisitos que impone RETE para que resulte eficiente, es evitar la duplicidadde nodos en el grafo. En un sistema de muchas reglas difusas, es habitual encontrarse conantecedentes cuya variable sea la misma pero su etiqueta no. Por ejemplo, supongamos lassiguientes reglas:

1 R1: IF A is a1 THEN B is b;2 R2: IF A is a2 THEN C is c;

Listado 5.13: Ejemplo de Regla con etiquetas distintas

Como se puede apreciar en el listado 5.13, tenemos dos reglas cuyo antecedente comparte lamisma variable difusa (A) pero no así su etiqueta (a y a’). Sino lo tuviésemos en cuenta, lared que se generaría sería errónea, pues lo que expresaría sería una regla de la forma:

1 R1: IF A is a1 THEN B is b, C is c;

Listado 5.14: Ejemplo de regla incorrecta resultante

que no tiene nada que ver con la base de reglas anterior. Por esta razón se almacena, ademásde la variable, su etiqueta asociada, de tal manera que dos nodos alfa son iguales sí y solosí tienen la misma variable, la misma etiqueta y el mismo «flag». Además, posee ciertosatributos de clase, como el id, requerido a la hora de identificar el nodo cuando se traslade abajo nivel; cambiado, que es una variable booleana que indica el cambio reciente del nodo;sucesores, una lista que contiene los sucesores de dicho nodo, y valor, que almacena encoma flotante qué valor fuzzy tiene.

En lo que respecta a los nodos beta, se emplea el siguiente criterio para su construcción:


como padre izquierdo tendrá otro beta o ningún otro nodo (nulo), y como padre derecho, obien otro beta o bien un alfa, pero nunca nulo o gamma. Esta restricción de diseño no restapotencia a la red y facilita la comprobación de que ha sido construida correctamente.

Este tipo de nodo tiene por objetivo encapsular la conectiva que une dos nodos alfa delantecedente de una regla. A su vez, distinguimos tres tipos de nodos beta:

None: Aquel cuyo padre izquierdo es nulo.

AND: Aquel cuyo padre izquierdo es un beta y cuyo padre derecho es un alfa o un betacuya conectiva indica que se debe emplear una T-Norma, que habrá sido especificadaen el lenguaje.

OR: Aquel cuyo padre izquierdo es un beta y cuyo padre derecho es un alfa o un betacuya conectiva indica que se debe emplear una T-Conorma, que habrá sido especificadaen el lenguaje.

Por tanto, un nodo beta queda definido por el tipo de beta que es, el padre izquierdo, el padrederecho, nivel que ocupa dentro del grafo (necesario para su construcción) y la operaciónque tiene que realizar (T-Norma o T-Conorma). Al igual que pasa con los betas, tambiéndispone de ciertos atributos para almacenar el valor que le llega de sus padre o una lista contodos sus sucesores.

En último lugar, están los nodos gamma. Estos nodos se encargan de encapsular las variableslingüísticas de salida, o lo que es lo mismo, los actuadores del mOway. De esta forma, quedandefinidos mediante el identificador de la regla asociada (Rn) y un registro que almacena lavariable lingüística y su etiqueta asociada. Un nodo gamma puede almacenar informaciónde diferentes antecedentes (i.e, variables lingüísticas), por lo que resulta necesario llevar unamínima identificación para evitar duplicaciones en los nodos.

Estas restricciones entre nodos son imprescindibles tenerlas presentes para poder compren-der el proceso de construcción de la red en el apartado siguiente.

En resumen, las clases alfa, beta y gamma permiten construir nodos de distintos tipos quealbergarán distinta información; sin embargo, por sí mismas no construyen nodos (actúancomo memorias), ya que son clases distintas y resultaría imposible compararlas. Para permi-tir su construcción, se ha creado una clase que permite tener agrupadas distintas memoriasen una única estructura de datos denominada Nodo, manteniendo una jerarquía acorde a laespecificación original de RETE.

Algoritmo de RETE

En el algoritmo 1 se puede ver en pseudocódigo la forma en la que se propagan los datosa través de la red. Su funcionamiento es el que sigue: mientras la cola de prioridad quedesencola nodos beta en función de un identificador único que establece un orden parcialentre ellos no sea vacía, se coge el nodo mayor prioridad, que en este caso será el que menor


Algoritmo 1: Algoritmo actualizar RETENet-Rete: Array indexando los nodos por ID.

1 while no Lista-Actualizar.vacia() do2 ID← Coger-Nodo(Lista-Actualizar);3 VALP0← VAL(Net-Rete[IDP0(Net-Rete[ID])]);4 VALP1← VAL(Net-Rete[IDP1(Net-Rete[ID])]);5 TEMP← OP(Net-Rete[ID], VALP0, VALP1);6 if TEMP <>VAL(Net-Rete[ID]) then7 VAL(Net-Rete[ID])← TEMP;8 Lista-Actualizar(IDH(Net-Rete[ID]));9 end

10 end

ID tenga. Se obtiene el valor del padre izquierdo y del padre derecho y se almacena elresultado de la operación (T-Norma o T-Conorma establecida) en una variable temporal, demodo que si el valor del nodo es distinto del valor temporal entonces actualizamos su valory lo expandimos, almacenando sus descendientes en la cola, repitiendo este ciclo hasta queno hayan más cambios.

La consecuencia directa que se desprende de este algoritmo es que sólo se propagan valoresque efectúan cambios de valor en los nodos, de manera que sólo se disparan reglas cuandoexisten cambios en el entorno apreciable por el robot.

5.2.6 Módulo de Procesamiento de LenguajeEste módulo, junto con el anterior es el más importante de todo el sistema, pues es el en-cargado de generar el motor de inferencia, utilizando las funcionalidades implementadas enlos módulos anteriores, por lo que una mala interpretación del lenguaje llevaría a resultadosanómalos.

Las principales características se pueden resumir en:

Permite la definición de variables lingüísticas así como los conjuntos difusos que par-ticionan el universo de discurso de dicha variable.

Se permiten los sistemas de reglas difusas comentados en el capítulo 3. Si bien en elantecedente se permiten agrupaciones de variables de todo tipo, incluidas negacionesde las mismas, en el consecuente solo se permiten variables positivas.

Se cede la responsabilidad en la especificación de la base de conocimiento al usua-rio, de manera que tendrá que tener presente la posible absurdez en ciertas reglas ocualquier otra circunstancia similar.

Por ser el más crítico, se hará una descripción más detallada que en los anteriores. Así,este módulo lo podemos dividir en tres partes: Analizador léxico, Analizador Sintáctico yAnalizador Semántico.


Analizador Léxico

También denominado lexer o Scanner, tiene como principal objetivo reconocer tokens queaparecen en un lenguaje fuente para pasárselos al sintáctico a medida que los vaya requirien-do, además de eliminar espacios en blanco, comentarios y avisar en caso de errores léxicos.Su implementación se ha realizado en JFlex, ya que fue diseñado para trabajar conjuntamentecon el parser CUP. El anexo D contiene la especificación completa del analizador.

Para el reconocimiento de tokens del lenguaje se hacen uso de expresiones regulares. Dichostokens identificados se pueden clasificar en lo que sigue:

Números: El lenguaje es capaz de reconocer únicamente números enteros, ya que elrango de representación de los sensores del mOway son números enteros.

Reconocimiento de comentarios: Por un lado, abre la posibilidad de escribir un co-mentario de una sola linea comenzando por el token «//», además de ofrecer la posi-bilidad de comentarios multilínea. En este último caso, los tokens de inicio y fin decomentario son «/*» y «*/» respectivamente. Además permite anidamiento de comen-tarios multilinea, detectando errores léxicos relacionados con los no cierres de éstos.

Identificadores: Reconoce un conjunto de tokens cuyo primer carácter sea una letra(minúscula o mayúscula) seguido de caracteres alfanuméricos.

Palabras Reservadas: Son palabras restringidas del lenguaje que deben aparecer enciertas partes del mismo y han de ser tratas como tales. La lista exhaustiva de palabrasse puede encontrar en la tabla 5.2.

Otros caracteres: Específicos del lenguajes, incorporan operadores de asignación :=,el uso de paréntesis para agrupar antecedentes de reglas, puntoycoma para delimitarlíneas, comas para separar consecuentes, dos puntos para definir especificar el tipo devariable (omitido), el igual para asociar un identificador de conexión con el robot o elguion para indicar números negativos detectados sintácticamente.

El tratamiento de palabras reservadas del lenguaje es uno de los aspectos más importantes ala hora de conseguir un compilador eficiente. La solución planteada consiste en implementaruna tabla hash. El analizador léxico reconoce un único token identificador. Tras ello, miraprimero en su tabla de palabras reservadas para comprobar si lo tiene; de ser así, devuelve eltoken asociado al analizador sintáctico; en caso contrario, es que se trata de un identificadornormal por lo que no requiere de ningún tratamiento especial.

Analizador Sintáctico

Para el analizador sintáctico, se ha empleado la herramienta de construcción analizadoressintácticos LALR denominada CUP. Su especificación en notación EBNF puede verse en elanexo C.


CUP aborda el analisis sintáctico de manera ascendente basado en la técnica de desplaza-

miento-reducción. Esta técnica consiste en ir leyendo tokens de la entrada para ir desplazán-dolos en una pila e ir comprobando si el contenido coincide con alguna parte derecha de lasproducciones de la gramática. De ser se así, se realiza la reducción, extrayendo de la pila losn tokens que coincidían con la parte derecha de la producción, poniendo en su lugar la parteizquierda de dicha producción.

Las gramáticas que permiten abordar el análisis sintáctico de manera ascendente son lasdenominadas LALR, que no son más que un subconjunto de gramáticas LR, pues permitenanalizar cadenas del lenguaje de izquierda a derecha (Left to Right) aplicando derivacionesmás a la derecha. Estas gramáticas son más fáciles de escribir y permiten generar a partir deellas la mayoría de lenguajes de programación [San13]. Por esta razón, se ha hecho uso dela herramienta CUP, y por extensión, de JFlex.

El lenguaje final reconocido consiste en una ligera adaptación del propuesto por el IEC1131, manteniendo casi toda la especificación propuesta por éste. Básicamente, un lenguajereconocible por FUMO puede quedar dividido en las siguientes partes:

Bloque de declaración: Aquí se declaran el conjunto de variables difusas utilizadopara representar el conocimiento. Se admiten varios bloques de declaración, aunqueéstos deben ir al principio del lenguaje (ver. listado 5.15).

Bloque de definición: Una vez declarado las variables, se definen los conjuntos difu-sos que particionarán el universo de discurso de las mismas. También se admiten va-rios bloques y deben ir inmediatamente después del anterior, e inmediatamente antesdel posterior (ver. listado5.16). Los sensores deben ir forzosamente en el sub-bloqueFuzzify, mientras que los actuadores en el sub-bloque Defuzzify. Dichos sub-bloquescomienzan por la palabra reservada Term y esperan un identificador (no palabra reser-vada) seguido de la definición del conjunto difuso de acuerdo a la ecuación 3.1.

Bloque de conocimiento: En él se declaran el conjunto de reglas difusas que codifica-rá el conocimiento disponible. Un bloque de reglas comienza por la palabra reservadaRuleblock y espera un nombre, seguido del operador difuso y la operación a utilizar(aunque no se use ninguna conectiva en las reglas). El proyecto de estándar aconseja,con el propósito de facilitar las leyes de DeMorgan, utilizar los operadores en formade pares (Tabla 5.3), respetando dicha especificación. De este modo, basta con especi-ficar uno de los operadores difusos y su operación para automáticamente, en caso deutilizar su complementario, asociarlo con su operación correspondiente. Respecto a lasreglas, en su forma más simple, siguen el siguiente formato: Rn: IF <variable>IS <eti-queta>THEN <variable>IS <etiqueta>, donde n es un número entero que identificaráunívocamente dicha regla en la red (nodo gamma). Si el parser detecta que una reglaya ha sido re-declarada (R1 y R1, con distinto cuerpo en la regla), entonces a la últimade ellas le modifica el identificador de la regla e intenta acoplarla a la red RETE. Por


supuesto, las reglas pueden ser tan complejas como se desee, permitiendo agrupaciónde partes del antecedente, empleando el operador de negación o utilizar indistintamen-te operadores AND y OR (ver listado 5.17). Por último, y a diferencia de los otros dosbloques anteriores, sólo se admite un único bloque de reglas, dado que tener variosaumenta ostensiblemente la complejidad y no proporciona ninguna ventaja apreciable.

Bloque de opciones: Este bloque lo plantea el estándar como un área donde propor-cionar información adicional necesaria para mejorar la conversión de aplicaciones decontrol difuso. En este caso concreto, este bloque es opcional, y debe ir justo despuésdel anterior (ver listado 5.18). Únicamente permite definir un identificador mediantela palabra reservada Moway_ID para indicarle al programa qué mOway es con el quehay que intentar conectarse. Sino se especifica nada, el sistema intentará conectarsecon un mOway cuyo identificador es el 14.

1 SENSOR2 velocidad(MOT_VEL): INT;3 END_SENSOR

5 /* ------*/6 ACTUATOR7 giro(MOT_ANG): INT;8 END_ACTUATOR

Listado 5.15: Ejemplo de declaración de variables

1 FUZZIFY velocidad2 TERM baja := (0,1) (0,1) (10 ,1) (15,0);3 END_FUZZIFY

5 /* ------*/6 ACTUATOR7 TERM leve := (0,1) (0,1) (10 ,1) (15,0);8 END_ACTUATOR

Listado 5.16: Ejemplo de definición de variables

1 RULEBLOCK nombre2 AND:MIN;3 R1: IF velocidad IS baja THEN giro IS leve;4 /*Regla compleja */5 R2: IF NOT(NOT((A is a) AND (B is NOT b)) OR C is c) THEN

D is d;6 END_RULEBLOCK

Listado 5.17: Ejemplo de definición de reglas


1 OPTIONS /* Opcional */2 MOWAY_ID = 15;3 END_OPTIONS

Listado 5.18: Ejemplo de definición de opciones

Por otra parte, CUP en el momento en que se topa con un error sintáctico detiene el procesode análisis bruscamente. Esto puede implicar que, si el error se localiza al principio dellenguaje, el resto del contenido se habrá quedado sin analizar. Para intentar mitigarlo en lamedida de lo posible, se ha implementado un mecanismo de recuperación del error en elbloque de definición, de manera que si detecta un error sintáctico dentro de ese bloque serecuperará y continuará con el resto del análisis. Evidentemente, ante una situación así, nose genera código intermedio (la red RETE).

Para poder implementar este mecanismo, basta con añadir un símbolo terminal especial de-nominado error a las producciones que contienen dichos bloques (ver listado 5.19, seguidode un símbolo terminal (end_fuzzy) que indicará el descarte de tokens hasta encontrarlo,momento en el cual se retoma el proceso de análisis.

1 FUZZIFY_BLOCK ::= fuzzify VARIABLE_NAME LINGUISTIC_TERM_1end_fuzzy | error end_fuzzy;

3 DEFUZZIFY_BLOCK ::= defuzz F_VARIABLE_NAME RANGELINGUISTIC_TERM_1 DEFAULT_VALUE end_defuzz | errorend_defuzz;

Listado 5.19: Ejemplo de definición de opciones

Analizador Semántico

El verdadero artífice de la generación del motor de inferencias, pues es el encargado en últimainstancia de generar el fichero binario .rete que lo contiene y de comprobar que todo estécorrecto. En la presente sección se comentarán las decisiones semánticas tomadas durante sudiseño con el objetivo de aumentar su capacidad de expresión así como usabilidad:

Cada variable declarada es comprobada si está siendo usada o no, y en ese caso, mos-trar warnings avisando al usuario de ello. Un warning permite generar código inter-medio, por lo que no afectará a la generación de la red si el resto del fichero que lacodifica está bien escrito.

Cada variable de entrada debe llevar asociado forzosamente un sensor, y una de salidaun actuador. El conjunto de sensores y actuadores queda definido mediante dos clasesenumeradas, de modo que se comprueba si la asociación realizada entre variable ysensor - actuador, encuentra su equivalente en dichas clases y están declaradas dentro


de su ámbito. Si esto no es así, se avisa al usuario y no se genera la red.

Cada variable de entrada (sensor) o de salida (actuador) debe ser definida (bloque dedefinición) en su bloque correspondiente. Además se controla la posibilidad de haceruso de una variable que no ha sido previamente declarada. En ambos casos, se generaun error y se avisa al usuario de su localización para que lo arregle.

A la hora de definir un conjunto difuso, sólo se requiere escribir el conjunto de paresordenados; de esta manera, dependiendo de la función de pertenencia a utilizar, habráuna cantidad de pares de entre uno a cuatro. Dependiendo del tipo de función se tieneen cuenta lo siguiente:

• Singleton. Se requiere que la coordenada «x» esté dentro del rango del sensorasociado a la variable, y la coordenada «y» debe ser uno. Semánticamente secomprueba esto mismo y se notifica al usuario de cualquier error si es lo que hay.

• Rectangular. Requiere de dos pares de puntos ordenados, de modo que la coor-denada x1 debe ser menor que x2 y además, y1 e y2 igual a uno, para representarun conjunto rectángulo o intervalo. Al igual que antes, se comprueba si los puntosestán dentro del rango y cumple el requisito comentado en la línea anterior.

• Triangular. Requiere de tres pares de puntos ordenados, de modo que x1 <x2<x3, con y1 e y3 igual a cero e y2 igual a uno, para representar un conjunto trian-gular. Al igual que antes, se comprueba si los puntos están dentro del rango ycumple el requisito comentado en la línea anterior.

• Trapezoidal. Esta es la función de pertenencia que más comprobaciones semán-ticas requiere. Como se ha comentado a lo largo de la presente documentación,se contemplan tres tipos de funciones trapezoidales: L, Γ, y Trapezoidal. Para sudefinición se necesitan cuatro pares de puntos, de modo que el analizador semán-tico comprueba si éstos están dentro del rango de definición y si están ordenados.Además, para diferenciar un tipo del otro se sigue el siguiente criterio: si los pri-meros pares son idénticos, de manera que y1 e y2 sean igual a uno, y los otros dosdistintos, de modo que y3 sea también uno e y4 sea cero, siempre y cuando esténordenados de menor a mayor, estaremos ante una función de tipo Γ; si los dosúltimos pares son idénticos, de modo que y3 sea e y4 sean igual a uno, y los otrosdistintos, de manera que y1 sea igual a cero e y2 sean igual a uno, aplicando elmismo criterio de ordenación, estaremos ante una función de tipo L; por último,si los cuatro pares son distintos, con x1 <x2 <x3 x4, y con y1 e y4 igual a cero yy2 y3 igual a uno, estaremos ante una función de tipo trapezoidal.

Sólo se admite un bloque de reglas, por lo que si un usuario intenta escribir otro, sele avisa mediante un error y no se genera la red. Esta parte es realmente sencilla deimplementar, pues basta con una simple variable global que actúe las veces de contadorpara llevar la cuenta de cuantos bloques hay, de modo que, si ésta es distinto de uno,


entonces se produce el error.

Al declarar las etiquetas dentro de una variable, es posible que ésta ya haya sido decla-rada (mismo nombre aunque tenga distinto conjunto difuso asociado). Ésto se controlasemánticamente avisando al usuario de ello y se produce otro error. En caso contrario,se generaría el conjunto difuso asociado a la variable definida.

Cada regla difusa lleva asociado un identificador en forma de Rn, donde n es un núme-ro entero, de manera que se mantienen ordenadas, comenzando por el 1. Si el usuariointenta introducir una regla difusa con un n que no sigue la cuenta (por ejemplo, sise ha escrito hasta la R3, la siguiente debe ser R4), internamente se establece de nue-vo y se avisa al usuario. A nivel semántico se considera un warning y no afecta a lageneración de la red.

La construcción de la red constituye la parte más delicada de todo el proceso. Básica-mente distinguiremos 4 casos de construcción:

1. Regla difusa con único antecedente (A→ B). El antecedente se construye co-mo un nodo alfa, al cual se le asocia un nodo beta de tipo none. Si recordamos,un nodo gamma debe tener como padre un nodo beta. Para cumplir esta restric-ción forzamos a que cada nodo alfa lleve consigo un nodo beta, de manera quese comprueba si esta construcción simple (alfa ->beta) ya existe para ser emplea-da. De este modo, reducimos el número de nodos y lo más importante, evitamosgenerar nodos redundantes.

2. Regla difusa con único antecedente negado (A → B). Se aplica el mismocriterio que en el caso anterior, con la salvedad que ahora, el nodo alfa tendráel «flag» de negación activo, lo que significa que a la hora de operar con él, esnecesario aplicar la operación de complemento difuso.

3. Regla difusa con antecedente binario (A AND B → C). Es indistinto el casode que se trate de un AND o un OR, pues la lógica que siguen es idéntica. Enprimer lugar se comprueba la definición de operador utilizada para el bloque dereglas, de manera que, si se ha especificado la operación AND:MIN, entonces enla producción donde se aplique el or es necesario complementarla, para asociarcorrectamente los betas con su operación siguiendo el criterio expuesto en la tabla5.3. Una vez hecho esto, hay que comprobar el tipo de nodo que son A y B.

a) Caso alfa - alfa. Se empieza siempre de izquierda a derecha. En primer lu-gar se realiza una construcción como la vista en el punto 1. Posteriormente,se genera un nodo beta’, de manera que su padre izquierdo queda estable-cido por la construcción (alfa ->beta) y su padre derecho el otro alfa. Secomprueba si esta construcción ya existe, en cuyo caso se usará. Sino es elcaso, se prueba a intercambiar los nodos padres del beta’, por si existiese.Si tampoco es el caso, entonces deshacemos esta última combinación y nos


quedamos con la primera.b) Caso alfa - beta. Se empieza por el caso más simple, que es generar un

nodo beta’ cuyo padre izquierdo será el beta y el derecho el alfa. Si noexiste, comprobamos si el beta es de tipo none. En este caso, se realiza unaconstrucción como la vista en el punto 1 con el nodo alfa, y para mantenerlas restricciones comentadas en la sección 5.2.5, se extrae del beta su padrederecho, que será forzosamente un nodo alfa, y se construye un nodo beta’

cuyo padre izquierdo será la construcción del alfa, y el padre derecho el alfa

del beta none. Si tampoco existiese, nos quedamos entonces con el primercaso expuesto.

c) Caso beta - alfa. Constituye el caso recíproco al anterior, por lo que suexplicación es aplicable a este caso también.

d) Caso beta1 - beta2. Al igual que el caso anterior, se parte por el caso mássimple. Se comienza construyendo un nodo beta’ cuyo padre izquierdo seael beta1 y el padre derecho el beta2. Si no existe, se comprueba si el beta1

es de tipo none, siendo el beta2 de tipo AND u OR. De ser así, se obtienesu alfa y se construye un nodo beta’ cuyo padre izquierdo es el beta2 yel derecho el alfa, siguiendo con las restricciones de diseño impuestas. Sitampoco existe, miramos si el beta2 es de tipo none. En este caso estamosante dos betas none. El criterio a comprobar ahora consiste en probar unode los beta none con el alfa del otro y viceversa para comprobar si existealguna de las construcciones. Si tampoco existe, miramos si estamos ante uncaso beta1 de tipo AND u OR y beta2 de tipo none. De ser así aplicamosel mismo criterio expuesto en estas lineas. Si este caso resulta que tampocoexiste, pues probamos el último que nos queda, que es generar un nodo beta’

cuyo padre izquierdo es el beta2 y padre derecho beta1. Finalmente, si estecaso tampoco existe, entonces generamos el más simple, que es el expuestoen la primera línea del presente párrafo.

4. Regla difusa con antecedente binario negado (A AND B → C). Este su-puesto no es más que un caso compuesto de los puntos 2 y 3, por lo que siguiendoel mismo criterio que en ellos, se logra su construcción

5. Regla difusa con antecedente binario, con uno de ellos negado(A AND B →C). Si alguno de los dos se trata de un nodo alfa, la solución pasa por estable-cer su «flag» de negación a cierto y construir el nodo como uno negado. Unavez hecho, estamos ante un caso igual al del punto 3. Por contra, si los dos no-dos son beta, el tratamiento de la negación pasa por aplicar el punto anterior yposteriormente lo comentado en el punto 3.

6. En general existen tantos casos como se nos puedan ocurrir, aunque todos sonresolubles en base a los casos más básicos, como son los expuestos en los puntos


1, 2 y 3.

En cada regla difusa, se comprueba que efectivamente las etiquetas utilizadas han sidopreviamente declaradas como parte de las variables en las que están siendo usadas,además de corroborar que la variable que está siendo utilizada ha sido también previa-mente declarada.

Por último, hay que comentar el orden en que los nodos son generados dentro de la red. Paraun correcto funcionamiento del algoritmo de propagación, es crítico que los nodos beta esténordenados por niveles de modo que sigan el orden parcial comentado en el capítulo 4. Cadavez que un nodo es generado, su nivel será 1. Cada vez que se profundiza más en el árbolsintáctico durante el análisis, el nivel del nodo incrementará en una unidad. De este modo,aprovechando la forma con la que los parsers LALR generan su árbol sintáctico, podemos irestableciendo los niveles de los nodos beta simplemente incrementando su nivel en uno, demodo que cuando se produzca una reducción, los resultados semánticos se propaguen hastaniveles más altos, teniendo siempre los nodos nivelados correctamente.

Todos los nodos son almacenados en listas enlazadas separadas (una para cada tipo de nodo),por lo que en última instancia, se requiere ordenar la lista de nodos beta de menor a mayor.Así, el identificador único asociado al nodo, que recordemos será el encargado de establecerla prioridad para ser expandido primero en la red, resulta tan simple como recorrer cadauna de las listas y, mediante una variable contadora, ir incrementándola en una unidad hastarecorrer todos los nodos.

Una vez todos los nodos ya están ordenados por su identificador, solamente falta almacenar-los en un fichero binario con extensión .rete. Para ello, se crea un flujo de salida (OutputS-tream) y se van transmitiendo los bytes. Destacar que para poder hacerlo, todas las clasesinvolucradas en la creación de la red deben implementar la interfaz serializable.

5.2.7 Módulo MowayEste módulo proporciona un conjunto de clases que permiten la comunicación vía radiofre-cuencia con el robot. Este módulo se divide en dos sub-módulos: radiofrecuencia e inter-acción.

Submódulo de radiofrecuencia

Se encarga de establecer toda la lógica necesaria para crear una comunicación inalámbricamediante radiofrecuencia. El desarrollo de éste módulo se inició empleando una definiciónescrita en C++ sobre la misma. De este modo, el esfuerzo aquí se centró en realizar unatraducción lo más próxima a la tomada como referencia.

Para lograrlo se hace uso de librería libusb, empleando el binding comentando en capítu-lo anteriores denominado usb4java. Tratar directamente con las funciones de libusb resultapoco intuitivo e implica tener que conocer demasiado la arquitectura para poder utilizarla


Moway

<<enumera t i on>>Sensores

DISTANCIATIEMPO

<<enumera t i on>>Tipo

IZQDER

<<enumera t i on>>Rueda

CENTRORUEDA

<<enumera t i on>>Rotacion

IZQDER

<<enumera t i on>>Direccion

BACKFWD

<<enumera t i on>>Sentido

+Moway()+conectarMoway(robotId : int) : boolean+deshabilitarRF() : void+desconectarMoway() : boolean+getObstaculos() : int []+getLineas() : int []+getTemperatura() : int+onLuzFrontal() : boolean+offLuzFrontal() : boolean+onLuzFreno() : boolean+irRecto(velocidad : byte, sentido : Sentido, tipo : Tipo, valor : byte) : int+setVelRueda(velocidad : byte, sentido : Sentido, rueda : Rueda, tipo : Tipo, valor : byte) : int+rotar(velocidad : byte, sentido : Sentido, ejeRot : Rotacion, rueda : Rueda, tipo : Tipo, valor : byte) : int+hacerCurva(velocidad : byte, sentido : Sentido, radio : byte, rueda : Rueda, tipo : Tipo, valor : byte) : int+feedback() : int []+getTodosSensores() : int []+resetMot(reset : byte) : int+motEnd() : int+offLuzFreno() : boolean+onLedVerde() : boolean+offLedVerde() : boolean+onLedRojo() : boolean+offLedRojo() : boolean+onSpeaker(freq : byte) : int+offSpeaker() : int+getGolpe() : int+getAcelerometro() : int []+getLuzIncidente() : int+getBateria() : int+enviarRete(rete : byte [], len_alfas : int, len_betas : int, len_gammas : int) : boolean+sendActuadoresManualRete(actuadores : byte []) : boolean+resetRete() : boolean+initReteAuto() : boolean+execReteAuto() : boolean+debug_rete_auto(nivel : Mode_Exec) : void+debug_rete_autoTest(sensores : byte []) : int []+resetReteManual() : boolean

Moway

+ModuloRF()+RFHabilitado() : boolean+free() : void+abrirDispositivo() : boolean+conectarRF(ch : byte, add_send : byte, add_receive : byte) : int+desconectarRF() : boolean-rawSend(cmd : byte []) : int+send(cmd : byte []) : int+receive() : ByteBuffer-receive(size : int) : ByteBuffer

ModuloRF

<<enumera t i on>>Actuadores

+InterfazThreads(rete : ReteAlgoritmo, robot : Moway, robotId : int)+InterfazThreads()+isConstruida() : boolean+run() : void+isIniciada() : boolean+isConectado() : boolean-conectarMoway() : boolean-DesconectarMoway() : boolean-initManual() : void-manualRete() : void-resetReteManual() : void-debugReteManual(nivel : Mode_Exec) : void+isEnviable() : boolean+isInicializada() : boolean+isEnviada() : boolean-enviarRete() : void-initReteAuto() : void-autoRete() : void-resetReteAuto() : void-debugReteAuto(nivel : Mode_Exec) : void+testCaseRete(rete1 : ReteAlgoritmo, sensores : byte []) : int []-construirRete() : void-execRoutineSimple(nivel : Mode_Exec, freq : byte) : void

InterfazThreads

<<enumera t i on>>Mode_Exec

<< In te r face>>Comandos

1

-state

1

1


Figura 5.10: Diagrama de clases Moway

correctamente. Sin embargo, se pretende todo lo contrario: crear una API que sea lo suficien-temente expresiva como para permitirte interactuar con el robot y a su vez intuitiva.

Por esta razón, se ha desarrollado la clase ModuloRF, que proporciona una serie de métodosintuitivos que envuelven las llamadas a la libusb. Su principal propósito es poder inicializarel transmisor usb, además de liberar toda la memoria asociada una vez finalizado su uso, yproporcionar unas rutinas de envío y recepción de datos de bajo nivel.

La comunicación entre el robot y el computador se realiza mediante tuberias o pipes. Unatubería, en este contexto, describe una conexión entre un dispositivo y un buffer desde elcual los datos entran o salen del mismo denominado endpoint. Existirán dos bufferes quepermitirán la transferencia de datos unidireccional: uno de entrada (IN) desde el dispositivoal computador, y otro de salida (OUT) desde el computador al dispositivo.

Para la comunicación entre el mOway y el computador, estos bufferes se localizan en lasposiciones 0x81 y 0x01 respectivamente.


El transmisor usb permite mandar paquetes de hasta 64 Bytes; sin embargo, las rutinas derecepción de tramas del mOway, sólo toleran hasta 8 Bytes por envío. El envío se realizamediante una transferencia masiva de datos denominada bulk. En el listado 5.20 se muestrael código que permite el envío de tramas.

1 private int rawSend(byte [] cmd){2 ByteBuffer buffer = null;3 IntBuffer transferred = null;

5 /* Ahora ya podemos mandarlo */6 if(dev_handle != null){7 buffer = BufferUtils.allocateByteBuffer(cmd.length);8 buffer.put(cmd);

10 transferred = BufferUtils.allocateIntBuffer ();

12 result = LibUsb.bulkTransfer(dev_handle ,OUT_ENDPOINT , buffer , transferred ,RF_SEND_TIMEOUT);

14 //Reseteamos el dispositivo para evitar mandar lo mismo15 LibUsb.clearHalt(dev_handle , OUT_ENDPOINT);

17 if(result != LibUsb.SUCCESS){18 return RF_ERROR;19 }20 }

22 return transferred != null ? transferred.get():RF_ERROR;

23 }

Listado 5.20: Rutina de envío de bytes

Dicha función retorna en caso de éxito el numero de bytes transferidos y -1 en caso de error.Es necesario que después de cada envío se reinicie el buffer de salida para evitar posiblessolapamientos entre envíos.

Por otra parte, la rutina de recepción se puede ver en el listado 5.21.

1 private ByteBuffer receive(int size){2 ByteBuffer buffer = null;3 IntBuffer transferred;4 boolean fromMyMoway = false;

6 int cont = 64;


8 if(dev_handle != null){9 do{

10 if(cont == 0) break;

12 buffer =BufferUtils.allocateByteBuffer(size).order(ByteOrder.

13 LITTLE_ENDIAN);14 transferred = BufferUtils.allocateIntBuffer ();

16 result = LibUsb.bulkTransfer(dev_handle , IN_ENDPOINT ,buffer , transferred , RF_REC_TIMEOUT);

18 if(result != LibUsb.SUCCESS){19 return null;20 }else{21 if(transferred.get() != 9 || (buffer.get() !=

sendAddress)){22 continue;23 }

25 transferred.rewind ();26 buffer.limit(transferred.get());

28 fromMyMoway = true;29 }

31 cont --;32 }while (! fromMyMoway);33 }

35 return buffer;36 }

Listado 5.21: Rutina de recepción de bytes

Una de las características que permite mOway es hacer trabajos colaborativos con otros mO-ways. Esto supone un intercambio de información entre robots que pueden ser capturados porel transmisor usb. Esta rutina se encarga de descartar paquetes de mOways cuya direcciónde envío no tenga como destinatario el computador (sendAddress). Además, también se pro-pone un número de reintentos en caso de haber hecho un envío al robot y estemos esperandosu contestación. En caso de éxito devuelve los Bytes recibidos, y en caso de fallo un punteronulo.

Con esta clase ya se puede establecer una comunicación entre el robot y el computador.Sin embargo, resulta todavía un poco compleja de utilizar para poder encapsular llamadasconcretas al mOway. Como una capa de abstracción entre ésta clase y el firmware que será


comentado más adelante, se diseñó la clase Moway, la cual nos proporciona una serie derutinas que ejecutan un comando concreto en el robot.

En esencia, esta clase propone un envoltorio de la clase MóduloRF que facilita la interaccióncon el robot. En la figura 5.11 se puede observar el diagrama de secuencia que es llevado acabo por todos los métodos de la clase Moway, si bien cada uno de ellos envía un comandodistinto obviamente.

mOway

ModuloRF

Moway

Usuario

7: ACK o envío de datos

6: Ejecutar orden

5.2: wait

3.1:

5.1: Envío de Bytes

5: Enviar comando

4 :

1: Conectar con Robot

3: Abrir Dispositivo USB

2 :


Figura 5.11: Diagrama de Secuencia de comandos

Submódulo de interacción

Este módulo permite la interacción entre el programa principal y el mini-robot. Para su desa-rrollo, se ha seguido un patrón de diseño denominado command. Este patrón encapsula losdatos de una operación a realizar por un objeto.

La clase que lo implementa se denomina InterfazThreads, la cual implementa un hilo deejecución que se encarga de atender las peticiones del usuario vía mensaje. Así, esta claseimplementa un método run() que se encarga de seleccionar, en función de la petición delusuario, qué funcionalidad llevar a cabo, pudiendo ir desde mandar un simple comando alrobot hasta compilar la red. Gracias a este enfoque, obtenemos ciertas ventajas:

Flexibilidad. Para incorporar nueva funcionalidad únicamente hay añadir un nuevométodo a la clase y que el run() sea capaz de usarlo. De este modo, no es necesario


cambiar las clases ya existentes.

Intuitividad. La selección de la funcionalidad a realizar se realiza mediante un men-saje. Los mensajes son en realidad tipos enumerados, de modo que resultaría muysencillo añadir un nuevo mecanismo funcional, pues únicamente hay que añadir laetiqueta con la que queremos referirnos a dicha funcionalidad.

El uso del hilo en segundo plano, además de permitir lo expuesto anteriormente, tambiénse utiliza para evitar bloqueos derivados de tareas pesadas ejecutadas en segundo plano.Cierta funcionalidad implementada permite estar ejecutándose indefinidamente hasta queno se especifique lo contrario. Un ejemplo de ésta problemática consistiría en ejecutar lainferencia en el lado del computador y mandarle los resultados obtenidos al robot. Si soloempleamos un hilo de ejecución, al solicitar al sistema que ejecute dicha funcionalidad,se mantendría indefinidamente en ese estado sin poder hacerse nada más. Otras, como porejemplo obtener información de los sensores, no hacen tan perceptible este problema ya quesólo lo hace una vez y se tiene la garantía que liberará el recurso cuando finalice. Así pues,gracias al uso de un hilo secundario, el principal no se bloquea y permite atender peticionesdel usuario constantemente.

5.3 Perspectiva de Bajo nivelEn esta sección se comentará todo lo referente del control a bordo del robot. Esta parte, adiferencia del resto del proyecto, está implementada en C.

5.3.1 Firmware mOwayEl mOway permite dos tipos de recepción de datos: mediante rutina de interrupción y sinella. Según el fabricante, recomienda recibir los datos por interrupción pues el otro métodoposibilita la pérdida de tramas en caso de interferencias.

Su funcionamiento consiste en un bucle infinito con un switch que va atendiendo peticionessegún le llegan desde el computador. En función de la seleccionada, realiza una operacióndeterminada. Así, cuando el usuario manda un comando al robot, se genera una interrupciónque es atendida de inmediato. En la trama mandada va encapsulado el comando a ejecutar,por lo que simplemente se selecciona el case correspondiente y se lleva a cabo. Tras suejecución, se retorna un acuse de recibo o ACK para indicar al servidor que la operación hasido atendida satisfactoriamente.

Con la funcionalidad comentada se consigue un sistema cliente-servidor que permite inter-cambio de datos. Pero además de esto, también se necesitan estructuras que almacenen lared RETE.

Para ello, se ha reservado un arreglo de memoria donde residirán los nodos de la red. Ademásde éste, dos arreglos más albergarán los valores de los sensores y actuadores con los que


se han inferido los resultados. Dichos arreglos resultan útiles para la representación de lared en bajo nivel, pues cada posición del arreglo se identifica con algún sensor o actuadorconcreto. Por último, se han codificado estructuras (structs) que agrupan cierta informaciónrelacionada.

1 /* Variables necesarias para manipular la red*/2 struct RCB{3 int tam_alfas; //Tamaño de alfas4 int tam_betas; //Tamaño de betas5 int tam_gammas; //Tamaño de gammas6 };

8 struct RCB rcb; //Bloque de control de la red

10 /* Informacion de variables para actuadores */11 struct code_functions{12 char velocidad;13 char radio;14 char angulo;15 char flags;16 };

18 struct code_functions cf;

Listado 5.22: Estructuras que albergan datos relacionados

En el listado 5.22 se pueden apreciar dos. La estructura RCB o bloque de control de lared, almacena el tamaño total en Bytes de cada porción de la red, necesaria para ejecutarel algoritmo de rete. Por otro lado, la estructura code functions se encarga de almacenarinformación temporal durante el proceso de asignación de los valores almacenados en elarreglo de actuadores a las funciones que ejecutan acciones en el mOway.

5.3.2 RETE de bajo nivelEsta es la parte más delicada desde esta perspectiva. En esta sección se procederá a explicarcomo se ha traducido la estructura de red de alto nivel a bajo nivel.

Uno de los requisitos obligatorios de cumplir fue que la red de bajo nivel estuviese agrupadaen un único área de memoria contigua. Como se comentó en el capítulo 4, fue necesariomodificar el mapa de memoria (linker) del robot para agrupar distintos bloques de 256 Bytesen uno de 2048 Bytes. Esto significa que como máximo se podrá almacenar una red que nosobrepase dicha memoria. Si se ha diseñado una red de un tamaño superior, entonces no sepodrá ejecutar en el robot. Un aspecto a tener en cuenta es que la memoria del robot es muylimitada, por lo que resulta útil probar redes con un número pequeño de nodos.

Así pues, se hicieron cálculos acerca de la memoria necesaria por cada tipo de nodo, teniendo


en cuenta que la transimisión de datos entre el robot y el computador solo tolera Bytes, esdecir, valores de 8 bits a lo sumo.

Nodos alfa

Un nodo alfa de bajo nivel está representado de la siguiente manera:

ID: Identificador único del nodo, obtenido en el proceso de compilación de la red.Ocupa 2Bytes de memoria, divididos en parte alta y parte baja. Como la red disponecomo máximo de 2048Bytes, el número de bits necesarios para representar dicho nú-mero es 12, que es mayor de 8. El identificador en alto nivel son 32 bits, de los cualessólo necesitaremos los 12 primeros, pues son los que contienen la información quenos interesa. Por tanto, se separa dicho número en dos números de 8 bits cada uno, demanera que los 8 primeros serán la parte baja y los 8 últimos la parte alta.

Flags: Ocupa 1Byte de memoria, donde cada bit representa información adicional:

1. Bit 0. Si el nodo está negado, en cuyo caso habrá que realizar el complementariodifuso.

2. Bit 1. Si el nodo ha cambiado su valor recientemente, necesario para propagar elresto de la información por la red.

3. Bits 2 y 3. Codifican la función de pertenencia utilizada. Así, un 00 represen-tará un conjunto singleton, un 01 un conjunto rectangular, un 10 un conjuntotriangular, y un 11 un conjunto trapezoidal.

Valor: Ocupa 2Bytes y almacena el valor del nodo. Se requieren 2 Bytes puesto queel valor vendrá dado en forma flotante, por que será necesario partirlo en parte entera

y parte decimal y almacenar dichos valores en el primer y segundo Byte respectiva-mente. Como sólo manejan valores fuzzy, no hay riesgo de desbordamiento, pues elmáximo número que puede tomar es uno.

Variable lingüística: Ocupa 1Byte. En alto nivel, guardábamos tanto la variable comola etiqueta. Aquí ya no es necesario porque la red ya está construída, así que única-mente tenemos que almacenar qué posición del arreglo de sensores ocupa el sensorasociado.

Puntos de Pertenencia: Se requieren de 1 a 4Bytes dependiendo de la función defini-da. De esta manera, cada Byte almacena la coordenada «x» del par de puntos utilizadoen su definición, pues la coordenada «y» sólo se requiere en la construcción de la red.Además, como el universo de discurso viene dado por los sensores, y éstos tienen comomáximo un rango de hasta 255 valores (1Byte), no existe problema de desbordamiento.Por esta razón, se decidió no permitir al usuario definir un dominio propio.

Número de sucesores: Ocupa 1Byte, lo que significa que como máximo, un nodo alfa

podrá tener 255 sucesores, situación bastante improbable porque no habría espacio


suficiente.

Lista de sucesores: Ocupa un total de 2Bytes * n, donde n es el número de sucesores.Esta lista almacena los identificadores únicos de los nodos.

Esta es la estructura que representa en memoria un nodo alfa. Sin embargo, antes de con-tinuar, conviene destacar una observación. En el campo ID finalmente no se almacena elidentificador propio del nodo, sino el identificador del siguiente nodo, ya que resulta máseficiente tener al principio de cada nodo el final del mismo o comienzo del siguiente, segúnse vea, que tener que recorrer todos los Bytes de cada nodo hasta alcanzar el buscado. Ade-más resulta un poco absurdo gastar 2Bytes para almacenar un valor que lo podemos obtenerpor indexación durante el recorrido de la red.

Esto resulta muy útil a la hora de ejecutar el algoritmo 1. De esta manera, podemos saltarnosnodos enteros en el recorrido del arreglo que contiene la red, lo que se traduce en mayorrapidez a la hora de llevar a cabo las inferencias.

Este enfoque de los identificadores es seguido en los otros tipos de nodos también.

Por tanto, la cantidad total de memoria que ocupa un nodo alfa será de 7Bytes fijos + 2B *#Sucesores + 1 a 4 Bytes dependiendo del conjunto difuso definido.

Nodos Beta

Un nodo beta de bajo nivel está representado de la siguiente manera:

ID: Ocupa 2Bytes de memoria, siguiendo el mismo criterio que los alfas. Tal y co-mo se ha explicado hace escasas líneas, por cuestiones de eficiencia, se almacena elidentificador del siguiente nodo de la red en vez del propio.

Flags: Ocupa 1Byte de memoria, donde cada bit representa información adicional:

1. Bit 0. Si el nodo está negado, en cuyo caso habrá que realizar el complementariodifuso.

2. Bits 1 y 2. Codifican el tipo de nodo beta. Así, un 00 representará un none, un 01un and, y un 11 un or.

3. Bits 3, 4 y 5. Codifican la operación a realizar. El bit número 5 con valor igual a 1representa una T-Conorma, y con valor 0 una T-Norma. Los bits 3 y 4 especificanla operación concreta. Así, un 00 representará la operación suma algebraica si esuna T-Conorma y producto algebraico si es una T-Norma; un 01 representará laoperación suma limitada si es una T-Conorma y la T-norma de Lukasiewicz sies una T-Norma; y un 10 representará la operación maximo si es una T-Conormay mínimosi es una T-Norma.





Padre izquierdo: Se requieren 2Bytes. Se almacenará el identificador del padre. Alhaber 2048 posiciones de memoria, con 8 bits no podemos cubrirlas todas. Por estarazón se requieren 2Bytes, divididos en parte alta y parte baja. El identificador en altonivel son 32 bits, de los cuales sólo necesitaremos los 12 primeros, pues son los quecontienen la información que nos interesa. Por tanto, se separa dicho número en dosnúmeros de 8 bits cada uno, de manera que los 8 primeros serán la parte baja y los 8últimos la parte alta. Un caso especial lo encontramos cuando el beta es none, pues enese caso, carece de padre izquierdo. Para reflejarlo, la parte alta adquiere el valor 24 yla baja 0, pues si se junta el número, se obtiene un valor que nunca se va dar.

Padre derecho: Ídem al padre izquierdo con la salvedad que no puede existir comopadre derecho un beta none.

Número de sucesores: Ídem al caso de los nodos alfa.

Lista de sucesores: Idéntico al caso de los nodos alfa.

Por tanto, la cantidad total de memoria que ocupa un nodo beta será de 10Bytes fijos + 2B *#Sucesores.

Nodos Gamma

Un nodo gamma de bajo nivel está representado de la siguiente manera:

ID: Exactamente igual que el caso anterior.

Activado: Ocupa 1Byte de memoria. Su utilidad radica en saber si el nodo ha sidoactivado, es decir, si la propagación de valores por la red ha llegado al consecuente deuna regla. Sólo los nodos gammas activos actualizarán los valores de los actuadores.

Regla: Ocupa 1Byte, y almacena el identificador de la regla difusa.





Padre: Se requieren 2Bytes. Se almacenará el identificador del padre, el cual será unnodo beta. Al haber 2048 posiciones de memoria, con 8 bits no podemos cubrirlastodas. Por esta razón se requieren 2Bytes, divididos en parte alta y parte baja. Elidentificador en alto nivel son 32 bits, de los cuales sólo necesitaremos los 12 primeros,pues son los que contienen la información que nos interesa. Por tanto, se separa dichonúmero en dos números de 8 bits cada uno, de manera que los 8 primeros serán laparte baja y los 8 últimos la parte alta.

Número de etiquetas: Ocupa 1Byte e indica la cantidad de consecuentes de una regladifusa.

Lista de etiquetas: Ocupan 3Bytes * n, donde n es el número de etiquetas. De esos3Bytes, el primero indica la posición del actuador en el arreglo donde se almacenaráel valor crisp en caso de activación, y los otros dos restantes, almacenan el centro de

gravedad de la etiqueta, necesario para la obtención del valor nítido a partir del difuso(ver ecuación 3.47).

Por tanto, la cantidad total de memoria que ocupa un nodo gamma será de 9Bytes fijos + 3B* #etiquetas.

RETE

SENSORES

ACTUADORES

Figura 5.12: Estructuras involucradas en RETE de bajo nivel


1 /**2 *3 * @author usuario4 * @param <X> Tipo de elementos contenidos en la cola5 */6 public interface BinaryHeap <X> {7 /**8 * Dice si la cola esta vacia o no.9 *

10 * @return {@code true} is es vacia11 */12 public boolean isEmpty ();

14 /**15 * Inserta el elemento especificado en la cola de

prioridad.16 *17 * @param e Elemento a ñaadir al heap18 * @throws NullPointerException si el elemento

especificado es nulo19 * @throws BinaryHeapException si se intenta anyadir

mas elementos de20 * los que caben21 */22 public void add(X e);

24 /**25 * Elimina el primer elemento de la cola (ímnimo),26 * ajustando el resto de los elementos para cumplir la

propiedad27 * de monticulo.28 *29 * @return Elemento eliminado30 */31 public X remove ();

33 /**34 * Funcion que nos dice el ñtamao de la cola.35 *36 * @return ñTamao del heap37 */38 public int size();

40 /**41 * Funcion que busca la presencia de un elemento en la

cola.42 *43 * @param e Elemento a buscar44 * @return {@code true} si esta el elemento45 */46 public boolean contains(X e);47 @Override public String toString ();48 @Override public boolean equals(Object e);49 }

Listado 5.2: TAD Montículo Binario


Palabras Reservadas

FUNCTION_BLOCK END_FUNCTION_BLOCK FUZZIFYEND_FUZZIFY DEFUZZIFY END_DEFUZZIFYRULEBLOCK END_RULEBLOCK TERMRANGE DEFAULT NCREAL INT ORMAX ASUM BSUMAND MIN PRODBDIF RULE IFTHEN NOT ISSENSOR END_SENSOR ACTUATOREND_ACTUATOR OPTIONS END_OPTIONS

MOWAY_ID

Tabla 5.2: Tabla de Palabras Reservadas

operador OR operador AND

Máximo MínimoSuma algebraica Producto algebraicoSuma limitada T-Norma de Lukasiewicz

Tabla 5.3: Tabla de Pares de algoritmos

CAPÍTULO

6

Conclusiones y Propuestas

E N este capítulo se valorarán las conclusiones obtenidas a través del desarrollo del pre-sente Trabajo Fin de Grado. Se expondrán qué objetivos de los enunciados en el ca-

pítulo 2 han sido cumplidos además de concluir si el mini-robot empleado se ha mostradocomo una buena elección. Por último se propondrán posibles líneas de trabajo futuro quepermitan expandir FUMO más allá de un trabajo de investigación, y siente las bases parapoder crear motores de inferencia adaptables a cualquier tipo de arquitectura.

6.1 Objetivos alcanzadosLa motivación principal por la que surgió el presente proyecto fue comprobar cómo podíamoverse un pequeño artilugio móvil en su entorno de acuerdo a un conocimiento dado en tér-minos imprecisos. Existen numerosas herramientas que permiten modelar sistemas difusos,desde bibliotecas que hacen extensible un lenguaje de programación para permitir su defi-nición, hasta proyectos que incorporan todo lo necesario para modelarlos sin necesidad deposeer amplios conocimientos en programación. Algunas de estas alternativas ya se vieronen el capítulo 2.

Sin embargo, estas alternativas suelen quedarse ahí. Se limitan a simular por software loscambios que se producen en función de su base de conocimiento, la cual no variará pues semantiene estática y no es capaz de interaccionar con su entorno. Por todo esto, se pensó endiseñar el software propuesto. Siempre ha tenido una fuerte componente investigadora, pues,desde el comienzo de su desarrollo, habían muchos interrogantes acerca de qué herramientasutilizar y cómo se iba a abordar el problema de manera que fuese aplicable a un dispositivoreal.

Uno de de los objetivos más destacables fue la necesidad de utilizar un sistema físico sobreel que poder probar el sistema desarrollado. El sistema propuesto es capaz de ejecutarsesobre el dispositivo físico empleado como caso de estudio; sin embargo, los resultados nosiempre son los que caben esperar. Uno de los propósitos de existencia del mOway, según

99

100 CAPÍTULO 6. CONCLUSIONES Y PROPUESTAS

sus desarrolladores, reside en la investigación. Además, su bajo coste unitario sumado a queya está ensamblado y «listo para usar», hizo que se coronase como la mejor opción de todaslas que se barajaron.

Uno de los principales inconvenientes que ha demostrado poseer este mini-robot es una altaimprecisión a la hora de obtener información a través de sus sensores, algo crítico para elbuen funcionamiento del motor de inferencia difuso. En pruebas empíricas realizadas con-juntamente con el director del proyecto, para un mismo objeto sin cambio de posición, losvalores obtenidos sufrían mucha variación, hasta llegar al punto de «no detectarlo» cuandolo tenía a escasos centímetros del frontal. Dada la tremenda variación de resultados obteni-dos fue imposible establecer un patrón de comportamiento para intentar ejecutarlo bajo unascondiciones ideales de uso.

En lo que respecta a la comunicación por radiofrecuencia, en entornos con presencia detecnologías que utilicen la banda ISM 2.4GHz (wifi, bluetooth, etc) puede propiciar la apa-rición de interferencias, lo que puede conllevar a la pérdida de respuesta con el robot. Unaposible solución podría pasar por acoplarle un módulo de expansión wifi; sin embargo, nose ha tenido acceso a él además de haber supuesto una re-implementación de la librería deradiofrecuencia para adaptarla al estándar wifi. Otra solución no muy elegante, ya que restacapacidades al sistema propuesto, pasa por mantener el robot cercano al transmisor usb.

Estos problemas fueron detectados en unas fases tardías del desarrollo del proyecto, impo-sibilitando una posible elección de otro dispositivo de similares característica, por lo que secentró el esfuerzo en obtener los mejores resultados posibles dentro de lo que cabe.

En resumen, el robot es capaz de ser autónomo según su propia toma de decisiones ademásde interaccionar con el computador; sin embargo, debido a los inconvenientes detectados, enmuchas ocasiones el comportamiento que se puede esperar de él resulta impredecible. Estaimpredecibilidad está relacionada con la toma de decisiones de la red, pues la variación delos valores analógicos obtenidos de los sensores fomenta decisiones anómalas, aunque nosiempre se dan.

Otro de los objetivos que se planteaban era la construcción de un lenguaje que facilitasela creación de un sistema difuso. Este objetivo sí ha sido satisfecho completamente, puesFUMO permite a través de un lenguaje descriptivo fuertemente basado en la versión pre-liminar del estándar IEC 1131 definir una base de conocimiento a partir de la cual, inferirresultados. Sin ninguna duda este objetivo ha sido el más importante y complejo de todos,pues de él se desprenden los objetivos de construcción del motor de inferencia a bajo nively depuración del sistema, ambos también conseguidos.

En lo que al lenguaje respecta, se ha prestado especial mimo a la hora establecer las rela-ciones semánticas del mismo, pues desde el primer momento debía re-alimentar al usuariode todos los posibles errores presentes en su definición además de tener que generar una red

CAPÍTULO 6. CONCLUSIONES Y PROPUESTAS 101

óptima en lo que a redundancia de nodos se refiere. Ésto último ha supuesto un verdaderodesafío, pues había que comprobar muchos casos posibles y no debería demorarse en excesotodo el proceso de compilación. Para ganar eficiencia, se hizo uso de sendas tablas hash quealmacenaban las estructuras de nodos parciales ya definidas con el propósito de reducir eltiempo en buscar similitudes entre las reglas.

El desarrollo de bajo nivel de las estructuras necesarias para ejecutar la red. sin duda alguna,ha estado a la altura del caso anterior. En primer lugar, la traducción de los nodos de altonivel a bajo nivel implicaba ser muy meticuloso de qué información es realmente necesariay cual es superflua. Una vez se decidió la información que se utilizaría, había que mandarlaal robot. Para ello, se ha desarrollado una función de alto nivel que particiona la red en pa-quetes de 8Bytes cada una, ya que es el máximo tamaño de trama por envío que admite elmOway. Este aspecto resultó ser crítico, pues la velocidad del microprocesador del compu-tador es mucho más rápida que la del PIC18 del mOway, por la que sincronizar los envíos hasupuesto una ardua tarea. De hecho, esta sincronización no es exhaustiva, y se recomiendaencarecidamente mantener el robot cerca del transmisor usb para que minimizar pérdidas depaquetes y proporcionar la velocidad más alta en el envío.

El siguiente objetivo que se planteó fue garantizar un funcionamiento óptimo en sistemasGNU/Linux. Todo el desarrollo, desde el las tempranas fases de análisis hasta la escritura dela presente documentación se ha llevado a cabo mediante un sistema operativo GNU/Linux,por lo que podemos asegurar que dicho objetivo ha sido cumplido. Además todo el desarrolloha sido realizado mediante el uso de tecnologías libres y multiplataforma (Java, libusb),evitando las llamadas al sistema. La única dependencia clara del sistema operativo es elarchivo Makefile que permite automatizar la compilación de los ficheros .jflex y .cup paragenerar el analizador léxico-sintáctico, que emplea la herramienta make.

El desarrollo de un sistema comunicación por radio-frecuencia también ha sido logrado.Como se ha dicho en el capítulo 2, se partió de una implementación escrita en C++. Éstahacía uso una versión de más bajo nivel de la librería libusb que no se logró que funcionasedel todo bien a la hora de traducirla a Java. Por ello, se empleó la versión 1.0 que proporcionamétodos de mayor abstracción y un mejor resultado. Como se ha visto en el capítulo 5, estemódulo consigue inicializar el transmisor usb y proporciona una serie de procedimientos quepermiten la transimisión de datos entre el robot y el computador.

Por último, la facilidad de uso, premisa presente durante todas las fases de desarrollo, ylos modos de ejecución y depuración, que permiten interaccionar con el mOway y obtenerinformación del estado de sus sensores, actuadores o red, junto el uso de arte ascii para queno resulte demasiado anodino el uso de la aplicación también han sido satisfechos.

En resumen, tanto el objetivo general como los objetivos más específicos desprendidos deéste han sido resueltos satisfactoriamente en su gran mayoría, lo que denota el compromiso


y dedicación tanto del desarrollador del sistema como del director del proyecto.

6.2 Propuestas de trabajo futuroSi bien se han cumplido todos los objetivos propuestos al comienzo del presente Trabajo Finde Grado, aún pueden mejorarse ciertas cosas del sistema realizado así como extender sufuncionalidad. De este modo, algunas propuestas sugeridas que resultarían interesantes deabordar pueden ser las siguientes:

Mejorar el lenguaje FCL. El lenguaje de FUMO es la herramienta sobre la cual giratodo el proyecto, ya que constituye la principal herramienta de interacción del usuariocon el sistema y resulta básica para el desarrollo del motor de inferencia.

Actualmente, se controla duplicidad de variables (i.e, mismo nombre); sin embargo,tal y como se comentó en el capítulo 5, cada variable lleva asociado un sensor o actua-dor del mOway. Ésta duplicidad no se controla, de manera que se podría dar el caso detener dos variables semánticamente idénticas, es decir, dos variables linguisticas cu-yo nombre cambia pero los conjuntos difusos definidos son los mismos. Si en la basede reglas se utilizan ambas variables para definir distintas reglas, se generarán nodosinnecesarios, que si bien al funcionamiento global no afectan, si la base de reglas es ex-tremadamente grande, puede verse relentizado el proceso de obtención de resultados.En esta versión, el usuario asume la responsabilidad de este tipo de situaciones.

Otro de los aspectos a mejorar podría estar relacionado con la información de erroresvertida por FUMO. En la actualidad, los errores muestran la línea y columna dondese han producido además del token que lo ha provocado. Si el error es semántico, enfunción de qué lo ha provocado, además se muestra una breve descripción de qué hapasado. Por ejemplo, si declaramos los puntos de pertenencia en un orden inadecuado,el parser te avisa diciéndote cómo deberían ir. Una posible mejora en este aspectosería intentar mostrar mayor información acerca de errores léxicos y sintácticos, puesde éstos, la información no es tan completa.

Crear nuevas interfaces comunicativas. El sistema ha sido desarrollado para brin-dar un sistema de comunicación por radiofrecuencia con cualquier robot mOway. Sinembargo, no serían compatibles con otros sistemas que empleen el mismo mecanismo,pues está particularizado para funcionar con esta plataforma, ya que no se fijó comorequisito hacerlo genérico. Por ello, lo que se propone es la realización de una interfazque proporcione una serie de métodos básicos (send() y receive(), por ejemplo) quesean particularizados en función del sistema de comunicación a emplear (wifi, blue-

tooth, etc). Por ejemplo, la clase ModuloRF que da acceso al transmisor usb podríaser generalizada fácilmente mediante un archivo de configuración, en el cual se espe-cifiquen una serie de características únicas de cada transmisor como son el PID, VID,mecanismo de transferencia, etc. Este archivo de configuración puede ser o un simple

CAPÍTULO 6. CONCLUSIONES Y PROPUESTAS 103

archivo de texto, o mejor aún, ficheros .xml que establezcan una jerarquía de dependen-cias requeridas para poder usar un sistema de comunicación concreto. De esta manera,se dota a FUMO de mayor flexibilidad y adaptabilidad.

Por otro lado, también sería interesante dotar de mayor capacidad sintáctica o semán-tica al bloque de opciones del lenguaje, de tal manera que permita definir opciones yano sólo de la arquitectura móvil, sino también de diversos aspectos relacionados conel propio lenguaje que se crean convenientes de resaltar. En la actualidad, únicamen-te consta de una palabra reservada que permite seleccionar el identificador empleadopara conectarnos con el robot.

Universalidad. La red generada tras el proceso de compilación es almacenada en unfichero binario .rete que almacena objetos serializados en Java, haciéndolo dependientede dicho lenguaje. Si se quisiese utilizar la red empleando otro lenguaje de programa-ción sería necesario crear una aplicación en Java que traduzca el contenido del ficheroa contenido legible por el otro lenguaje a utilizar. Por ello, en vez de almacenarlos enformato binario, se propone almacenarlos en ficheros .xml, de tal forma que se inde-pendiza del lenguaje. Con esta funcionalidad, prácticamente permitimos poder usar elmotor de inferencias difuso basado en RETE en cualquier lenguaje de programaciónque sea capaz de leer archivos con dicho formato. .xml constituye un lenguaje de mar-cas ampliamente utilizado en la actualidad en distintas disciplinas relacionadas con elalmacenamiento de datos, por lo que aseguraríamos un diseño de futuro.

Exportar RETE a más arquitecturas. FUMO está enfocado para ser completamen-te funcional con los mini-robots mOways. Sin embargo, se ha desarrollado el sistemade modo que pueda independizarse de la arquitectura móvil en cuestión. En efecto,todos los módulos que intervienen en la generación del motor de inferencia son inde-pendientes de la plataforma móvil. Además, las redes RETE pueden ser generadas anivel de Byte, por lo que pueden embeberse en prácticamente cualquier arquitectura(microcontroladores, procesadores móviles, etc).

Por ello, lo que se propone es crear un nuevo módulo que estas redes de bajo niveloptimizadas a distintas arquitecturas ampliamente utilizadas como puede ser Arduino,otra familia PIC, etc.

Crear una interfaz gráfica de usuario. Tal y como se ha justificado en capítulos an-teriores, para el propósito del presente trabajo no se requería porque se pretende queel robot tome decisiones por sí mismo. Sin embargo, si llevan a cabo alguna de lasmejoras aquí expuestas, sí que resultaría más indicado, pues en este caso, FUMO dejade ser una herramienta puramente experimental y empieza a parecer una herramientaque engloba muchas funcionalidades referentes a la creación y uso de motores de in-ferencia.Así con esta interfaz, se podrían agilizar distintos procesos como compilar lared, exportarla a .xml, etc.


Creación de un editor texto enriquecido. Cualquier editor de texto plano sirve pa-ra escribir una base de conocimiento. Sin embargo, para aumentar la productividadse podría desarrollar un editor de texto personalizado que permita muchas de las ca-racterísticas disponibles en los Entornos de Desarrollo Integrados (IDE), como son elresaltado de código, autocompletado, etc.

En definitiva, como se ha podido comprobar, el desarrollo de este proyecto da lugar a variasvías de desarrollo que podrían permitir hacer de FUMO un sistema versátil, multiplataforma,flexible y adaptable a cambios.

ANEXOS

ANEXO

A

Manual de Usuario

E N este anexo se muestran los requisitos previos para poder usar de manera adecuadael sistema desarrollado además de un pequeño manual de usuario que muestra todo

el abanico de opciones proporcionado. Por otra parte, también se muestra una pequeña guíaenfocada a desarrolladores para realizar modificaciones del código.

A.1 InstalaciónTal y como se comentó en el capítulo 2, el desempeño de la aplicación está centrado en siste-mas GNU/Linux. Por tanto, para poder ejecutarla, es necesario tener debidamente instaladasy configuradas las siguientes herramientas:

Java Runtime Environment (JRE), en versión 7 como mínimo.

Fichero de configuración RF-USB. Para poder utilizar el transmisor de radiofrecuen-cia usb, es necesario situar en el directorio /etc/udev/rules.d/ el fichero 99-rfusb.rules.En la figura A.1 se muestra el contenido de dicho fichero. Para obtener el idVendor y elidProduct del dispositivo usb, basta con abrir una terminal, escribir el comando lsusb,y buscar una entrada similar a esta:

Bus zzz Device zzz: ID xxxx:yyyy Microchip Technology, Inc.

Por último, hay que dar permisos de lectura y ejecución con el siguiente comando:chmod +755 99- rfusb.rules

Configuración 99-rfusb.rules

# RFUSB MowayACTION != "add|change", GOTO=" mowayend",SUBSYSTEM =="usb", ATTRS{idVendor }==" xxxx",ATTRS{idProduct }==" yyyy", OWNER ="root",MODE ="0666"LABEL =" mowayend"

107

108 ANEXO A. MANUAL DE USUARIO

Figura A.1: Contenido del ficheroLa aplicación se distribuye como un fichero comprimido .jar, quedando el resto de depen-dencias integradas en el propio archivo.

A.2 Guía de DesarrolloEn esta sección de abordarán aspectos técnicos que sean necesarios para poder realizar mo-dificaciones en el sistema propuesto.

A.3 HerramientasSe necesitan las siguientes herramientas para poder satisfacer todas las dependencias de laaplicación:

JFlex. Se requiere para la construcción del analizador léxico, de modo que los posiblescambios en su fichero de especificación, analex.flex, surtan efecto.

CUP. Se requiere para la construcción del analizador sintáctico y semántico, de modoque para que los cambios en la gramática (AnalizadorSintactico.cup), ya sea en susemántica o en su estructura sintáctica, surtan efecto.

usb4java. Requerida para hacer uso de las llamadas de bajo nivel involucradas en lacreación del adaptador del transmisor de radiofrecuencia usb (MóduloRF.java).

libusb1.0. Generalmente suele venir instalado por defecto en las distribuciones GNU/-Linux. usb4java no es más que un envoltorio de esta herramienta, por lo que es nece-saria para poder compilar el sistema.

UMLGraph.java [Opcional]. Consiste en un plugin para insertar en el javadoc dia-gramas de clases con los que se relacionan cada uno de los módulos. El código seencuentra debidamente documentado mediante su javadoc correspondiente, por lo quees recomendable que cualquier modificación en el mismo siga manteniendo esta ca-racterística.

Configuración del entornoA excepción de la libusb1.0, el resto de dependencias pueden encontrarse incluidas en losarchivos .jar, por lo que únicamente basta con añadir en las propiedades del proyecto, sise está usando un IDE, las rutas absolutas a dichos bibliotecas. En la estructura de direc-torios generada por éstos, se recomienda crear un directorio lib/ que albergue todas estasdependencias.En lo que respecta a la libusb1.0, es muy probable que se encuentre disponible en los repo-sitorios de la distribución, por lo que en ese caso, basta con abrir una terminal y escribir elsiguiente comando:

sudo apt -get install libusb

Si ésta no se encontrase en los repositorios, siempre se puede descargar desde su web yrealizar una instalación manual.

ANEXO A. MANUAL DE USUARIO 109

A.4 CompilaciónVamos a estructurar el proyecto en tres entidades: Lenguaje, Desarrollo Java y Firmware(C).Para modificar la gramática o algún elemento que forme parte de la construcción del lengua-je, se recomienda emplear un editor de texto similar a Sublime Text o emacs. La compilaciónde los programas una vez modificadas se realizan mediante un archivo Makefile, el cual per-mite automatizar todo el proceso ejecutando en una terminal el siguiente comando:

make

Este fichero se encuentra englobado dentro del módulo de procesamiento del lenguaje.En lo que al desarrollo en Java se refiere, se recomienza hacer uso de algún entorno de desa-rrollo integrado (IDE) como puede ser eclipse o NetBeans. El proyecto ha sido codificadoutilizando éste último, el cual emplea para las fases de compilación y construcción la herra-mienta Apache ant.Otra opción sería prescindir de estos entornos y generar un archivo pom.xml para integrarlocon Maven. Ésta al igual que ant, permiten realizar tareas mecánicas y repetitivas, permi-tiendo a su vez establecer todas las dependencias entre los módulos y componentes externos,permitiendo a su vez obtener de su repositorio todas las dependencias (bibliotecas) de lasque hace uso FUMO. La última alternativa radica en una compilación completamente ma-nual mediante el siguiente comando:

javac

si bien no resulta recomendable para compilar proyectos de cierta envergadura como es elpropuesto en este Trabajo Fin de Grado.Por último, para modificar el firmware es casi imprescindible utilizar el IDE provisto porel fabricante del microcontrolador, MPLAB X, ya que además de proveer característicascomunes al resto de IDEs como resaltado de sintaxis o autocompletado de código, facilita lacompilación del fuente y aumenta la productividad.

A.5 Guía de UsuarioEn esta guía se dará una breve explicación acerca de cómo utilizar la aplicación y qué opcio-nes son permitidas.

A.5.1 Ejecutar la aplicaciónAbrir una terminal y situarse en el directorio donde está alojado el .jar que contiene la apli-cación. Una vez situado, ejecutar el siguiente comando:

java -jar MowayTFG .jar

La aplicación es distribuida conjuntamente con una directorio denominado lib/ que contienelas dependencias de la aplicación. Para que la aplicación ejecute es necesario que tanto elempaquetado como sus dependencias se encuentren en el mismo directorio.


Sin embargo, esta alternativa muestra por la misma pantalla tanto mensajes de error comomensajes estándar; para evitar esto, se propone ejecutarlo como sigue:

1. Abrir dos terminales o en una misma terminal dos pestañas.

2. En una de ellas, ejecutar el comando tty. Ésto devolverá el número de terminal asocia-do a ella, con un formato del tipo /dev/pts/N, donde N es un número.

3. Estando en la terminal sobre la que no se ha hecho tty, ejecutamos el siguiente coman-do:

java -jar MowayTFG .jar 2> /dev/pts/N

donde, /dev/pts/N es la otra terminal.

De esta manera, los mensajes de error serán redireccionados a la segunda terminal, dejandola primera sólo para lo mensajes estándar.

A.5.2 Uso de la aplicaciónEn el momento en que se ejecuta el sistema, por la salida estándar se muestran una serie deopciones que se pasan a describir a continuación (cada número se corresponde con la entradaque debe escribir el usuario para seleccionar dicha funcionalidad):

1. Compilar Red. Compila y carga la red en el sistema. El sistema solicitará al usuariolas rutas absolutas donde se de almacenará el archivo binario compilado (.rete), la rutaabsoluta del fichero de texto que contiene el lenguaje, y la ruta absoluta del ficherode texto que contiene la red compilada. Puede ser llamado en cualquier momento, sinembargo, no se recomienda realizar una nueva compilación sin haber cerrado la sesiónanterior con el sistema.

2. Generar gráfico Rete. Se encarga de dibujar la red rete en un fichero con formato.svg. Para ello, el sistema solicitará al usuario la ruta absoluta donde se almacenará elarchivo y el nombre del mismo.

3. Conectar con robot. Establece una conexión radiofrecuencia con el mOway y se man-tiene hasta que se indique lo contrario. Para su conexión, toma de la compilación dellenguaje el Moway_id comentado en el capítulo 5. Si se intenta conectar con el robotsin haber cargado previamente una red, por defecto tiene asignado el identificador 14,por lo que sólo será capaz de conectarse con un robot en cuyo firmware tenga el mismoidentificador asociado.

4. Desconectar con el robot. Intenta finalizar la conexión con el robot. Para ello, elsistema envía la orden al mOway y espera un tiempo limitado (1000 ms) a ver sirecibe contestación (ACK). Sin embargo, si en el entorno hay muchas interferencias ose ha alejado demasiado es muy posible que la conexión se pierda. Por esta razón, seaconseja utilizar directamente la opción Finalizar sesión, pues además de esto, liberatodos los recursos de memoria asociados con el transmisor usb.


5. Inicializar la red (PC). Para su ejecución es necesario a ver compilado y cargadoen el sistema una red además de estar conectados al robot. Básicamente carga la redRETE del lado del computador con valores recogidos del entorno en el que se sitúael mOway. Esta opción resulta útil para poder hacer inferencias partiendo desde unestado en el que se tiene una percepción del entorno real donde se ejecutará.

6. Ejecutar la red (PC). Para su ejecución se requiere una conexión con el robot y haberinicializado la red previamente. Este comando se encarga de hacer las inferencias enel lado del servidor (PC) pasándole los resultados al cliente (PC).

7. Reiniciar la red (PC). Debe haber sido inicializada y existir una conexión con elrobot para poder hacer uso de ella. Básicamente se encarga de eliminar los valoresalmacenados en la red, siendo necesaria una nueva inicialización para poder ser usada.

8. Depuración de sensores/actuadores (PC). Se requiere la inicialización y una cone-xión con el robot para poder hacer uso de ella. Proporciona una salida en arte ascii conlos valores analógicos utilizados en el último proceso de inferencia.

9. Depuración de red (PC). Se requiere la inicialización y una conexión con el robotpara poder hacer uso de ella. A diferencia del caso anterior, este comando nos propor-ciona una salida en arte ascii de todos los valores intermedios almacenados por la reden cada uno de sus nodos.

10. Depuración mixta (PC). Es una combinación de los otros métodos de depuración, demanera que que los requisitos de éstos son extensibles a éste también.

11. Construir red. Se requiere tener una red cargada en el sistema para su uso. Este co-mando «traduce» la red de alto nivel a bajo nivel tal y como se explicó en el capítulo5.

12. Enviar la red. Se requiere de una red de bajo nivel construida y de una conexión conel robot. Este comando se encarga de mandar la red por radiofrecuencia al robot. Te-niendo en cuenta la limitación del tamaño de paquete máximo que aceptan las rutinasde recepción del robot, el envío se puede demorar unos minutos (dependiendo del ta-maño de la red). Con el propósito de mostrar una referencia visual al usuario, mientrasse esté mandando la red, el led superior rojo estará encendido, apagándose en el mo-mento en que se terminan de mandar los últimos Bytes. En ese instante, se enciende elled verde durante 50 ms indicando que el proceso ha sido correcto.

13. Inicializar la red (Robot). Su función es similar a la de alto nivel sólo que aplicada alas estructuras envueltas en el proceso de bajo nivel. Se requiere de una red construiday enviada antes de poder ser ejecutado. Se mantiene a la espera durante 2 segundos conel propósito de darle tiempo al robot de iniciar la red y enviar el ACK de confirmación.Durante ese tiempo, no se atenderán nuevas peticiones, si bien serán tenidas en cuentauna vez transcurrido dicho tiempo.


14. Ejecutar la red (Robot). Se requiere que la red esté construida, haya sido enviada einicializada. Tras esto, el robot es completamente autónomo, pues la inferencia la llevaa cabo él mismo.

15. Reiniciar la red (Robot). Se requiere que la red esté construida, haya sido enviada einicializada. Su funcionamiento es exactamente el mismo que su equivalente de altonivel. Elimina todo el contenido de la red, por lo que se hace necesario un nuevo envíocon la red completa, con su consiguiente inicialización antes de poder ser ejecutada denuevo.

16. Depuración de sensores/actuadores (Robot). Se requiere de una conexión y de unared que haya sido previamente enviada e inicializada. Devuelve un conjunto de datosque son representados en arte ascii que reflejan los valores analógicos utilizados en elúltimo proceso de inferencia.

17. Depuración de red (Robot). Se requiere de una conexión y de una red que haya sidopreviamente enviada e inicializada. Este comando nos proporciona una salida en arteascii de todos los valores intermedios almacenados por la red en cada uno de sus nodos.

18. Depuración mixta (Robot). Es una combinación de los otros métodos de depuración,de manera que que los requisitos de éstos son extensibles a éste también.

19. Encender luz de freno. Sólo requiere una conexión con el mOway. El empleo de estecomando finalizará cualquier modo de ejecución de inferencia difusa y el robot pasa amodo manual, en el sentido de que no hace nada hasta que no lo ordenes algún otrocomando. Su cometido es encender la luz de freno del robot, enviando un ACK deconfirmación al computador.

20. Apagar luz de freno. Sólo requiere una conexión con el mOway. El empleo de estecomando finalizará cualquier modo de ejecución de inferencia difusa y el robot pasaa modo manual, en el sentido de que no hace nada hasta que no lo ordenes algúnotro comando. Su cometido es apagar la luz de freno del robot, enviando un ACK deconfirmación al computador.

21. Encender luz frontal. Sólo requiere una conexión con el mOway. El empleo de estecomando finalizará cualquier modo de ejecución de inferencia difusa y el robot pasaa modo manual, en el sentido de que no hace nada hasta que no lo ordenes algúnotro comando. Su cometido es encender la luz frontal del robot, enviando un ACK deconfirmación al computador.

22. Apagar luz frontal. Sólo requiere una conexión con el mOway. El empleo de estecomando finalizará cualquier modo de ejecución de inferencia difusa y el robot pasaa modo manual, en el sentido de que no hace nada hasta que no lo ordenes algúnotro comando. Su cometido es apagar la luz frontal del robot, enviando un ACK deconfirmación al computador.


23. Encender led rojo. Sólo requiere una conexión con el mOway. El empleo de estecomando finalizará cualquier modo de ejecución de inferencia difusa y el robot pasa amodo manual, en el sentido de que no hace nada hasta que no lo ordenes algún otrocomando. Su cometido es encender el led superior rojo del robot, enviando un ACKde confirmación al computador.

24. Apagar led rojo. Sólo requiere una conexión con el mOway. El empleo de este co-mando finalizará cualquier modo de ejecución de inferencia difusa y el robot pasa amodo manual, en el sentido de que no hace nada hasta que no lo ordenes algún otrocomando. Su cometido es apagar el led superior rojo del robot, enviando un ACK deconfirmación al computador.

25. Encender led verde. Sólo requiere una conexión con el mOway. El empleo de estecomando finalizará cualquier modo de ejecución de inferencia difusa y el robot pasa amodo manual, en el sentido de que no hace nada hasta que no lo ordenes algún otrocomando. Su cometido es encender el led superior verde del robot, enviando un ACKde confirmación al computador.

26. Apagar led verde. Sólo requiere una conexión con el mOway. El empleo de estecomando finalizará cualquier modo de ejecución de inferencia difusa y el robot pasa amodo manual, en el sentido de que no hace nada hasta que no lo ordenes algún otrocomando. Su cometido es apagar el led superior verde del robot, enviando un ACK deconfirmación al computador.

27. Obtener valor de todos los sensores. Sólo requiere una conexión con el mOway. Elempleo de este comando finalizará cualquier modo de ejecución de inferencia difusay el robot pasa a modo manual, en el sentido de que no hace nada hasta que no loordenes algún otro comando. Su cometido es recoger el valor analógico de todos lossensores del robot, siendo mostrados en arte ascii.

28. Encender micrófono. Sólo requiere una conexión con el mOway. El empleo de estecomando finalizará cualquier modo de ejecución de inferencia difusa y el robot pasa amodo manual, en el sentido de que no hace nada hasta que no lo ordenes algún otrocomando. Su cometido es encender el micrófono del robot, por lo que se precisa unvalor entero del rango [0,255] que indice la frecuencia de sonido, enviando un ACKde confirmación al computador.

29. Apagar micrófono. Sólo requiere una conexión con el mOway. El empleo de estecomando finalizará cualquier modo de ejecución de inferencia difusa y el robot pasaa modo manual, en el sentido de que no hace nada hasta que no lo ordenes algúnotro comando. Su cometido es apagar el micrófono del robot, enviando un ACK deconfirmación al computador.

30. Finalizar sesión. Detiene el hilo que se ejecuta en segundo plano, intenta desconectar-


se con el mOway y desinicializa el transmisor usb, liberando toda la memoria asociada.Es recomendable cada vez que se finaliza una sesión, extraer y volver a meter el trans-misor usb para que adquiera una nueva interfaz, por si se quiere ejecutar nuevamenteel sistema.

Todos los comandos aquí descritos muestran mensajes de error en caso de fallo. Por ejemplo,el intentar ejecutar una red de bajo nivel sin haberla enviado antes arrojaría un resultado deerror.Los comandos numerados desde el 5 hasta el 10, ambos inclusive, son los encargados deejecutar ciclos de inferencia manuales, en el sentido que el robot no es completamente autó-nomo, pues se le libera de la carga de ejecutar la inferencia ya que ésta se lleva a cabo en elcomputador.Por otro lado, los comandos numerados desde el 11 hasta el 18, ambos inclusive, son losencargados de ejecutar ciclos de inferencia automáticos, en el sentido de que el robot escompletamente autónomo y sólo precisa del computador para finalizar la conexión.

IEC 1131-7 CD1 - 4 - IEC TC65/WG 7/TF8

Foreword

A New Working Item Proposal (NWIP) has been submitted for standardisation of the programmingmethodology, environment and functional characteristics of Fuzzy Control in the area ofProgrammable Controllers; IEC 65B (U.S.A.) 60, July 1993.

The result of the international voting on the NWIP was the approval and the introduction in the IECwork program under the title preliminary “Fuzzy Control Standardisation“; IEC 65B (Secretariat) 194,February 1994.

Since this emerging technology is being included in today’s Programmable Controllers design thisproject was assigned by the IEC Sub-Committee SC65B (Devices) to its Working Group IEC65B/WG7 (Programmable Controllers); IEC TC65B (Milan), meeting October 1994.

This Comittee Draft (CD 1.0) was elaborated by an international Task Force (TF8) of IEC/65B/WG7 inFrankfurt, Germany, December 6, 1996. It is planned to become Part 7 of the International StandardIEC 1131 “Programmable Controllers“.

Introduction

The theory of Fuzzy Logic in the application of control is named Fuzzy Control. The Fuzzy Control isemerging as a technology that can enhance the capabilities of industrial automation, and is suitablefor control level tasks generally performed in Programmable Controllers (PC).

Fuzzy Control is based upon practical application knowledge represented by so called linguistic rulebases, rather than by analytical (either empirical or theoretical) models. Fuzzy Control can be usedwhen there is an expertise that can be expressed in its formalism. That allows to take opportunity ofavailable knowledge to improve processes and perform a variety of tasks, for instance

- control (closed or open loop, single or multi-variable, for linear or non linear systems)- on-line or off-line setting of control systems’ parameters- classification and pattern recognition- real-time decision making (send this product to machine A or B ?)- helping operators to make decisions or tune parameters- detection and diagnosis of faults in systems

Its wide range of applications and natural approach based on human experience makes FuzzyControl a basic tool that should be made available to Programmable Controller users as a standard.

Fuzzy Control can also in a straightforward way be combined with classical control methods.

The application of Fuzzy Control can be of advantage in such cases where there is no explicitprocess model available, or in which the analytical model is too difficult to evaluate (e.g. multiple inputmultiple output systems) or when the model is too complicated to evaluate it in real time.

Another advantageous feature of Fuzzy Control is, that human experience can be incorporated in astraightforward way. Also it is not necessary to model the whole controller with Fuzzy Control:sometimes Fuzzy Control just interpolates between a series of locally linear models, or dynamicallyadapts the parameters of a "linear controller", thereby rendering it non linear, or alternatively just"zoom in" onto a certain feature of an existing controller that needs to be improved.

Fuzzy Control is a multi-valued Control, no longer restricting the values of a Control proposition to"true" or "false". This makes Fuzzy Control particularly useful to model empirical expertise, stating,which control actions have to be taken under a given set of inputs.

The existing theory and systems already realised in the area of Fuzzy Control differ widely in terms ofterminology (definitions), features (functionalities) and implementation (tools).

The goal of this Standard is to offer the manufactures and the users a well defined commonunderstanding of the basic means to integrate Fuzzy Control applications in the ProgrammableController languages according to Part 3, as well as the possibility to exchange portable FuzzyControl programs among different programming systems.

ANEXO

B

Fuzzy Control Language

115

IEC 1131-7 CD1 - 5 - IEC TC65/WG 7/TF8

To achieve this, Annex A of the Standard gives a short introduction to the theory of Fuzzy Control andFuzzy Control as far as it is necessary for the understanding of the Standard. It may be helpful forreaders of this Standard which are not familiar with Fuzzy Control theory to read the Annex A first.

The standard terminology is defined in clause 3, the integration of Fuzzy Control application into theStandard Languages of Programmable Controllers in clause 4, and a three level set of features withtheir functionality and textual representation in clause 5. This clause 5 defines the syntax and thesemantics of the standardised features in form of the textual Fuzzy Control Language (FCL) using thedefinitions from Part 3 (Programmable Controller Languages) like Data Types and Function Blocks.

Fuzzy Control is used from small and simple applications up to highly sophisticated and complexprojects. To cover all kinds of usage by this Part the features of a compliant Fuzzy Control system aremapped into defined conformance classes described in clause 6.

The Basic Class defines a minimum set of features which has to be achieved by all compliantsystems. This facilitates the exchange of Fuzzy Control programs.

Optional standard features are defined in the Extension Class. Fuzzy Control programs applyingthese features can only be fully ported among systems using the same set of features, otherwise apartial exchange may be possible only. The Standard does not force all compliant systems to realiseall features in the Extension Class, but it supports the possibility of (partial) portability and theavoidance of the usage of non-standard features. Therefore a compliant system should not offer non-standard features which can be meaningfully realised by using standard features of the Basic Classand the Extension Class.

In order not to exclude systems using their own highly sophisticated features from complying with thisStandard and not to hinder the progress of future development, the Standard permits also additionalnon-standard features which are not covered by the Basic Class and the Extension. However, thesefeatures need to be listed in a standard way to ensure that they are easily recognised as non-standard features.

The portability of Fuzzy Control applications depends on the different programming systems and alsothe charcteristics of the control systems. These dependencies are covered by the Data Check List tobe delivered by the manufacturer.

1 Scope

This part of IEC 1131 defines a language for programming of Fuzzy Control applications which useprogrammable controllers.

2 Normative references

The following standard documents contain provisions which, through reference in this text, constituteprovisions of this part of IEC 1131. At the time of publication, the editions indicated below were valid.All such documents are subject to revision. Parties to agreements based on this part of IEC 1131 aretherefore encouraged to apply the current editions of standards. Members of IEC and ISO maintainregisters of current standard documents.

IEC 1-1581-FDIS 1996, International Electrotechnical Vocabulary, clause 351: AutomaticControlIEC 1131 Part 1: 1992, General informationIEC 1131 Part 2: 1992, Equipment requirements and testsIEC 1131 Part 3: 1993, Programming languagesIEC 1131 Technical Report, Guidelines for users and implementers of IEC 1131-3

116 ANEXO B. FUZZY CONTROL LANGUAGE

IEC 1131-7 CD1 - 6 - IEC TC65/WG 7/TF8

3 Definitions

Further definitions for language elements are given in Part 3.

3.1 accumulation [ or result aggregation ]: Combination of results of linguistic rules in a final result.

3.2 aggregation : Calculation of the degree of accomplishment of the condition of a rule.

3.3 activation : The process by which the degree of fulfilment of a condition acts on an output fuzzyset.

NOTE - Also known as composition.

3.4 conclusion: The output of a linguistic rule, i.e. the actions to be taken (the THEN part of anIF..THEN Fuzzy Control rule).

NOTE - Also known as consequent.

3.5 condition : A composition of linguistic terms forming the IF-part of a rule.

3.6 crisp set : A crisp set is a special case of a Fuzzy set, in which the membership function onlytakes two values, commonly defined as 0 and 1.

3.7 defuzzification : Conversion of a Fuzzy set into a numerical value.

3.8 degree of membership : membership function value.

3.9 fuzzification : Conversion of an input value into degrees of membership for the membershipfunctions defined on the variable taking this value.

3.10 Fuzzy Control : A type of control in which the control algorithm is based on Fuzzy Logic (IEV351-07-51 modified)

3.11 Fuzzy Logic : Collection of mathematical theories based on the notion of Fuzzy set. FuzzyControl is a branch of multi-valued Control.

3.12 Fuzzy Control operator : Operator used in Fuzzy Logic theory

3.13 Fuzzy set : A Fuzzy set A is defined as the set of ordered pairs (x,µA(x)), where x is an elementof the universe of discourse U and µA(x) is the membership function, that attributes to each x ∈ U areal number ∈ [0,1], describing the degree to which x belongs to the set.

3.14 inference : Application of linguistic rules on input values in order to generate output values

3.15 linguistic rule : IF-THEN rule with condition and conclusion, one or both at least linguistic.

3.16 linguistic term : In the context of Fuzzy Control linguistic terms are defined by Fuzzy sets

3.17 linguistic variable : Variable that takes values in the range of linguistic terms.

3.18 membership function : A function which expresses in which degree an element of a set belongsto a given Fuzzy subset (see IEV 351-07-52).

NOTE - Also known as antecedent.

3.19 singleton : A singleton is a Fuzzy set whose membership function is equal to one at one pointand equal to zero at all other points.

3.20 rule base : Collection of linguistic rules to attain certain objectives.

3.21 weighting factor : Value between 0..1, that states the degree of importance, credibility,confidence of a linguistic rule.

ANEXO B. FUZZY CONTROL LANGUAGE 117

IEC 1131-7 CD1 - 7 - IEC TC65/WG 7/TF8

4 Integration into the Programmable Controller

The Fuzzy Control applications programmed in Fuzzy Control Language FCL according to clause 5 ofthis Part of the Standard shall be encapsulated in Function Blocks (or Programs) as defined inIEC1131 Part 3, Programming Languages. The concept of Function Block Types and Function BlockInstances given in Part 3 apply to this part.

The Function Block Types defined in Fuzzy Control Language FCL shall specify the input and outputparameters and the Fuzzy Control specific rules and declarations.

The corresponding Functions Block Instances shall contain the specific data of the Fuzzy Controlapplications.

Function Blocks defined in Fuzzy Control Language FCL can be used in Programs and FunctionBlocks written in any of the languages of Part 3, e.g. Ladder Diagram, Instruction List, etc. The datatypes of the input and output parameters of the Function Block or Program written in FCL shall matchthose of the corresponding “calling environment“ as illustrated in Figure 4-1.

Figure 4-1: Example of a Fuzzy Control Function Block in FBD representation

In this example Valve_Control_1 is a user defined Function Block Instance of the Function BlockType Fuzzy_FB. The Function Block Type Fuzzy_FB may be programmed in Fuzzy Control LanguageFCL according to clause 5 of this Part. The Function Block Fuzzy_FB is used here in a program or aFunction Block which is represented in the graphical language FBD (Function Block Diagram) of Part3.

Pressure

Div Fuzzy _FB

T1

Const

Valve_Control_1

ValveTemp

P1

Add

Var1 Valve1

in1

in2out

outin2

in1


IEC 1131-7 CD1 - 8 - IEC TC65/WG 7/TF8

5 Fuzzy Control Language FCL

5.1 Exchange of Fuzzy Control programs

The definition of the Fuzzy Control Language FCL is based on the definitions of the programminglanguages in Part 3. The interaction of the Fuzzy Control algorithm with its program environmentcauses it to be “hidden“ from the program. The Fuzzy Control algorithm is therefore externallyrepresented as a Function Block according to Part 3. The necessary elements for describing theinternal linguistic parts of the Fuzzy Control Function Block like membership functions, rules,operators and methods have to be defined according to clause 5.

The language elements of FCL standardise a common representation for data exchange amongFuzzy Control configuration tools of different manufacturers shown in figure 5.1-1. Using this commonrepresentation every manufacturer of programmable controllers can keep his hardware, softwareeditors and compilers. The manufactuer has only to implement the data interface into his specificeditor. The customer would be able to exchange Fuzzy Control projects between differentmanufacturers.

P rogram m able C ontro lle rm anufac turer A

P rogram m able C ontro lle rm anufac turer B

E d ito r fo r FuzzyC ontro l app lica tion

m anufactu re r A

In te rface FC LIn te rface

E d ito r fo r FuzzyC ontro l app lica tion

m anufactu re r B

In te rface FC LIn te rface

FC L text f ileD ata exchange fo rm at

Figure 5.1-1: Data exchange of Programs in Fuzzy Control Language (FCL)

5.2 Fuzzy Control Language elements

Fuzzy control language elements in this clause are described using examples. The detailedproduction rule is given in clause 5.4.


IEC 1131-7 CD1 - 9 - IEC TC65/WG 7/TF8

5.2.1 Function Block interface

According to clause 4 the external view of the Fuzzy Function Block requires that the followingstandard language elements of Part 3 shall be used:

FUNCTION_BLOCK function_block_name Function block

VAR_INPUT Input parameter declarationvariable_name: data_type;....END_VAR

VAR_OUTPUT Output parameter declarationvariable_name: data_type;....

END_VAR....VAR Local variablesvariable_name: data_type;END_VAREND_FUNCTION_BLOCK

With these language elements it is possible to describe a function block interface. The function blockinterface is defined with parameters which are passed into and out of the function block. The datatypes of these parameters shall be defined according to Part 3.

Figure 5.2.1-1 shows an example for a Function Block declaration in Structured Text (ST) andFunction Block Diagram (FBD) languages.

FUNCTION_BLOCK Fuzzy-FB VAR_INPUT

Temp: REAL;Pressure: REAL;

END_VAR

VAR_OUTPUTValve: REAL;

END_VAR

END_FUNCTION_BLOCK

Fuzzy - FB

Temp

Pressure

Valve

Structured Text (ST) Function Block Diagram (FBD)

Figure 5.2.1-1: Example of a Function Block interface declaration in ST and FBD languages

5.2.2 Fuzzification

The values of the input variables have to be converted into degrees of membership for themembership functions defined on the variable. This conversion is described between the keywordsFUZZIFY and END_FUZZIFY.

FUZZIFY variable_nameTERM term_name := membership_function ;....

END_FUZZIFY

After the keyword FUZZIFY the name of a variable which is used for the fuzzification shall be named.


IEC 1131-7 CD1 - 10 - IEC TC65/WG 7/TF8

This is the name of a previously defined variable in the VAR_INPUT section. This linguistic variableshall be described by one or more linguistic terms. The linguistic terms introduced by the keywordTERM described by membership functions in order to fuzzify the variable. A membership function is apiece-wise linear function. It is defined by a table of points.

membership_function ::= (point i), (point j), ...

Every point is a pair of the values of the variable and the membership degree of that value separatedby a comma. The pairs are enclosed in parentheses and separated by commas.

point i ::= value of input i | variable_name of input i , value i of membership degree

With this definition all simple elements e.g. ramp and triangle can be defined. The points shall begiven in ascending order of variable value. The membership function is linear between successivepoints. The degree of membership for each term is therefore calculated from the crisp input value bythe linear interpolation between the two relevant adjacent membership function points.

The number of points can vary, but its maximum number is restricted according to the clause 6conformance classes.

Example of membership function with 3 points for linguistic term "warm":

TERM warm := (17.5, 0.0), (20.0, 1.0), (22.5, 0.0);

If the value of a linguistic variable is less than the first base point in the look-up table all values belowthe first point in the lookup table shall have the same membership degree as defined at the first point.

If the value of a linguistic variable is greater than the last base point in the lookup table all valuesgreater that the last point in the lookup table shall have the same membership degree as defined atthe last point.

Definition of ramps:

FUZZIFY temp;TERM cold := (3, 1) (27, 0);TERM warm := (3, 0) (27, 1);

END_FUZZIFY 00,

51

0 10 20 30

cold warm

temp

Figure 5.2.2-1: Example of ramp terms

In order to adapt the Fuzzy Control application on-line the base points in the membership functionscan be modified. This can be done using variables which are input to the function block. Thesevariables have to be declared in the VAR_INPUT section of the function block. An example for theuse of variables for the definition of the points the membership functions is given in fig. 5.2.2-2.

NOTE - The values of membership functions points at runtime may be out of sequence.


IEC 1131-7 CD1 - 11 - IEC TC65/WG 7/TF8

VAR_INPUTtemp: REAL; (* this input shall be fuzzified *)pressure: REAL; (* this input shall be fuzzified *)bp_warm1, bp_warm2 : REAL; (* these inputs are for on-line adaptation *)

END_VARFUZZIFY temp

TERM warm := (bp_warm1, 0.0), (21.0, 1.0), (bp_warm2, 0.0);..END_FUZZIFY

Figure 5.2.2-2: Example of usage of variables for membership functions

5.2.3 Defuzzification

A linguistic variable for an output variable has to be converted into a value. This conversion isdescribed between the keywords DEFUZZIFY and END_DEFUZZIFY.

After the keyword DEFUZZIFY the variable which is used for the defuzzification shall be named. Thisis the name of a previous defined variable in the VAR_OUTPUT section.

DEFUZZIFY variable_nameTERM term_name := membership_function ;defuzzification_method ;default_value ;[range ;]

END_DEFUZZIFY

The definition of linguistic terms is given in clause 5.2.2 Fuzzification.

Singletons are special membership functions used for outputs in order to simplify the defuzzification.They are described only by a single value for the linguistic term. In figure 5.2.3-1 examples of termsare given.

Definition of singletons:DEFUZZIFY valve

TERM drainage := -100;TERM closed := 0;

TERM inlet := 100;END_DEFUZZIFY

00,

51

-100 -50 0 50 100

drainage closed inlet

valve

Figure 5.2.3-1: Example of singleton terms

The defuzzification method shall be defined by the language element Method.

METHOD : defuzzification_method ;

The following defuzzification methods are possible.


IEC 1131-7 CD1 - 12 - IEC TC65/WG 7/TF8

Table 5.2.3-1: Defuzzification methods

Keyword ExplanationCOG Centre of Gravity (Note 1)COGS Centre of Gravity for SingletonsCOA Centre of Area (Notes 2 and 3)LM Left Most MaximumRM Right Most MaximumNOTE 1 - Centre of Gravity is equivalent to Centroid of Area

NOTE 2 - Centre of Area is equvalent to Bisector of Area

NOTE 3 - COA is not applicable if singletons are used.

Table 5.2.3-2: Formulae for Defuzzification methods

C O G

C O A

C O G S

R M

LM

Ui

i

=∑

∑

[u

[

i

i=1

p

i=1

p

µ

µ

]

]

U

u M in

M ax

M in

M ax=∫

∫

(u ) du

(u ) du

µ

µ

( ) ( )[ ]

( )U u uu M in M ax

u= =∈

sup ' , ' sup,

µ µ

( ) ( )U u du u du= =∫ ∫ u ' , M in

u '

u '

M ax'

µ µ

( ) ( )[ ]

( )U u uu M in M ax

u= =∈

in f ' , ' su p,

µ µ

where:U : result of defuzzificationu : output variablep : number of singletonsµ : membership function after accumulationi : indexMin : lower limit for defuzzificationMax : upper limit for defuzzificationsup : largest valueinf: smallest value

If the degree of membership is 0 for all linguistic terms of an output variable, that means: no rule forthis variable is active. In that case the defuzzification is not able to generate a valid output. Thereforeit is possible to define a default value for the output. This default value is the value for the outputvariable only in the case when no rule has fired.

DEFAULT := value | NC;

After the keyword DEFAULT the value shall be specified. Otherwise the key word NC (no change)shall be specified to indicate that the output shall remain unchanged if no rule has fired.

The range is a specification of a minimum value and a maximum value separated by two points.

RANGE := (minimum value .. maximum value);


IEC 1131-7 CD1 - 13 - IEC TC65/WG 7/TF8

The range is used for the specification of minimum and maximum values of an output variable. This isnot applicable if singletons are used for output membership functions. In other cases, the RANGE isused for limiting each membership function to the range of each output variable and should bedefined to avoid unpredictable output values.

If there is no range defined the default range shall be the range of the data type of the variablespecified in Part 3.

5.2.4 Rule block

The inference of the fuzzy algorithm shall be defined in one or more rule blocks. For proper handlingand to cater for the possibility of splitting the rule base into different modules, the use of several ruleblocks is possible. Each rule block has a unique name.

Rules shall be defined between the keywords RULEBLOCK and END_RULEBLOCK.

RULEBLOCK ruleblock_name operator_definition ;

[activation_method ;] accumulation_method ; rules ;

END_RULEBLOCK

The Fuzzy operators are used inside the rule block.

operator_definition ::= operator : algorithm

To fulfill de Morgan’s Law, the algorithms for operators AND and OR shall be used pair-wise e.g.MAX shall be used for OR if MIN is used for AND.

Table 5.2.4-1: Paired algorithms

operator OR operator ANDkeyword forAlgorithm

Algorithm keyword forAlgorithm

Algorithm

MAX Max (µ1(x), µ2(x)) MIN Min(µ1(x), µ2(x))ASUM µ1(x)+µ2(x) - µ1(x) µ2(x) PROD µ1(x) µ2(x)BSUM Min(1, µ1(x) + µ2(x)) BDIF Max (0, µ1(x) + µ2(x) -1)

An example of rule blocks:

RULEBLOCK firstAND : MIN;..

END_RULEBLOCKRULEBLOCK second

AND : PROD;..

END_RULEBLOCK

The following language element defines the method of the activation:

ACT : activation_method;

The following activation methods are available:


IEC 1131-7 CD1 - 14 - IEC TC65/WG 7/TF8

Table 5.2.4-2: Activation methods

Name Keyword Algorithm

Product PROD µ1(x) µ2(x)

Minimum MIN Min(µ1(x), µ2 (x))

NOTE -The activation method is not relevant for singelton.

The following language element defines the method of the accumulation.

ACCU : accumulation_method;

The following accumulation_methods are possible:

Table 5.2.4-3: Accumulation methods

Name Keyword FormulaMaximum MAX Max(µ1(x), µ2(x) )Bounded Sum BSUM Min(1, µ1(x) + µ2(x) )

Normalised Sum NSUM µ1(x) + µ2(x )____________Max(1, MAX ( µ1(x’) + µ2(x’) ))

The inputs of a rule block are linguistic variables with a set of linguistic terms. Each term has adegree of membership assigned to it.

Inside the rule block the rules are defined. Each begins with the keyword RULE followed by a namefor the rule and shall be concluded by a semicolon. Each rule has a unique number inside the ruleblock.

RULE numbers : IF condition THEN conclusion [ WITH weighting factor];

The rule itself shall begin with the keyword IF followed by the condition. After the condition theconclusion follows beginning with the keyword THEN.

It is possible to combine several subconditions and input variables in one rule. The purpose ofvariables is to permit fuzzy degrees of membership to be imported into the Fuzzy Function Block. Allof them shall be defined between the kewords IF and THEN and combined by the operators with thekeywords AND, OR or NOT .

The priority of the operator is handled according to boolean algebra given in Table 5.2.4.1.

Table 5.2.4-4: Priority of operators

Priority operator1 ( ) parenthesis2 NOT3 AND4 OR

Simplified example for a rule:

RULE 1 : IF subcondition1 AND variable1 OR variable2 THEN conclusion;

In the Basic Level of conformance the OR operation can be implemented by defining two rules:

RULE 3 : IF subcondition 1 OR subcondition 2 THEN conclusion;replaced by:

RULE 3a : IF condition 1 THEN conclusion;RULE 3b : IF condition 2 THEN conclusion;


IEC 1131-7 CD1 - 15 - IEC TC65/WG 7/TF8

The subcondition begins with the name of a linguistic variable followed by the keyword IS with anoptional NOT and one linguistic term of the linguistic variable used in the condition.

Subcondition := linguistic_variable IS [NOT] linguistic_term

Note: The linguistic terms which are used in the condition shall match the linguistic variable in the same condition. The term

used has to be previously defined with the keyword TERM.

Example of subconditions:

temp IS hottemp IS NOT hot

It is also possible to use the keyword NOT in front of the subcondition. In this case parentheses shallbe used.

IF NOT (temp IS hot) THEN ...

The conclusion can be split into several subconclusions and output variables.

The subconclusion begins with the name of a linguistic variable followed by the keyword IS and onelinguistic term of the given linguistic variable.

Subconclusion := linguisti_ variable IS linguisti_ term

Example with several subconclusions in one or more lines:

IF temp IS cold AND pressure IS low THEN var1, valve1 IS inlet , valve2 IS closed;or In several lines:

IF temp IS cold AND pressure IS lowTHEN var1,

valve1 IS inlet,valve2 IS closed;

Optionally it is possible to give each subconclusion a weighting factor which is a number of data typeREAL with a value between 0.0 and 1.0. This shall be done by the keyword WITH followed by theweighting factor.

The weighting factor shall reduce the membership degree (membership function) of thesubconclusion by multiplication of the result in the subconclusion with the weighting factor.

In order to manipulate the Fuzzy Control application parameters externally the weighting factor can bea variable. In this case the variable has to be declared in the VAR_INPUT section. This enables thepossibility to change the weighting factor during runtime in order to adapt the Fuzzy Conrtol programto process needs.

If there is no WITH statement assigned to the subconclusion a default weighting factor of 1.0 shall beassumed.

IF condition THEN subconclusion [ WITH weighting_factor] subconclusion ;

An example of a constant weighting_factor:

IF temp IS cold AND pressure IS low THEN valve1 IS inlet WITH 0.5,valve2 IS closed;

An example of a variable weighting factor:


IEC 1131-7 CD1 - 16 - IEC TC65/WG 7/TF8

VAR_INPUTw_myrule1 : REAL := 0.8;

END_VARRULEBLOCK temp_rule

RULE 1: IF temp IS cold AND pressure IS lowTHEN valve IS inlet WITH w_myrule1;

..END_RULEBLOCK

5.2.5 Optional parameters

For implementation on different target systems it may be necessary to give additional information tothe system in order to allow the best possible conversion of Fuzzy Control applications.

Such additional information may be required in a language element enclosed by OPTIONS andEND_OPTIONS.

OPTIONSapplication_specific_parameters

END_OPTIONS

These language elements shall be used for features in the conformance class of the open levelaccording clause 6.


IEC 1131-7 CD1 - 17 - IEC TC65/WG 7/TF8

5.3 FCL example

An example in Fuzzy Control Language is given in Figure 5.3-1.

FUNCTION_BLOCK Fuzzy_FBVAR_INPUT

temp : REAL;pressure : REAL;

END_VARVAR_OUTPUT

valve : REAL;END_VARFUZZIFY temp

TERM cold := (3, 1) (27, 0);TERM hot := (3, 0 (27, 1);

END_FUZZIFYFUZZIFY pressure

TERM low := (55, 1) (95, 0);TERM high:= (55, 0) (95, 1);

END_FUZZIFYDEFUZZIFY valve

TERM drainage := -100;TERM closed := 0;TERM inlet := 100;ACCU : MAX;METHOD : COGS;DEFAULT := 0;

END_DEFUZZIFYRULEBLOCK No1

AND : MIN;RULE 1 : IF temp IS cold AND pressure IS low THEN valve IS inletRULE 2 : IF temp IS cold AND pressure IS high THEN valve IS closed WITH 0.8;RULE 3 : IF temp IS hot AND pressure IS low THEN valve IS closed;RULE 4 : IF temp IS hot AND pressure IS high THEN valve IS drainage;

END_RULEBLOCKEND_FUNCTION_BLOCK

Figure 5.3-1: Example for fuzzy function block


IEC 1131-7 CD1 - 18 - IEC TC65/WG 7/TF8

5.4 Production Rules and Keywords of the Fuzzy Control Language (FCL)

Annex A of Part 3 defines the specification method for textual languages for ProgrammableControllers. This specification method is used here for FCL.

Annex B of Part 3 defines the formal specification of language elements for the textual programminglanguages of Part 3. For FCL a subset of the following language elements of Part 3 shall be used:

B.1.1 Letters, digits, identifersB.1.2 ConstantsB.1.3 Data typesB.1.4 Variables

5.4.1 Production Rules

Additionally to the above listed language elements of Part 3 following language elements shall beused:

function_block_declaration ::= ‘FUNCTION_BLOCK‘ function_block_name{fb_io_var_declarations}{other_var_declarations}function_block_body

‘END_FUNCTION_BLOCK’

fb_io_var_declarations ::= input_declarations | output_declarations

other_var_declarations ::= var_declarations

function_block_body ::= {fuzzify_block}{defuzzify_block}{rule_block}{option_block}

fuzzify_block ::= ‘FUZZIFY’ variable_name{linguistic_term}

‘END_FUZZIFY

defuzzify_block ::= ‘DEFUZZIFY’ f_variable_name{linguistic_term}defuzzification_methoddefault_value[range]

‘END_FUZZIFY’

rule_block ::= ‘RULEBLOCK’ rule_block_nameoperator_definition[activation_method]accumulation_method{rule}

‘END_RULEBLOCK’

option_block ::= ‘OPTION’any manufacturere specific parameter

‘END_OPTION’

linguistic_term ::= ‘TERM’ term_name ‘:=‘ membership_function ‘;’

membership_function ::= singleton | points

singleton ::= numeric_literal | variable_name


IEC 1131-7 CD1 - 19 - IEC TC65/WG 7/TF8

points ::= {‘(‘ numeric_literal | variable_name ‘,’ numeric_literal ‘)’}

defuzzification_method ::= ‘METHOD’ ‘:’ ‘COG’ | ‘COGS’ | ‘COA’ | ‘LM’ | ‘RM’ ‘;’

default_value ::= ‘DEFAULT’ ‘:=‘ numeric_literal | ‘NC’ ‘;’

range ::= ‘RANGE’ ‘:=‘ ‘(‘numeric_literal ‘..’ numeric_literal‘)’ ‘;’

operator_definition ::= (‘OR’ ‘:’ ‘MAX’ | ‘ASUM’ | ‘BSUM’) |(‘AND’ ‘:’ ‘MIN’ | ‘PROD’ | ‘BDIF’) ‘;’

activation_method ::= ‘ACT’ ‘:’ ‘PROD’ | ‘MIN’ ‘;’

accumulation_method ::= ‘ACCU’ ‘:’ ‘MAX’ | ‘BSUM’ | ‘NSUM’ ‘;’

rule ::= ‘RULE’ integer_literal ‘:’‘IF’ condition ‘THEN’ conclusion [WITH weighting_factor] ‘;’

condition ::= (subcondition | variable_name) {AND’ | ‘OR’(subcondition | variable_name)}

subcondition ::= (‘NOT’ ‘(‘ variable_name ‘IS’ [‘NOT'] ) term_name ‘)’) |( variable_name ‘IS’ [‘NOT’] term_name )

conclusion ::= { (variable_name | (variable_name ‘IS’ term_name)) ‘,’} (variable_name | variable_name ‘IS’ term_name)

weighting_factor ::= variable | numeric_literal

function_block_name ::= identifier

rule_block_name ::= identifier

term_name ::= identifier

f_variable_name ::= identifier

variable_name ::= identifier

numeric_literal ::= integer_literal | real_literal

input_declarations ::= see IEC 1131-3 Annex B

output_declarations ::= see IEC 1131-3 Annex B

var_declarations ::= see IEC 1131-3 Annex B

identifier ::= see IEC 1131-3 Annex B


IEC 1131-7 CD1 - 20 - IEC TC65/WG 7/TF8

5.4.2 Keywords

Table 5.4.2-1: Reserved keywords

Keyword Meaning Clause( ) Parentheses in condition, term, range 5.2.4

ACCU Accumulation method 5.2.4

ACT Actuation method 5.2.4

AND AND operator 5.2.4

ASUM OR operator, Algebraic sum 5.2.4

BDIF AND operator, Bounded difference 5.2.4

BSUM Accumulation method, Bounded sum 5.2.4

COA Center of area defuzzification method 5.2.3

COG Center of gravity defuzzification method 5.2.3

COGS Center of gravity defuzzification of singletons 5.2.4

DEFAULT Default output value in case no rule has fired 5.2.3

DEFUZZIFY Defuzzification of output variable 5.2.3

END_DEFUZZIFY End of defuzzification specifications 5.2.3

END_FUNCTION_BLOCK End of function block specifications 5.2.1

END_FUZZIFY End of fuzzification specifications 5.2.3

END_OPTIONS End of options specifications 5.2.5

END_RULEBLOCK End of rule block specifications 5.2.4

END_VAR End of input/output variable definitions 5.2.1

FUNCTION_BLOCK End of function block specifications 5.2.1

FUZZIFY Fuzzification of input variable 5.2.2

IF Begin of rule which is followed by the condition 5.2.4

IS Follows linguistic variable in condition and conclusion 5.2.4

LM Left Most Maximun defuzzification method 5.2.3

MAX Maximum accumulation method 5.2.3

METHOD Method of defuzzification 5.2.3

MIN Minimum as AND operator 5.2.4

NC No Change of output variable in case no rule has fired 5.2.3

NOT NOT operator 5.2.4

NSUM Normalised sum accumulation method 5.2.4


IEC 1131-7 CD1 - 21 - IEC TC65/WG 7/TF8

OPTIONS Definition of optional parameters 5.2.5

OR OR operator 5.2.4

PROD Product as AND operator 5.2.4

RANGE Range of variable for scaling of membership function 5.2.3

RM Right Most Maximum defuzzification method 5.2.3

RULE Begin of specification of fuzzy rule 5.2.4

RULEBLOCK Begin of specification of rule block 5.2.4

TERM Definition of a linguistic term (membership function) for a

linguistic variable

5.2.2

THEN Separates condition from conclusion 5.2.4

VAR Definition of local variable (s) 5.2.1

VAR_INPUT Definition of input variable(s) 5.2.1

VAR_OUTPUT Definition of output variable(s) 5.2.1

WITH Definition of weighting factor 5.2.4


IEC 1131-7 CD1 - 22 - IEC TC65/WG 7/TF8

6 Compliance

6.1 Conformance Classes of Fuzzy Control Language FCL

The levels of conformance for Control System using the Fuzzy Control Language (FCL) are shown inFigure 6.1-1. The hierarchy consists of the following three levels:

Basic Level including the definitions of the function block and the data types of Part 3.

Extension level with optional features.

Open Level encompassing additional features.

Figure 6.1-1: Levels of conformance

A Control System using the Fuzzy Control Language FCL claiming to conform with this part of theStandard shall achieve the following rules:

1. It shall be able to use the Function Block features according to Part 3 of this Standard in order torealise the Fuzzy Control functionality. Therefore the definition of the Function Blocks and the DataTypes required for the input and output parameters of the function block shall be in accordancewith Part 3.

2. All features of Fuzzy Control functionality defined in Table 6.1-1 shall be implemented according tothe definitions of this Part. This table defines the set of Basic Level elements which all standardsystems shall have in common.

3. A subset of the Extension Level elements defined in table 6.1-2 are additional elements which canbe implemented optionally. The implementation shall be exactly according to the definitions of thisPart. These features shall be marked as Standard Extensions and a list of realised features inform of Table 6.1-2 shall be part of the system documentation.

4. Further features exceeding the Basic Level and the Extended Level may be realised providedthese features do not have the same or similar functionality or representation of the standardfeatures thereby avoiding any possible confusion. These features shall be marked as Open Levelfeatures and a list in form of Table 6.1-3 shall be part of the system documentation.

5. The exchange of application programs among different Fuzzy Control systems shall be done in thetextual form of the Fuzzy Control Language FCL according to the definitions in this part. This

Extension Level with optional features(see Table 6.1-2)

Open Level with additional features(see Table 6.1-3)

including (IEC 1131-3)Function Block definitionData Type definition

Basic Level with mandatory features(see Table 6.1-1)


IEC 1131-7 CD1 - 23 - IEC TC65/WG 7/TF8

format shall be made available by the standard comformant systems as input and output formats.

6. In order to achieve the most comfortable and suitable user interface and to not hinder futureprogress, the external representations for the design, input, testing etc. of Fuzzy Controlapplication programs can be realised by any graphical or textual means.

The elements in the Table 6.1-1 are the basic set of features, which shall be realised in all standardFuzzy Conrol systems.

Table 6.1-1: FCL Basic Level language elements (mandatory)

Language Element Keyword Detailsfunction block declaration VAR_INPUT,

VAR_OUTPUTcontains input and output variables

membership function input variable:TERM

maximum of three points(degree of membership co-ordinate = 0 or 1)

output variable:TERM

only singletons

conditional aggregation operator: AND algorithm: MINactivation - Not relevant because singletons are used

onlyaccumulation(result aggregation)

operator: ACCU algorithm: MAX

defuzzification METHOD algorithm: COGSdefault

Note - Provisions shall be made to handlethis feature in the Basic Class

condition IF ... IS ... n subconditionsconclusion THEN only one subconclusionweighting factor WITH value only

The elements in the Table 6.1-2 are the extended set of features, which can be optionally realised ina standard Fuzzy Control system (e.g. for the AND operator the algorithm PROD or BDIF or bothmight be chosen).


IEC 1131-7 CD1 - 24 - IEC TC65/WG 7/TF8

Table 6.1-2: FCL Extension Level language elements (optional)

Language Element Keyword Details

function block declaration VAR contains local variables

membership function: inputvariable:TERM

maximum of four points

(degree of membership co-ordinate = 0or 1)

outputvariable:TERM

maximum of four points

(degree of membership co-ordinate = 0or 1)

conditional aggregation operator: AND algorithm: PROD , BDIF

operator: OR algorithm: ASUM , BSUM

operator: NOT 1 - {argument}

parentheses ( )

activation operator: ACT algorithm: MIN, PROD

accumulation operator:ACCU

algorithm: BSUM , NSUM

defuzzification method operator:METHOD

algorithm: COG , COA , LM , RM

default value DEFAULT NC, value

condition IF n subconditions, n input variables

conclusion THEN n subconclusions, n output variables

weighting factor WITH value assigned to variable in thedeclaration part

VAR_INPUT.....END_VAR

The Table 6.1-3 defines an example of a list of language elements in the Open Level. This list shallbe a part of the system documentation.

Table 6.1-3: Examples of List with Open Level language elements

free input/output membership functions (e.g. Gaussian, exponential)more than four membership function pointsdegree of membership co-ordinate values from 0 to 1please dream on .....

6.2 Data check list

This data check list shall be delivered within the technical documentation. In this list a manufacturer ofprogrammable controllers, Fuzzy programming tools and application software shall describe specificperformance features of their Fuzzy Control system. In order to facilitate the transfer of Fuzzy Controlapplications among different manufacturer’s systems the following Data check list is the means ofverifying a possible program transfer.


IEC 1131-7 CD1 - 25 - IEC TC65/WG 7/TF8

Table 6.2-1: Data Check List

Technical data Manufacturer statement (examples)

data types of function block inputs and outputs REAL, INT

line comments in the FCL program YES, NO

length of identifiers (e.g. name of variables, ruleblocks, terms) 6, 8

max. number of input variables for fuzzification 6, 8

max. number of membership function terms per input variable 5, 7

max. total number of membership function terms for all input variables 30, 56

max. number of points for the membership function associated with eachinput variable term

3, 4, 10

max total number of points for membership functions associated with allinput variable terms

90, 224

max. number of output variables for defuzzification 6, 8

max. number of membership function terms per output variable 5, 7

max. total number of membership function terms for all output variables 30, 56

max. number of points for the membership function associated with eachoutput variable term

1, 4, 10

max total number of points for membership functions associated with the alloutput variable terms

90, 224

max. number of rule blocks 1, 10

max. number of rules per block 10

max. number of subconditions per rule 4, 10

max. number of all rules 15

max. number of subconclusions per rule 4

Nesting depth of ( ) 1, 3


〈function block declaration〉 ::= FUNCTION BLOCK 〈function block name〉{〈fb io var declarations〉} 〈function block body〉END FUNCTION BLOCK

〈fb io var declarations〉 ::= 〈input declarations〉 | 〈output declarations〉

〈function block body〉 ::= {〈fuzzify block〉} {〈defuzzify block〉} {〈rule block〉} [〈options block〉]

〈fuzzify block〉 ::= FUZZIFY 〈variable name〉 {〈linguistic term〉} END FUZZIFY

〈defuzzify block〉 ::= DEFUZZIFY 〈f variable name〉 [〈range〉]{〈linguistic term〉} 〈default value〉 END DEFUZZIFY

〈rule block〉 ::= RULEBLOCK 〈rule block name〉〈operator definition〉{〈rule〉} END RULEBLOCK

〈options block〉 ::= OPTIONS 〈config flag〉 ’=’ 〈integer literal〉 END OPTIONS

〈linguistic term〉 ::= TERM 〈variable name〉 ’:=’ 〈membership function〉 ’;’

〈membership function〉 ::= 〈singleton〉 | 〈rectangle〉 | 〈triangular〉 | 〈trapezoidal〉

〈singleton〉 ::= 〈point〉

〈rectangle〉 ::= 〈point〉〈point〉

〈triangular〉 ::= 〈point〉〈point〉〈point〉

〈trapezoidal〉 ::= 〈point〉〈point〉〈point〉〈point〉

〈point〉 ::= ’(’ 〈num〉 ’,’ 〈num〉 ’)’

〈default value〉 ::= DEFAULT ’:=’ 〈num〉 | NC ’;’

〈range〉 ::= RANGE ’:=’ ’(’ 〈num〉 ’..’ 〈num〉 ’)’ ’;’

〈operator definition〉 ::= (OR ’:’ MAX | ASUM | BSUM)| (AND ’:’ MIN | PROD | BDIF) ’;’

〈rule〉 ::= RULE 〈num〉 ’:’ IF 〈condition〉 THEN 〈conclusion〉 ’;’

〈condition〉 ::= 〈subcondition〉 { (AND | OR) 〈subcondition〉 }| [NOT] ’(’ 〈condition〉 ’)’

〈subcondition〉 ::= 〈variable name〉 IS [NOT] 〈term name〉

ANEXO

C

Gramática EBNF

137

〈conclusion〉 ::= (〈variable name〉 IS 〈term name〉)| { ’,’ (〈variable name〉 IS 〈term name〉) }

〈function block name〉 ::= 〈identifier〉

〈rule block name〉 ::= 〈identifier〉

〈term name〉 ::= 〈variable name〉

〈f variable name〉 ::= 〈identifier〉

〈variable name〉 ::= 〈identifier〉

〈input declarations〉 ::= SENSOR 〈var declarations〉 ’;’ { 〈var declarations〉 ’;’ }END SENSOR

〈var declarations〉 ::= 〈variable name〉〈asoc〉 ’:’ 〈type〉

〈type〉 ::= REAL | INT

〈output declarations〉 ::= ACTUATOR 〈var declarations〉 ’;’ { 〈var declarations〉 ’;’ }END ACTUATOR

〈identifier〉 ::= 〈letter〉 {〈letter〉〈digit〉 [’ ’] [’-’] }

〈letter〉 ::= ’A’ | ’B’ | (...) | ’Z’ | ’a’ | ’b’ | (...) | ’z’

〈digit〉 ::= ’0’ | ’1’ | ’2’ | ’3’ | ’4’ | ’5’ | ’6’ | ’7’ | ’8’ | ’9’

〈integer literal〉 ::= 〈digit〉 {〈digit〉}

〈asoc〉 ::= ’(’ 〈moway functions〉 ’)’

〈moway functions〉 ::= 〈moway sensors〉 | 〈moway actuators〉

〈moway sensors〉 ::= SEN LIGHT | SEN BATTERY | SEN TEMP | SEN MIC

| VEL DER | VEL IZQ | MOT ANG | MOT DER | MOT IZQ | OBS IZQ

| OBS CEN I | OBS CEN D | OBS DER | ACCE X | ACCE Y | ACCE Z |LINE IZQ | LINE DER | ∆ SEN LIGHT | ∆ SEN BATTERY | ∆ SEN TEMP

| ∆ SEN MIC | ∆ VEL DER | ∆ VEL IZQ | ∆ MOT ANG | ∆ MOT DER

| ∆ MOT IZQ | ∆ OBS IZQ | ∆ OBS CEN I | ∆ OBS CEN D | ∆ OBS DER

| ∆ ACCE X | ∆ ACCE Y | ∆ ACCE Z | SEN TOUCH | ∆ LINE IZQ |∆ LINE DER

138 ANEXO C. GRAMÁTICA EBNF

〈moway actuators〉 ::= SPEAKER FQ | MOT VEL STR | MOT VEL IZQ

| MOT VEL DER | MOT VEL ROT | MOT ANG | MOT VEL CUR |MOT RAD CUR | ∆ SPEAKER FQ | ∆ MOT VEL STR

| ∆ MOT VEL IZQ | ∆ MOT VEL DER | ∆ MOT VEL ROT

| ∆ MOT ANG | ∆ MOT VEL CUR | ∆ MOT RAD CUR

〈config flag〉 ::= MOWAY ID

〈num〉 ::= ’-’ 〈integer literal〉 | 〈integer literal〉

〈others〉 ::= ’-’ | ’ ’ | ’;’ | ’.’ | ’:’ | ’,’ | ’ˆ’ | ’+’ | ’-’ | ’*’ | ’/’ | ’?’ | ’@’ | ’ !’ | ’&’| ’%’

〈com ml〉 ::= ’/*’ { 〈letter〉 | 〈digit〉 | 〈others〉 } ’*/’

〈com line〉 ::= ’//’ { 〈letter〉 | 〈digit〉 | 〈others〉 }

ANEXO C. GRAMÁTICA EBNF 139

ANEXO

D

Analizador léxico

1 //* –––––––––––––Seccion codigo-usuario ––––––––––––*/2 import java.io.*;3 import java_cup.runtime .*;4 import java.util .*;

6 % %

8 /* -----------------Seccion de opciones y declaraciones-----------------*/

9 /*--OPCIONES --*/10 /* Nombre de la clase generada para el analizadorlexico */

12 %class analex

14 /* Indicar funcionamientoautonomo */

16 %standalone

18 /* Posibilitar acceso a la columna y fila actual deanalisis */

20 %line

22 %column

24 /* Habilitar la compatibilidad con el interfaz CUP para elgenerador ásintctico */

26 %cup

28 /* Tipo de implentacion del analizador lexico Tabla oSwitch */

141

142 ANEXO D. ANALIZADOR LÉXICO

30 %table31 /* %switch */

33 /*--DECLARACIONES --*/

35 %{

37 private TablaPReservadas t = new TablaPReservadas ();38 private boolean error = false;39 private Symbol s;40 private int comentario_anidado = 0, comentario_sincerrar

= 0;

42 private Symbol symbol(int type , Object value) {

44 return new Symbol(type ,yyline ,yycolumn , value);

46 }/* Fin symbol */

48 private Symbol symbol(int type) {

50 return new Symbol(type ,yyline ,yycolumn);

52 }/* Fin symbol */

55 %} /* Fin Declaraciones */

57 %eofval{58 if(comentario_anidado > 0){59 Configuracion.setErroresLexicos("ERROR lexico. No se ha

cerrado un comentario (/*).");60 comentario_anidado = 0;61 return symbol(sym.ERROR);62 }else if(comentario_sincerrar > 0){63 Configuracion.setErroresLexicos("ERROR lexico. Se

intenta cerrar un comentario no abierto (*/).");64 comentario_sincerrar = 0;65 return symbol(sym.ERROR);66 }67 if(error){68 error = false;69 return symbol(sym.ERROR);70 }71 return symbol(sym.EOF);72 %eofval}

ANEXO D. ANALIZADOR LÉXICO 143

74 NL = \n|\r|\r\n75 BLANCO = " "76 TAB = \t

78 %state comlin commul

80 % %81 /* ------------------------Seccion de reglas y acciones

----------------------*/

83 <YYINITIAL > {84 "(" {return symbol(sym.parenizq);}85 ")" {return symbol(sym.parender);}86 ";" {return symbol(sym.puntoycoma);}87 "," {return symbol(sym.coma);}88 "=" {return symbol(sym.igual);}89 ":" {return symbol(sym.dospuntos);}90 ":=" {return symbol(sym.asignacion);}91 "-" {return symbol(sym.menos);}92 ".." {return symbol(sym.puntodoble);}

94 [0-9]+95 {96 if((s=t.buscar(yytext ())) == null)97 return symbol(sym.integer_literal , new

Integer(yytext ()));98 }

100 "//"101 {yybegin(comlin);}

103 "/*"104 {yybegin(commul); comentario_anidado ++;}

106 "*/"107 {comentario_sincerrar ++;}

110 [a-zA-Z][a-zA-Z0 -9_-]*111 {if((s=t.buscar(yytext ())) != null){112 return symbol(s.sym , new String(yytext ()));113 }114 else{115 return symbol(sym.identifier , new

String(yytext ()));}116 }

144 ANEXO D. ANALIZADOR LÉXICO

119 {NL} { /* ignoramos los saltos de ílnea y retornos decarro , contamos lineas */ }

120 {TAB} { /* ignora los tabuladores */ }121 {BLANCO} { /* ignora los espacios en blanco */ }

123 . {Configuracion.setErroresLexicos("ERROR Lexico:"+yytext ()+" linea: "+( yyline +1)+" columna:"+( yycolumn +1));}

125 }/* fin YYinitial */

127 <comlin >{128 [^\n] {}129 \n {yybegin(YYINITIAL);}130 }

132 <commul >{133 [^/*] | [//] | [*] {} /* Importante para evitar que

muestre por pantalla lo que hay entre comentarios */134 "/*" {comentario_anidado ++;}135 "*/" {136 comentario_anidado --;137 if(comentario_anidado == 0)138 yybegin(YYINITIAL);139 }140 }

Listado D.1: Especificación léxica del lenguaje

ANEXO

E

Ejemplo RETE

Este anexo contendrá un ejemplo completo de inferencia de una red RETE, con el propósitode esclarecer cualquier duda que haya podido surgir al lector tras leer la documentación.

E.1 Base de reglasEn el listado E.1 se puede apreciar el conjunto de reglas difusas empleado para codificar elconocimiento del problema, obteniendo la representación gráfica de la figura E.1. La basede conocimiento ha sido realizada sólo para el ejemplo, y lo importante en este punto escomprender el funcionamiento de RETE más que el contenido de las reglas difusas.

1 FUNCTION_BLOCK Programa_Moway_Difuso2 //Declaraciones de variables

4 SENSOR5 ObsI(OBS_IZQ) : INT;6 ObsCI(OBS_CEN_I) : INT;7 ObsCD(OBS_CEN_D) : INT;8 ObsD(OBS_DER) : INT;9 END_SENSOR

11 ACTUATOR12 VelRuedaIzq(MOT_VEL_IZQ): INT;13 VelRuedaDer(MOT_VEL_DER): INT;14 END_ACTUATOR

16 //Construccion de conjuntos difusos

18 FUZZIFY ObsI19 TERM muy_alejado := (0,1) (0,1) (10,1) (15,0);20 TERM alejado := (14 ,0) (20 ,1) (26,0);21 TERM medio := (25 ,0) (50 ,1) (80 ,1) (100 ,0);22 TERM proximo := (95, 0) (120 ,1) (160 ,1) (182, 0);

145

146 ANEXO E. EJEMPLO RETE

23 TERM muy_proximo := (180 ,0) (200 ,1) (255 ,1) (255 ,1);24 END_FUZZIFY

26 FUZZIFY ObsCI27 TERM muy_alejado := (0,1) (0,1) (10,1) (15,0);28 TERM alejado := (14 ,0) (20 ,1) (26,0);29 TERM medio := (25 ,0) (50 ,1) (80,1) (100 ,0);30 TERM proximo := (95, 0) (120 ,1) (160 ,1) (182, 0);31 TERM muy_proximo := (180 ,0) (200 ,1) (255 ,1) (255 ,1);32 END_FUZZIFY

34 FUZZIFY ObsCD35 TERM muy_alejado := (0,1) (0,1) (10,1) (15,0);36 TERM alejado := (14 ,0) (20 ,1) (26,0);37 TERM medio := (25 ,0) (50 ,1) (80,1) (100 ,0);38 TERM proximo := (95, 0) (120 ,1) (160 ,1) (182, 0);39 TERM muy_proximo := (180 ,0) (200 ,1) (255 ,1) (255 ,1);40 END_FUZZIFY

42 FUZZIFY ObsD43 TERM muy_alejado := (0,1) (0,1) (10,1) (15,0);44 TERM alejado := (14 ,0) (20 ,1) (26,0);45 TERM medio := (25 ,0) (50 ,1) (80,1) (100 ,0);46 TERM proximo := (95, 0) (120 ,1) (160 ,1) (182, 0);47 TERM muy_proximo := (180 ,0) (200 ,1) (255 ,1) (255 ,1);48 END_FUZZIFY

50 DEFUZZIFY VelRuedaIzq51 RANGE := (0..1);52 TERM muy_despacio := (0,1) (0,1) (10,1) (14,0);53 TERM despacio := (11 ,0) (16 ,1) (33,0);54 TERM normal := (32 ,0) (43 ,1) (57,0);55 TERM un_poco_rapido := (54 ,0) (61,1) (68,0);56 TERM rapido := (66 ,0) (70 ,1) (77,0);57 TERM muy_rapido := (75 ,0) (80,1) (100 ,1) (100 ,1);58 DEFAULT := 0;59 END_DEFUZZIFY

61 DEFUZZIFY VelRuedaDer62 RANGE := (0..1);63 TERM muy_despacio := (0,1) (0,1) (10,1) (14,0);64 TERM despacio := (11 ,0) (16 ,1) (33,0);65 TERM normal := (32 ,0) (43 ,1) (57,0);66 TERM un_poco_rapido := (54 ,0) (61,1) (68,0);67 TERM rapido := (66 ,0) (70 ,1) (77,0);68 TERM muy_rapido := (75 ,0) (80,1) (100 ,1) (100 ,1);69 DEFAULT := 0;

ANEXO E. EJEMPLO RETE 147

70 END_DEFUZZIFY

72 //Definicion de reglas difusas73 RULEBLOCK BloqueReglas74 AND: MIN;75 RULE 1: IF ObsI IS muy_proximo AND ObsCI IS medio THEN

VelRuedaIzq IS muy_despacio ,76 VelRuedaDer IS despacio;77 RULE 2: IF ObsI IS muy_proximo AND ObsCI IS muy_proximo

THEN VelRuedaIzq IS muy_despacio ,78 VelRuedaDer IS muy_despacio;79 RULE 3: IF ObsI IS proximo AND ObsCI IS alejado THEN

VelRuedaIzq IS despacio ,80 VelRuedaDer IS normal;81 RULE 4: IF ObsD IS muy_alejado AND ObsCD IS muy_alejado

THEN VelRuedaIzq IS muy_rapido ,82 VelRuedaDer IS muy_rapido;83 END_RULEBLOCK

86 END_FUNCTION_BLOCK

Listado E.1: Base de Reglas

E.2 Infiriendo resultadosHay que tener presente que todos los nodos en el momento de su creación valen «0». Segúnla especificación de la base de conocimiento, se hacen uso de los sensores frontales de obs-táculos y de las dos ruedas del mOway. Supongamos que el robot ha hecho una lectura delos sensores y ha obtenido los siguientes datos: 89, 100, 4, 0 para sensor izquierdo, centralizquierdo, central derecho y derecho respectivamente. Cuanto más cercano al 255 más cercaestará el obstáculo.Comenzamos el ciclo de propagación. Todos los nodos alfa cuya variable lingüística estéasociada a cada sensor accederá al dato obtenido del robot acerca de los mismos.

E.2.1 Etapa de fuzzyficaciónConsiste en obtener un valor difuso partiendo de los valores nítidos.OBS_I_muy_proximo = fuzzyficar(89) = 0. Esto significa que el nodo alfa OBS_I_muy_-proximo no ha sido activado, pues hemos obtenido el mismo valor que ya tenía el nodo, ycomo tal no propaga a sus descendientes.OBS_I_proximo = fuzzyficar(89) = 0. Esto significa que el nodo alfa OBS_I_proximo noha sido activado, pues hemos obtenido el mismo valor que ya tenía el nodo, y como tal nopropaga a sus descendientes.OBS_CI_medio = fuzzyficar(100) = 0. Esto significa que el nodo alfa OBS_I_proximo no


RE

TE

_Netw

ork

0

Ob

sI_mu

y_proxim

o

34

R1

R2

Ob

sCI_m

edio

Ob

sCI_m

uy_p

roximo

1

Ob

sI_proxim

o

5R3

Ob

sCI_alejad

o

2

Ob

sD_m

uy_alejad

o

6R4

Ob

sCD

_mu

y_alejado

FiguraE

.1:Motorde

inferenciasde

labase

deconocim

ientos

ANEXO E. EJEMPLO RETE 149

ha sido activado, pues hemos obtenido el mismo valor que ya tenía el nodo, y como tal nopropaga a sus descendientes.OBS_CI_muy_proximo = fuzzyficar(100) = 0. Esto significa que el nodo alfa OBS_CI_-muy_proximo no ha sido activado, pues hemos obtenido el mismo valor que ya tenía elnodo, y como tal no propaga a sus descendientes.OBS_CI_alejado = fuzzyficar(100) = 0. Esto significa que el nodo alfa OBS_CI_alejado noha sido activado, pues hemos obtenido el mismo valor que ya tenía el nodo, y como tal nopropaga a sus descendientes.OBS_D_muy_alejado = fuzzyficar(0) = 1. Esto significa que como el valor anterior es dis-tinto del obtenido, hay que expandir sus sucesores. Sólo tiene un sucesor, que es el nodo betanone no 2, por lo que se inserta en la cola de prioridad con un valor actual de nodo iguala 1. Esto sólo sucede con los beta none, ya que al no tener padre izquierdo, no se puedehacer ninguna operación, por lo que directamente actúan como filtro o pasarela de modo quemodifican su valor por el de su padre.OBS_CD_muy_alejado = fuzzyficar(4) = 1. Esto significa que como el valor anterior esdistinto del obtenido, hay que expandir sus sucesores. Sólo tiene un sucesor, que es el nodobeta and no 6, por lo que se inserta en la cola de prioridad. Este nodo, a diferencia de losnone, sí que pueden operar porque tienen dos padres referenciados, de tal manera que dichaoperación se pospone hasta el momento de expandir los beta (algoritmo de rete).En este punto, podemos concluir que las reglas 1, 2 y 3 no van a ser activadas, porque ningunode sus antecesores ha sido expandido.

Etapa de propagaciónEn este punto se lleva a cabo el algoritmo de rete expuesto en el capítulo 5.Desencolamos el elemento de menor prioridad, que es el nodo beta no 2. Como no podemosoperar con él porque no tiene padre izquierdo, expandimos sus sucesores. Sin embargo, sinos damos cuenta, en la cola de prioridad ya está expandido el único sucesor que tiene, porlo que evitamos hacerlo nuevamente.Como la cola no es vacía, desencolamos el nodo beta no 6 y operamos de acuerdo a lo vistoen el algoritmo:ID = 6;VALP0 = valor(padre_izq) = valor(beta no2) = 1;VALP1 = valor(padre_der) = valor(OBS_CD_muy_alejado) = 1;TEMP = opera(1,1) = min(1,1) = 1;

Como TEMP es distinto del valor almacenado en el beta no6, lo modificamos y expandimossus hijos. En este caso, su único descendiente es un nodo gamma, lo que significa que he-mos llegado al consecuente de la regla y éstos no se introducen para expandir en la cola deprioridad.


Etapa de Obtención de valores crispComo se ha citado en el capítulo 3, se hace uso de un sistema de inferencia TSK de ordencero. Esto, si recordamos, significaba que en el antecedente, los conjuntos difusos seríantratados como conjuntos singletons, cuyo nuevo punto en el dominio vendría dado por laecuación 3.1. Por seguir con el ejemplo, vamos a suponer que el centro de gravedad delnuevo conjunto es de 89.Así, el proceso de obtención de valores crisp vendría dado por la aplicación de la ecuación3.1:

(0 · 0) + (0 · 0) + (0 · 0) + (1 · 89)

0 + 0 + 0 + 1= 89. (E.1)

Como el antecedente de la regla 4 presenta dos conjuntos, el valor pasado a los actuadoresasociados a los consecuentes de dichas reglas será el mismo, es decir 89.De este modo, se ha ejecutado un ciclo de inferencias y se ha activado solamente una regla(R4), lo que implica que la velocidad a la que se ejecutarán las ruedas del robot será de 89.Así se repite una y otra vez este ciclo hasta que decidamos dar por finalizada la sesión conFUMO.

ANEXO

F

mOway Sensores y Actuadores

En este anexo se muestran las palabras reservadas que identifican al conjunto de sensores yactuadores del mOway, así como su precisión. En la gramática EBNF del anexo C apare-cen reflejados de un modo que parecen estructuras sintácticas. Pues bien, son estructurassemánticas, por lo que pueden ser fácilmente modificables cambiando los tipos enumeradosque las definen.Por otra parte, la especificación en el lenguaje FCL de las variables con incrementos sedenota con una letra D_ delante de la variable sin incrementos. Un ejemplo de declaraciónlo podemos apreciar en el listado F.1.

1 /*Sin incrementos */2 SENSOR3 temperatura(SEN_TEMP): INT;4 END_SENSOR

6 /*Con incrementos */7 SENSOR8 temperaturaDelta(D_SEN_TEMP): INT;9 END_SENSOR

Listado F.1: Ejemplo de declaración de variables incrementadas

F.1 SensoresVer Tabla F.1.

F.2 Sensores con incrementosLas variables con incrementos son ampliamente utilizadas en el control de procesos. Suutilidad radica en estimar qué incremento hay que aplicar al valor nominal de una variabledeterminada en un muestreo anterior, es decir, en un ciclo RETE anterior.Como se aprecia en la tabla F.2, básicamente se tratan de los mismos sensores. No hay que

151

152 ANEXO F. MOWAY SENSORES Y ACTUADORES

Mnemotécnico Sensor mOway DominioSEN_LIGHT Sensor de Luz 0 - 100

SEN_BATTERY % de carga de la batería 0 - 100SEN_TEMP Ta en oC No indicado (0-255)SEN_MIC Micrófono 0-255ACCE_X Acelerómetro en X 0-255ACCE_Y Acelerómetro en Y 0-255ACCE_Z Acelerómetro en Z 0-255OBS_IZQ Obstáculo Izquierdo 0-255

OBS_CEN_I Obstáculo Central Izquierdo 0-255OBS_CEN_D Obstáculo Central Derecho 0-255

OBS_DER Obstáculo Derecho 0-255LINE_IZQ Sensor de línea izquierdo 0-255LINE_DER Sensor de línea izquierdo 0-255MOT_ANG Información del Ángulo 0-100VEL_DER Información de velocidad Rueda Derecha 0-100VEL_IZQ Información de velocidad Rueda Izquierda 0-100

MOT_DER Distancia recorrida por motor derecho No indicado (0-255)MOT_IZQ Distancia recorrida por motor izquierdo No indicado (0-255)

Tabla F.1: Lista de asociaciones de sensores

Mnemotécnico Sensor mOway Dominio∆_SEN_LIGHT Sensor de Luz 0 - 100

∆_SEN_BATTERY % de carga de la batería 0 - 100∆_SEN_TEMP Ta en oC No indicado (0-255)∆_SEN_MIC Micrófono 0-255∆_ACCE_X Acelerómetro en X 0-255∆_ACCE_Y Acelerómetro en Y 0-255∆_ACCE_Z Acelerómetro en Z 0-255∆_OBS_IZQ Obstáculo Izquierdo 0-255

∆_OBS_CEN_I Obstáculo Central Izquierdo 0-255∆_OBS_CEN_D Obstáculo Central Derecho 0-255

∆_OBS_DER Obstáculo Derecho 0-255∆_LINE_IZQ Sensor de línea izquierdo 0-255∆_LINE_DER Sensor de línea izquierdo 0-255∆_MOT_ANG Información del Ángulo 0-100∆_VEL_DER Información de velocidad Rueda Derecha 0-100∆_VEL_IZQ Información de velocidad Rueda Izquierda 0-100

∆_MOT_DER Distancia recorrida motor derecho No indicado (0-255)∆_MOT_IZQ Distancia recorrida motor izquierdo No indicado (0-255)

Tabla F.2: Lista de asociaciones de delta sensores

ANEXO F. MOWAY SENSORES Y ACTUADORES 153

olvidar que el motor de inferencia es difuso, por lo que las variables que decidan implementarun delta sensor, será necesario someterlas a una fuzzyficacion. Por tanto, es responsabilidadcompleta del usuario definir unos conjuntos difusos acordes al incremento máximo aplica-ble

F.3 ActuadoresLos actuadores tienen un rango de representación en complemento a2 que oscila entre -100 y100. Con el signo identificaremos el sentido de la marcha (delante, detrás, izq, der) necesariopara ejecutar las funciones propuestas por el fabricante del mOway. Por otro lado, el valorabsoluto numérico indicará cuan rápido debe efectuar la actuación, es decir, la velocidad

para ir en línea recta, trazar una curva, etc.

Mnemotécnico Sensor mOway DominioSPEAKER_FQ Altavoz 0 - 255

MOT_VEL_STR Motores para línea recta -100,100MOT_VEL_IZQ Ajusta vel. rueda izq. -100,100MOT_VEL_DER Ajusta vel. rueda der. -100,100MOT_VEL_ROT Ajusta vel. rotación -100,100

MOT_ANG Ajusta el ángulo de giro -100,100MOT_VEL_CUR Ajusta vel. curva -100,100MOT_RAD_CUR Ajusta radio curva -100,100

Tabla F.3: Lista de asociaciones de actuadores

F.4 Actuadores con incrementosSu función es exactamente igual que con los sensores.

Mnemotécnico Sensor mOway Dominio∆_SPEAKER_FQ Altavoz 0 - 255

∆_MOT_VEL_STR Motores para línea recta -100,100∆_MOT_VEL_IZQ Ajusta vel. rueda izq. -100,100∆_MOT_VEL_DER Ajusta vel. rueda der. -100,100∆_MOT_VEL_ROT Ajusta vel. rotación -100,100

∆_MOT_ANG Ajusta el ángulo de giro -100,100∆_MOT_VEL_CUR Ajusta vel. curva -100,100∆_MOT_RAD_CUR Ajusta radio curva -100,100

Tabla F.4: Lista de asociaciones de delta actuadores

Como se aprecia en la tabla F.2, básicamente se tratan de los mismos sensores. No hay queolvidar que el motor de inferencia es difuso, por lo que las variables que decidan implementarun delta sensor, será necesario someterlas a una fuzzyficacion. Por tanto, es responsabilidad

154 ANEXO F. MOWAY SENSORES Y ACTUADORES

completa del usuario definir unos conjuntos difusos acordes al incremento máximo aplica-ble

ANEXO

G

Código Fuente

Dada la extensión del código fuente, éste se aportará únicamente en versión electrónica, enel CD adjunto a la presente documentación.Su contenido queda definido así:

doc/ En esta carpeta irá la documentación del proyecto en formato .pdf.

exec/ En este directorio irá la aplicación empaquetada junto con sus dependencias, demodo que esté lista para ser usada.

src/ Este directorio recogerá los códigos fuentes desarrollados. Como han sido utili-zados diferentes lenguajes de programación, con el fin de mantener la legibilidad, seestructurará en los siguientes subdirectorios:

1. Firmware/ Albergará el código C con el que se ha desarrollado el firmware delrobot.

2. Java/ Albergará la especificación de alto nivel de la aplicación:

• JavaDoc/ Contendrá la documentación generada relativa al código fuente enformato html.• Cobertura/ Se muestra el análisis de cobertura obtenido tras la ejecución de

los distintos test-case.• src/ Contiene el código de alto nivel estructurado por paquetes.• test/ Contiene las pruebas unitarias encargadas de probar los métodos que

componen que componen la aplicación.

155

ANEXO

H GNU Free Documentation Licen-se

Version 1.3, 3 November 2008Copyright c© 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. <http://fsf.org/>Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PREAMBLEThe purpose of this License is to make a manual, textbook, or other functional and useful document “free” in the sense of freedom: toassure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially.Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsiblefor modifications made by others.This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. Itcomplements the GNU General Public License, which is a copyleft license designed for free software.We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a freeprogram should come with manuals providing the same freedoms that the software does. But this License is not limited to softwaremanuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend thisLicense principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONSThis License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can bedistributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that workunder the conditions stated herein. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee,and is addressed as “you”. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyrightlaw.A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or withmodifications and/or translated into another language.A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship ofthe publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could falldirectly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain anymathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial,philosophical, ethical or political position regarding them.The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice thatsays that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed tobe designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sectionsthen there are none.The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says thatthe Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25words.A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to thegeneral public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels)generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or forautomatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format

157

http://fsf.org/

158 ANEXO H. GNU FREE DOCUMENTATION LICENSE

whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent.An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”.Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format,SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modifi-cation. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be readand edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available,and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material thisLicense requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text nearthe most prominent appearance of the work’s title, preceding the beginning of the body of the text.The “publisher” means any person or entity that distributes copies of the Document to the public.A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parenthesesfollowing text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknow-ledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Documentmeans that it remains a section “Entitled XYZ” according to this definition.The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These WarrantyDisclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implicationthat these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

2. VERBATIM COPYINGYou may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, thecopyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add noother conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or furthercopying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a largeenough number of copies you must also follow the conditions in section 3.You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITYIf you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and theDocument’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts:Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you asthe publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You mayadd other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Documentand satisfy these conditions, can be treated as verbatim copying in other respects.If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on theactual cover, and continue the rest onto adjacent pages.If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readableTransparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the generalnetwork-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, freeof added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies inquantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time youdistribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to givethem a chance to provide you with an updated version of the Document.

4. MODIFICATIONSYou may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that yourelease the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensingdistribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in theModified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions(which should, if there were any, be listed in the History section of the Document). You may use the same title as a previousversion if the original publisher of that version gives permission.

B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the ModifiedVersion, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five),unless they release you from this requirement.

ANEXO H. GNU FREE DOCUMENTATION LICENSE 159

C. State on the Title page the name of the publisher of the Modified Version, as the publisher.

D. Preserve all the copyright notices of the Document.

E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Versionunder the terms of this License, in the form shown in the Addendum below.

G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s licensenotice.

H. Include an unaltered copy of this License.

I. Preserve the section Entitled “History”, Preserve its Title, and add to it an item stating at least the title, year, new authors, andpublisher of the Modified Version as given on the Title Page. If there is no section Entitled “History” in the Document, create onestating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the ModifiedVersion as stated in the previous sentence.

J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, andlikewise the network locations given in the Document for previous versions it was based on. These may be placed in the “History”section. You may omit a network location for a work that was published at least four years before the Document itself, or if theoriginal publisher of the version it refers to gives permission.

K. For any section Entitled “Acknowledgements” or “Dedications”, Preserve the Title of the section, and preserve in the sectionall the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalentare not considered part of the section titles.

M. Delete any section Entitled “Endorsements”. Such a section may not be included in the Modified Version.

N. Do not retitle any existing section to be Entitled “Endorsements” or to conflict in title with any Invariant Section.

O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copiedfrom the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list ofInvariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles.You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by variousparties—for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of astandard.You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end ofthe list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (orthrough arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by youor by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, onexplicit permission from the previous publisher that added the old one.The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert orimply endorsement of any Modified Version. 5. COMBINING DOCUMENTSYou may combine the Document with other documents released under this License, under the terms defined in section 4 above for modifiedversions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and listthem all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a singlecopy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique byadding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Makethe same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled“History”; likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete allsections Entitled “Endorsements”.

5. COLLECTIONS OF DOCUMENTSYou may make a collection consisting of the Document and other documents released under this License, and replace the individual copiesof this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of thisLicense for verbatim copying of each of the documents in all other respects.You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy ofthis License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

160 ANEXO H. GNU FREE DOCUMENTATION LICENSE

6. AGGREGATION WITH INDEPENDENT WORKSA compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storageor distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights of thecompilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does not applyto the other works in the aggregate which are not themselves derivative works of the Document.If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one halfof the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or theelectronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the wholeaggregate.

7. TRANSLATIONTranslation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. ReplacingInvariant Sections with translations requires special permission from their copyright holders, but you may include translations of some orall Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, andall the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version ofthis License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the originalversion of this License or a notice or disclaimer, the original version will prevail.If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section 4) to Preserve its Title(section 1) will typically require changing the actual title.

8. TERMINATIONYou may not copy, modify, sublicense, or distribute the Document except as expressly provided under this License. Any attempt otherwiseto copy, modify, sublicense, or distribute it is void, and will automatically terminate your rights under this License.However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally,unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails tonotify you of the violation by some reasonable means prior to 60 days after the cessation.Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violationby some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyrightholder, and you cure the violation prior to 30 days after your receipt of the notice.Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you underthis License. If your rights have been terminated and not permanently reinstated, receipt of a copy of some or all of the same material doesnot give you any rights to use it.

9. FUTURE REVISIONS OF THIS LICENSEThe Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Suchnew versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Seehttp://www.gnu.org/copyleft/.Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of thisLicense “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version orof any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a versionnumber of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. If the Documentspecifies that a proxy can decide which future versions of this License can be used, that proxy’s public statement of acceptance of a versionpermanently authorizes you to choose that version for the Document.

10. RELICENSING“Massive Multiauthor Collaboration Site” (or “MMC Site”) means any World Wide Web server that publishes copyrightable works andalso provides prominent facilities for anybody to edit those works. A public wiki that anybody can edit is an example of such a server. A“Massive Multiauthor Collaboration” (or “MMC”) contained in the site means any set of copyrightable works thus published on the MMCsite.“CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0 license published by Creative Commons Corporation, a not-for-profit corporation with a principal place of business in San Francisco, California, as well as future copyleft versions of that license publishedby that same organization.“Incorporate” means to publish or republish a Document, in whole or in part, as part of another Document.An MMC is “eligible for relicensing” if it is licensed under this License, and if all works that were first published under this Licensesomewhere other than this MMC, and subsequently incorporated in whole or in part into the MMC, (1) had no cover texts or invariantsections, and (2) were thus incorporated prior to November 1, 2008.

ANEXO H. GNU FREE DOCUMENTATION LICENSE 161

The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before August

1, 2009, provided the MMC is eligible for relicensing.

Referencias

[BB95] George Bojadziev y Maria Bojadziev. Fuzzy sets, fuzzy logic, applications,volume 5. World Scientific, 1995.

[Dat14] Data Structures and Algorithms - 6.2 Heaps, 2014. url: https://www.cs.auckland.ac.nz/~jmor159/PLDS210/heaps.html.

[Doo95] Robert B Doorenbos. Production matching for large learning systems. PhDthesis, University of Southern California, 1995.

[FFUA+99] A Ferreyra, R Fuentes, Depto de Electrónica UAM-Azcapotzalco, Av San Pa-blo, y Col Reynosa Tamaulipas. Estudio comparativo entre control pid y difuso.En SOMI XIII-Congreso de Instrumentación, Ensenda, Mex, 1999.

[GG14] Jose Galindo G. Curso Introductorio de Conjuntos y Sistemas Difusos LógicaDifusa y Aplicaciones, 2014. Universidad de Malaga. url: http://www.lcc.uma.es/~ppgg/FSS/FSS5.pdf.

[Gra14] Graphviz - Graph Visualization Software, 2014. url: http://www.graphviz.org/.

[Ian12] Ion Iancu. A Mamdani type fuzzy logic controller. Fuzzy Logic: Controls,

Concepts, Theories and Applications, InTech Croatia, Rijeka, páginas 55–54,2012.

[Inc05] Microchip Technology Inc. MPLAB C18 C COMPILER USER’S GUIDE,2005.

[Inc09] Microchip Technology Inc. PIC18F87J50 Family Data Sheet, 2009.

[Jag95] Rene Jager. Fuzzy logic in control. Rene Jager, 1995.

[jes14] Rete Algorithm, 2014. url: http://www.jessrules.com/docs/71/rete.html.

[Mat14] Francisco J. Martín Mateos. Implementación del algoritmo RETE,Agosto 2014. url: https://www.cs.us.es/cursos/ia2-2008/trabajos/propuesta-fjmm.html.

163

https://www.cs.auckland.ac.nz/~jmor159/PLDS210/heaps.html

https://www.cs.auckland.ac.nz/~jmor159/PLDS210/heaps.html

http://www.lcc.uma.es/~ppgg/FSS/FSS5.pdf

http://www.lcc.uma.es/~ppgg/FSS/FSS5.pdf

http://www.graphviz.org/

http://www.graphviz.org/

http://www.jessrules.com/docs/71/rete.html

http://www.jessrules.com/docs/71/rete.html

https://www.cs.us.es/cursos/ia2-2008/trabajos/propuesta-fjmm.html

https://www.cs.us.es/cursos/ia2-2008/trabajos/propuesta-fjmm.html

164 REFERENCIAS

[Mor14] Eduardo F. Morales. Rete (red), Agosto 2014. url: http://ccc.inaoep.mx/~emorales/Cursos/Representa/node62.html.

[OV07] Jose Angel Olivas Varela. Logica borrosa y sus aplicaciones. 2007. Universidadde Castilla La Mancha.

[Pér07] Enrique Mandado Pérez. Microcontroladores PIC: sistema integrado para el

autoaprendizaje. Marcombo, 2007.

[RBP02] Timothy J Ross, Jane M Booker, y W Jerry Parkinson. Fuzzy logic and proba-

bility applications: bridging the gap, volume 11. SIAM, 2002.

[RJ00] Marco Russo y Lakhmi C Jain. Fuzzy learning and applications. CRC Press,2000.

[Rob14] Robotica Educativa & Personal, 2014. url: http://ro-botica.com/es/tienda/.

[Rom14] Luis Alonso Romero. Sistemas Expertos, Agosto 2014. url: http://avellano.fis.usal.es/~lalonso/Cursos/SistemasInteligentes/LectureNotes/ssee.pdf.

[Ros09] Timothy J Ross. Fuzzy logic with engineering applications. John Wiley &Sons, 2009.

[San13] Jose Jesus Castro Sanchez. Apuntes de Procesadores de Lenguajes. 2013.

[S.L10] Bizintek Innova S.L. Manuales de Usuario de Moway, 2007-2010.

[US14] Tushar Pradip Upalanchiwar y AV Sakhare. Design and implementation of thefuzzy PID controller using MATLAB/SIMULINK model. IJRCCT, 3(3):369–372, 2014.

[XP214] The Values of Extreme Programming, 2014. url: http://www.extremeprogramming.org/values.html.

[yRC14] Ramón Hermoso y Roberto Centeno. Inteligencia Artificial - Represen-tación del conocimiento, Agosto 2014. url: http://www.ia.urjc.es/cms/sites/default/files/userfiles/file/ia3/2010-11/teoria/tema03 to print%281%29.pdf.

[Zad65] Lotfi A Zadeh. Fuzzy sets. Information and control, 8(3):338–353, 1965.

[Zad73] Lotfi A Zadeh. Outline of a new approach to the analysis of complex systemsand decision processes. Systems, Man and Cybernetics, IEEE Transactions on,(1):28–44, 1973.

http://ccc.inaoep.mx/~emorales/Cursos/Representa/node62.html

http://ccc.inaoep.mx/~emorales/Cursos/Representa/node62.html

http://ro-botica.com/es/tienda/

http://ro-botica.com/es/tienda/

http://avellano.fis.usal.es/~lalonso/Cursos/SistemasInteligentes/LectureNotes/ssee.pdf



http://www.extremeprogramming.org/values.html

http://www.extremeprogramming.org/values.html

http://www.ia.urjc.es/cms/sites/default/files/userfiles/file/ia3/2010-11/teoria/tema03_to_print%281%29.pdf



REFERENCIAS 165

[Zad74] Lotfi A Zadeh. The concept of a linguistic variable and its application to ap-

proximate reasoning - I. Springer, 1974.

[Zad75] Lotfi A Zadeh. The concept of a linguistic variable and its application to ap-proximate reasoningII. Information sciences, 8(4):301–357, 1975.

[ZB02] Jin Zhao y B.K. Bose. Evaluation of membership functions for fuzzy logiccontrolled induction motor drive. En IECON 02 [Industrial Electronics Society,

IEEE 2002 28th Annual Conference of the], volume 1, páginas 229–234, 2002.

Este documento fue editado y tipografiado con LATEXempleando la clase esi-tfg que se puede encontrar en:

https://bitbucket.org/arco group/esi-tfg

[Respeta esta atribución al autor]

https://bitbucket.org/arco_group/esi-tfg