Implementación de observadores de estado para el HRC AUV

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas Facultad de Ingenierı́a Eléctrica Departamento de Automática y Sistemas Computacionales. TRABAJO DE DIPLOMA. Implementación de observadores de estado para el HRC-AUV. Autor: José Carlos La O Trujillo Tutor: Ing. Yeiniel Suárez Sosa. Santa Clara 2014 ”Año 56 de la Revolución”.

(2) Universidad Central “Marta Abreu” de Las Villas Facultad de Ingenierı́a Eléctrica Departamento de Automática y Sistemas Computacionales. TRABAJO DE DIPLOMA Implementación de observadores de estado para el HRC-AUV. Autor: José Carlos La O Trujillo email: jltrujillo@uclv.edu.cu. Tutor: Ing. Yeiniel Suárez Sosa Dpto. de Automática, Facultad de Ing. Eléctrica, UCLV email: yeiniel@uclv.cu. Santa Clara 2014 ”Año 56 de la Revolución”.

(3) Hago constar que el presente TRABAJO DE DIPLOMA fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de estudios de la especialidad de Ingenierı́a en Automática, autorizando a que el mismo sea utilizado por la Institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos, ni publicados sin autorización de la Universidad.. José Carlos La O Trujillo Autor. Fecha. Los abajo firmantes certificamos que el presente trabajo ha sido realizado según acuerdo de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. José Carlos La O Trujillo Autor. Fecha. Boris Luis Martı́nez Jiménez, Dr.C Jefe del Departmento. Fecha. Responsable ICT o J’ de Carrera, (Dr.C., M.Sc. o Ing.) Responsable de Información Cientı́fico-Técnica. Fecha.

(4) PENSAMIENTO. “Per aspera ad astra.” “Por el sendero áspero, a las estrellas.”. Séneca. i.

(5) DEDICATORIA. A mis padres, José y Mabel, por su apoyo en todos estos años y por tomar las decisiones correctas cuando yo no podı́a.. A mi abuela, Xiomara (Abua), por su cariño incondicional y hasta un punto obsesivo.. A mi hermana, Massiel, por hacerme entender lo que representa no estar solo.. A mi amigo, Jorge, por arrastrarme por la carrera y obligarme a concentrarme.. A Mima, Tı́o, Tı́a, Ernesto, Jesús, Maylen, Amanda, que de alguna manera me apoyan desde lejos.. ii.

(6) TAREA TÉCNICA. 1. Revisión bibliográfica para determinar los aspectos teóricos básicos para la implementación de observadores de estado. 2. Análisis de las funcionalidades necesarias para la realización de la implementación. 3. Estudio de la documentación técnica necesaria. 4. Implementación de observadores de estado para el HRC-AUV. 5. Elaboración de la documentación de la implementación a partir de las herramientas y métodos empleados al efecto. 6. Evaluación de la efectividad de la implementación. 7. Redacción del informe de tesis.. José Carlos La O Trujillo Autor Ing. Yeiniel Suárez Sosa Tutor. iii.

(7) RESUMEN. Los Vehı́culos Autónomos Subacuáticos (AUV, Autonomous Underwater Vehicle) son muy utilizados e investigados a nivel mundial debido a sus variadas aplicaciones tanto académicas como productivas. Instituciones de nuestro paı́s han mostrado interés en el tema, llevando a cabo la construcción de un AUV a partir de componentes de bajo costo denominado HRC-AUV. El objetivo de este trabajo es la implementación en C de observadores de estado pasivos, diseñados y simulados con anterioridad, al HRC-AUV como elementos de acondicionamiento de señales, en sustitución al filtrado simple con que cuenta. Los métodos, diseños y herramientas utilizadas están ampliamente referenciados en la literatura, y han sido validadas por décadas en proyectos nacionales e internacionales. Los observadores implementados, de rumbo y de profundidad, fueron probados cumpliendo con los estándares requeridos por el HRC-AUV, arrojando resultados positivos en ambos casos.. iv.

(8) TABLA DE CONTENIDO Página PENSAMIENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. i. DEDICATORIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. ii. TAREA TÉCNICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. iii. RESUMEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. iv. INTRODUCCIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 1. ESTADO DEL ARTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5. 1.1. Antecedentes de los AUVs . . . . . . . . . . . . . . . . . . . . . . . . .. 5. 1.1.1 HRC-AUV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. Observadores de estado . . . . . . . . . . . . . . . . . . . . . . . . . . .. 10. 1.2.1 Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 11. 1.2.2 Acondicionamiento de señales con OE . . . . . . . . . . . . . . .. 13. Algoritmos de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 15. 1.3.1 Observador pasivo de rumbo . . . . . . . . . . . . . . . . . . . .. 15. 1.3.2 Observador pasivo de profundidad . . . . . . . . . . . . . . . . .. 19. Consideraciones finales del capı́tulo . . . . . . . . . . . . . . . . . . . .. 22. MÉTODOS Y HERRAMIENTAS . . . . . . . . . . . . . . . . . . . . . . . . .. 23. 1.2. 1.3. 1.4 2. 2.1. Subrutinas Básicas de Álgebra Lineal (BLAS, Basic Linear Algebra Subprograms) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 23. 2.2. Librerı́a Cientı́fica de GNU (GSL, GNU Scientific Library) . . . . . . .. 24. 2.3. Sistema de Construcción GNU (GNU Build System) . . . . . . . . . . .. 25. 2.3.1 Construcción . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 29. 2.4. Doxygen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 30. 2.5. Lenguaje Unificado de Modelado (UML, Unified Modeling Language) .. 31. 2.6. Consideraciones finales del capı́tulo . . . . . . . . . . . . . . . . . . . .. 32. v.

(9) 3. INGENIERÍA Y RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . .. 33. 3.1. Modelado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 33. 3.2. Portabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 36. 3.2.1 Empaquetado . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 38. 3.3. Documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 38. 3.4. Validación en MATLAB . . . . . . . . . . . . . . . . . . . . . . . . . .. 41. 3.5. Consideraciones finales del capı́tulo . . . . . . . . . . . . . . . . . . . .. 44. CONCLUSIONES Y RECOMENDACIONES . . . . . . . . . . . . . . . . . . . . .. 46. vi.

(10) INTRODUCCIÓN. El medio marino representa una gran fuente de recursos naturales, constituyendo un terreno en su mayorı́a inexplorado debido a su difı́cil acceso, despertando un creciente interés desde hace varias décadas lograr alcanzar dichos recursos. Debido a esto la necesidad de desarrollar herramientas y técnicas que permitan adentrarse cada vez más a este medio. Se desarrollan entonces dos tendencias fundamentales: los Vehı́culos Operados Remotamente (ROV, Remotely Operated Vehicles) que carecen de tripulación pero requieren la constante necesidad de comunicación entre el vehı́culo y la estación de mando; y los Vehı́culos Autónomos Subacuáticos (AUV, Autonomous Underwater Vehicle) que igualmente no requieren de tripulación, presentan gran autonomı́a y son más tolerantes con respecto a la comunicación (Ramos, 2011). Varios centros de investigación y universidades del mundo han mostrado un creciente interés en los AUVs, debido a las ventajas que ofrecen y el mercado que se genera alrededor de ellos. En Cuba su desarrollo todavı́a es escaso, sin embargo el Centro de Investigación y Desarrollo Naval (CIDNAV), se ha propuesto el reto de una implementación nacional de esta tecnologı́a debido a las posibilidades que brindan estos vehı́culos y su especial utilidad en la explotación de los recursos marinos que posee nuestro paı́s. Con el objetivo de llevar a cabo el desarrollo de un sistema de supervisión y control para un prototipo desarrollado por el CIDNAV, que lleva por nombre HRC-AUV, este le presenta una propuesta de colaboración al Grupo de Automatización, Robótica y Percepción (GARP) de la Universidad Central de Las Villas (UCLV), teniendo en cuenta la experiencia del último en materias de teledirección y modelado de vehı́culos. Ası́, se establece un proyecto de colaboración entre ambas partes con el objetivo de desarrollar. 1.

