Modelación y simulación de la conexión a red de un parque eólico

Se tiene una red eléctrica compuesta por tres centrales térmicas convencionales y dos núcleos de consumo diferenciados, uno industrial y otro residencial, a la que se le va a conectar un parque eólico. El objetivo es dimensionar la línea de conexión y conocer el comportamiento de la red ante este cambio. Se han calculado las características de la línea eléctrica de conexión para satisfacer la potencia instalada del parque. También se ha estimado la demanda horaria de electricidad en las zonas residencial e industrial y se han tomado los valores horarios significativos de la potencia generada por el parque eólico, ambos, para las distintas estaciones del año. Como programa para la simulación de la red eléctrica se utilizó el PSS/E (Power System Simulator for Engineering) en el que, ayudándose del lenguaje de programación Python, se creó un código que cambiaba los datos horarios del consumo y la generación del parque, resolvía el flujo de cargas y exportaba los resultados que mostraban el comportamiento de la red para las distintas casuísticas. Finalmente, se analizaron los resultados de las potencias activa y reactiva generadas por las centrales convencionales, la tensión en los buses y las posibles sobrecargas.

Transforming meteorological data into linked data

This paper describes the process followed in order to make some of the public meterological data from the Agencia Estatal de Meteorología (AEMET, Spanish Meteorological Office) available as Linked Data. The method followed has been already used to publish geographical, statistical, and leisure data. The data selected for publication are generated every ten minutes by the 250 automatic stations that belong to AEMET and that are deployed across Spain. These data are available as spreadsheets in the AEMET data catalog, and contain more than twenty types of measurements per station. Spreadsheets are retrieved from the website, processed with Python scripts, transformed to RDF according to an ontology network about meteorology that reuses the W3C SSN Ontology, published in a triple store and visualized in maps with Map4rdf.

Implementation of wireless communication based on Software Defined Radio

In current communication systems, there are many new challenges like various competitive standards, the scarcity of frequency resource, etc., especially the development of personal wireless communication systems result the new system update faster than ever before, the conventional hardware-based wireless communication system is difficult to adapt to this situation. The emergence of SDR enabled the third revolution of wireless communication which from hardware to software and build a flexible, reliable, upgradable, reusable, reconfigurable and low cost platform. The Universal Software Radio Peripheral (USRP) products are commonly used with the GNU Radio software suite to create complex SDR systems. GNU Radio is a toolkit where digital signal processing blocks are written in C++, and connected to each other with Python. This makes it easy to develop more sophisticated signal processing systems, because many blocks already written by others and you can quickly put them together to create a complete system. Although the main function of GNU Radio is not be a simulator, but if there is no RF hardware components,it supports to researching the signal processing algorithm based on pre-stored and generated data by signal generator. This thesis introduced SDR platform from hardware (USRP) and software(GNU Radio), as well as some basic modulation techniques in wireless communication system. Based on the examples provided by GNU Radio, carried out some related experiments, for example GSM scanning and FM radio station receiving on USRP. And make a certain degree of improvement based on the experience of some investigators to observe OFDM spectrum and simulate real-time video transmission. GNU Radio combine with USRP hardware proved to be a valuable lab platform for implementing complex radio system prototypes in a short time. RESUMEN. Software Defined Radio (SDR) es una tecnología emergente que está creando un impacto revolucionario en la tecnología de radio convencional. Un buen ejemplo de radio software son los sistemas de código abierto llamados GNU Radio que emplean un kit de herramientas de desarrollo de software libre. En este trabajo se ha empleado un kit de desarrollo comercial (Ettus Research) que consiste en un módulo de procesado de señal y un hardaware sencillo. El módulo emplea un software de desarrollo basado en Linux sobre el que se pueden implementar aplicaciones de radio software muy variadas. El hardware de desarrollo consta de un microprocesador de propósito general, un dispositivo programable (FPGA) y un interfaz de radiofrecuencia que cubre de 50 a 2200MHz. Este hardware se conecta al PC por medio de un interfaz USB de 8Mb/s de velocidad. Sobre la plataforma de Ettus se pueden ejecutar aplicaciones GNU radio que utilizan principalmente lenguaje de programación Python para implementarse. Sin embargo, su módulo de procesado de señal está construido en C + + y emplea un microprocesador con aritmética de coma flotante. Por lo tanto, los desarrolladores pueden rápida y fácilmente construir aplicaciones en tiempo real sistemas de comunicación inalámbrica de alta capacidad. Aunque su función principal no es ser un simulador, si no puesto que hay componentes de hardware RF, Radio GNU sirve de apoyo a la investigación del algoritmo de procesado de señales basado en pre-almacenados y generados por los datos del generador de señal. En este trabajo fin de máster se ha evaluado la plataforma de hardware de DEG (USRP) y el software (GNU Radio). Para ello se han empleado algunas técnicas de modulación básicas en el sistema de comunicación inalámbrica. A partir de los ejemplos proporcionados por GNU Radio, hemos realizado algunos experimentos relacionados, por ejemplo, escaneado del espectro, demodulación de señales de FM empleando siempre el hardware de USRP. Una vez evaluadas aplicaciones sencillas se ha pasado a realizar un cierto grado de mejora y optimización de aplicaciones complejas descritas en la literatura. Se han empleado aplicaciones como la que consiste en la generación de un espectro de OFDM y la simulación y transmisión de señales de vídeo en tiempo real. Con estos resultados se está ahora en disposición de abordar la elaboración de aplicaciones complejas.

Interactividad programada en el Game Engine de Blender