(11) un sistema autopiloto para el HRC-AUV. Con este fin se han desarrollado ya varios trabajos entre los que constan varias tesis de grado y publicaciones mostrando los resultados alcanzados. Debido a la ineficiencia de algunas soluciones para esta aplicación y el alto costo de otras, el GARP se ha dado a la tarea de implementar un Sistema de Navegación Inercial (INS, Inertial Navigation System) el cual requiere el cumplimiento estricto del periodo de muestreo para el buen funcionamiento, ası́ como del sistema de control de forma general. El prototipo existente es una solución que comprende tanto el hardware como el software necesario. En materia de hardware, se emplea una computadora diseñada para uso industrial con arquitectura i586 y compatible con el estándar PC-104, esta se conecta por puerto USB a una Unidad de Mediciones Inerciales (IMU, Inertial Measurement Unit) mientras que por puerto RS-232 se comunica con el Sistema de Control y con el Sistema de Supervisión. Mientras que en materia de software se emplea un programa escrito en lenguaje C que se ejecuta en un ambiente alojado por un sistema operativo GNU/Linux como una aplicación de usuario. Dicho software utiliza como variables primarias las mediciones de la IMU introduciendo errores en la determinación de la posición en el espacio del vehı́culo, actualmente se corrige este error utilizando filtros digitales. Dichos filtros se ajustan tomando en cuenta una frecuencia de corte o discriminación, la cual debe estimarse a partir de un comportamiento previamente definido para el sistema objeto. A partir de aquı́ se propone el desarrollo de una implementación de observadores de estado (OE) previamente diseñados y simulados como elementos de acondicionamiento al software del HRC-AUV en sustitución al filtrado simple. El empleo de observadores de estado en C como elementos de acondicionamiento tiene la ventaja de que se pueden ajustar a variaciones en la dinámica del sistema con mucha mas facilidad que los filtros. Problema cientı́fico: No existe una implementación de observadores de estado en el software del HRC-AUV para atenuar los disturbios externos, la cual puede utilizarse para sustituir al filtrado simple con el que cuenta.. 2.

(12) Objetivo general: Implementar observadores de estado previamente diseñados conceptualmente y simulados matemáticamente para el HRC-AUV como elementos de acondicionamiento de señales. Objetivos especı́ficos: • Realizar una revisión bibliográfica para determinar los antecedentes y aspectos teóricos básicos de los observadores de estados y su implementación. • Definir las herramientas, funcionalidades y métodos a emplear para la implementación de observadores de estado, partiendo del análisis de la documentación técnica especializada. • Implementar en lenguaje C observadores de estados previamente diseñados, que cumplan con los estándares de calidad correspondientes, como un medio para el acondicionamiento de señales. • Comprobar el funcionamiento del módulo de observadores de estado de forma simulada y real, ası́ como de manera online y offline. Con esta investigación se pretende contribuir al desarrollo y mejoramiento del software del GARP para el HRC-AUV mediante la implementación de observadores de estado en C como alternativa al filtrado simple para el acondicionamiento de señales. Dichas mejoras se verán reflejadas en los análisis comparativos de los resultados a partir de los experimentos realizados tanto reales como simulados. La documentación elaborada a partir de este proyecto servirá de pilar para la correcta compresión del funcionamiento del software. El desarrollo de esta implementación dará soluciones a problemáticas modernas vinculadas con el desarrollo de un software de gran complejidad y valor cuya adquisición no es viable actualmente en nuestro paı́s. El informe de la investigación, posterior a esta introducción, se estructurará en tres capı́tulos, conclusiones, recomendaciones y referencias bibliográficas. Capı́tulo 1: Se ofrecerán antecedentes teóricos de esta investigación, el problema a resolver, justificación y los principales aspectos teóricos sobre el desarrollo de observadores de estado en AUVs. 3.

(13) Capı́tulo 2: Se presentarán los métodos utilizados para el desarrollo del proyecto, ası́ como las herramientas de software empleadas. Capı́tulo 3: Se dedicará a la explicación de la ingenierı́a del proyecto, ası́ como a la presentación de los resultados obtenidos con este trabajo mediante simulación. También se realizará un análisis de la efectividad y calidad de la implementación desarrollada.. 4.

(14) CAPÍTULO 1 ESTADO DEL ARTE. 1.1. Antecedentes de los AUVs AUV son vehı́culos no tripulados que navegan de forma autónoma que no se ven. afectados por las limitaciones que presentan los ROV al estar conectados a otro vehı́culo durante el cumplimiento de las misiones. Portan consigo alguna fuente de energı́a operando de manera automática sin presencia humana (Antonelli, 2008). El desarrollo de AUVs se encuentra ampliamente documentado en la literatura cientı́fica, desde sus comienzos y primeros pasos en la década de 1960, donde comenzaron con fines experimentales y académicos para luego extender su uso en exploración del océano, supervisión de tuberı́as, recopilación de datos, mantenimiento de plataformas petrolı́feras, monitoreo de volcanes marinos y otros fines cientı́ficos, industriales y militares; hasta llegar a las más novedosas investigaciones a nivel mundial donde se hacen uso de técnicas avanzadas y modelos matemáticos para representar el movimiento del vehı́culo. Actualmente más de 200 AUVs se encuentran funcionando en el mundo; en la industria petrolera y gası́fera se reconoce que con el empleo de estos vehı́culos se logra reducir los costos hasta en un 30% (Antonelli, 2008). Es por eso que compañı́as comerciales ofertan sistemas de AUV listos para usarse en tareas bien definidas. Muchas universidades y centros de investigación alrededor del mundo han desarrollado numerosas investigaciones y proyectos referentes a los AUVs, generando publicaciones e informes de un alto nivel cientı́fico e ingenieril, algunos de estos centros son: “Universidad Nacional del Sur” (UNS), Argentina (Jordán, 2008); “Universidad de Oporto”, Portugal (Ramos, 2008); “Universidad BEIHANG”, China (Liang, 2008); “Universidad de Zagreb”, 5.

(15) Capı́tulo 1: Estado del Arte. 6. Croacia (Miskovic, 2008); “Universidad de Newcastle”, Australia (Pérez, 2008); ”Universidad de Girona”, España (Palomeras et al., 2006), ”Universidad Nacional Formosa”, Taiwán (Tsay, 2009); “Universidad Noruega de Ciencia y Tecnologı́a” (NTNU) (Fossen, 1994, 2006, 2008);“Instituto de Problemas Tecnológicos Marinos de la Academia Rusa de Ciencias del Lejano Oriente” (IMTP FEB RAS) (Inzartsev, 2008); “Agencia de ciencia y tecnologı́a de tierra y mar”, Japón (Yoshida, 2008). Estas son algunas de las identidades que mantienen un desarrollo paulatino de estas tecnologı́as a nivel mundial, y que han servido de referencia y punto de apoyo a las investigaciones realizadas por el GARP para el HRC-AUV. Actualmente existen varios proyectos que demuestran la diversidad de modelos de AUVs diseñados para tareas especı́ficas, como el Modular Autonomous Robot for Environment Sampling (MARES) desarrollado en Portugal para seguir trayectorias predefinidas y llevar a cabo la recolección de datos relevantes del medio ambiente (Cruz, 2008); el MARIUS, el MARTIN y finalmente el MARIDAN desarrollados por Marine Science and Technology (MAST) y la Programme of the Commission of the European Communities con el objetivo de realizar mediciones medioambientales y la adquisición oceanográfica de datos en aguas costeras, llegando a realizar descubrimientos de embarcaciones hundidas (Gorset, 2010); el Remote Environmental Monitoring Units (REMUS) el cual se diseñó bajo un programa cooperativo que involucraba a la Naval Oceanographic Office, la Office of Naval Research y a la Woods Hole Oceanographic Institution (WHOI) en E.E.U.U para el mapeo del fondo marino, operaciones de búsqueda y rescate y muestreo cientı́fico (Gorset, 2010); el HUGIN desarrollado por Kongsberg Maritime y Forvarets Forskning Institute (FFI) de Noruega diseñado para el mapeo de alta precisión del fondo marino, vigilancia y reconocimiento de minas (Gorset, 2010); el proyecto Cormorán (Ruiz, 2009) que propone el desarrollo de una plataforma de observación oceánica de bajo costo; el MARLIN (Tonge, 2000) desarrollado por BAE Systems para la Defense Evaluation and Research Agency (DERA) en Reino Unido para la evaluación tecnológica subacuática, el R-One utilizado por la Universidad de Tokio con fines cientı́ficos para el estudio y validación de.

(16) Capı́tulo 1: Estado del Arte. 7. estrategias de control (Kim, 2003). Ejemplos de estos vehı́culos se pueden observar en la Figura 1.1.. Figura 1.1 Ejemplos de AUVs. En el desarrollo del trabajo del GARP para el HRC-AUV se han realizado investigaciones sobre modelado y control del vehı́culo (Cañizares, 2010), diseño e implementación del sistema de control (Guerra, 2010), arquitectura de software y hardware (Martinez et al., 2010) (Martı́nez, 2013b), navegación inercial asistida por modelo dinámico (Martı́nez, 2013a), mejoramiento de las prestaciones de la IMU (Garcı́a, 2010), y desarrollo de técnicas de filtrado para la navegación y el control (Garcı́a, 2014); en esta última se abordan los principios y métodos para el diseño e implementación de observadores de estados pasivos, los cuales servirán de punto de partida para la implementación en C de la presente investigación. 1.1.1. HRC-AUV. El HRC-AUV es un vehı́culo con un diseño tubular de 9,5 m de longitud y un peso aproximado de 4100 kg. Presenta una velocidad crucero de 3.1 m/s, está capacitado para.