Con este proyecto se ha desarrollado una guía introductoria a uno de los aspectos más complejos y especializados de Blender, que es el control de su motor de videojuegos mediante programas escritos en Python. Está orientado a lectores que tienen un conocimiento amplio sobre el manejo de Blender, su interfaz y el funcionamiento de sus diferentes elementos, así como una mínima experiencia en cuanto a programación. Se ha organizado en una parte descriptiva, centrada en el lenguaje Python y en las bases de su uso para programar el motor de videojuegos (Game Engine) de Blender, y otra de práctica guiada, que constituye la mayoría del proyecto, donde se estudian de manera progresiva ejemplos concretos de uso del mismo. En la parte descriptiva se ha tratado tanto el funcionamiento más básico del lenguaje Python, especialmente las características que difieren de otros lenguajes de programación tradicionales, como su relación con Blender en particular, explicando las diferentes partes de la API de Blender para Python, y las posibles estrategias de uso. La parte práctica guiada, dado que esta interacción entre Blender y Python ofrece un rango de posibilidades muy amplio, se ha centrado en tres áreas concretas que han sido investigadas en profundidad: el control del objeto protagonista, de la cámara y la implementación de un mapa de orientación. Todas ellas se han centrado en torno a un ejemplo común, que consiste en un videojuego muy básico, y que, gracias a los ficheros de Blender que acompañan a esta memoria, sirve para apoyar las explicaciones y poder probar su efecto directamente. Por una parte, estos tres aspectos prácticos se han explicado exhaustivamente, y se han llevado hasta un nivel relativamente alto. Asimismo se han intentado minimizar las dependencias, tanto entre ellos como con la escena que se ha usado como ejemplo, de manera que sea sencillo usar los programas generados en otras aplicaciones. Por otra, la mayoría de los problemas que ha sido necesario resolver durante el desarrollo no son específicos de ninguna de las tres áreas, sino que son de carácter general, por lo que sus explicaciones podrán usarse al afrontar otras situaciones. ABSTRACT. This Thesis consists of an introductory guide to one of the most complex and specific parts of Blender, which is the control of its game engine by means of programs coded in Python. The dissertation is orientated towards readers who have a good knowledge of Blender, its interface and how its different systems work, as well as basic programming skills. The document is composed of two main sections, the first one containing a description of Python’s basics and its usage within Blender, and the second consisting of three practical examples of interaction between them, guided and explained step by step. On the first section, the fundamentals of Python have been covered in the first place, focusing on the characteristics that distinguish it from other programming languages. Then, Blender’s API for Python has also been introduced, explaining its different parts and the ways it can be used in. Since the interaction between Blender and Python offers a wide range of possibilities, the practical section has been centered on three particular areas. Each one of the following sections has been deeply covered: how to control the main character object, how to control the camera, and how to implement and control a mini-map. Furthermore, a demonstrative videogame has been generated for the reader to be able to directly test the effect of what is explained in each section. On the one hand, these three practical topics have been thoroughly explained, starting from the basis and gradually taking them to a relatively advanced level. The dependences among them, or between them and the demonstrative videogame, have been minimised so that the scripts or ideas can be easily used within other applications. On the other hand, most of the problems that have been addressed are not exclusively related to these areas, but will most likely appear in different situations, thus enlarging the field in which this Thesis can be used.

Determinación de un modelo de geoide gravimétrico para Puerto Rico como sistema de referencia para las altitudes ortométricas