(17) Capı́tulo 1: Estado del Arte. 8. maniobrar a profundidades de hasta 10 m y cuenta con un propulsor y dos timones de cola (Garcı́a, 2014). La estructura de hardware está compuesta por dos segmentos, uno a bordo del vehı́culo y otro remoto (Martinez et al., 2010). El segmento de hardware a bordo está compuesto por dos unidades de computo y una unidad de suministro de potencia. Las unidades de computo son una PC industrial (PC-104) y un sistema empotrado con un DsPIC 30F4013 que comparten las tareas de adquisición de los datos de los sensores, el control del vehı́culo y la navegación. El segmento remoto es para la supervisión de las maniobras del vehı́culo y esta compuesto por una laptop que ejecuta el software de alto nivel, brindando al operador una interfaz de monitoreo, control y teleoperación del vehı́culo (Rodrı́guez, 2010). En (Ramos, 2011) se detallan los componentes que conforman la arquitectura del HRC-AUV, que es la siguiente: • Unidad de Mediciones Inercial (IMU, Inertial Measurement Unit) MTI-G de Xsens. Sensor inteligente que contiene acelerómetros, magnetómetros y giróscopos en los tres ejes. Esta version del sensor, incluye un receptor GPS que brinda latitud, longitud, altitud y velocidad en los tres ejes. • Cerabar T PMP 133 de Endress+Hauser. Sensor analógico de presión utilizado para determinar la profundidad del AUV. • Actuador lineal eléctrico TLM30 de Tritex. Se encarga del posicionamiento de los timones. Incluye encoders (sensores digitales de posición) para medir la posición de los mismos. • Sensor digital. Emite una secuencia de pulsos cuyo intervalo es proporcional a las revoluciones del motor propulsor. • Sensores digitales. Detectan presencia de agua dentro del casco. • Computadora industrial tipo PC-104. Encargada de la adquisición de las mediciones del sensor MTI-G, además de ejecutar algoritmos de navegación, comunicación y guiado del vehı́culo..

(18) Capı́tulo 1: Estado del Arte. 9. • Hardware empotrado basado en Microchip DsPIC 30F4013. Encargado de la ejecución de los lazos de control de dirección y profundidad además de la adquisición de varios sensores (profundidad, revoluciones del motor, carga de baterı́as y sensores de nivel de agua). • Computadora de supervisión. Encargada de ejecutar el software supervisorio, que constituye la interfaz del sistema con los operadores humanos. El sistema está basado en sensores de bajo costo haciendo su realización mucho más barata en comparación con millonarios proyectos antes mencionados, recayendo un peso especial sobre la calidad y eficiencia del software para el AUV. La arquitectura del hardware se muestra en la Figura 1.2.. Figura 1.2 Arquitectura de hardware del HRC-AUV..

(19) Capı́tulo 1: Estado del Arte 1.2. 10. Observadores de estado Los observadores de estado son herramientas virtuales de control que permiten estimar. las variables o estados de un sistema en base a mediciones de las señales de salida y señales de control. Estos observadores permiten enviar información estimada acerca del valor que toman dichos estados, permitiendo conocer un aproximado del valor real, además cuentan con muy poco margen de diferencia o error al estar diseñados con modelos del sistema (Chi, 1998). Se les considera una herramienta virtual, puesto que se desarrollan como software o programa alojados en un hardware determinado. Existen dos tipos de observadores: observadores de orden completo, utilizados para observar o estimar todos los estados del sistema; y observadores de orden reducido u orden mı́nimo, los cuales estiman solo algunos estados del sistema (Ogata, 1998). En la Figura 1.3 se puede ver el diagrama de bloques de un sistema y su observador donde para:. ẋ = Ax + Bu + Ke (y − ŷ). (1.1). ŷ = Cx. (1.2). Se tiene que: A y B - Matrices que caracterizan la dinámica del sistema. C - Matriz de medición. Ke - Vector de ganancias que permiten la observación de estados. x - Vector de estado. u - Señal de control. y - Señal de salida..

(20) Capı́tulo 1: Estado del Arte. 11. En las técnicas de filtrado basadas en observadores el elemento esencial del diseño es la determinación del vector de ganancias Ke . Este término se multiplica por el error de estimación obtenido para realizar las correcciones necesarias (Garcı́a, 2014).. Figura 1.3 Diagrama de bloques de un sistema y su observador de orden completo. 1.2.1. Aplicaciones Los OE tiene como función básica estimar u observar los estados o variables de. un sistema, gracias a esto ofrecen una gama de aplicaciones numerosas y su uso va en crecimiento. Entre las aplicaciones más importantes figuran las orientadas al control, resultando ser buena estrategia conocer si el sistema en cuestión es observable y/o controlable, ası́ como trazar estrategias de control como en (Miklosovic et al., 2006) en donde se diseñan OE para estimar el disturbio en tiempo real y generar una retroalimentación para cancelarlo. El diseño de sistemas de control en el espacio de estados basados en OE representa un alternativa muy confiable y además ajustable a las necesidades del sistema, pudiendo.

(21) Capı́tulo 1: Estado del Arte. 12. combinarse con otras estrategias de control para optimizar el diseño, como bien se explica en (Ogata, 1998). Una ventaja notable de los OE en el diseño de controladores es que, como en general no son dispositivos fı́sicos sino un software, es posible incrementar la velocidad de respuesta para que el estado observado converja rápidamente hacia el estado actual. Por lo general, la velocidad de respuesta máxima del observador se limita sólo mediante el problema de la sensibilidad y los ruidos implı́citos en el sistema de control. Existen numerosas investigaciones que utilizan los OE en diferentes campos y disciplinas, por ejemplo en (Alessandri and Coletta, 2001) se diseñan observadores para sistemas lineales hı́bridos en tiempo discreto, en donde las condiciones de convergencia son calculadas para asegurar la estabilidad del error dinámico y las ganancias escogidas son seleccionadas resolviendo una serie de inecuaciones matriciales. La aplicación de observadores en reactores se encuentra bien explicada en (Soroush, 1997) donde se prueba analı́ticamente que el error dinámico de los observadores en muchos procesos quı́micos es estable asintóticamente, y varios casos como clásicos reactores quı́micos, reactores de polimerización libre de radicales y bioreactores sirven de ejemplo para ilustrar la aplicación exitosa de la solución con OE, además dicho trabajo presenta el primer observador con una convergencia global analı́ticamente probada para muchos de estos proceso quı́micos. (Lumsdaine and Lang, 1990) es una investigación interesante debido a que se desarrolla una secuencia de complejos observadores, cada uno trabajando con mediciones de voltajes de fase y corriente, para motores de reactancia variable; para todos los observadores los resultados de experimentos fı́sicos como analı́ticos son expuestos en la investigación para demostrar la estabilidad global del error dinámico. La sincronización de sistemas caóticos puede se alcanzada usando técnicas de diseño de OE ampliamente usadas en el control de sistemas dinámicos, en (Morgül and Solak, 1997) se prueba que la sincronización local es posible bajo condiciones relativamente amortiguadas y que la sincronización global se puede alcanzar si el sistema caótico posee estructuras especiales, o puede ser transformado a algunas formas especiales; también se prueba la robustez con respecto a ruidos y.

(22) Capı́tulo 1: Estado del Arte. 13. a parámetros errados y se ofrecen ejemplos de éxito en la implementación de observadores en varios sistemas con este comportamiento. El diseño e implementación de OE en el contexto de los AUVs tı́picamente van dirigidos a la observación o estimación de posición, ángulo, profundidad, velocidad, aceleración entre otros, tal es el caso de (Viegas et al., 2011) (Tsay, 2009) (Jouffroy, 2003) y (Kim et al., 2002), en este último se utilizan observadores no lineales para la estimación de los coeficientes hidrodinámicos de un AUV como alternativa a su obtención experimental, mejorando la exactitud en los resultados obtenidos. Dado la versatilidad de los OE su uso se ha ido generalizando en aplicaciones de diversas ı́ndoles como el acondicionamiento de señales. Las técnicas de filtrado aplicadas en AUVs son muy diversas y abarcan desde los filtros tradicionales (paso bajo y notch) hasta los mas complejos algoritmos basados en OE (Nijmeijer, 1999) usando modelos lineales (Fossen, 2011) como no lineales (Fossen, 1999) como se verá a continuación. 1.2.2. Acondicionamiento de señales con OE. Los observadores de estado han tenido una gran difusión en el filtrado de señales debido a su estructura simple, diseño robusto y solución factible (Garcı́a, 2014); al ser filtros basados en modelos presentan una alta fiabilidad y eficiencia superior a otras soluciones análogas. El principal objetivo de los OE como filtros es realizar una reconstrucción de los componentes de baja frecuencia que no pueden ser medidos, partiendo de una medición ruidosa y contaminada con otros componentes de alta frecuencia (Fossen, 2011). Desde que comenzó su uso a mediados de 1970 se han mejorado las técnicas y métodos de implementación resaltando las contribuciones del profesor Thor I. Fossen en el diseño de observadores y técnicas de control para distintas embarcaciones, muchas de ellas patentadas. Muchos son los autores que han mostrado los resultados de sus investigaciones en el campo de los observadores en el contexto de implementaciones para AUV. Buscando.

(23) Capı́tulo 1: Estado del Arte. 14. alternativas que permitieran realizar estimaciones en maniobras complejas con mayor exactitud y al mismo tiempo filtrar el oleaje, desde el año 1998 hasta la actualidad se han desarrollado diseños más avanzados de observadores pasivos pero empleando modelos no lineales de la planta, resaltando los trabajos (Fossen, 1999) y (Strand, 2001) en los cuales se utiliza la teorı́a de pasividad de Lyapunov para determinar la ganancia de los términos de corrección. La utilización de modelos no lineales y las estrategias de filtrado de las olas a finales de la década de 1990 se abordan de manera amplia en (Nijmeijer, 1999) y en (Strand and Fossen, 1999), apareciendo luego interesantes trabajos y modificaciones en los modelos utilizados. Dentro de las modificaciones se puede mencionar los trabajos (Refness, 2007) y (Snijders, 2005) en donde se diseñan Sistemas de Posicionamiento Dinámico con filtrado del oleaje, basados en modelos horizontales no lineales del vehı́culo y agregando el efecto de las corrientes marinas mediante un término de desviación (offset del movimiento). Otra investigación a mencionar es (Ibaraki et al., 2001) donde se propone resolver el problema de la optimización H∞ de los OE y como ejemplo es aplicado en la corrección del filtrado de señales del control lateral de vehı́culos automáticos tripulados. Además se han empleado las técnicas de gain-scheduled (Torsetness, 2004), y backstepping (Aarset, 2008) que ofrecen un mejor desempeño ante cambios en las condiciones del mar pero presentan fuertes requerimientos de hardware. Algunos de estos observadores de estados han sido implementados en aplicaciones reales por las industrias Asea Brown Boveri (ABB) en Suiza desde hace más de una década y actualmente se encuentran en operación como productos comerciales y patentados (Nijmeijer, 1999) (Fossen, 2009). Una importante investigación dentro del GARP que trata a fondo el filtrado con OE es (Garcı́a, 2014), especı́ficamente con observadores de estado pasivos. Como ya se mencionó con anterioridad dicha investigación será el punto de partida proporcionando el diseño de los OE para su implementación real. Dicho trabajo propone el uso de dos tipos de filtros basados en observadores: uno de rumbo y uno de profundidad; y provee el algoritmo de diseño ası́ como los modelos y artilugios matemáticos necesarios para la implementación..

(24) Capı́tulo 1: Estado del Arte 1.3. 15. Algoritmos de diseño Los algoritmos de diseño de los OE expuestos en (Garcı́a, 2014) están basados en. modelos sencillos y factibles de implementar sin perder de vista los requerimientos necesarios para el control. A continuación se explicará a grandes rasgos dichos algoritmos con el objetivo de una correcta comprensión de las estrategias de implementación adoptadas. 1.3.1. Observador pasivo de rumbo. El modelo del HRC-AUV tomado es el muy utilizado modelo de Nomoto de 1er orden (Nomoto, 1957). Luego del desarrollo correspondiente se tiene en el espacio de estados:.        ψ̇  0 1  ψ   0   = 1    + K  δ 0 − r ṙ T T. (1.3). Donde: ψ es la posición puntual en la rotación de la guiñada. r es la razón de cambio del ángulo de guiñada. δ representa la deflexión del timón de cola o dirección. K es ganancia del modelo. T es la constate de tiempo del modelo. K y T se calculan:. Nδ Nr. (1.4). Nṙ + Izz Nr. (1.5). K=−. T =−.

(25) Capı́tulo 1: Estado del Arte. 16. Nδ y Nr son coeficientes hidrodinámicos e Izz es el momento de inercia alrededor del eje Z. Según (Garcı́a, 2014) los primeros experimentos realizados con el HRC-AUV en el mar demostraron que la respuesta en el rumbo con el sistema de control en lazo abierto exhibe un comportamiento inestable ante variaciones del timón, aspecto que se puede fácilmente corroborar matemáticamente. Por lo tanto, la identificación de los parámetros se realizo experimentalmente en el mar usando una configuración en lazo abierto; para ello se realizaron manualmente variaciones tipo paso en la posición del timón de cola δ que fueron registradas junto con la razón de cambio r en la estación remota (Rodrı́guez, 2010) en lugar del propio ángulo, luego estos valores fueron procesados con la herramienta de identificación de sistemas de MATLAB, obteniéndose (Valeriano-Medina, 2013): K = 0.14. T = 4 seg. Además del modelo dinámico del HRC-AUV es necesario, para ambos observadores, una aproximación lineal de la afectación por las olas debido a que estas son uno de los elementos perturbadores que más afectan a los AUVs y se debe tomar en consideración. El modelo adoptado es (Garcı́a, 2014):. . . . . . . . ˙ 1  ξ   0  ξ  0    +   wo  = 2 ˙ −we −2ζwe ψo ψo Ko ψo. Donde: ξ es la altura de las olas. ψo es la afectación que sufre el rumbo a causa de las olas. we es la frecuencia de encuentro del vehı́culo con las olas. ζ es un coeficiente de amortiguamiento. wo constituye un ruido blanco gaussiano.. (1.6).

(26) Capı́tulo 1: Estado del Arte. 17. Ko se define como: Ko = 2ζwσw. (1.7). Siendo w la frecuencia dominante de las olas y σw una constante ajustable mediante la cual se describe la intensidad de las olas. Ahora, para arribar a la forma en espacio de estados del observador de rumbo se debe agregar un término de corrección a las ecuaciones dinámicas del modelo del HRC-AUV y el modelo de aproximación de las olas, quedando de la siguiente manera:.   ˙ 0 1  ψ̂       r̂˙  0 − 1    T  =  ξˆ˙     0 0    ˙ ψô 0 0 | . 0 0 0 −we2 {z A. . . . . .   0 0 0 K1    ψ̂       K       r̂    0 K2  0    T      δ + + w +       r   ψe   ξˆ    0 K  1    0     3         ˆ ψo Ko K4 −2ζwe 0 | {z } | {z } } | {z } | {z } x̂. . E. B. . (1.8). K. .  ψ̂     r̂    ψ̂ = 1 0 0 1     {z }  ξˆ  |   C ψô. (1.9). Constituyendo un sistema lineal de forma:. e ˙ x̂(t) = A(t)x̂(t) + B(t)δ(t) + E(t)wr (t) + K(t)ψ(t). (1.10). ψ̂(t) = C(t)x̂(t). (1.11). Siendo: ψ̂ y r̂ las estimaciones de baja frecuencia del ángulo de rumbo y su razón de cambio respectivamente..

(27) Capı́tulo 1: Estado del Arte. 18. ψô la estimación del rumbo inducido por las olas. ψe = ψ − ψ̂ − ψô el error cometido en la estimación. wr una entrada de ruido o valor aleatorio generado. Ki (i = 1.., 4) las ganancias del observador las cuales se representan mediante el vector T Kψ = K1 K 2 K 3 K4 y se calcula mediante:. Kψ = L−1 N. (1.12). Con:. . we2 T. we2. 0.   2ζw  e + w2 2ζwe − we2 e  T T L=  1 + 2ζw 1 −we2 T e  1 0 0 .  0  0   1 T  1. p 1 p2 p3 p4   2  −p1 p2 p4 − p1 p2 p3 − p2 p3 p4 − p1 p3 p4 − wTe  N = p p + p p + p p + p p + p p + p p − w 2 −  1 2 2 4 2 3 1 4 1 3 3 4 e  −(p1 + p2 + p3 + p4 + 2ζwe + T1 ). (1.13).       2ζwe  T  . (1.14). Siendo pi (i = 1.., 4) los cuatro parámetros de diseño mediante los cuales se especifican las localizaciones deseadas para los polos que representan la dinámica del error. Los subı́ndices numéricos en la matriz N indican suma o multiplicación de los polos correspondientes. Como se puede apreciar el vector de ganancias se calcula mediante L y N que a la vez dependen de los parámetros K y T del modelo de Nomoto de 1er orden y además de los parámetros ζ y we de la aproximación lineal de las olas. Por lo que los valores de estos parámetros influyen en el ajuste del filtro (Garcı́a, 2014)..