El geoide, definido como la superficie equipotencial que mejor se ajusta (en el sentido de los mínimos cuadrados) al nivel medio del mar en una determinada época, es la superficie que utilizamos como referencia para determinar las altitudes ortométricas. Si disponemos de una superficie equipotencial de referencia como dátum altimétrico preciso o geoide local, podemos entonces determinar las altitudes ortométricas de forma eficiente a partir de las altitudes elipsoidales proporcionadas por el Sistema Global de Navegación por Satélite (Global Navigation Satellite System, GNSS ). Como es sabido uno de los problemas no resueltos de la geodesia (quizás el más importante de los mismos en la actualidad) es la carencia de un dátum altimétrico global (Sjoberg, 2011) con las precisiones adecuadas. Al no existir un dátum altimétrico global que nos permita obtener los valores absolutos de la ondulación del geoide con la precisión requerida, es necesario emplear modelos geopotenciales como alternativa. Recientemente fue publicado el modelo EGM2008 en el que ha habido una notable mejoría de sus tres fuentes de datos, por lo que este modelo contiene coeficientes adicionales hasta el grado 2190 y orden 2159 y supone una sustancial mejora en la precisión (Pavlis et al., 2008). Cuando en una región determinada se dispone de valores de gravedad y Modelos Digitales del Terreno (MDT) de calidad, es posible obtener modelos de superficies geopotenciales más precisos y de mayor resolución que los modelos globales. Si bien es cierto que el Servicio Nacional Geodésico de los Estados Unidos de América (National Geodetic Survey, NGS) ha estado desarrollando modelos del geoide para la región de los Estados Unidos de América continentales y todos sus territorios desde la década de los noventa, también es cierto que las zonas de Puerto Rico y las Islas Vírgenes Estadounidenses han quedado un poco rezagadas al momento de poder aplicar y obtener resultados de mayor precisión con estos modelos regionales del geoide. En la actualidad, el modelo geopotencial regional vigente para la zona de Puerto Rico y las Islas Vírgenes Estadounidenses es el GEOID12A (Roman y Weston, 2012). Dada la necesidad y ante la incertidumbre de saber cuál sería el comportamiento de un modelo del geoide desarrollado única y exclusivamente con datos de gravedad locales, nos hemos dado a la tarea de desarrollar un modelo de geoide gravimétrico como sistema de referencia para las altitudes ortométricas. Para desarrollar un modelo del geoide gravimétrico en la isla de Puerto Rico, fue necesario implementar una metodología que nos permitiera analizar y validar los datos de gravedad terrestre existentes. Utilizando validación por altimetría con sistemas de información geográfica y validación matemática por colocación con el programa Gravsoft (Tscherning et al., 1994) en su modalidad en Python (Nielsen et al., 2012), fue posible validar 1673 datos de anomalías aire libre de un total de 1894 observaciones obtenidas de la base de datos del Bureau Gravimétrico Internacional (BGI). El aplicar estas metodologías nos permitió obtener una base de datos anomalías de la gravedad fiable la cual puede ser utilizada para una gran cantidad de aplicaciones en ciencia e ingeniería. Ante la poca densidad de datos de gravedad existentes, fue necesario emplear un método alternativo para densificar los valores de anomalías aire libre existentes. Empleando una metodología propuesta por Jekeli et al. (2009b) se procedió a determinar anomalías aire libre a partir de los datos de un MDT. Estas anomalías fueron ajustadas utilizando las anomalías aire libre validadas y tras aplicar un ajuste de mínimos cuadrados por zonas geográficas, fue posible obtener una malla de datos de anomalías aire libre uniforme a partir de un MDT. Tras realizar las correcciones topográficas, determinar el efecto indirecto de la topografía del terreno y la contribución del modelo geopotencial EGM2008, se obtuvo una malla de anomalías residuales. Estas anomalías residuales fueron utilizadas para determinar el geoide gravimétrico utilizando varias técnicas entre las que se encuentran la aproximación plana de la función de Stokes y las modificaciones al núcleo de Stokes, propuestas por Wong y Gore (1969), Vanicek y Kleusberg (1987) y Featherstone et al. (1998). Ya determinados los distintos modelos del geoide gravimétrico, fue necesario validar los mismos y para eso se utilizaron una serie de estaciones permanentes de la red de nivelación del Datum Vertical de Puerto Rico de 2002 (Puerto Rico Vertical Datum 2002, PRVD02 ), las cuales tenían publicados sus valores de altitud elipsoidal y elevación. Ante la ausencia de altitudes ortométricas en las estaciones permanentes de la red de nivelación, se utilizaron las elevaciones obtenidas a partir de nivelación de primer orden para determinar los valores de la ondulación del geoide geométrico (Roman et al., 2013). Tras establecer un total de 990 líneas base, se realizaron dos análisis para determinar la 'precisión' de los modelos del geoide. En el primer análisis, que consistió en analizar las diferencias entre los incrementos de la ondulación del geoide geométrico y los incrementos de la ondulación del geoide de los distintos modelos (modelos gravimétricos, EGM2008 y GEOID12A) en función de las distancias entre las estaciones de validación, se encontró que el modelo con la modificación del núcleo de Stokes propuesta por Wong y Gore presentó la mejor 'precisión' en un 91,1% de los tramos analizados. En un segundo análisis, en el que se consideraron las 990 líneas base, se determinaron las diferencias entre los incrementos de la ondulación del geoide geométrico y los incrementos de la ondulación del geoide de los distintos modelos (modelos gravimétricos, EGM2008 y GEOID12A), encontrando que el modelo que presenta la mayor 'precisión' también era el geoide con la modificación del núcleo de Stokes propuesta por Wong y Gore. En este análisis, el modelo del geoide gravimétrico de Wong y Gore presento una 'precisión' de 0,027 metros en comparación con la 'precisión' del modelo EGM2008 que fue de 0,031 metros mientras que la 'precisión' del modelo regional GEOID12A fue de 0,057 metros. Finalmente podemos decir que la metodología aquí presentada es una adecuada ya que fue posible obtener un modelo del geoide gravimétrico que presenta una mayor 'precisión' que los modelos geopotenciales disponibles, incluso superando la precisión del modelo geopotencial global EGM2008. ABSTRACT The geoid, defined as the equipotential surface that best fits (in the least squares sense) to the mean sea level at a particular time, is the surface used as a reference to determine the orthometric heights. If we have an equipotential reference surface or a precise local geoid, we can then determine the orthometric heights efficiently from the ellipsoidal heights, provided by the Global Navigation Satellite System (GNSS). One of the most common and important an unsolved problem in geodesy is the lack of a global altimetric datum (Sjoberg, 2011)) with the appropriate precision. In the absence of one which allows us to obtain the absolute values of the geoid undulation with the required precision, it is necessary to use alternative geopotential models. The EGM2008 was recently published, in which there has been a marked improvement of its three data sources, so this model contains additional coefficients of degree up to 2190 and order 2159, and there is a substantial improvement in accuracy (Pavlis et al., 2008). When a given region has gravity values and high quality digital terrain models (DTM), it is possible to obtain more accurate regional geopotential models, with a higher resolution and precision, than global geopotential models. It is true that the National Geodetic Survey of the United States of America (NGS) has been developing geoid models for the region of the continental United States of America and its territories from the nineties, but which is also true is that areas such as Puerto Rico and the U.S. Virgin Islands have lagged behind when to apply and get more accurate results with these regional geopotential models. Right now, the available geopotential model for Puerto Rico and the U.S. Virgin Islands is the GEOID12A (Roman y Weston, 2012). Given this need and given the uncertainty of knowing the behavior of a regional geoid model developed exclusively with data from local gravity, we have taken on the task of developing a gravimetric geoid model to use as a reference system for orthometric heights. To develop a gravimetric geoid model in the island of Puerto Rico, implementing a methodology that allows us to analyze and validate the existing terrestrial gravity data is a must. Using altimetry validation with GIS and mathematical validation by collocation with the Gravsoft suite programs (Tscherning et al., 1994) in its Python version (Nielsen et al., 2012), it was possible to validate 1673 observations with gravity anomalies values out of a total of 1894 observations obtained from the International Bureau Gravimetric (BGI ) database. Applying these methodologies allowed us to obtain a database of reliable gravity anomalies, which can be used for many applications in science and engineering. Given the low density of existing gravity data, it was necessary to employ an alternative method for densifying the existing gravity anomalies set. Employing the methodology proposed by Jekeli et al. (2009b) we proceeded to determine gravity anomaly data from a DTM. These anomalies were adjusted by using the validated free-air gravity anomalies and, after that, applying the best fit in the least-square sense by geographical area, it was possible to obtain a uniform grid of free-air anomalies obtained from a DTM. After applying the topographic corrections, determining the indirect effect of topography and the contribution of the global geopotential model EGM2008, a grid of residual anomalies was obtained. These residual anomalies were used to determine the gravimetric geoid by using various techniques, among which are the planar approximation of the Stokes function and the modifications of the Stokes kernel, proposed by Wong y Gore (1969), Vanicek y Kleusberg (1987) and Featherstone et al. (1998). After determining the different gravimetric geoid models, it was necessary to validate them by using a series of stations of the Puerto Rico Vertical Datum of 2002 (PRVD02) leveling network. These stations had published its values of ellipsoidal height and elevation, and in the absence of orthometric heights, we use the elevations obtained from first - order leveling to determine the geometric geoid undulation (Roman et al., 2013). After determine a total of 990 baselines, two analyzes were performed to determine the ' accuracy ' of the geoid models. The first analysis was to analyze the differences between the increments of the geometric geoid undulation with the increments of the geoid undulation of the different geoid models (gravimetric models, EGM2008 and GEOID12A) in function of the distance between the validation stations. Through this analysis, it was determined that the model with the modified Stokes kernel given by Wong and Gore had the best 'accuracy' in 91,1% for the analyzed baselines. In the second analysis, in which we considered the 990 baselines, we analyze the differences between the increments of the geometric geoid undulation with the increments of the geoid undulation of the different geoid models (gravimetric models, EGM2008 and GEOID12A) finding that the model with the highest 'accuracy' was also the model with modifying Stokes kernel given by Wong and Gore. In this analysis, the Wong and Gore gravimetric geoid model presented an 'accuracy' of 0,027 meters in comparison with the 'accuracy' of global geopotential model EGM2008, which gave us an 'accuracy' of 0,031 meters, while the 'accuracy ' of the GEOID12A regional model was 0,057 meters. Finally we can say that the methodology presented here is adequate as it was possible to obtain a gravimetric geoid model that has a greater 'accuracy' than the geopotential models available, even surpassing the accuracy of global geopotential model EGM2008.

Ampliación y mejora de aplicativo de análisis forense de imágenes