(28) Capı́tulo 1: Estado del Arte. 19. Luego de comprobar la propiedad de observabilidad del sistema se lleva a cabo la sintonización del observador la cual consiste en la selección detallada de los polos deseados, como se explica en (Garcı́a, 2014). Los parámetros del modelo de las olas corresponden a una situación moderada del clima, ζ = 0.1, σ = 0.5 y we = 6 rad y la ubicación de los polos seg , p2 = −10−3 y p3 = p4 = −1.5ζwe (Garcia-Garcia et al., 2012). se escogieron: p1 = − 1.5 T 1.3.2. Observador pasivo de profundidad. El modelo de profundidad para el HRC-AUV se obtiene a partir de las ecuaciones que componen el sistema longitudinal del mismo. Atendiendo a su configuración y tomando en cuenta que varias variables son despreciables o presentan una pequeña desviación se obtiene la siguiente expresión (Garcı́a, 2014):.    −u0 ż  0    θ̇  = 0 0       GBz q̇ 0 − IW yy −Mq̇.     0  z   0       θ  +  0  δE 1          Mq b4 q Iyy −Mq̇ Iyy −Mq̇. Donde: z es la medición de profundidad. θ es el ángulo de cabeceo. δE es el ángulo de deflexión del estabilizador de la cola. u0 es la velocidad de crucero del AUV. q es la velocidad de rotación del eje Y (cabeceo). Iyy es el momento de inercia alrededor del eje Y. Mq es un término lineal de amortiguamiento. b4 es un coeficiente de ganancia del actuador. W es la fuerza de la gravedad ejercida sobre el AUV. BGz es un valor geométrico de distancia con respecto al centro de gravedad.. (1.15).

(29) Capı́tulo 1: Estado del Arte. 20. Como se puede comprobar en (Garcı́a, 2014) todos los parámetros y valores necesarios para el uso del modelo descrito fueron identificados o estimados. Al igual que para el observador de rumbo, para el diseño del observador de profundidad es necesario un modelo de las olas para estimar la afectación de estas con respecto a la profundidad del vehı́culo. Dicho modelo, como se muestra a continuación, es muy similar al tomado para el rumbo, siendo este su homólogo en el eje Z:.        ˙ 1  ξz   0  ξz   0    +   wo  = zo Ko z˙o −we2 −2ζwe. (1.16). Este modelo es el utilizado para representar el movimiento oscilatorio de las olas, ya que en el mismo se abarca tanto la profundidad como el ángulo de cabeceo que son las variables empleadas en las estrategias de control de profundidad diseñadas para el HRC-AUV. Para obtener las ecuaciones del observador de profundidad igualmente se adicionan los términos de corrección correspondientes a las ecuaciones del los modelos antes descritos:.            ẑ 0 K1z 0 −u0 0 0 0 ẑ˙ 0                 ˙        θ̂  0 0         1 0 0   θ̂   0     0 K2z               q̂  + d  δE +  0  wo + K  ze (1.17)  q̂˙  = 0 b c 0 0 1 1 1 3z                       ˆ    ˆ˙       0 0 1  ξz   0  ξz  0 0 0 K4z             2 ˙ 0 0 0 −we −2ζwe zˆ0 0 zˆ0 Ko K5z | {z } | {z } | {z } | {z } | {z } Az. x̂z. Bz. Ez. Kz.

(30) Capı́tulo 1: Estado del Arte. 21   ẑ        θ̂     ẑ = 1 0 0 0 1   q̂   {z }  |  ξˆz  Cz   zˆ0. (1.18). Constituyendo también un sistema lineal:. x̂˙ z (t) = Az (t)x̂z (t) + Bz (t)δE (t) + Ez (t)wo (t) + Kz (t)e z (t). (1.19). ẑ(t) = Cz (t)x̂z (t). (1.20). En el cual: ẑ es la estimación de baja frecuencia de la profundidad. ξˆz y ẑo son las estimaciones de alta frecuencia provocadas por las olas. BGz b1 = − IW yy −Mq̇. c1 =. Mq Iyy −Mq̇. d1 =. b4 Iyy −Mq̇. Para este caso el vector de ganancia Kz =. K1z K2z K3z K4z K5z. T se calcula. igualando los siguientes términos: a0 = −p1z,2z,3z,4z,5z. (1.21). a1 = p2z,3z,4z,5z + p1z,3z,4z,5z + p1z,2z,4z,5z + p1z,2z,3z,5z + p1z,2z,3z,4z. (1.22). a2 = −p3z,4z,5z −p2z,4z,5z −p2z,3z,5z −p2z,3z,4z −p1z,4z,5z −p1z,3z,5z −p1z,3z,4z −p1z,2z,5z −p1z,2z,4z −p1z,2z,3z (1.23) a3 = p4z,5z + p3z,5z + p3z,4z + p2z,5z + p2z,4z + p2z,3z + p1z,5z + p1z,4z + p1z,3z + p1z,2z (1.24) a4 = −p1z − p2z − p3z − p4z − p5z. (1.25).

(31) Capı́tulo 1: Estado del Arte. 22. Siendo piz (i = 1.., 5) los cinco parámetros de diseño mediante los cuales se especifican las localizaciones deseadas para los polos que representan la dinámica del error de profundidad. En estas expresiones los subı́ndices numéricos separados por coma indican multiplicación de los polos correspondientes. La sintonización del modelo se realizó experimentalmente debido a la pobreza en la literatura respecto a este método para filtrar profundidad, arrojando valores de los polos p1 = −10−3 , p2 = p3 = −0.01 y p4 = p5 = −1.5. Para el modelo de las olas la decisión lógica serı́a tomar los mismo parámetros que para el observador de rumbo descrito anteriormente. 1.4. Consideraciones finales del capı́tulo El tema de los AUVs y los OE está ampliamente difundido y documentado, tanto. a través de investigaciones nacionales como internacionales, mostrando la increı́ble aplicabilidad, versatilidad y necesidad del desarrollo sin altos costos de un AUV de carácter nacional. No es el caso de las implementaciones en C de OE las cuales solo se mencionan a la ligera en la literatura, careciendo de una explicación formal y detallada de los métodos y herramientas a emplear. El diseño a tomar para el desarrollo de la implementación de este trabajo es el exhibido en (Garcı́a, 2014), simulado y validado con anterioridad en dicho trabajo, los cuales muestran una correcta funcionalidad sin perder simpleza y eficacia. Es necesario aclarar que el objetivo de esta investigación no va dirigido a la optimización, modificación o comparación del diseño tomado, sino ponerlo en uso a través de una implementación real, llevando a cabo experimentos de varias ı́ndoles y documentando tanto los resultados como la implementación en sı́..

(32) CAPÍTULO 2 MÉTODOS Y HERRAMIENTAS. La implementación de observadores de estado de la presente investigación se pondrá en funcionamiento sobre un sistema operativo GNU/Linux, por lo que gran parte de su desarrollo cumplirá con varios estándares y directrices mantenidas por la comunidad del software libre (Free Software) y la comunidad del código abierto (Open Source). En el presente capitulo se abordarán los métodos, herramientas, rutinas y librerı́as que se utilizaron para la realización de la implementación. 2.1. Subrutinas Básicas de Álgebra Lineal (BLAS, Basic Linear Algebra Subprograms) Las BLAS son una serie de rutinas organizadas en tres niveles con el objetivo de. proveer implementaciones eficientes, mantenibles, modulares y portables de algoritmos para computadoras de alto rendimiento; especialmente para aquellas que posean memoria jerárquica (RAM, ROM, caché) y capacidades de procesamiento paralelo (Dongarra et al., 1990). Especı́ficamente las BLAS definen un grupo de operaciones fundamentales sobre vectores y matrices las cuales pueden ser usadas para crear funcionalidades optimizadas de alto nivel de álgebra lineal (Galassi et al., 2009). El nivel uno de las BLAS esta destinado para las operaciones con vectores, el nivel dos a operaciones matrix-vector y el nivel tres a operaciones matrix-matrix. Fueron publicadas por primera vez como una librerı́a de Fortran en 1979 (Lawson, 1999) debido a la necesidad de adoptar un grupo de rutinas básicas para resolver problemas de álgebra lineal; sin embargo un interfaz estándar para C ha sido desarrollada denominada CBLAS (Datardina et al., 1992). Las BLAS son usadas en lenguajes de programación de 23.

(33) Capı́tulo 2: Métodos y herramientas. 24. alto y bajo nivel en implementaciones de librerı́as y programación algebraica. Actualmente constituyen la Interfaz de Programación de Aplicaciones (API, Applications Programming Interface) estándar para rutinas y librerı́as de álgebra lineal. Varias implementaciones de las BLAS han sido adaptadas para arquitecturas de computadoras especificas, por ejemplo las desarrolladas para las compañı́as de Intel y AMD. 2.2. Librerı́a Cientı́fica de GNU (GSL, GNU Scientific Library ) La GSL es una colección de rutinas para el cálculo numérico. Las rutinas se han escrito. desde cero en C, y presentan una moderna API para programadores de C, permitiendo que varias capas puedan ser escritas por lenguajes de muy alto nivel (Galassi et al., 2009). El código fuente es distribuido bajo la Licencia Pública General de GNU (GNU GPL, GNU General Public License) la cual garantiza a los usuarios finales (personas, organizaciones, compañı́as) la libertad de usar, estudiar, compartir (copiar) y modificar el software. La librerı́a cubre un gran rango de tópicos en la computación numérica. Existen rutinas disponibles para las siguientes áreas: Funciones matemáticas básicas. Eigenvectores. Números complejos. Transformada rápida de Fourier. Polinomios. Integración numérica. Funciones especiales. Generación aleatoria de números. Vectores y matrices. Secuencias Quasi-aleatorias. Permutaciones. Distribuciones de números aleatorios. Combinaciones. Estadı́sticas. Multiset. Histogramas. Ordenación. N-tuplas. BLAS. Integración de Monte Carlo. Álgebra lineal. Simulated annealing.

(34) Capı́tulo 2: Métodos y herramientas. 25. Ecuaciones diferenciales ordinariass. Búsqueda de raı́ces en una y varias dimen-. Interpolación. siones. Derivación numérica. Minimización en una y varias dimensiones. Aproximaciones de Chebyshev. Medida de mı́nimos cuadrados. Aceleración de Series. Medida de mı́nimos cuadrados no lineales. Transformada discreta de Hankel. Constantes Fı́sicas Aritmética de punto flotante IEEE. Es necesario puntualizar que en algunos casos GSL posee una implementación propia de determinadas herramientas, como por ejemplo las Subrutinas Básicas de Álgebra Lineal (BLAS) implementadas como CBLAS en GSL, pero solo para emplearla en entornos donde no exista una de mejor desempeño. 2.3. Sistema de Construcción GNU (GNU Build System) EL GNU Build System también conocido como Autotools es un conjunto de he-. rramientas producido por el proyecto GNU y se encuentran disponibles en la mayorı́a de los proyectos Open Source de hoy en dı́a; la mayor ventaja en el uso de estas herramientas se debe a que ayudan a la portabilidad de las aplicaciones a nivel de código fuente, abstrayéndose en la medida de lo posible, de las versiones de las herramientas tradicionales disponibles en cada sistema operativo tipo Unix. Autotools tiene dos objetivos. El primero es simplificar el desarrollo de aplicaciones portables y el segundo facilitar la construcción de programas que son distribuidos como código fuente. El primer objetivo se alcanza debido a la generación automática del shell script ‘configure’, el cual configura el código fuente para la plataforma de instalación. El segundo objetivo se logra gracias a la creación automática de Makefiles y otros shell scripts que son tı́picamente usados en el proceso de construcción. De esta forma el desarrollador puede concentrarse en debbugear el código fuente en vez de complejos Makefiles, y el.

(35) Capı́tulo 2: Métodos y herramientas. 26. instalador puede compilar e instalar el programa directamente desde la distribución del código fuente mediante un simple y automático procedimiento. Este tema es relevante debido a que existe controversia en los desarrolladores a nivel nacional en el uso de este tipo de herramientas, a pesar que es un tema de interés y que han manifestado en más de una ocasión su intención de aprender. Por otra parte, está la competencia entre aprender a crear un proyecto y comenzar a programar inmediatamente, muchas veces acompañado por las barreras de entrada que impone la mantención de archivos Makefile y posteriormente el uso de macros m4. En la Figura 2.1 se muestra la estructura básica del proyecto para su construcción con Autotools.. Figura 2.1 Estructura básica del proyecto. El directorio raı́z del proyecto contiene una serie de archivos de textos que permiten mantener un control del proyecto y sirve como primer canal de comunicación con el usuario..

(36) Capı́tulo 2: Métodos y herramientas. 27. Archivos de información obligatorios • NEWS, es un registro de los cambios visibles al usuario donde los cambios más recientes se deben colocar al inicio. • README, contiene una descripción general del paquete. También es posible indicar instrucciones especiales de instalación o recomendaciones para leer el archivo INSTALL. • AUTHORS, contiene la lista de nombres de quienes han trabajado en la aplicación. • ChangeLog, es un registro de todos los cambios que se han efectuado en la aplicación. • COPYING, especifica los permisos de copia y distribución de la aplicación. Es una buena idea permitir que automake cree este archivo, siempre que se desee licenciar bajo GPL. • INSTALL, instrucciones de instalación de la aplicación. automake provee un archivo genérico, en donde siempre es aconsejable personalizarlo de acuerdo a los detalles de cada aplicación. Archivos de información opcionales • MAINTAINERS, contiene la lista de nombres de los responsables del proyecto para quien desee ponerse en contacto con ellos. • HACKING, contiene instrucciones para otros desarrolladores que quieran contribuir a la aplicación. Aquı́ se incluyen normas de sana convivencia como es el estilo de programación, tipos de autorización para efectuar cambios, etc. • VERSION, indica la versión del programa. • THANKS, contiene los créditos a las personas que han contribuido al proyecto pero que no son considerados autores. • TODO, listado de caracterı́sticas que se necesitan llevar a cabo. Permite llevar un orden de prioridades entre los autores y facilitar que potenciales contribuyentes sepan dónde y cómo pueden contribuir. Además, para los usuarios que han solicitado alguna caracterı́stica es una retroalimentación que indica que sus peticiones están siendo consideradas..

(37) Capı́tulo 2: Métodos y herramientas. 28. Archivos de programas y configuración La estructura que se muestra, corresponde a la visión del desarrollador. Cuando un programa se distribuye, se entregan en muchos casos archivos generados a partir de ciertos procesos. El caso más caracterı́stico es el script ‘configure’, que es un script creado en forma automática. • configure.ac, contiene las reglas de verificación y construcción del proyecto. Es la base para crear el script ‘configure’. Las reglas se escriben en macros m4. • Makefile.am, es el archivo que sirve como entrada al programa automake, quien se encargará de generar de forma automática el archivo Makefile, necesario para construir la aplicación. • src/, directorio donde se almacena el código fuente de la aplicación. Eventualmente existen los directorios include/ y lib/ en los cuales se define y se implementan las estrategias del software. • autogen.sh, script que permite automatizar la llamada a cada uno de los programas de Autotools. Este script no se muestra en la figura dado que no es obligatorio. Cuando hablamos de GNU Build System nos referimos principalmente a los siguientes cuatros paquetes: • Autoconf procesa los archivos configure.in o configure.ac. Cuando ejecuta el script de configuración también puede procesar otros archivos como Makefile.in para producir como salida un archivo Makefile. Autoconf se usa para intentar salvar las diferencias que existen entre distintos tipos de Unix. Por ejemplo, algunos sistemas Unix pueden tener funcionalidades que no existen o no funcionan en otros sistemas. Autoconf puede detectar ese problema y busca la forma de solucionarlo. La salida de Autoconf es un script denominado configure. Autoconf incluye la herramienta Autoheader que se usa para manejar los archivos de cabecera de C. • Automake ayuda a crear archivos Makefile portables. Estos son procesados después por la herramienta make. Toma como entrada un archivo Makefile.am y lo transforma en un.

(38) Capı́tulo 2: Métodos y herramientas. 29. Makefile.in. Este, a su vez, es utilizado por Autoconf para generar el archivo Makefile final. • Libtool ayuda a crear bibliotecas estáticas y dinámicas para varios sistemas operativos Unix. Libtool abstrae el proceso de creación de las bibliotecas ocultando las diferencias entre los distintos sistemas (entre GNU/Linux y Solaris por ejemplo). • Autotoolset ayuda a desarrollar código fuente portable acorde a los estándares de GNU generando archivos prototipo que contribuyen al desarrollo del software. 2.3.1. Construcción Para dar uso a las funcionalidades que nos brinda Autotools son necesarias una. serie de configuraciones y requisitos indispensables para su correcto funcionamiento. Los archivos Makefile.am tı́picamente contienen una especificación acerca de lo que se pretende construir, por ello es necesario crear uno en cada directorio que lo requiera, en nuestro caso en doc/, include/, lib/, src/ y otro en el directorio raı́z, con esto nos aseguramos que en tiempo de compilación se incluyan todos los ficheros necesarios ası́ como indicar algunas configuraciones dependiendo del directorio en que se encuentre. Se necesita también establecer en configure.ac directivas acerca de las caracterı́sticas generales del paquete, el compilador, integración con Doxygen ası́ como los tests de portabilidad entre plataformas. Con las configuraciones en orden las herramientas de GNU harán el resto del trabajo, para lo cual ejecutaremos los comandos aclocal, autoconf y automake (de preferencia en ese orden). El programa aclocal examina el archivo configure.ac y analiza si se requieren macros no incorporadas en autoconf (por ejemplo, las macros relacionadas con automake que tienen la forma ”AM*”) las cuales son agregadas en el archivo auxiliar aclocal.m4. El programa autoconf generará el script ”configure” y otros archivos auxiliares; además programa un test de existencia del compilador de lenguaje C y posee macros que permiten especificar qué archivos se generarán al ejecutarse configure..