Ampliación de software dedicado al análisis de imágenes mediante la introducción de nuevas opciones en el procesamiento de video digital, mejoras en la interacción con el usuario. Para ello se ha estudiado el funcionamiento de la aplicación, integrando el lenguaje Python como herramienta de gestión y ejecución de la aplicación. En esta parte de la aplicación se ha integrado: - Traducción de la UI a una versión castellana. - Modificación y eliminación de cualquier filtro añadido para el procesamiento de video, no únicamente el último. - Descripciones de puntero y en la barra de estado de elementos de la aplicación. - Iconos en la barra de herramientas de los filtros añadidos más importantes. Por la otra parte, la del tratamiento digital de video, Avisynth se dispone como el eje de estudio, el cuál ejecuta sobre lenguaje de bajo nivel (C++) las operaciones pertinentes a través de librerías de enlace dinámico o *.dll. Las nuevas funcionalidades son: Convolución matricial, filtro de media adaptativa, DCT, ajustes de video generales, en formato RGB o YUV, rotaciones, cambios de perspectiva y filtrado en frecuencia. ABSTRACT. Improvement about a digital image processing software, creating new options in digital video processing or the user interaction. For this porpuse, we have integrated the application language,Python, as the tool to the application management and execution. In this part of the application has been integrated: - Translation of the UI: Spanish version. - Modifying and removing any added filter for video processing, not just the last. - Descriptions for the pointer and the status bar of the application. - New icons on the toolbar of the most important filters added. On the other hand, Avisynth was used tool for the digital video processing, which runs on low-level language (C ++) for a quickly and to improve the video operations. The new introduced filters are: Matrix Convolution, adaptive median filter, DCT, general video settings on RGB or YUV format, rotations, changes in perspective and frequency filtering.

Análisis de imágenes del rostro humano

El objetivo general de este trabajo es el correcto funcionamiento de un sistema de reconocimiento facial compuesto de varios módulos, implementados en distintos lenguajes. Uno de dichos módulos está escrito en Python y se encargarí de determinar el género del rostro o rostros que aparecen en una imagen o en un fotograma de una secuencia de vídeo. El otro módulo, escrito en C++, llevará a cabo el reconocimiento de cada una de las partes de la cara (ojos, nariz, boca) y la orientación hacia la que está posicionada (derecha, izquierda). La primera parte de esta memoria corresponde a la reimplementación de todas las partes de un analizador facial, que constituyen el primer módulo antes mencionado. Estas partes son un analizador, compuesto a su vez por un reconocedor (Tracker) y un procesador (Processor), y una clase visor para poder visualizar los resultados. Por un lado, el reconocedor o "Tracker.es el encargado de encontrar la cara y sus partes, que serán pasadas al procesador o Processor, que analizará la cara obtenida por el reconocedor y determinará su género. Este módulo estaba dise~nado completamente en C y OpenCV 1.0, y ha sido reescrito en Python y OpenCV 2.4. Y en la segunda parte, se explica cómo realizar la comunicación entre el primer módulo escrito en Python y el segundo escrito en C++. Además, se analizarán diferentes herramientas para poder ejecutar código C++ desde programas Python. Dichas herramientas son PyBindGen, Cython y Boost. Dependiendo de las necesidades del programador se contará cuál de ellas es más conveniente utilizar en cada caso. Por último, en el apartado de resultados se puede observar el funcionamiento del sistema con la integración de los dos módulos, y cómo se muestran por pantalla los puntos de interés, el género y la orientación del rostro utilizando imágenes tomadas con una cámara web.---ABSTRACT---The main objective of this document is the proper functioning of a facial recognition system composed of two modules, implemented in diferent languages. One of these modules is written in Python, and his purpose is determining the gender of the face or faces in an image or a frame of a video sequence. The other module is written in C ++ and it will perform the recognition of each of the parts of the face (eyes, nose , mouth), and the head pose (right, left).The first part of this document corresponds to the reimplementacion of all components of a facial analyzer , which constitute the first module that I mentioned before. These parts are an analyzer , composed by a tracke) and a processor, and a viewer to display the results. The tracker function is to find and its parts, which will be passed to the processor, which will analyze the face obtained by the tracker. The processor will determine the face's gender. This module was completely written in C and OpenCV 1.0, and it has been rewritten in Python and OpenCV 2.4. And in the second part, it explains how to comunicate two modules, one of them written in Python and the other one written in C++. Furthermore, it talks about some tools to execute C++ code from Python scripts. The tools are PyBindGen, Cython and Boost. It will tell which one of those tools is better to use depend on the situation. Finally, in the results section it is possible to see how the system works with the integration of the two modules, and how the points of interest, the gender an the head pose are displayed on the screen using images taken from a webcam.

Sistema de gestión de rankings deportivos V6: funcionalidades avanzadas

El trabajo realizado en este Trabajo de Fin de Grado (en adelante, TFG) consiste en la inclusión de nuevas funcionalidades avanzadas a la última versión del Sistema de Gestión de Rankings de carreras de orientación. El proyecto, actualmente en fase de explotación, es un sistema de clasificación y manejo de diferentes tipos de rankings para las carreas de orientación a pie de la FEDO1. Por medio de este ranking, se determina la clasificación global de los distintos corredores federados dentro de cada categoría, a través de diferentes parámetros de entrada que establecen la funcionalidad del ranking. En cuanto al trabajo realizado en este TFG, se trata de la implementación de la siguiente versión del sistema (versión 6). En esta nueva versión se ha querido incluir nuevas funcionalidades requeridas por los miembros de la federación, así como mejora de otras que no funcionan correctamente. El primer punto del trabajo fue el de comprender y familiarizarme con la herramienta ya implementada hasta el momento, así como aprender un nuevo lenguaje de programación desconocido hasta la fecha para mí; Python. Una de las primeras modificaciones realizadas, sobre las versiones anteriores, es la modificación del Sistema de Gestión de Rankings para los organizadores de carreras. Los organizadores de las carreras obtienen una recompensa de puntos por la organización de carreras, lo que significa un punto de gran importancia para el sistema. Esta funcionalidad no funcionaba correctamente en las versiones anteriores, de manera se tuvo que rehacer desde cero con las especificaciones necesarias. Otro requisito necesario fue modificar los requisitos para el cálculo de las nuevas medias de corredores, permitiendo el cálculo de la misma de forma continua o solo cuando se cumplan todos los requisitos. Respecto a la versión anterior, existía un problema con los accesos a los directorios de cada ranking. En caso de introducir los valores iniciales del ranking desde una carpeta diferente al directorio raíz de la aplicación, el sistema no realizaba correctamente la búsqueda de archivos en el directorio de ranking. De esta manera, había que modificar todo el código implementado para que todas las búsquedas se realizaran sobre el directorio de cada ranking. A continuación, se incluyó una nueva funcionalidad para el ranking individual de los corredores. Esta nueva funcionalidad permite la inclusión de una nueva opción de cálculo de puntuaciones para el ranking individual, a través de un fichero de entrada de puntuaciones que determinase las puntuaciones de los corredores exactas. Durante toda la fase del proyecto se ha tenido que añadir otra serie de especificaciones en la aplicación, las cuales serán explicadas en esta memoria. En definitiva, el trabajo realizado se ha basado en la mejora de una aplicación que gestiona rankings deportivos, de manera que esta versión se acercase lo máximo posible a la versión final de la aplicación.---ABSTRACT---The work done during these months is based on the addition of new advanced functionalities to the last version of the "Sistema de Gestión de Rankings" of orientation races. The project, now in phase of operation, is based on a classification system and management of different types of rankings for walk orienteering of the FEDO. Through this ranking, the global classification of the federal runners in each category is determinated, through various input parameters which establish the functionality of the ranking. Talking about the work done, it consist in the implementation of a new system version (version 6). This new version include new required functionalities by the members of the federation, as well as improving others that were working wrong. The first point of the project was to understand and become familiar with the tool already implemented in that moment, as well as learn a new programming language unknown to date for me; Python. One of the first changes made on previous versions, was the modification of the system for races organizers. The races organizers obtained a reward of points for the organized race, which means a point of great important for the system. This functionality didn't work correctly in previous versions, so was essential to redo it from zero with the required specifications. Another requirement was the addition of a new option for calculating the average of organizers, allowing calculation of it at all times. In the previous version, there was a problem with the access to directories of each ranking. In case of introduce the initial values of the ranking from a different folder to the root directory of the application, the system didn't perform correctly the finding of files in the directory of the ranking. So check all the implemented code for all searches were carried out on each ranking directory.Then a new functionality was included for the individual ranking of runners. This new feature is the inclusion of a new option to calculate scores for the individual ranking, through an input file that determinates exact scores for the runners. Throughout the project phase the addition of another set of specifications in the application was important, which will be explained in this memory. In short, the work done has been based on improving of an application that manage sport rankings, so this version could approach as much as possible to the final version of the application.

Dashboard configurable para la gestión y administración de una instancia de OpenStack

En este documento está descrito detalladamente el trabajo realizado para completar todos objetivos marcados para este Trabajo de Fin de Grado, que tiene como meta final el desarrollo de un dashboard configurable de gestión y administración para instancias de OpenStack. OpenStack es una plataforma libre y de código abierto utilizada como solución de Infraestructura como Servicio (Infrastructure as a Service, IaaS) en clouds tanto públicos, que ofrecen sus servicios cobrando el tiempo de uso o los recursos utilizados, como privados para su utilización exclusiva en el entorno de una empresa. El proyecto OpenStack se inició como una colaboración entre la NASA y RackSpace, y a día de hoy es mantenido por las empresas más potentes del sector tecnológico a través de la Fundación OpenStack. La plataforma OpenStack permite el acceso a sus servicios a través de una Interfaz de Linea de Comandos (Command Line Interface, CLI), una API RESTful y una interfaz web en forma de dashboard. Esta última es ofrecida a través del servicio Horizon. Este servicio provee de una interfaz gráfica para acceder, gestionar y automatizar servicios basados en cloud. El dashboard de Horizon presente algunos problemas como que: solo admite opciones de configuración mediante código Python, lo que hace que el usuario no tenga ninguna capacidad de configuración y que el administrador esté obligado a interactuar directamente con el código. no tiene soporte para múltiples regiones que permitan que un usuario pueda distribuir sus recursos por distintos centros de datos en diversas localizaciones como más le convenga. El presente Trabajo de Fin de Grado, que es la fase inicial del proyecto FI-Dash, pretende solucionar estos problemas mediante el desarrollo de un catálogo de widget de la plataformaWireCloud que permitirán al usuario tener todas las funcionalidades ofrecidas por Horizon a la vez que le ofrecen capacidades de configuración y añaden funcionalidades no presentes en Horizon como el soporte de múltiples regiones. Como paso previo al desarrollo del catálogo de widgets se ha llevado a cabo un estudio de las tecnologías y servicios ofrecidos por OpenStack, así como de las herramientas que pudieran ser necesarias para la realización del trabajo. El proceso de desarrollo ha sido dividido en distintas fases de acuerdo con los distintos componentes que forman parte del dashboard cada uno con una funcion de gestion sobre un tipo de recurso distinto. Las otras fases del desarrollo han sido la integración completa del dashboard en la plataforma WireCloud y el diseño de una interfaz gráfica usable y atractiva.---ABSTRACT---Throughout this document it is described the work performed in order to achieve all of the objectives set for this Final Project, which has as its main goal the development of a configurable dashboard for managing and administrating OpenStack instances. OpenStack is a free and open source platform used as Infrastructure as a Service (IaaS) for both public clouds, which offer their services through payments on time or resources used, and private clouds for use only in the company’s environment. The OpenStack project started as a collaboration between NASA and Rackspace, and nowadays is maintained by the most powerful companies in the technology sector through the OpenStack Foundation. The OpenStack project provides access to its services through a Command Line Interface (CLI), a RESTful API and a web interface as dashboard. The latter is offered through a service called Horizon. This service provides a graphical interface to access, manage and automate cloud-based services. Horizon’s dashboard presents some problems such as: Only supports configuration options using Python code, which grants the user no configuration capabilities and forces the administrator to interact directly. No support for multiple regions that allow a user to allocate his resources by different data centers in different locations at his convenience. This Final Project, which is the initial stage of the FI-Dash project, aims to solve these problems by developing a catalog of widgets for the WireCloud platform that will allow the user to have all the features offered by Horizon while offering configuration capabilities and additional features not present in Horizon such as support for multiple regions. As a prelude to the development of the widget catalog, a study of technologies and services offered by OpenStack as well as tools that may be necessary to carry out the work has been conducted. The development process has been split in phases matching the different components that are part of the dashboard, having each one of them a function of management of one kind of resource. The other development phases have been the achieving of full integration with WireCloud and the design of a graphical interface that is both usable and atractive.

Utilización de métodos de visión artificial para PC como apoyo en la automoción

La detección de los bordes de líneas en la carretera es una parte muy importante en los sistemas inteligentes de transportación, así como la detección de objetos tal como vehículos, con la finalidad de informar o prevenir a través de una alerta al conductor o al sistema informático. De aquí nace el interés de analizar algunos métodos de visión artificial (VA) que es un subcampo de la inteligencia artificial, cuyo propósito es programar un computador y que este “entienda” una escena o imagen, algunos de los métodos más comunes en la detección de líneas y vehículos (considerados objetos en nuestra investigación) son la transformada de Hough, el método de Canny, clasificador Haar Cascade, filtros de Fourier, etc. Se desarrollará una aplicación de escritorio o PC (Personal Computer) para el reconocimiento de vehículos y las líneas de bordes, el lenguaje de programación utilizado será Python y la biblioteca OpenCV que contiene más de 500 funciones en el campo de visión por computador. La validación del reconocimiento de objetos se la realizará con una prueba de campo. Este resultado apoyará a la automoción (máquina que se desplaza por acción de un motor como el vehículo) con datos que luego pueden ser procesados.