(39) Capı́tulo 2: Métodos y herramientas. 30. Ahora ejecutamos automake -a. La opción -a solicita a automake que genere algunos archivos complementarios que son necesarios para etapas posteriores del proceso de generación del paquete. En este punto el proyecto está listo para que se ejecute ./configure, el cual generará un Makefile especı́fico para nuestro sistema. Es muy recomendable (especialmente para los desarrolladores que utilizan herramientas GNU ) lanzar configure desde un nuevo directorio al que llamaremos ”de construcción”, en vez de emplear el mismo directorio ”de fuentes”. Esto ayuda a detectar ciertos errores en las rutas y de paso no se contamina más nuestro directorio de fuentes con los subproductos del proceso de construcción. Para ello se crea un fichero build/ y desde dentro ejecutamos <directorio raı́z>/configure y se genera un Makefile, este hace referencia al directorio que contiene las fuentes (que no están aquı́). Sin embargo, todos los archivos que se generen como parte de proceso de compilación se almacenarán en este ”directorio de construcción”. A continuación ejecutamos el comando make generando ası́ el ejecutable deseado; y sudo make install para instalarlo (luego de escribir el password de administrador). El ejecutable se copia a /usr/local/bin. 2.4. Doxygen Doxygen es un generador de documentación para C++, C, Java, Objective-C, Python,. IDL (versiones Corba y Microsoft), VHDL y en cierta medida para PHP, C# y D. Dado que es fácilmente adaptable, funciona en la mayorı́a de sistemas Unix ası́ como en Windows y Mac OS X. Doxygen es un acrónimo de dox (document) gen(generator), generador de documentación para código fuente. En este proyecto se utiliza Doxygen como herramienta principal para la elaboración de la documentación del código fuente de la implementación, debido a que es capaz de generar documentación tanto off-line como on-line en una gran cantidad de formatos como HTML, LATEX, RTF, MS-Word, PostScript, PDF, páginas de manual de Unix. La documentación es extraı́da directamente del código fuente, lo cual la hace mas fácil mantener consistente.

(40) Capı́tulo 2: Métodos y herramientas. 31. con el código. Además Doxygen se puede configurar para que extraiga estructuras de código desde archivos no documentados, representando una ventaja para rápidamente encontrar guı́a en largos archivos de código fuente. Doxygen se utiliza tı́picamente a partir de modificar un fichero autogenerado (Doxyfile) por el uso del comando doxygen -g, luego se llenan los campos indispensables para la creación de la documentación como nombre del proyecto, dirección del directorio raı́z, idioma, dirección del directorio donde se va a generar la documentación, etc. El fichero de configuración posee muchos otros campos dando una gran gama de opciones y alternativas. Para documentar con Doxygen se deben utilizar etiquetas especiales en el código fuente a modo de comentarios como /// y //! por solo mencionar algunas. La implementación queda documentada automáticamente a través del comando doxygen, en este caso en formato HTML, en un directorio destinado para ello: doc/, quedando ası́ fácil de modificar, mantener y escalar. 2.5. Lenguaje Unificado de Modelado (UML, Unified Modeling Language) UML es el lenguaje de modelado de sistemas de software más conocido y utilizado en. la actualidad. Teniendo como antecedentes los lenguajes de modelado orientados a objetos que comenzaron a surgir a mediados de la década de 1970 y que lograron alcanzar gran diversidad a lo largo de los años (llegando a existir más de cincuenta lenguajes de modelado en el perı́odo de 1989 a 1994), se comenzó el desarrollo del UML en 1994 y se liberó en octubre de 1996 con una invitación de los autores a la realimentación por parte de la comunidad en general, alcanzando ser el foco de atención en su época. UML es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. Ofrece un estándar para describir un ”plano” del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y otros (Jacobson et al., 2000)..

(41) Capı́tulo 2: Métodos y herramientas. 32. Es muy común tener presente un diagrama general en UML en casi cualquier proyecto de programación, debido a que da, mas allá de la lógica del código y la apropiada documentación, un esquema legible que sirve de guı́a o directriz, siendo este fácilmente adaptable y flexible a las necesidades finales. 2.6. Consideraciones finales del capı́tulo Para la realización de la implementación se seleccionaron herramientas y métodos. de alta calidad ingenieril: UML para realizar el modelado del problema y generar una secuencia lógica de solución del mismo, ası́ como para una mejor comprensión de la implementación tanto para usuario como para otros desarrolladores; GSL con el objetivo de dotar al software con una fuerte base para el álgebra de matrices y tipos de datos; Autotools para una correcta construcción del programa, incluyendo total integración, configuración, portabilidad y empaquetadura de la solución; y Doxygen con el cual generar una documentación fácilmente mantenible y escalable. Como se puede apreciar estas han sido avaladas y probadas por décadas, demostrando robustez y eficiencia en el producto construido a partir de ellas. Es importante mencionar que han sido seleccionadas las herramientas anteriores, además de ser altamente usadas y validadas, por ser libres y de código abierto lo cual nos brinda la seguridad, soporte y ayuda de las comunidades que abogan por el software libre..

(42) CAPÍTULO 3 INGENIERÍA Y RESULTADOS. En los capı́tulos anteriores se ha realizado un análisis de los elementos que anteceden a esta investigación, ası́ como una explicación de los materiales, métodos y herramientas usadas para el desarrollo de la implementación. En este capı́tulo se ofrecerá la ingenierı́a aplicada para llevar a cabo los objetivos trazados; junto con los resultados alcanzados con la implementación real y su comparación con simulaciones en MATLAB. 3.1. Modelado El software de nivel táctico es un software de mayor envergadura alojado en el hard-. ware a bordo del HRC-AUV, como se puede apreciar en el diagrama UML de casos de uso de la figura 3.1 este es el principal actor sobre los OE.. Figura 3.1 Diagrama general de casos de uso. 33.

(43) Capı́tulo 3: Ingenierı́a y Resultados. 34. El uso que el software táctico da al observador es dependiente de la configuración que este le establezca, en este caso la creación y seteo de parámetros a los elementos algebraicos intrı́nsecos del observador; una aproximación mas exacta del caso de uso ”configurar” se muestra en la figura 3.2.. Figura 3.2 Diagrama de caso de uso ”configurar”. Para llevar a cabo la implementación es necesario una clase o estructura que defina la composición del observador, le de consistencia y lógica para su trabajo eficiente. Como C es un lenguaje estructurado no existen clases, por lo que se crea una estructura la cual representará al observador y contendrá los parámetros necesarios para su funcionamiento. En la figura 3.3 se presenta la estructura del observador, en este se observan los métodos configurar y estimar parámetros los cuales hacen uso del tipo de dato gsl matrix proporcionado por GSL; debido a esto y los métodos para el cálculo algebraico usados se establece la relación de dependencia mostrada en la figura 3.3.. Figura 3.3 Diagrama de clases de los OE..

(44) Capı́tulo 3: Ingenierı́a y Resultados. 35. En la figura 3.4 se observa un diagrama de secuencia ”configurar”, en este se puede observar con más detalle el flujo de la aplicación en este estado.. Figura 3.4 Diagrama de secuencia ”configurar”. Se aprecia el uso de la librerı́a estándar GSL la cual es la piedra angular de todo cálculo algebraico realizado en la implementación. Como vemos el actor (el software de nivel táctico) hace uso del observador y este a su vez de la librerı́a cientı́fica para realizar las operaciones requeridas; de esta forma se crean y se establecen los parámetros y valores que posteriormente mantendrán el estado del observador..

(45) Capı́tulo 3: Ingenierı́a y Resultados. 36. Una vez configurado el observador, el siguiente estado realiza la estimación de parámetros, en la figura 3.5 se refleja el diagrama de secuencias para lograr esta operación. Igualmente se requiere el uso de GSL para el artilugio algebraico necesario.. Figura 3.5 Diagrama de secuencia ”estimación de parámetros”. 3.2. Portabilidad La implementación y su construcción se realizaron sobre Ubuntu Trusty Thar con. una arquitectura de procesador i386. Bajo esta plataforma como era de esperarse no presento ningún problema para su construcción. En las siguientes figuras se muestra como la implementación se construyó correctamente en varios sistemas operativos, luego de una previa instalación de las bibliotecas y herramientas de GNU necesarias para ello. Se tuvo como ventaja que estos sistemas son implementaciones derivadas de Unix heredando ası́ varias caracterı́sticas importantes como la interfaz de lı́nea de comandos..

(46) Capı́tulo 3: Ingenierı́a y Resultados. Figura 3.6 Construcción completada en Mac OS X.. Figura 3.7 Construcción completada en FreeBSD.. 37.

(47) Capı́tulo 3: Ingenierı́a y Resultados. 38. Figura 3.8 Construcción completada en Debian Wheezy. 3.2.1. Empaquetado. El Makefile generado por el proceso de construcción tiene la capacidad de generar un paquete en formato tar.gz para ser distribuido a otras plataformas o usuarios a fin de que reconfiguren, construyan, e instalen el programa. Para esto se puede emplear el comando make dist. Hay que tener en cuenta que esto no requiere que se haya compilado previamente el paquete, pues no estamos distribuyendo ningún ejecutable. El resultado es el archivo auv-observer-1.0.tar.gz que corresponde a la combinación de ”nombrepaqueteversion” de la macro que inicia a automake. 3.3. Documentación Como se explicó en el capı́tulo 2 Doxygen es una poderosa herramienta para docu-. mentar código fuente y hacerlo mantenible de forma fácil y rápida. En la siguiente figura se muestra un diagrama que resume el proceso de generación de la documentación con esta herramienta..