Implementación de plug-ins para REAPER: módulo de reverberación convolutiva en tiempo real y sistema para la medición de respuestas acústicas en salas

Existen en el mercado numerosas aplicaciones para la generación de reverberación y para la medición de respuestas al impulso acústicas. Sin embargo, éstas son de precios muy elevados y/o no se permite acceder a su código y, mucho menos, distribuir de forma totalmente libre. Además, las herramientas que ofrecen para la medición de respuestas al impulso requieren de un tedioso proceso para la generación de la señal de excitación, su reproducción y grabación y, finalmente, su post-procesado. Este procedimiento puede llevar en ocasiones al usuario a cometer errores debido a la falta de conocimientos técnicos. El propósito de este proyecto es dar solución a algunos de los inconvenientes planteados. Con tal fin se llevó a cabo el desarrollo e implementación de un módulo de reverberación por convolución particionada en tiempo real, haciendo uso de software gratuito y de libre distribución. En concreto, se eligió la estación digital de trabajo (DAW. Digital Audio Worksation) REAPER de la compañía Cockos. Además de incluir las funcionalidades básicas de edición y secuenciación presentes en cualquier DAW, el programa incluye un entorno para la implementación de efectos de audio en lenguaje JS (Jesusonic), y se distribuye con licencias completamente gratuitas y sin limitaciones de uso. Complementariamente, se propone una extensión para REAPER que permite la medición de respuestas al impulso de recintos acústicos de una forma completamente automatizada y amigable para el usuario. Estas respuestas podrán ser almacenadas y posteriormente cargadas en el módulo de reverberación, permitiendo aplicar sobre nuestras pistas de audio la respuesta acústica de cualquier recinto en el que se hayan realizado medidas. La implementación del sistema de medida de respuestas se llevó a cabo empleando la herramienta ReaScript de REAPER, que permite la ejecución de pequeños scripts Python. El programa genera un Barrido Sinusoidal Logarítmico que excita el recinto acústico cuya respuesta se desea medir, grabando la misma en un archivo .wav. Este procedimiento es sencillo, intuitivo y está al alcance de cualquier usuario doméstico, ya que no requiere la utilización de sofisticado instrumental de medida. ABSTRACT. There are numerous applications in the market for the generation of reverb and measurement of acoustic impulse responses. However, they are usually very costly and closed source. In addition, the provided tools for measuring impulse responses require tedious processes for the generation and reproduction of the excitation signal, the recording of the response and its final post-processing. This procedure can sometimes drive the user to make mistakes due to the lack of technical knowledge. The purpose of this project is to solve some of the mentioned problems. To that end we developed and implemented a real-time partitioned convolution reverb module using free open source software. Specifically, the chosen software was the Cockos’ digital audio workstation (DAW) REAPER. In addition to the basic features included in any DAW, such as editing and sequencing, the program includes an environment for implementing audio effects in JS (Jesusonic) language of free distribution and features an unrestricted license. As an extension for REAPER, we propose a fully automated and user-friendly method for measuring rooms’ acoustic impulse responses. These will be stored and then loaded into the reverb module, allowing the user to apply the acoustical response of any room where measurement have been taken to any audio track. The implementation of the impulse response measurement system was done using REAPER’s ReaScript tool that allows the execution of small Python scripts. The program generates a logarithmic sine sweep that excites the room and its response is recorded in a .wav file. This procedure is simple, intuitive and it is accessible to any home user as it does not require the use of sophisticated measuring equipment.

Nepfix: on-demand cloud elastic simulation of networks of evolutionary processors

Una Red de Procesadores Evolutivos o NEP (por sus siglas en ingles), es un modelo computacional inspirado por el modelo evolutivo de las celulas, específicamente por las reglas de multiplicación de las mismas. Esta inspiración hace que el modelo sea una abstracción sintactica de la manipulation de information de las celulas. En particu¬lar, una NEP define una maquina de cómputo teorica capaz de resolver problemas NP completos de manera eficiente en tóerminos de tiempo. En la praóctica, se espera que las NEP simuladas en móaquinas computacionales convencionales puedan resolver prob¬lemas reales complejos (que requieran ser altamente escalables) a cambio de una alta complejidad espacial. En el modelo NEP, las cóelulas estóan representadas por palabras que codifican sus secuencias de ADN. Informalmente, en cualquier momento de cómputo del sistema, su estado evolutivo se describe como un coleccion de palabras, donde cada una de ellas representa una celula. Estos momentos fijos de evolucion se denominan configuraciones. De manera similar al modelo biologico, las palabras (celulas) mutan y se dividen en base a bio-operaciones sencillas, pero solo aquellas palabras aptas (como ocurre de forma parecida en proceso de selection natural) seran conservadas para la siguiente configuracióon. Una NEP como herramienta de computation, define una arquitectura paralela y distribuida de procesamiento simbolico, en otras palabras, una red de procesadores de lenguajes. Desde el momento en que el modelo fue propuesto a la comunidad científica en el año 2001, múltiples variantes se han desarrollado y sus propiedades respecto a la completitud computacional, eficiencia y universalidad han sido ampliamente estudiadas y demostradas. En la actualidad, por tanto, podemos considerar que el modelo teórico NEP se encuentra en el estadio de la madurez. La motivación principal de este Proyecto de Fin de Grado, es proponer una aproxi-mación práctica que permita dar un salto del modelo teórico NEP a una implantación real que permita su ejecucion en plataformas computacionales de alto rendimiento, con el fin de solucionar problemas complejos que demanda la sociedad actual. Hasta el momento, las herramientas desarrolladas para la simulation del modelo NEP, si bien correctas y con resultados satisfactorios, normalmente estón atadas a su entorno de ejecucion, ya sea el uso de hardware específico o implementaciones particulares de un problema. En este contexto, el propósito fundamental de este trabajo es el desarrollo de Nepfix, una herramienta generica y extensible para la ejecucion de cualquier algo¬ritmo de un modelo NEP (o alguna de sus variantes), ya sea de forma local, como una aplicación tradicional, o distribuida utilizando los servicios de la nube. Nepfix es una aplicacion software desarrollada durante 7 meses y que actualmente se encuentra en su segunda iteration, una vez abandonada la fase de prototipo. Nepfix ha sido disenada como una aplicacion modular escrita en Java 8 y autocontenida, es decir, no requiere de un entorno de ejecucion específico (cualquier maquina virtual de Java es un contenedor vólido). Nepfix contiene dos componentes o móodulos. El primer móodulo corresponde a la ejecución de una NEP y es por lo tanto, el simulador. Para su desarrollo, se ha tenido en cuenta el estado actual del modelo, es decir, las definiciones de los procesadores y filtros mas comunes que conforman la familia del modelo NEP. Adicionalmente, este componente ofrece flexibilidad en la ejecucion, pudiendo ampliar las capacidades del simulador sin modificar Nepfix, usando para ello un lenguaje de scripting. Dentro del desarrollo de este componente, tambióen se ha definido un estóandar de representacióon del modelo NEP basado en el formato JSON y se propone una forma de representation y codificación de las palabras, necesaria para la comunicación entre servidores. Adicional-mente, una característica importante de este componente, es que se puede considerar una aplicacion aislada y por tanto, la estrategia de distribution y ejecución son total-mente independientes. El segundo moódulo, corresponde a la distribucióon de Nepfix en la nube. Este de-sarrollo es el resultado de un proceso de i+D, que tiene una componente científica considerable. Vale la pena resaltar el desarrollo de este modulo no solo por los resul-tados prócticos esperados, sino por el proceso de investigation que se se debe abordar con esta nueva perspectiva para la ejecución de sistemas de computación natural. La principal característica de las aplicaciones que se ejecutan en la nube es que son gestionadas por la plataforma y normalmente se encapsulan en un contenedor. En el caso de Nepfix, este contenedor es una aplicacion Spring que utiliza el protocolo HTTP o AMQP para comunicarse con el resto de instancias. Como valor añadido, Nepfix aborda dos perspectivas de implementation distintas (que han sido desarrolladas en dos iteraciones diferentes) del modelo de distribution y ejecucion, que tienen un impacto muy significativo en las capacidades y restricciones del simulador. En concreto, la primera iteration utiliza un modelo de ejecucion asincrono. En esta perspectiva asincrona, los componentes de la red NEP (procesadores y filtros) son considerados como elementos reactivos a la necesidad de procesar una palabra. Esta implementation es una optimization de una topologia comun en el modelo NEP que permite utilizar herramientas de la nube para lograr un escalado transparente (en lo ref¬erente al balance de carga entre procesadores) pero produce efectos no deseados como indeterminacion en el orden de los resultados o imposibilidad de distribuir eficiente-mente redes fuertemente interconectadas. Por otro lado, la segunda iteration corresponde al modelo de ejecucion sincrono. Los elementos de una red NEP siguen un ciclo inicio-computo-sincronizacion hasta que el problema se ha resuelto. Esta perspectiva sincrona representa fielmente al modelo teórico NEP pero el proceso de sincronizacion es costoso y requiere de infraestructura adicional. En concreto, se requiere un servidor de colas de mensajes RabbitMQ. Sin embargo, en esta perspectiva los beneficios para problemas suficientemente grandes superan a los inconvenientes, ya que la distribuciín es inmediata (no hay restricciones), aunque el proceso de escalado no es trivial. En definitiva, el concepto de Nepfix como marco computacional se puede considerar satisfactorio: la tecnología es viable y los primeros resultados confirman que las carac-terísticas que se buscaban originalmente se han conseguido. Muchos frentes quedan abiertos para futuras investigaciones. En este documento se proponen algunas aproxi-maciones a la solucion de los problemas identificados como la recuperacion de errores y la division dinamica de una NEP en diferentes subdominios. Por otra parte, otros prob-lemas, lejos del alcance de este proyecto, quedan abiertos a un futuro desarrollo como por ejemplo, la estandarización de la representación de las palabras y optimizaciones en la ejecucion del modelo síncrono. Finalmente, algunos resultados preliminares de este Proyecto de Fin de Grado han sido presentados recientemente en formato de artículo científico en la "International Work-Conference on Artificial Neural Networks (IWANN)-2015" y publicados en "Ad-vances in Computational Intelligence" volumen 9094 de "Lecture Notes in Computer Science" de Springer International Publishing. Lo anterior, es una confirmation de que este trabajo mas que un Proyecto de Fin de Grado, es solo el inicio de un trabajo que puede tener mayor repercusion en la comunidad científica. Abstract Network of Evolutionary Processors -NEP is a computational model inspired by the evolution of cell populations, which might model some properties of evolving cell communities at the syntactical level. NEP defines theoretical computing devices able to solve NP complete problems in an efficient manner. In this model, cells are represented by words which encode their DNA sequences. Informally, at any moment of time, the evolutionary system is described by a collection of words, where each word represents one cell. Cells belong to species and their community evolves according to mutations and division which are defined by operations on words. Only those cells are accepted as surviving (correct) ones which are represented by a word in a given set of words, called the genotype space of the species. This feature is analogous with the natural process of evolution. Formally, NEP is based on an architecture for parallel and distributed processing, in other words, a network of language processors. Since the date when NEP was pro¬posed, several extensions and variants have appeared engendering a new set of models named Networks of Bio-inspired Processors (NBP). During this time, several works have proved the computational power of NBP. Specifically, their efficiency, universality, and computational completeness have been thoroughly investigated. Therefore, we can say that the NEP model has reached its maturity. The main motivation for this End of Grade project (EOG project in short) is to propose a practical approximation that allows to close the gap between theoretical NEP model and a practical implementation in high performing computational platforms in order to solve some of high the high complexity problems society requires today. Up until now tools developed to simulate NEPs, while correct and successful, are usu¬ally tightly coupled to the execution environment, using specific software frameworks (Hadoop) or direct hardware usage (GPUs). Within this context the main purpose of this work is the development of Nepfix, a generic and extensible tool that aims to execute algorithms based on NEP model and compatible variants in a local way, similar to a traditional application or in a distributed cloud environment. Nepfix as an application was developed during a 7 month cycle and is undergoing its second iteration once the prototype period was abandoned. Nepfix is designed as a modular self-contained application written in Java 8, that is, no additional external dependencies are required and it does not rely on an specific execution environment, any JVM is a valid container. Nepfix is made of two components or modules. The first module corresponds to the NEP execution and therefore simulation. During the development the current state of the theoretical model was used as a reference including most common filters and processors. Additionally extensibility is provided by the use of Python as a scripting language to run custom logic. Along with the simulation a definition language for NEP has been defined based on JSON as well as a mechanisms to represent words and their possible manipulations. NEP simulator is isolated from distribution and as mentioned before different applications that include it as a dependency are possible, the distribution of NEPs is an example of this. The second module corresponds to executing Nepfix in the cloud. The development carried a heavy R&D process since this front was not explored by other research groups until now. It's important to point out that the development of this module is not focused on results at this point in time, instead we focus on feasibility and discovery of this new perspective to execute natural computing systems and NEPs specifically. The main properties of cloud applications is that they are managed by the platform and are encapsulated in a container. For Nepfix a Spring application becomes the container and the HTTP or AMQP protocols are used for communication with the rest of the instances. Different execution perspectives were studied, namely asynchronous and synchronous models were developed for solving different kind of problems using NEPs. Different limitations and restrictions manifest in both models and are explored in detail in the respective chapters. In conclusion we can consider that Nepfix as a computational framework is suc-cessful: Cloud technology is ready for the challenge and the first results reassure that the properties Nepfix project pursued were met. Many investigation branches are left open for future investigations. In this EOG implementation guidelines are proposed for some of them like error recovery or dynamic NEP splitting. On the other hand other interesting problems that were not in the scope of this project were identified during development like word representation standardization or NEP model optimizations. As a confirmation that the results of this work can be useful to the scientific com-munity a preliminary version of this project was published in The International Work- Conference on Artificial Neural Networks (IWANN) in May 2015. Development has not stopped since that point and while Nepfix in it's current state can not be consid¬ered a final product the most relevant ideas, possible problems and solutions that were produced during the seven months development cycle are worthy to be gathered and presented giving a meaning to this EOG work.