(48) Capı́tulo 3: Ingenierı́a y Resultados. Figura 3.9 Diagrama de generación de documentación.. Figura 3.10 Ejemplo de código documentado.. 39.

(49) Capı́tulo 3: Ingenierı́a y Resultados. 40. Figura 3.11 Documentación en HTML generada. Doxygen es también sensible a estructuras y palabras reservadas de muchos lenguajes, lo que hace que la documentación generada se organice automáticamente:.

(50) Capı́tulo 3: Ingenierı́a y Resultados. 41. Figura 3.12 Documentación del fichero fuente auvyawobserver.c. 3.4. Validación en MATLAB Como resultado de la investigación (Garcı́a, 2014) se diseñaron e implementaros en. MATLAB los observadores de rumbo y profundidad para el HRC-AUV. Para la validación.

(51) Capı́tulo 3: Ingenierı́a y Resultados. 42. de resultados del presente trabajo se realizaron tests comparativos entre la implementación en C desarrollada y la existente en el software matemático MATLAB. Como se aprecia en las siguientes figuras las curvas prácticamente se solapan, validando la efectividad de la implementación. Las diferencias que se refleja en las figuras 3.14 y 3.16 son totalmente despreciables, representan una exactitud de hasta cinco lugares después de la coma, ya que para un mismo valor de la abscisa se obtiene casi exactamente un mismo valor de ordenada.. Figura 3.13 Estimación de rumbo..

(52) Capı́tulo 3: Ingenierı́a y Resultados. Figura 3.14 Estimación de rumbo (Ampliación).. Figura 3.15 Estimación de profundidad.. 43.

(53) Capı́tulo 3: Ingenierı́a y Resultados. 44. Figura 3.16 Estimación de profundidad (Ampliación). 3.5. Consideraciones finales del capı́tulo Se implementó eficazmente la implementación de OE en lenguaje C para el HRC-. AUV cumpliendo con los requerimientos necesarios por este. Fue indispensable el uso correcto de las herramientas descritas en el capı́tulo 2, arrojando resultados satisfactorios. Para el modelado de la situación se diseñaron varios diagramas UML, entre ellos varios casos de uso, diagrama de clases y de secuencias que asistieron al desarrollo de la aplicación. GSL constituyó los cimientos fundamentales para toda ingenierı́a aplicada al proyecto, proporcionándonos el tipo de datos con el cual trabajar, e indispensables funciones para el desarrollo del algoritmo de diseño; a través de Autotools fue posible portar la aplicación a sistemas como Mac OS y otras distribuciones basadas en Unix, validando la compatibilidad de plataforma; la generación de la documentación gracias a Doxygen fue sencilla y rápida de redactar, obteniendo como resultado una página web completamente funcional y lista para montar en servidores para el acceso de todos..

(54) Capı́tulo 3: Ingenierı́a y Resultados. 45. La validación de la implementación en MATLAB exhibieron resultados positivos, con un margen de error despreciable la implementación de OE en C muestra un comportamiento muy similar (exacto a efectos prácticos) a su contrapartida discreta diseñada en MATLAB..

(55) CONCLUSIONES Y RECOMENDACIONES Conclusiones • Partiendo del análisis de los antecedentes y aspectos teóricos básicos de los observadores de estado y sus aplicaciones, se constata que son herramientas muy poderosas y bien documentadas. Siendo su implementación real en AUVs y otros vehı́culos, una de las más usadas a nivel mundial. • El empleo de las herramientas y métodos de código abierto como GNU/Linux, GSL, Autotools, Doxygen son viables en la realización de implementaciones de calidad ya sean con fines académicos o destinadas a la producción. • La implementación de OE cumple con los estándares de funcionalidad y calidad requeridos por el HRC-AUV, ası́ como los estándares de compatibilidad entre plataformas y documentación. Se validó su funcionamiento a partir de datos reales obtenidos de manera online y offline. • Los tests comparativos en Simulink fueron cruciales para verificar el correcto funcionamiento de la aplicación, ası́ como para relevar el margen de error de esta en contraste con el diseño discreto previamente desarrollado en MATLAB. Recomendaciones • Integrar nuevas funcionalidades a la implementación con el fin de optimizar la estimación de parámetros, ası́ como estimar otros parámetros a partir de los obtenidos. • Implementar una funcionalidad que permita la configuración de las matrices del observador sin tener que acceder al código fuente (ej. a través de un archivo externo, una terminal, etc.). • Construir e instalar la implementación en otras arquitecturas como ARM, SPARC, IBM POWER, PowerPC, SuperH para verificar su portabilidad, funcionamiento y rendimiento.. 46.

(56) REFERENCIAS BIBLIOGRÁFICAS Aarset, M. F.; Strand, J. P.; Fossen T. I. (2008). Nonlinear vectorial observer backstepping with integral action and wave filtering for ships. Alessandri, A. and P. Coletta (2001). Design of luenberger observers for a class of hybrid linear systems. In: Hybrid Systems: Computation and Control (Maria Domenica Di Benedetto and Alberto Sangiovanni-Vincentelli, Eds.). pp. 7–18. Number 2034 In: Lecture Notes in Computer Science. Springer Berlin Heidelberg. Antonelli, Gianluca (2008). Handbook of Robotics. Springer. Cañizares, J.R. (2010). Modelado y control del vehı́culo autónomo sumergible del CIDNAV. Universidad Central de las Villas (UCLV). Chi, T. C. (1998). Linear System. Theory and Design, 3ra edición. Cruz, Nuno A.; Matos, Anı́ıbal C. (2008). The MARES AUV, a modular autonomous robot for environment sampling. technical report. Faculdade de Engenharia da Universidade do Porto. Datardina, SP, JJ Du Croz, SJ Hammarling and MW Pont (1992). A proposed specification of blas routines in c. The Journal of C Language Translation 3(4), 295–309. Dongarra, Jack J, Jeremy Du Croz, Sven Hammarling and Iain S Duff (1990). A set of level 3 basic linear algebra subprograms. ACM Transactions on Mathematical Software (TOMS) 16(1), 1–17. Fossen, T. I. (2011). Handbook of Marine Craft Hydrodynamics and Motion Control. John Wiley & Sons.. Nueva York, Estados Unidos. Fossen, T. I.; Strand, J. P. (1999). Passive nonlinear observer design for ships using lyapunov methods: Full-scale experiments with a supply vessel. Elsevier Science Ltd. Fossen, T. I.;Pérez, T. (2009). Kalman filtering for positioning and heading control of ships and offshore rigs. IEEE Control Systems. 47.

(57) 48 Fossen, Thor I. (1994). Guidance and Control of Ocean Vehicles. Wiley & Sons. Pub.. Nueva York, Estados Unidos. Fossen, Thor I.; Johansen, Tor A. y Perez Tristan (2008). Underwater vehicles. Chap. A survey of control allocation Methods for underwater vehicles, pp. 109–128. I-Tech. Viena, Austria. Fossen, Thor I. y Ross, A. (2006). Advances in unmanned marine vehicles. Chap. Nonlinear modelling, identification and control of UUVs, pp. 13–42. Vol. 69. Peter Peregrinus LTD. Gran Bretaña. Galassi, M., J. Davies, J. Theiler, B. Gough, G. Jungman, P. Alken, M. Booth and F. Rossi (2009). GNU Scientific Library. Garcia-Garcia, Delvis, Yunier Valeriano-Medina, Luis Hernández and Alain Martı́nezLaguardia (2012). Wave filtering for heading control of an auv based on passive observer. IJMS 41, 540–549. Garcı́a, D. (2010). Técnicas para el incremento de las prestaciones de los sistemas de navegaciónon inercial de bajo costo para vehı́culos autónomos. Universidad Central de las Villas (UCLV). Garcı́a, D. (2014). Desarrollo de técnicas de filtrado de las olas para la navegación y el control de un AUV. PhD thesis. Gorset, Jon E. (2010). Nonlinear model-based control of slender body AU V s. Tesis doctoral. NTNU. Noruega. Guerra, C.E. (2010). Diseño e implementación de hardware y software de bajo nivel para vehı́culo submarino autónomo. Universidad Central de las Villas (UCLV). Ibaraki, S., S. Suryanarayanan and M. Tomizuka (2001). H infin; optimization of luenberger state observers and its application to fault detection filter design. In: Proceedings of the 40th IEEE Conference on Decision and Control, 2001. Vol. 2. pp. 1011–1016 vol.2. Inzartsev, Alexander. y Pavin, Alexander. (2008). Underwater vehicles. Chap. AUV application for inspection of underwater comunications, pp. 216–234. I-Tech. Viena, Austria..