Sistema domótico controlado por mensajería instantánea Whatsapp para personas con discapacidad

El presente PFC tiene como objetivo el desarrollo de un gestor domótico basado en el dictado de voz de la red social WhatsApp. Dicho gestor no solo sustituirá el concepto dañino de que la integración de la domótica hoy en día es cara e inservible sino que acercará a aquellas personas con una discapacidad a tener una mejora en la calidad de vida. Estas personas, con un simple comando de voz a su aplicación WhatsApp de su terminal móvil, podrán activar o desactivar todos los elementos domóticos que su vivienda tenga instalados, “activar lámpara”, “encender Horno”, “abrir Puerta”… Todo a un muy bajo precio y utilizando tecnologías OpenSource El objetivo principal de este PFC es ayudar a la gente con una discapacidad a tener mejor calidad de vida, haciéndose independiente en las labores del hogar, ya que será el hogar quien haga las labores. La accesibilidad de este servicio, es por tanto, la mayor de las metas. Para conseguir accesibilidad para todas las personas, se necesita un servicio barato y de fácil aprendizaje. Se elige la red social WhatsApp como interprete, ya que no necesita de formación al ser una aplicación usada mayoritariamente en España y por la capacidad del dictado de voz, y se eligen las tecnologías OpenSource por ser la gran mayoría de ellas gratuitas o de pago solo el hardware. La utilización de la Red social WhatsApp se justifica por sí sola, en septiembre de 2015 se registraron 900 millones de usuarios. Este dato es fruto, también, de la reciente adquisición por parte de Facebook y hace que cumpla el primer requisito de accesibilidad para el servicio domotico que se presenta. Desde hace casi 5 años existe una API liberada de WhatsApp, que la comunidad OpenSource ha utilizado, para crear sus propios clientes o aplicaciones de envío de mensajes, usando la infraestructura de la red social. La empresa no lo aprueba abiertamente, pero la liberación de la API fue legal y su uso también lo es. Por otra parte la empresa se reserva el derecho de bloquear cuentas por el uso fraudulento de su infraestructura. Las tecnologías OpenSource utilizadas han sido, distribuciones Linux (Raspbian) y lenguajes de programación PHP, Python y BASHSCRIPT, todo cubierto por la comunidad, ofreciendo soporte y escalabilidad. Es por ello que se utiliza, como matriz y gestor domotico central, una RaspberryPI. Los servicios que el gestor ofrece en su primera versión incluyen el control domotico de la iluminación eléctrica general o personal, el control de todo tipo de electrodomésticos, el control de accesos para la puerta principal de entrada y el control de medios audiovisuales. ABSTRACT. This final thesis aims to develop a domotic manager based on the speech recognition capacity implemented in the social network, WhatsApp. This Manager not only banish the wrong idea about how expensive and useless is a domotic installation, this manager will give an opportunity to handicapped people to improve their quality of life. These people, with a simple voice command to their own WhatsApp, could enable or disable all the domotics devices installed in their living places. “On Lamp”, “ON Oven”, “Open Door”… This service reduce considerably the budgets because the use of OpenSource Technologies. The main achievement of this thesis is help handicapped people improving their quality of life, making independent from the housework. The house will do the work. The accessibility is, by the way, the goal to achieve. To get accessibility to a width range, we need a cheap, easy to learn and easy to use service. The social Network WhatsApp is one part of the answer, this app does not need explanation because is used all over the world, moreover, integrates the speech recognition capacity. The OpenSource technologies is the other part of the answer due to the low costs or, even, the free costs of their implementations. The use of the social network WhatsApp is explained by itself. In September 2015 were registered around 900 million users, of course, the recent acquisition by Facebook has helped in this astronomic number and match the first law of this service about the accessibility. Since five years exists, in the internet, a free WhatsApp API. The OpenSource community has used this API to develop their own messaging apps or desktop-clients, using the WhatsApp infrastructure. The company does not approve officially, however le API freedom is legal and the use of the API is legal too. On the other hand, the company can block accounts who makes a fraudulent use of his infrastructure. OpenSource technologies used in this thesis are: Linux distributions (Raspbian) and programming languages PHP, Python and BASHCSRIPT, all of these technologies are covered by the community offering support and scalability. Due to that, it is used a RaspberryPI as the Central Domotic Manager. The domotic services that currently this manager achieve are: Domotic lighting control, electronic devices control, access control to the main door and Media Control.

Desarrollo de una aplicación web para la reducción de ruido del sonido grabado de un disco de vinilo

Las grabaciones digitales de discos de vinilo, al ser un medio de almacenamiento de sonido analógico, están afectadas por ruido de diversos tipos, debido al deterioro de la superficie con el tiempo y con su reproducción. Aunque algunos programas de edición de audio permiten hacer una reducción de ruido sobre esas grabaciones, muchos consumidores de música en vinilo los desconocen, encuentran complicado su uso o quieren evitar la instalación de programas adicionales en su ordenador. Este proyecto consiste en el desarrollo de una aplicación web que pretende acabar con estos impedimentos y ofrecer un medio sencillo y eficaz para la reducción de ruido, ejecutable a través de un navegador, que simplifique el proceso de cara al usuario. El funcionamiento es sencillo: un usuario sube un archivo de audio al servidor, éste lo procesa y lo devuelve al cliente. El servidor, en la fase de procesamiento de señal, realiza una reducción de ruido mediante una puerta de ruido en el dominio de la frecuencia, desarrollada en lenguaje Python, y diseñada en función de un estudio previo de diversas muestras de ruido. En el proyecto se pueden distinguir tres bloques: la caracterización del ruido que afecta a grabaciones de discos de vinilo, el desarrollo de un algoritmo que realice la reducción de ruido correspondiente y el desarrollo de la aplicación web. En este documento se recogen los fundamentos de cada uno de los bloques, tratando de resumir las bases de su funcionamiento y de justificar cada una de las decisiones tomadas, como la tecnología empleada, el valor de algunos parámetros, la estructura del código o los pasos seguidos en cada algoritmo.