PerSe: Person as a Sensor

Tamaño: px
Comenzar la demostración a partir de la página:

Download "PerSe: Person as a Sensor"

Transcripción

1 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA GRADO EN INGENIERÍA INFORMÁTICA TRABAJO FIN DE GRADO PerSe: Person as a Sensor Alba Barón Rubio Septiembre, 2014

2

3 PERSE: PERSON AS A SENSOR

4

5 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA Tecnologías y Sistemas de Información TECNOLOGÍA ESPECÍFICA DE INGENIERÍA DE COMPUTADORES TRABAJO FIN DE GRADO PerSe: Person as a Sensor Autor: Alba Barón Rubio Director: María José Santofimia Romero Director: Félix Jesús Villanueva Molina Septiembre, 2014

6

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

8

9 TRIBUNAL: Presidente: Vocal: Secretario: FECHA DE DEFENSA: CALIFICACIÓN: PRESIDENTE VOCAL SECRETARIO Fdo.: Fdo.: Fdo.: iii

10

11 Resumen El envejecimiento progresivo de la población es una realidad que demanda cada vez más atención, en búsqueda de soluciones que mejoren la calidad de vida de las personas de la tercera edad. Las tecnologías de la información y comunicación (TIC) pueden verse como una oportunidad para proporcionar mayor independencia a los ancianos, mejorando por lo tanto su calidad de vida y permitiendo una mayor participación en la sociedad. En este sentido, el reconocimiento automático y no invasivo de acciones juega un papel esencial en este tipo de ambientes asistidos. La persona puede desarrollar una vida cotidiana a la vez que el sistema proporciona información acerca de la actividad que se está desarrollando, pudiendo responder a tiempo real ante una emergencia o elaborando a largo plazo un estudio sobre sus patrones de comportamiento, posibilidades de movimiento, etc. Dado el contexto en el que este tipo de sistemas estarán desplegados, es fundamental que este tipo de paradigmas se apoyen en el uso de objetos inteligentes que existen en nuestro entorno. Así, cada día en mayor medida, los teléfonos móviles han pasado a formar parte de nuestra vida, acompañándonos la mayor parte del tiempo. Este TFG tiene como objetivo utilizar la información que ofrecen los sensores con los que la mayor parte de los teléfonos inteligentes están equipados. Esos sensores, proporcionarán información que será utilizada para identificar las acciones que puede realizar la persona de forma autónoma, acciones como andar, correr o subir escaleras. Para llevar a cabo este sistema se ha seguido un esquema de trabajo de aprendizaje automático o machine learning compuesto por varias etapas: recogida de la señal de los sensores, preprocesamiento de la señal a través de una ventana deslizante, caracterización de la señal utilizando la Transformada Discreta Wavelet DWT, reducción del vector de características utilizando un conjunto de medidas estadísticas y entrenamiento del sistema utilizando un clasificador SVM. Finalmente, la precisión del sistema será calculada implementando una versión reducida del método de validación cruzada. El desarrollo de todas estas etapas ha supuesto la implementación de aplicaciones Android, un sistema cliente servidor, varios módulos en Python y algunos scripts en bash, así como el uso de una serie de librerías que han dado soporte tanto a las funciones matemáticas y estadísticas como a la de la implementación del clasificador SVM. Todo este conjunto forma un sistema capaz de recoger datos, entrenarlos y probar sus resultados. Finalmente, tras desarrollar el sistema y posteriormente entrenarlo con el conjunto de datos de prueba, se han evaluado los resultados y se han expuesto en forma de matrices de confusión para facilitar su comprensión. V

12

13 Abstract The progressive aging of population is increasingly gaining attention and major efforts are dedicated to find solutions for improving quality of life of seniors. Information and communications technology (ICT) can be seen as an opportunity to provide greater independence for elderly, therefore improving their quality of life and allowing greater participation in society. Accordingly, automatic and non-invasive recognition of actions plays a essential role in this type of assisted environments. The person can carry out a daily life while the system provides information about the activity being performed, being able to respond in real time to a emergency or developing a long-term study on patterns of behavior, motion capability, etc. Because of the context in which these systems are inteded to be deployed, it is essential that such paradigms are supported on the use of intelligent objects that already exist in our environment. Every day more, mobile phones have become part of our life, being around us most of the time. This project pursues the use information provided by the sensors with which most of of smartphones are equipped. These sensors provide information that will be used to identify actions that can be performed autonomously person, actions such as walking, running, or climbing stairs. To carry out this system, a machine learning approach is followed that involves, several steps: Collecting the sensor signal; the signal preprocessing using a sliding window approach; signal characterization using the discrete wavelet transform DWT; reduction of feature vector using a set of statistical measures and; training system using a SVM classifier. Lastly, the precision of system will be calculated with the implementation of a reduced version of the method of cross-validation. The development of these stages has resulted in the implementation of Android applications, client server system, several modules in Python, and some bash scripts. Also, the use of some additional libraries is required in order to support some mathematics and statistics functions and the implementation of the SVM classifier. This project therefore results in a system able to collect data, train and test their results. Lastly, after developing this system and then train the classifier with the collected dataset, the system have been evaluated and the results have been exposed as confusion matrices for easing the interpretation of the obtained results. VII

14

15 Agradecimientos El Trabajo Fin de Carrera supone el cierre de una etapa y el comienzo de otra. La etapa que viene aún está sin determinar, por primera vez en mi vida no se dónde voy a estar el próximo año, lo que me causa gran incertidumbre. La etapa que ha pasado ha sido sin duda la mejor de mi vida y esto se lo debo, en gran parte, a toda la gente que me ha acompañado a lo largo de todos estos años. Cuántas crisis superadas y buenos momentos vividos en el 4 o H, con mis queridas: Almudena, Sandra y Mónica. Es muy agradable tener a alguien con quien poder hablar al final del día sobre lo mal que se te ha dado el examen o lo gracioso que ha sido el comentario de un profesor. Tuve mucha suerte encontrándome con ellas, sin su apoyo todo hubiera sido mucho más triste. De la misma forma tengo que agradecer a mi familia su apoyo, tanto personal como económico, sin el que definitivamente mi vida ahora sería muy distinta. Gracias por todo el tiempo invertido, los numerosos viajes en coche a Ciudad Real, la compañía, el cariño y la confianza depositada en mí. A mis amigos de toda la vida: Carlos, Belén, Gloria y Noelia, gracias por continuar ahí aún después de no poderles prestar toda la atención que se merecían. Gracias por saber entender los «no puedo, tengo que hacer una práctica» y los «tengo que estudiar, otro día quedamos», siempre con respuestas de cariño y apoyo. Pero si a alguien tengo que agradecer el haber podido llegar a este punto, conservando medianamente mi cordura, es a mis compañeros y amigos, los que han estado ahí cada día. Ellos han hecho que no fueran tan duros los madrugones o que mereciera la pena hacer una práctica en grupo, que no siempre eran oficialmente en «grupo», y que me han dado posiblemente muchos de los mejores momentos de mi vida. A María, Carmen, Antonio, Carlos, Roberto, Puche y José, gracias por hacer que esta etapa de mi vida haya sido tan especial, unos han estado ahí desde el primer día, otros llegaron después a mi vida, pero igualmente han alegrado mis días y espero que sigan haciéndolo mucho tiempo, aunque tomemos caminos distintos. Finalmente tengo que agradecer a mi tutora María José la gran labor que ha hecho conmigo y los horarios indefinidos de consultas online durante todo este verano que ha dedicado a ayudarme. Ha sido muy importante para mi trabajar con alguien tan agradable, alguien con quien puedes hablar, que hace que lo difícil parezca fácil y que siempre tiene una palabra amable que decirte. Muchas gracias por todo. Alba IX

16

17 xi A mi familia y amigos, por hacer esto posible

18

19 Índice general Resumen V Abstract VII Agradecimientos IX Índice general XIII Índice de cuadros XVII Índice de figuras XIX Índice de listados XXI Listado de acrónimos XXIII 1. Introducción Sistema de Reconocimiento de Acciones Posibilidades Objetivos Objetivo General Objetivos Específicos Interacción con los sensores de Samsung Galaxy S Buscar voluntarios y recoger datos Enviar la señal a un servidor que la procese Procesar la señal de los sensores Generar los archivos de entrenamiento Entrenar el sistema con LIBSVM Validar el sistema XIII

20 3. Antecedentes Reconocimiento de Acciones Humanas Reconocimiento de Acciones Utilizando Sensores Proyectos Europeos Programa AAL Softcare Sensores de inercia inalámbricos BAN HELP Bag of Words Método y Fases de Trabajo SCRUM Fases de SCRUM Roles y fases de Scrum Herramientas Lenguajes Medios hardware Medios software Desarrollo del Proyecto Aplicación de Recogida de Datos Implementación Recogida de Datos Envío de los Datos y Ventana Deslizante Implementación Procesamiento de los Datos Generación de los Archivos de Entrenamiento Entrenamiento y Clasificación Validación del Sistema Implementación Resultados Matriz de Confusión del Barómetro Matriz de Confusión del Sensor Magnético xiv

21 6.3. Matriz de Confusión del Giroscopio Matriz de Confusión del Acelerómetro Matriz de Confusión del Sensor de Temperatura Matriz de Confusión del Sensor de Humedad Matriz de Confusión del Sensor de Luz Matriz de Confusión del Sensor de Proximidad Matriz de Confusión del GPS Conclusiones Conclusiones Interacción con los sensores de Samsung Galaxy S Buscar voluntarios y recoger datos Enviar la señal a un servidor que la procese Procesar la señal de los sensores Generar los archivos de entrenamiento Entrenar el sistema con LIBSVM Validar el sistema Propuestas A. Generación de Matrices de Confusión 99 B. Formulario de Consentimiento 101 C. Formularios de Consentimiento Firmados 107 D. Conclusión Personal 119 Referencias 121 xv

22

23 Índice de cuadros 4.1. Roles de los integrantes del proyecto Eventos por segundo Pruebas tomadas a los voluntarios Matriz de confusión del Barómetro Matriz de confusión del sensor Magnético Matriz de confusión del Giroscopio Matriz de confusión del Acelerómetro Matriz de confusión del sensor de Temperatura Matriz de confusión del sensor de Humedad Matriz de confusión del sensor de Luz Matriz de confusión del sensor de Proximidad Matriz de confusión del GPS XVII

24

25 Índice de figuras 1.1. Sensores Smartphone Sistema PerSe Objetivos del AAL-2 [AAL] Especificación del Sistema Softcare [Sofa] Proyecto HELP [HEL] Componentes del Sistema HELP [HEL] Sistema [dem] Representación BoW Histograma[Laz10] Matriz de Confusión[Mat] Fases de SCRUM [Pal11] Ciclo de cada iteración [aut14] Diagrama de Gantt de Readmine Eventos del Acelerómetro Jerarquía de Directorios Sensores Samsung Galaxy S4 [Ima] App Recogida de Datos App Recogida de Datos Grabando Jerarquía de Directorios App Recogida de Datos Ficheros de Eventos Ventana Deslizante Diagrama de Secuencia PerSeTCP Diagrama de clases paquete Eventos Ejemplo Sencillo de Ventana Deslizante Aplicación PerSeTCP Extraer la Información en el Servidor XIX

26 5.12. Filtros DWT Descomposición de la Señal [SL11] Formato de los Archivos de Entrenamiento SVM Ejemplo de maximización del margen con SVM Ejemplo simplificado de Matriz de Confusión xx

27 Índice de listados 5.1. Escribir los valores en ficheros Leer ficheros Ventana deslizante Script para entrenar el sistema Script probar.sh Probar el Sistema XXI

28

29 Listado de acrónimos AAL TFG Ambient Assisted Living Trabajo Fin de Grado H2020 Horizonte 2020 BoW API SDK RGB ADT IDE TCP UDP DWT SVM AmI Bag of Words Application Programming Interface Software Development Kit Red Green Blue Android Development Tools Integrated Development Environment Transmission Control Protocol User Datagram Protocol Discrete Wavelet Transform Support Vector Machines Ambient Intelligence XXIII

30

31 Capítulo 1 Introducción LAS tecnologías de la información y la comunicación (TIC) están en continua expansión y cada día en mayor medida se amplía su ámbito de aplicación. Uno de los paradigmas que han aparecido recientemente es el de Ambient Assisted Living (AAL), que tiene como objetivo principal prestar servicios de ayuda a las personas mayores utilizando para ello los dispositivos tecnológicos que están presentes en el entorno de manera natural, como los teléfonos inteligentes (smartphones) o las prendas de ropa y accesorios inteligentes (weareables). La posibilidad de tener los dispositivos tan integrados en la vida del usuario facilita las tareas del AAL. El propósito de estos sistemas AAL es el de facilitar la independencia de los ancianos, dándoles una mejor calidad de vida y una mayor participación en la sociedad. Gracias a estas aplicaciones adquieren más autonomía y confianza en sí mismos, pudiendo además compensar los grandes costes que supone la atención sociosanitaria [evi]. El impacto que el envejecimiento de la población tiene en la sociedad europea ha hecho que ésta preste especial atención a esta cuestión, organizando incluso una Programa Conjunto con titulo "Vida cotidiana asistida por el entorno"(aal) que está impulsado por veinte Estados miembros de la Unión Europea 1 y tres Estados Asociados 2 que publican periódicamente convocatorias de ayudas para proyectos de investigación y desarrollo en este ámbito [ope]. El Programa Conjunto AAL, gestionado conforme al Artículo 169 del Tratado de la Comunidad Europea, pretende solventar algunas dificultades que presenta el envejecimiento de la sociedad a través de la cooperación europea a gran escala. Los objetivos principales de este programa son: A través de servicios TIC tratar de favorecer la calidad de vida de los mayores, dando mayor autonomía y una mayor participación en la vida social y mejorar sus competencias. 1 Estados miembros que participan: Austria, Bélgica, Chipre, Dinamarca, Finlandia, Francia, Alemania, Grecia, Hungría, Irlanda, Italia, Luxemburgo, Países Bajos, Polonia, Portugal, Rumanía, Eslovenia, España, Suecia y el Reino Unido 2 Estados Asociados: Israel, Noruega y Suiza 1

32 A nivel económico, reforzar la base industrial en Europa mediante el uso de las TIC creando un entorno que favorezca la participación de las pequeñas y medianas empresas (PYME) en el programa. Proporcionar un marco europeo coherente que incluya normas comunes mínimas para desarrollar con un enfoque común. De esta forma se facilita la localización y adaptación de soluciones comunes que compatibilicen con la variedad de sociedades y aspectos reglamentarios a nivel nacional y regional de la UE [Cor]. Como se ha comentado anteriormente, este tipo de paradigmas se apoyan en el uso de los objetos de nuestro entorno, que cada vez más a menudo son pequeños sistemas inteligentes. Estos sistemas pueden interactuar y comunicarse, utilizando sensores y actuadores inalámbricos, con otros dispositivos o con otras personas [Ven11]. Este paradigma esta estrechamente relacionado con el de la Inteligencia Ambiental (AMI, Ambient Intelligence), con la diferencia de que el énfasis en el AAL se pone en personas de la tercera edad, pero que en ambos casos trata de promover un entorno en el que la tecnología esté siempre disponible y totalmente integrada en el entorno, de manera casi imperceptible para sus usuarios, simplificando de tal manera su uso que parezca que es el entorno, en sí mismo, el que se autogestiona de manera inteligente [LM09]. Así, podemos decir que el paradigma de la Inteligencia Ambiental pretende dar respuesta a los siguientes retos: Conseguir aumentar las habilidades comunicativas de los objetos inteligentes para que la comunicación hombre-máquina sea lo más natural posible y de esta forma, que la configuración de las preferencias no suponga mucho tiempo al usuario. Tratar de que el usuario se olvide de la presencia del sistema y de esta forma que esté totalmente integrado en su entorno [VR10]. Intentar explorar nuevas formas de interacción persona-ordenador en los entornos más cotidianos [Bie]. El rol que los smartphones o teléfonos móviles de última generación pueden jugar en la habilitación de los contextos concebidos por los paradigmas de AAL o AMI es fundamental, ya que éstos suelen acompañarnos en nuestro día a día y sus capacidades son cada vez mayores. Su uso puede ser muy positivo para el cuidado de personas mayores e incluso de niños. Si tenemos en cuenta además que la atención humana es un recurso limitado, estas tecnologías pueden ayudar a superar esta limitación ofreciendo asistencia desde cualquier dispositivo cotidiano, como un teléfono móvil. Precisamente, este Trabajo Fin de Grado (TFG) se centra en este último aspecto, el de la utilización de los sensores de los teléfonos móviles para poder ofrecer asistencia a las personas de la tercera edad en base a la información que del procesamiento de esos datos 2

33 se pueda derivar. Más concretamente, se utiliza la información obtenida de los sensores para tratar de reconocer la actividad que la persona está realizando en cada momento. 1.1 Sistema de Reconocimiento de Acciones Los nuevos smartphones cuentan cada vez con más sensores (ver Figura 1.1), dando así la posibilidad de utilizar éstos para múltiples funciones, tanto a nivel de ocio, como científico. Figura 1.1: Sensores Smartphone Este proyecto pretende desarrollar un sistema de reconocimiento de acciones gracias a estos sensores. El sistema sigue el siguiente proceso (ver Figura 1.2): En una aplicación Android se recogen los valores que ofrecen los sensores del smartphone. Un algoritmo de ventana deslizante recorre éstos valores y los envía a un servidor. Un servidor procesa los datos usando la Transformada Discreta Wavelet DWT para descartar el ruido y la información redundante de la señal de los sensores. Un proceso de extracción de características con SVM genera los modelos de cada acción. Finalmente se prueba el sistema y se crean matrices de confusión para ver los resultados. 1.2 Posibilidades Una vez reconocidas las actividades y la localización, cualquier otro sistema puede ofrecer funcionalidades más elaboradas en base a estos datos, ajustándose a las particularidades de 3

34 Figura 1.2: Sistema PerSe cada usuario. Si el sistema es capaz de reconocer las actividades del usuario e incluso una rutina diaria que éste lleve a cabo normalmente, otra aplicación podría utilizar esta información para ayudar a esa persona. Algunos ejemplos pueden ser: Realizar una llamada a los servicios de emergencia si se detecta que una persona mayor lleva demasiadas horas sin moverse y puede estar gravemente enferma. Avisar a los padres o tutores de un niño si se detecta en su teléfono móvil que está involucrado en una pelea. Enviar una unidad en busca de una persona con Alzheimer que se ha perdido y ha caminado a mucha distancia de su domicilio. Contactar con los servicios de emergencia si una persona estaba bajando escaleras y de repente se ha detectado un golpe y no se ha movido desde entonces, pudiendo representar que la persona se ha caído y ha quedado inconsciente o gravemente herida. Otra de las posibilidades de este sistema es utilizar la información que ofrecen los sensores para otros usos, interpretando los datos con otros objetivos distintos al reconocimiento de acciones. En otro proyecto es posible que sean necesarios los datos de un sensor concreto (giroscopio, barómetro) para determinar situaciones del entorno de la persona, el clima o la luz o la temperatura. Estos datos pueden ser útiles en entornos de riesgo, en hospitales o en emplazamientos industriales. 4

35 Capítulo 2 Objetivos EN esta sección se presentan los objetivos marcados para el desarrollo de este Trabajo Fin de Grado. Asimismo se expone el ámbito y el alcance al que se espera llegar tras el desarrollo y realización del sistema. 2.1 Objetivo General El objetivo general de este proyecto es el desarrollo de un sistema para el reconocimiento de acciones a partir del análisis de los datos recopilados por los sensores de un teléfono móvil inteligente. Estas acciones son acciones que puede realizar la persona de forma autónoma, por sí misma. Aunque este sistema puede estar dirigido a un público muy variado, el objetivo principal de este trabajo es el de dar soporte a personas de la tercera edad a tener una vida más autónoma e independiente en la medida de lo posible. Es por ello que el nombre de este Trabajo Fin de Grado es PerSe: Person as a Sensor, porque auna la expresión latina «por sí mismo» y simplifica el título completo. Person as a Sensor, es decir, persona como un sensor, ya que su objetivo es que la persona con sus movimientos haga emitir señales a los sensores, como si la propia persona fuese un sensor. 2.2 Objetivos Específicos El objetivo genérico de crear un sistema de reconocimiento de acciones basado en la señal que emiten los sensores de un smartphone se desarrolla a través de una serie de objetivos más específicos que tendrán lugar en el desarrollo de un sistema sobre Android que captura los valores de los sensores y un sistema sobre Linux que procese los datos recogidos por sensores del smarphone e interprete esta señal prediciendo las acciones a las que pertenece. Para el desarrollo de estos objetivos específicos es necesario tener en cuenta una serie de objetivos más concretos: 1 o Objetivo: estudiar los sensores del Samsung Galaxy S4 y cómo interaccionar con ellos. 2 o Objetivo: buscar voluntarios y recoger datos acerca de todas las acciones que se quieran predecir. 5

36 3 o Objetivo: enviar la señal de los sensores recogidos hasta un servidor que procese éstos. 4 o Objetivo: procesar la señal de los sensores utilizando la transformada DWT y más tarde con medidas estadísticas. 5 o Objetivo: generar los archivos de entrenamiento para posteriormente utilizar el clasificador SVM. 6 o Objetivo: entrenar el sistema con LIBSVM. 7 o Objetivo: validar el sistema. Estos objetivos se detallan a continuación Interacción con los sensores de Samsung Galaxy S4 Este objetivo se centra en estudiar qué tipos de sensores tiene el smartphone Samsung Galaxy S4 y desarrollar una aplicación que pueda interactuar con ellos. Se ha de estudiar cómo utilizar las llamadas al sistema operativo Android para que ofrezca información acerca de los sensores y más tarde recoger los valores que ofrezcan éstos. Cuando ya se obtengan los eventos que generan los sensores, éstos han de ser almacenados en archivos para poder procesarse con posterioridad. Estos archivos deben seguir todos el mismo formato para que el procesamiento posterior se ejecute sin problemas Buscar voluntarios y recoger datos Este segundo objetivo consiste en buscar una serie de voluntarios que se ofrezcan a realizar las acciones que se quieren reconocer utilizando la aplicación de recogida de datos. El objetivo es utilizar posteriormente estos datos como dataset (conjunto de datos) para entrenar el sistema. El resultado de este objetivo será un conjunto de archivos, organizados por acción y usuario con el mayor numero de pruebas posible. Todas estas pruebas han de realizarse con el smartphone Samsung Galaxy S4, de forma que la variación de la señal de los sensores sea causada por los usuarios y las acciones y no por usar diferentes terminales Enviar la señal a un servidor que la procese Una vez recopilado el dataset o conjunto de datos generado este se debe procesar de tal forma que la señal emitida por los sensores pueda dividirse en pequeños fragmentos que puedan ser posteriormente caracterizados. Para ello se implementa un algoritmo de ventana deslizante, dividiendo la señal, para después reducir el tamaño del conjunto de datos necesario para caracterizar esa ventana utilizando para ello la transformada DWT. Hay que tener en cuenta que la señal de los sensores debe ser procesada por el algoritmo de ventana deslizante, 6

37 dando la opción de poder elegir el tamaño de la ventana y el tamaño del solapamiento. Estos valores se calcularán empíricamente. Después, estas ventanas se han de enviar a un servidor a través de una conexión TCP para que éste se encargue de procesar la señal con la DWT Procesar la señal de los sensores El servidor ha de recibir la señal de los sensores en forma de ventanas y procesarla para obtener todos los valores. Estos valores han de procesarse ventana a ventana con la Transformada Discreta Wavelet DWT, que elimina la redundancia de la señal y el ruido. Aunque la aplicación de la transformada DWT ha servido para reducir el tamaño del conjunto de datos que caracteriza cada ventana, aún podemos reducirlo más aplicando un conjunto de funciones estadísticas. Se calculará el valor máximo, mínimo, media, varianza y desviación típica de los coeficientes obtenidos tras aplicar la transformada DWT. De esta forma se obtienen las características principales de la señal, con las que después se entrenará el clasificador SVM Generar los archivos de entrenamiento Con el objetivo de entrenar el clasificador más tarde, han de generarse los archivos de entrenamiento. Debe generarse un archivo por cada sensor que incluya los datos procesados por la DWT y las medidas estadísticas en el formato indicado por SVM. Para generar estos archivos de entrenamiento se ha de implementar un módulo que cree un fichero por cada sensor y escriba los cálculos que salgan de cada ventana. Más tarde ha de comprobarse que los ficheros son correctos antes del entrenamiento Entrenar el sistema con LIBSVM Una vez generados los archivos de entrenamiento se ha de entrenar el sistema con ellos. Para esta tarea se debe implementar un módulo que utilice el software para SVM para el entrenamiento, LIBSVM 1. Con las funciones que proporciona este software se debe entrenar el sistema con los archivos de entrenamiento generados a partir de todo el dataset. Este entrenamiento genera modelos, que se han de guardar en ficheros distintos para cada sensor Validar el sistema Finalmente, para validar el sistema se ha de utilizar el sistema de validación cruzada o Leave-One-Out. De esta forma se evalúa cada prueba particular con los modelos de todo dataset menos esa prueba. Así se prueba la precisión del sistema con las distintas pruebas y acciones, obteniendo una medida de la precisión final del sistema desarrollado. 1 cjlin/libsvm/ 7

38 Cuando se obtengan los resultados se deben generar, a través de otro módulo, las matrices de confusión correspondiente a cada sensor. De esta forma se comprueba cómo funciona el sistema para cada sensor y para cada acción. 8

39 Capítulo 3 Antecedentes ESTE capítulo presenta una revisión de los trabajos y tecnologías que, de una u otra forma, anteceden a este TFG. Se presta especial atención a las líneas de investigación abiertas y financiadas por la Unión Europea a través de sus distintas convocatorias porque reflejan la importancia que estos retos tienen sobre la sociedad. 3.1 Reconocimiento de Acciones Humanas Los seres humanos somos capaces de determinar con facilidad qué actividad estamos haciendo nosotros mismos o alguien de nuestro entorno, pero esta capacidad no está inherente en las máquinas. Sin embargo, poder dotar a un dispositivo informático con la capacidad de reconocer la acción que está realizando una persona u otro ente, sigue siendo uno de los grandes retos de la inteligencia artificial. Hoy en día, son muchas las disciplinas interesadas en el avance del reconocimiento de acciones, desde las ciencias de la computación hasta la psicología. Los avances científicos y tecnológicos han cambiado la forma de vida del ser humano; la existencia de las redes sociales, los dispositivos móviles o la computación ubicua proporcionan gran cantidad de información acerca de las personas. Esto ha dado lugar a que muchos investigadores comiencen a trabajar en la creación de sistemas informáticos con capacidad para reconocer acciones e interacciones entre los seres humanos y los sistemas artificiales de su alrededor. Para poder reconocer estas acciones se valen de la observación del comportamiento y del entorno a través de cámaras o sensores [LE14]. Además, el reconocimiento de acciones reduce la necesidad de los seres humanos de supervisar las dificultades particulares de cada persona, especialmente de personas mayores, que puedan depender de una persona para realizar ciertas actividades como levantarse de una caída o salir de la cama. También se puede utilizar en conjunto con el reconocimiento de patrones para determinar los cambios en la rutina de un sujeto. Por estas razones, estas tecnologías tienen muchos usos potenciales en la asistencia sanitaria y el cuidado de ancianos y son muy comunes en el ámbito del AAL. Aunque este área de estudio esté en auge en la actualidad, la necesidad de tomar decisiones a partir de la información que podemos obtener de un agente que interactúa no es un nuevo 9

40 concepto. En los años 40 ya había estudios de este tipo enfocados a los juegos, que estudiaban cómo debería actuar la máquina en los conflictos con oponentes, como en la Teoría de Juegos. Pero es desde finales de los años 90 y principios del 2000 cuando verdaderamente adquiere importancia el reconocimiento de acciones. Gracias a la consolidación del comercio online, la popularidad de las redes sociales y los pasos agigantados a los que avanzaron las tecnologías TIC se comenzaron a promover las investigaciones acerca de «qué hacen los otros?» y empezaron a surgir estudios sobre reconocimiento de actividades basadas en sensores. Todo esto ha dado lugar al desarrollo de aplicaciones activity-aware, sistemas informáticos conscientes de la actividad. El concepto de Awareness se puede entender como el conocimiento de lo que está pasando y puede servir como apoyo en entornos dinámicos, como hospitales o grandes industrias, mejorando el rendimiento y la experiencia de los trabajadores. Son de gran utilidad cuando el contexto de la acción que se quiere reconocer afecta directamente a la acción y más aún, cuando el entorno es cambiante [MM14]. Un sistema sensible al contexto puede «entender» la situación de un usuario y proporcionar un servicio adecuado a él. 3.2 Reconocimiento de Acciones Utilizando Sensores Los avances en telecomunicaciones y redes de sensores han promovido investigaciones sobre computación centradas en las actividades de las personas. Los conceptos de Inteligencia Ambiental (AI), «Internet of things» (Internet de las Cosas) o computación ubicua son, hoy en día, perfectamente conocidos en el ámbito tecnológico. Todos estos términos, de forma general, se refieren a un entorno en el que numerosos dispositivos inteligentes controlan la situación. Pero todo esto no podría llevarse a cabo sin la gran gama de sensores que existen ahora mismo en el mercado. Podemos encontrar múltiples tipos de sensores: acelerómetros, sensores de proximidad, detectores de sonido, de luz, de contacto o de movimiento. Principalmente se utilizan dos tipos de sensores para el reconocimiento de actividades: los sensores portátiles y las redes de sensores estáticos. Si se utilizan sensores portátiles se tiene la ventaja de un dispositivo con posibilidad de movilidad. Es posible colocar los sensores sobre la ropa del individuo, en su smartphone, en un gadget o en su calzado. Son capaces de monitorizar la temperatura corporal, el ritmo cardiaco, la posición del cuerpo, el movimiento o la dirección hacia la que mira la persona si su dispositivo está en su bolsillo. Concretamente los acelerómetros son utilizados de forma muy frecuente para el reconocimiento de actividades que involucran movimiento como caminar, correr o subir escaleras. Algunas investigaciones dan una precisión de acierto en torno al 85 % en el reconocimiento de acciones utilizando varios acelerómetros, pero es incómodo para los usuarios llevar 10

41 encima múltiples acelerómetros colocados en su cuerpo. Es por ello, que en este trabajo se ha procedido a utilizar un smartphone como fuente de sensores no intrusiva, ofreciento así también las ventajas de un producto comercial, fácil de conseguir. Los actuales teléfonos inteligentes no son sólo dispositivos de comunicación, son casi un ordenador personal, están equipados con una serie de sensores muy completa: acelerómetro, giroscopio, barómetro, termómetro y GPS [AA13]. Utilizar un smartphone para el reconocimiento de acciones es mucho más fácil y cómodo para el usuario que utilizar múltiples sensores individuales distribuidos por todo su cuerpo, porque normalmente el usuario ya lo lleva encima [LL10]. Los últimos modelos de smartphone incorporan incluso sensores traxiales, que permiten obtener una información mucho más precisa de los movimientos del terminal [Lee10]. Cabe destacar también los, cada vez más populares, monitores de actividad física. Comúnmente son comercializados en forma de pulsera pero también pueden encontrarse de tamaño bolsillo o incluso pueden ser pequeños dispositivos que se pueden llevar hasta en la zapatilla. Son capaces de detectar la actividad física e incluso medir patrones de sueño. Además de los sensores más comunes como los acelerómetros también cuentan con biosensores, capaces de monitorizar señales biomédicas como el pulso, la presión arterial e incluso la temperatura corporal. Algunos modelos incluso son capaces de determinar qué ejercicio está haciendo el usuario, como abdominales o sentadillas. Un inconveniente de estos dispositivos radica en la necesidad de llevarlo siempre encima, sin que tenga otra función que no sea la de monitorizar. Algunos empresas desarrolladoras han solventado este problema ofreciendo funcionalidades adicionales como la de reloj o la de monitor del propio smartphone, informando sobre llamadas o mensajes de éste, con el que está conectado todo el tiempo. Los monitores de actividad pertenecen a la tecnología wearable, este concepto representa al conjunto de dispositivos electrónicos que se incorporan de alguna forma en el cuerpo, en varias partes o en una sola, con la finalidad de realizar una función específica. Monitores de actividad, gafas, anillos o relojes inteligentes o zapatillas de deporte con GPS incorporado son ejemplos de esta tecnología wearable, cada vez más presente en la sociedad. Las distintas finalidades de estos dispositivos pueden ser: mejorar nuestra calidad de vida en general, mejorar la salud, vigilar la seguridad de las personas que se exponen a riesgos en su trabajo o ayudar en el entrenamiento de los deportistas. Un ejemplo de cómo puede ayudar en la seguridad en el trabajo son los cascos de bomberos inteligentes, que monitorizan los niveles de oxígeno y la temperatura además de llevar un GPS el cual permite conocer en cualquier momento el punto exacto donde se encuentra. Este tipo de tecnología comenzó en la década de 1970, pero no ha sido hasta el 2010 cuando esta tecnología ha evolucionado lo suficiente como para poder captar un amplio abanico 11

42 de consumidores. Empresas como Intel, Sony, Adidas o Rebook comercializan gadgets wearable. Google y Apple han hecho su apuesta con estas tecnologías con las Google glass y el iwatch respectivamente, unas gafas inteligentes y un reloj inteligente [Wea]. Estos dispositivos generalmente se conectan a través de bluetooh u otra tecnología inalámbrica con los smartphones, haciendo uso de alguna aplicación para registrar los valores que van tomando. Con estas aplicaciones se puede hacer un estudio del usuario e informarle, por ejemplo, sobre cuántas calorías ha quemado o la calidad de su sueño. Sin estas aplicaciones, la tecnología wearable quedan muy limitada, ya que llevan displays muy pequeños o simples leds de luz y con ellos no pueden mostrar toda la información. Tanto estos monitores de actividad física, como cualquier sistema que utilice sensores portátiles presentan una desventaja general: durante su desarrollo hay que tener en cuenta el consumo de energía, ya que dependen de una batería. Por ello, en algunos casos, es una mejor opción optar por los sensores fijos, los cuales están unidos a los objetos, por lo que el proceso de reconocimiento de acciones necesita que las personas interactúen con dichos objetos. Pueden estar instalados por ejemplo: en el interior de un coche, en una casa o en una oficina [B.]. En términos generales, en la computación móvil los sensores portátiles son los más utilizados. Por el contrario, en el desarrollo de aplicaciones para entornos inteligentes suelen utilizarse sensores adheridos a objetos. 3.3 Proyectos Europeos La Unión Europea también ha apostado por las investigaciones en el reconocimiento de acciones aplicándolas al Ambient Assisted Living o AAL, en el actual Programa Marco Horizonte 2020 o H2020. Con este programa se pretenden abordar los principales problemas sociales, utilizando la ciencia para promover el liderazgo industrial de Europa. El H2020 tiene un presupuesto de unos 76 millones de euros y se llevará a cabo entre 2014 y Los principales objetivos estratégicos de H2020 son: Fomentar una ciencia de excelencia, reforzando la posición de la Unión Europea en el panorama científico global. Para ello se han aumentado las investigaciones europeas y se han mantenido las actividades del programa de becas Marie Curie 1 para la formación, movilidad y cualificación de investigadores. Desarrollar tecnologías para mejorar la competitividad, para ello se han hecho inversiones en tecnologías TIC, nanotecnologías y biotecnología. Un 20 % del presupuesto está destinado a la participación de las PYMEs en los proyectos colaborativos sobre retos sociales y tecnologías. 1 El programa de becas europeas Marie Curie se enmarca en el VII Programa Marco de Investigación de la Unión Europea. Su objetivo es la financiación de personal investigador. 12

43 Investigar en: salud, alimentación y agricultura, energía, transporte, clima y materias primas, sociedades inclusivas y seguridad; las grandes cuestiones que afectan a los ciudadanos europeos. El objetivo de estas investigaciones es solventar problemas como: el envejecimiento de la sociedad, la protección informática o la transición a una economía eficiente y baja en emisiones de carbono [Hor]. En este último ámbito está incluido el Programa Conjunto AAL-2, Ambient and Assisted Living 2, cuyo objetivo es promover la creación de productos y servicios TIC que respondan a las necesidades de los mayores. En el anterior Programa Conjunto AAL se presentaron más de 125 proyectos, cuyos participantes han contribuido a crear una masa crítica de investigadores a nivel europeo. Se produjo también una gran participación de PYMEs y esto ha permitido continuar con AAL- 2, donde se optimizará aún más la toma de decisiones rápidas y se llevarán a cabo nuevos tipos de apoyo, como premios y subvenciones para la innovación gracias a Horizonte Esta forma de motivar y agradecer los proyectos a los investigadores aporta gran agilidad al programa, ya que se presentan mayor número de proyectos. Los principales objetivos del AAL-2 son comunes al AAL pero con un especial interés en el Reto Social de Salud y en el Cambio Demográfico (ver Figura 3.1). Figura 3.1: Objetivos del AAL-2 [AAL] Facilitar más y mejores productos y servicios para los mayores. Ayudar a las PYMEs especializadas en servicios y productos TIC para la tercera edad. Incrementar la sostenibilidad de los servicios sanitarios y sociales y lograr menores costes, colaborando con las autoridades. 13

44 Favorecer la comunicación a escala europea para lograr mayores sinergias[aal]. 3.4 Programa AAL-2 Para continuar con el éxito del actual programa de investigación, AAL, dedicado a envejecer mejor con las TIC, los nuevos proyectos del AAL-2 tienen como objetivo lanzar productos innovadores y servicios digitales para envejecer mejor. Con la ayuda de la Asociación para la Innovación Europea sobre Envejecimiento Activo y Saludable, EIP AHA, se podrá impulsar aún más el despliegue a escala europea. La Asociación para la Innovación Europea (EIP, European Innovation Partnership) sobre el Envejecimiento Activo y Saludable (AHA, Active and Healthy Ageing) es una iniciativa de la Comisión Europea y tiene la intención de trabajar de forma cooperativa con las herramientas financieras privadas y públicas vigentes en la UE. De esta forma es posible mejorar su eficacia y eficiencia a través de diferentes ámbitos políticos, trabajando en intereses compartidos, actividades y proyectos de innovación tecnológica social. El objetivo primordial de la EIP AHA es aumentar la esperanza de vida saludable de los ciudadanos de la UE en dos años. Persigue cubrir los tres ámbitos de la prevención y el mantenimiento de la salud: cuidado, curación y vida activa e independiente de las personas mayores [VP]. Al igual que el Programa Conjunto AAL, el AAL-2 persigue una triple ventaja para Europa: Permite a los ciudadanos de la UE llevar vidas saludables, activas e independientes mientras envejecen. Ayuda a la sostenibilidad y eficiencia de los sistemas sociales y de salud. Impulsa y mejora la competitividad de los mercados de productos y servicios innovadores, respondiendo al desafío del envejecimiento en la UE a escala mundial, creando así nuevas oportunidades para las empresas. La EIP AHA pretende, por el fuerte compromiso y el liderazgo de todos los interesados, llevar a cabo tres metas: unir recursos y conocimientos, mejora de las condiciones en el ámbito del AHA y acelerar el proceso de innovación, facilitando la ampliación y multiplicación de los proyectos. Muchos proyectos de la AAL-2 con la alianza de la EIP AHA han demostrado un potencial real de implantación en el mercado ya que han obtenido financiación más allá de la duración del proyecto. Algunos de ellos están estrechamente relacionados con los ámbitos de este trabajo [Pro13]. 14

45 3.4.1 Softcare Softcare es un sistema plug and play de monitorización para personas mayores. Gracias a la identificación de patrones es capaz de lanzar alertas en tiempo real y a largo plazo. También está indicado para usuarios en situaciones de peligro. Está coordinado por el Centro de Investigación e Innovación de Catalunya. Las condiciones crónicas en la vejez limitan severamente la capacidad para desarrollar una vida de forma autónoma ya que estas condiciones deben ser tratadas constantemente a través del uso de medicamentos (como es el caso de enfermedades como la diabetes). En otros casos, el paciente tiene problemas de comportamiento relacionados con alguna enfermedad degenerativa, como el Alzheimer y es necesario tomar medidas en su hogar. Aunque estas enfermedades son actualmente incurables, su adecuada gestión puede mejorar en gran medida el bienestar de una persona, ayudándoles a vivir su vejez con una mayor calidad de vida [Sofa]. El sistema Softcare permite alertar a los cuidadores en situaciones peligrosas y también advierte sobre tendencias del usuario potencialmente peligrosas que pueden derivar en un problema en el futuro. A través de la aplicación de técnicas de inteligencia artificial es posible reconocer las actividades diarias de los mayores en base a los datos que se obtienen a partir de un sensor colocado en una pulsera y a la información de la ubicación. Los usuarios deben usar el brazalete que contiene un acelerómetro triaxial que puede reconocer caídas o comportamientos anormales y un módulo Zigbee, que será el encargado de comunicarse con los dispositivos estáticos instalados en el domicilio, uno por habitación. Además, como es una herramienta de apoyo, cuenta con un canal de comunicación de voz manos libres full-duplex que funciona como centro de llamadas de emergencia. Para poder comunicarse a través de este canal los dispositivos estáticos tienen un sistema de altavoces y micrófonos (ver Figura 3.2). El sistema contará con: Detección de caídas en interiores y exteriores. Reconocimiento de patrones de comportamiento basado en la actividad y la información de localización. Detección de situaciones de riesgo en base al conocimiento experto. El proyecto tiene un presupuesto total de ,94 euros. El plan de negocios proporcionó estimaciones muy positivas, previendose en 2018 en torno a usuarios con ingresos aproximados de 66 millones de euros por la venta de dispositivos y por prestación de servicios [Sofb]. Podemos ver que el reconocimiento de acciones en estos ámbitos del AI y el AAL son fructíferos y prácticos. Otro de los proyectos que utilizan estas técnicas para dar calidad de 15

46 Figura 3.2: Especificación del Sistema Softcare [Sofa] vida a las personas mayores el proyecto Wireless Inertial Sensor [Ine] del Instituto Nacional Tyndall, en Irlanda del sur, el cual se trata a continuación Sensores de inercia inalámbricos El programa AAL-2 también cuenta con un proyecto basado en un sensor de inercia inalámbrico para la alerta temprana de eventos clínicos, Wireless Inertial Sensors. Instituto Nacional Tyndall (Irlanda) en colaboración con médicos, investigadores y académicos ha creado este proyecto para ofrecer soluciones tanto en el diagnóstico, como en la fase terapéutica y en el seguimiento de las enfermedades de las personas mayores. Wireless Inertial Sensors permite un flujo continuo de datos sobre el movimiento de los pacientes durante las primeras 24 horas después de su ingreso en la Unidad de Atención al Anciano. El reconocimiento de acciones del paciente en la asistencia sanitaria abarca un gran abanico de posibilidades, algunos ejemplos pueden ser: Medir de las mejoras de un paciente. Monitorizar la rehabilitación de un accidente cerebrovascular. Reconocer de forma precóz la aparición de Alzheimer o la demencia. En un estudio que está llevando a cabo en el Hospital General Nenagh de Irlanda, los pacientes son monitorizados utilizando dispositivos de medición inercial inalámbricos Tyndall durante sus primeras 24 horas ingresados en la Unidad de Atención al Anciano. Estos dispositivos, desarrollados por el Instituto Nacional Tyndall, transmiten todos los movimientos registrados durante este período de tiempo. Estos flujos continuos de datos se analizan exhaustivamente para determinar si existen diferentes patrones de movimiento y éstos se 16

47 pueden correlacionar con modelos clínicos. Esta es la gran ventaja de la tecnología de medición inercial inalámbrica, la capacidad de identificar pacientes en riesgo de muerte inminente o deterioro clínico generalizado [Ine]. El Instituto Nacional Tyndall lleva a cabo otro proyecto además de este en el AAL-2, BAN, Body Area Networks [BAN] BAN Body Area Networks (Redes de Área Corporal) es un proyecto del Instituto Nacional Tyndall que comprende un conjunto de componentes clínicamente relevantes y fiables de redes de área corporal. Todos los componentes se unen mediante firmware empotrado de forma que se obtiene una solución fácil de usar, rentable y escalable para pacientes que necesitan vigilancia y monitorización. Esta plataforma se utilizará para validar sensores de última generación desarrollados por distintos socios comerciales. La plataforma BAN está desarrollada no sólo para detectar y controlar parámetros tales como la presión arterial, los patrones de posición y movimiento, sino que estos datos serán fusionados y aplicados a la vigilancia de la biomecánica, la cardiología y la rehabilitación. Por ejemplo, podrían ser utilizado para controlar los factores de riesgo asociados con accidentes cerebrovasculares, pero también podría ser utilizado en un contexto de post-accidente cerebrovascular como parte de una rehabilitación. Para ello se utilizan sensores que son capaces de medir la respuesta galvánica de la piel, la oximetría del pulso, la biomecánica de los movimientos de la mano, el PH e incluso el sudor. BAN utiliza también sensores de temperatura, de luz, de humedad, así como tecnologías de medición inteligente que se pueden encontrar en el mercado actualmente, como los monitores de actividad física. Estos dispositivos permiten la extrapolación de los movimientos y actividades de los pacientes en el entorno del hogar. Esta nueva combinación de detección inalámbrica de los parámetros críticos seleccionados junto con nuevos algoritmos para la fusión de datos facilitará la vida independiente de las personas en riesgo de accidente cerebrovascular, enfermedad cardíaca o de los pacientes sometidos a rehabilitación [BAN]. En relación a este proyecto existe un proyecto español exclusivamente dedicado a tratar pacientes con Parkinson, el proyecto HELP [HEL] HELP El proyecto HELP (Home-based Empowered living for Parkinson s Disease Patients), de la Universitat Politècnica de Catalunya, es un sistema que monitoriza los síntomas de los pacientes de Parkinson en tiempo real y administra la medicación necesaria según los síntomas. Cuenta con un sensor que detecta los síntomas de la EP y un dispositivo intraoral para administrar los medicamentos de una manera no invasiva. 17

48 Este sistema de monitorización de la salud está expresamente dirigido a las necesidades de las personas con Parkinson. Sin tratamiento, la enfermedad avanza de tal modo que aproximadamente entre los 5 y los 10 años siguientes la persona se encuentra en un estado rígido, de forma que los pacientes son incapaces de cuidarse por sí mismos. Frecuentemente, los pacientes mueren a causa de las complicaciones que supone la inmovilidad, incluyendo neumonías o embolias pulmonares. La disponibilidad de un tratamiento farmacológico eficaz ha alterado radicalmente el pronóstico del Parkinson; en la mayoría de los casos puede mantenerse durante muchos años una buena movilidad funcional y la esperanza de vida ha aumentado sustancialmente. En primer lugar, las terapias están dirigidas a minimizar los síntomas y a maximizar la calidad de vida. Sin embargo, es necesario tener un cuidado intensivo, lo que requiere una gran cantidad de recursos económicos y humanos, además de los estrictamente médicos. Este proyecto propone una forma alternativa de hacer frente a la enfermedad (ver Figura 3.3), no sólo en el cuidado de los pacientes a nivel individual, sino también en la optimización de la rentabilidad de los planes sanitarios. El sistema HELP cuenta con presupuesto de euros y sus características principales son las siguientes: Un sensor corporal y un actuador de red (BS and AN, Body Sensor and Actuator Network) formados por dispositivos portátiles, wearable y estáticos en el hogar para controlar los parámetros de salud. Por ejemplo, para medir la presión arterial y la actividad corporal para detectar el movimiento o la ausencia de movimiento y para liberar la cantidad controlada de fármacos de una manera automática. Una unidad remota Point-of-Care para supervisar a los pacientes bajo el control de especialistas clínicos. El proyecto HELP podrá suministrar cantidades específicas de medicamentos de acuerdo a las necesidades, según la actividad física, en cualquier momento. Debido a que es un sistema de liberación continua del fármaco se evitan los excesos de medicamento y también los bajos niveles que se producen en una administración de medicamento normal. De esta forma se mejoran los síntomas de la enfermedad [HEL]. Los componentes son: una bomba subcutánea, un cartucho intraoral insertado en la boca de los pacientes, un sensor de movimiento portátil, un dispositivo para medir la presión arterial y un sistema de control que envía constantemente los datos, lleva el control del paciente y calcula la cantidad adecuada de medicamento a suministrar (ver Figura 3.4). Telefónica, el Consorcio Sanitario Garraf y la Universitat Politécnica de Catalunya publicaron los primeros resultados en el marco del Día Internacional del Parkinson. En la primera fase del proyecto se ha contado con la participación de siete pacientes, seis de ellos en España. En cuatro de los seis pacientes se apreciaron buenos resultados. Dos de ellos estaban obligados a utilizar inyecciones de «rescate» a menudo y gracias al sistema pudieron reducir 18

49 Figura 3.3: Proyecto HELP [HEL] Figura 3.4: Componentes del Sistema HELP [HEL] el número de éstas. Los otros dos pacientes incrementaron considerablemente el tiempo que permanecían sin síntomas. Los pacientes llevaban ajustado a su cintura el dispositivo formado por un pequeño sensor portátil, que capta los movimientos del paciente. El sistema, como se explicaba anteriormente, utiliza una bomba subcutánea, que administra medicación para el control de los síntomas. 19

50 El sensor detecta si el el paciente empeora e informa al sistema a través de el móvil y éste da instrucciones a la bomba del fármaco para que aumente la dosis y trate los síntomas. Si el paciente mejora se reduce la dosis de medicamento para que vuelva a la normalidad. Usando este sistema el paciente siempre recibe la dosis necesaria en el momento que lo necesita. Los datos que recoge el sensor y las reacciones que tiene el paciente tras la medicación se envían a un centro de asistencia. Desde este centro de asistencia, que también forma parte del sistema, los médicos especialistas pueden controlar los dispositivos a través de Internet y pueden observar cómo evolucionan los pacientes. Asimismo, les permite interactuar con el paciente e intervenir en los casos en que sea necesario. Hasta el momento no existe ningún otro tratamiento capaz de resolver los síntomas justo cuando se producen. La suministración común del medicamento resulta insuficiente para controlar los síntomas en determinados momentos y, sin embargo, resulta excesiva en otros, de manera que los pacientes pueden experimentar efectos adversos. Gracias a este sistema se actúa de forma dinámica y en tiempo real en función de la gravedad de los síntomas que sufra el paciente, mejorando así la calidad de vida del paciente. En este proyecto se ha unido el trabajo de instituciones y empresas alemanas, HSG-IMIT y Neusta, israelitas, Nevet i Peh-Med, italianas, Telecom Italia y la Universidad de Palermo y españolas, como son Telefónica I+D, el Centro de Estudios Tecnológicos para la Dependencia y la Vida Autónoma de la UPC y las Fundación Hospital Comarcal Sant Antoni Abat de Vilanova i la Geltrú. Además se ha creado una empresa spin-off de la Universitat Politècnica de Catalunya, Sense4Care, para comercializar el sensor [Res] es un proyecto que aspira a contribuir al fomento de la auto-independencia de las personas con demencia, insistiendo en la comprensión de cómo la enfermedad afecta a sus vidas y al comportamiento cotidiano. La solución que plantea es un sistema de gestión remota, en bucle cerrado multi-paramétrico, el cual se retroalimenta de forma adaptativa a la persona con la demencia. Al mismo tiempo informa a los médicos sobre el seguimiento remoto, lo que les permite mantener una visión completa del estado de salud y el progreso de la persona afectada. El objetivo es proporcionar las estructuras de conocimiento y análisis inteligente y procedimientos de toma de decisiones que permitan la interpretación personalizada de la conducta de una persona y la prestación de servicios de gestión y apoyo debidamente adaptados. El sistema incluye (ver Figura 3.5): Un bucle para las personas con demencia y sus cuidadores, para vigilar y evaluar su estado cognitivo y su conducta mediante la integración de una multiplicidad de sensores portátiles y sensores fijos. De esta forma se obtiene la evolución del paciente en 20

51 Figura 3.5: Sistema [dem] el tiempo, formando un perfil contextual que apoya la atención reactiva y proactiva, y personalizando el sistema de forma que se retroalimente y sea adaptable. Un bucle para los empleados de la clínica de demencia para proporcionar observaciones objetivas sobre la progresión de la salud de la persona con demencia y la efectividad de los medicamentos. Estos datos informan sobre las tendencias estrechamente asociadas a la demencia, como por ejemplo, la apatía y ayudan a la toma de decisiones sobre la atención preventiva y el ajuste del tratamiento. El equipo médico del proyecto determinará los requisitos clínicos y medidas de sensores necesarios para satisfacer las necesidades de las personas con demencia y sus cuidadores. Los sensores serán no intrusivos, pudiendo ser hasta sensores wearable, para las mediciones fisiológicas y serán desplegados para proporcionar una imagen constante y precisa del estado de salud de la persona con demencia. Este proyecto complementa la extracción de características sobre salud y estilo de vida con características de Inteligencia Ambiental Médica. La percepción visual permite la detección y el reconocimiento de situaciones de interés, el análisis del audio permite caracterizar el comportamiento del paciente y su estado mental y emocional. El seguimiento de actividades se registra para su posterior análisis, se almacenan la caracterización de las acciones de la persona y la organización de los eventos detectados [dem]. 21

52 3.5 Bag of Words Una vez revisados los esfuerzos que desde la Unión Europea se están desarrollando para fomentar los sistemas que, sobre la base del reconocimiento de acciones, ayuden a mejorar la vida de mayores y dependientes, esta sección revisará el método elegido para llevar a cabo ese reconocimiento sobre la base de la información proporcionada por los sensores de un smartphone. El reconocimiento de acciones, imágenes o cualquier otro elemento, como se ha podido ver reflejado en el plan Horizonte 2020, es un campo que está recibiendo cada vez más atención por parte de la comunidad científica. La primera etapa de cualquier sistema de reconocimiento consiste en la recogida de información, para cual se puede recurrir a sensores muy diversos como se ha podido comprobar en los apartados anteriores (wearables, pulseras o sensores diversos en un smartphone). La segunda etapa de este reconocimiento consistirá en el proceso de clasificación, según el cual los datos recogidos se clasificarán en uno de los distintos grupos con los que el sistema ha sido entrenado para reconocer. En el reconocimiento de imágenes se utiliza muy comúnmente el modelo Bag of Words (BOW) que básicamente consiste en representar los objetos a reconocer como un conjunto reducido de características, que en el caso de las imágenes podrán ser por ejemplo los puntos de interés de éstas. Así, el modelo Bag of Words (bolsa de palabras) es uno de los métodos de representación más populares para la recuperación de imágenes [Csu04] basada en contenido, permitiendo la implementación de buscadores de imágenes que encuentran la solución a una consulta basándose en si la imagen contiene o no ciertos objetos, en función de su contenido visual y no de las anotaciones textuales colindantes. Otros ejemplos a los que ha sido aplicado este modelo son los detectores de rostro en fotografías o sistemas de recuperación de imágenes médicas. El modelo BOW fue originariamente planteado como solución para el análisis de textos [Coh06] aunque su adaptación al campo del análisis de imágenes rápidamente demostró que éste era un enfoque novedoso con resultados muy prometedores. El modelo BOW [Zha10] consiste básicamente en obtener en primer lugar una representación reducida del conjunto de datos original, a través de lo que se conoce como vector de características. Durante la fase de entrenamiento esos vectores de características se agruparán en clústers, de tal forma que cada clúster será el equivalente a lo que en el contexto del análisis de documentos de textos sería una palabra. Las palabras visuales 2 son unidades de representación de un objeto (ver Figura 3.6) y, una vez identificadas, se procede a lo que en la analogía del análisis de documentos sería la cuantificación del número de ocurrencias de cada palabra, que en el caso de las imágenes o cualquier otro tipo de datos consistirá en la representación del histograma como medida de la distancia que separa el vector de características de cada uno de los clústers 2 Palabra visual es el término con el que en el contexto del análisis de imagen se refiere a cada vector de características. 22

53 identificados durante la etapa de clasificación. Figura 3.6: Representación BoW Cuando se procesan imágenes se representan las palabras visuales que se encuentran en ellas en un histograma. Este es un paso crucial para determinar qué características aparecen más a menudo en imágenes de entrenamiento, pudiendo así determinar la probabilidad de que una imagen desconocida pertenezca a una escena en particular en base a la frecuencia relativa de sus características o palabras visuales. De esta forma se puede saber qué características aparecen más a menudo en cada escena. Si tomamos como ejemplo tres imágenes similares, pero con texturas diferentes (ver Figura 3.7), en los histogramas se refleja claramente un pico en las barras que representan la cuantía de palabras visuales encontradas. Estos picos, o valores altos, dejan ver claramente qué palabras o características son predominantes en esa imagen. Si esas palabras visuales pertenecieran a un vocabulario visual general, a modo de diccionario, podríamos ver qué palabras de ese conjunto aparecen en mayor número en cualquier imagen que queramos procesar. Por lo tanto, una imagen desconocida que contiene una alta frecuencia relativa de una característica es muy probable que pertenezca a una escena que contenga esa característica. Después de calcular los histogramas se utiliza comúnmente el modelo SVM [Cha14] para proceder a la clasificación. Un modelo SVM, Support Vector Machine (Soporte para Máquinas de Vectores) es una representación de características de un modelo en el espacio, mapeados de forma que pueden verse grupos separados de puntos en varias categorías, divididas por un espacio de claridad tan amplio como sea posible. Los SVM han tenido un éxito significativo en numerosos sistemas que necesitan aprendizaje de elementos del mundo real, inicialmente fue creado para la categorización de texto. 23

54 Figura 3.7: Histograma[Laz10] Sin embargo, como la mayoría de los algoritmos de aprendizaje automático, se aplican generalmente mediante un conjunto de entrenamiento [Ton02]. El resultado de la etapa de entrenamiento del clasificador será el cómputo de un modelo. Este modelo consiste en un hiperplano que separa cada uno de los conjuntos de histogramas que se han utilizado para describir cada documento, imagen o acción que el clasificador debe reconocer. Una vez generador el modelo, para comprobar que este funciona correctamente es necesario evaluar el sistema y calcular su precisión. Para ello, es bastante común en estos casos la elaboración de una matriz de confusión en la que cada columna representa un tipo (imagen, acción u otra cosa que quiera clasificarse), y cada fila representa instancias de una tipo real. En la imagen (ver Figura 3.8) se puede ver cómo el modelo obtenido confunden determinadas instancias, como por ejemplo el 6 con el 2 o el 2 con el 10. Esto permite evaluar fácilmente si una clase está siendo confundida por otra y en qué medida. Una métrica de la precisión de clasificador obtenido se podrá obtener, por lo tanto, tomando la media de la diagonal de la matriz de confusión, pues esta representa las clasificaciones que se han hecho de forma correcta, dividiéndose por el número de pruebas utilizadas [New11]. 24

55 Figura 3.8: Matriz de Confusión[Mat] 25

56

57 Capítulo 4 Método y Fases de Trabajo EN esta sección se expone la metodología de trabajo seguida para llevar a cabo el desarrollo de este proyecto, en este caso una metodología ágil [Poo09]. Las metodologías tradicionales hacen énfasis en el control del desarrollo de los proyectos mediante una rigurosa definición de roles y de actividades. Son efectivas en proyectos de gran tamaño, sin embargo, este enfoque no resulta ser tan eficaz para proyectos cuyo entorno varía de forma notable y en donde se exige una gran reducción de los tiempos de desarrollo, pero manteniendo una alta calidad. Ante esta situación muchos equipos de desarrollo dejan a un lado la ingeniería del software, asumiendo los riesgos que eso conlleva. Las metodologías ágiles surgieron como respuesta a ese problema. Las metodologías ágiles son una solución a medida para pequeños proyectos, simplificando sin renunciar a lo esencial para asegurar la calidad del proyecto. El objetivo de este tipo de metodología es permitir a los equipos de trabajo desarrollar rápidamente software, respondiendo a los diferentes cambios que puedan surgir a lo largo del desarrollo del proyecto. Estas metodologías siguen «El Manifiesto Ágil» [UA07], en el cual se valora: Al individuo y a las interacciones del equipo de desarrollo más que al proceso y a las herramientas. El desarrollo de software que funciona por encima de obtener una buena documentación. Colaborar con el cliente sobre la negociación de un contrato. Responder a los cambios más que seguir estrictamente un plan. Existen varias metodologías ágiles, cada una con características propias que hacen hincapié en ciertos aspectos más específicos. Algunas de ellas son [CP03]: SCRUM 1 : especialmente indicada para proyectos en los que se suceden cambios en los requisitos. El proceso de desarrollo de software se realiza mediante sprints, iteraciones. 1 https://www.scrum.org/ 27

58 El resultado de cada sprint debe poder ejecutarse y es mostrado al cliente. Se da mucha importancia a las reuniones con el equipo. Crystal Methodologies 2 : centrada en las personas que forman el equipo y en la reducción del número de artefactos producidos. Considera el desarrollo de software como un juego cooperativo de invención y comunicación entre el equipo, sólo limitado por los recursos a utilizar. Es muy importante el equipo de desarrollo, se esfuerza en mejorar sus cualidades y en llevar a cabo políticas de trabajo en grupo. Dynamic Systems Development Method 3 : es un proceso iterativo e incremental en el que la clave es la cooperación entre el equipo de desarrollo y el usuario. Cuenta con cinco fases: estudio de viabilidad, estudio del negocio, modelado de la funcionalidad, diseño y construcción e implementación. Adaptive Software Development 4 : orientado a los componentes software más que a las tareas. Es un sistema iterativo tolerante a los cambios con tres fases esenciales: especulación, colaboración y aprendizaje. Se inicia el proyecto y se planifican las características del software; se desarrollan las características y se revisa su calidad, y finalmente se entrega al cliente. Para corregir los errores se revisan los componentes y se vuelve a iniciar el ciclo de desarrollo. Lean Development 5 : considera riesgos a los cambios, pero si se solucionan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal diferencia es introducir un mecanismo para llevar a cabo estos cambios. Para el desarrollo de este proyecto se ha decidido seguir la metodología Scrum [lib01] por su estrategia de desarrollo iterativo e incremental. En ella, cada iteración genera un resultado completo, de forma que los resultados de las iteraciones anteriores son necesarias para realizar las siguientes. De esta manera, ofreciendo cada iteración un resultado completo, se minimizan los errores del proyecto general. 4.1 SCRUM Las características principales de Scrum son: La primera y la última fase han de tener definidos sus procesos, entradas y salidas. El conocimiento de cómo se van a llevar a cabo estos procesos es explícito y se basa en hacer un repositorio con todas las actividades a realizar llamado Backlog System. El trabajo se desarrolla en iteraciones de duración máxima de 4 semanas, llamadas sprints. Mediante reuniones el equipo toma decisiones acerca de qué incluir en cada iteración, con estimaciones de tiempo para finalizar las tareas

59 Estos sprints son flexibles y no lineales. El beneficio que aporte al proyecto completo el resultado de cada sprint determina la prioridad de éste. Cuando finaliza se realiza una entrega parcial. En cada sprint se realizan reuniones diarias llamadas Scrum Meetings en las cuales el desarrollador se pregunta: Qué ha desarrollado desde la última reunión? Qué dificultades concretas tiene el desarrollo de esa tarea? Qué se va a llevar a cabo hasta la próxima reunión? El proyecto se mantiene abierto hasta la fase de clausura, pudiéndose planificar la entrega en cualquiera de las fases anteriores. De esta forma el proyecto se mantiene abierto a la complejidad del entorno, al tiempo o a la presión financiera durante el desarrollo de esas fases. Esta metodología está hecha para ser flexible durante el desarrollo de los sistemas, de forma que permite cambiar el proyecto y las entregas en cualquier punto en el que sea necesario. Permite a los desarrolladores inventar soluciones más ingeniosas y prácticas a los retos que van surgiendo en el proyecto. Por todos estos motivos es práctico y eficaz trabajar con esta metodología para elaborar este proyecto, ya que es muy probable que haya que hacer cambios en los requisitos en los plazos de entrega a lo largo del proyecto. Esto es debido a que no se puede saber cómo responderá el sistema, si reconocerá o no las acciones, y a que el tiempo con el que se cuenta es limitado. Usando Scrum evitamos los inconvenientes de las clásicas metodologías, en las cuales el proceso de desarrollo está definido por completo desde el principio. También resulta conveniente que tengamos completas las iteraciones para continuar con las siguientes y que este resultado no pueda ser alterado, ya que lo necesitamos para llevar a cabo la siguiente iteración. Otro de los motivos principales por el que se ha elegido Scrum como metodología es que permite que cada equipo esté formado solamente por un integrante, aspecto que se refleja directamente en este proyecto Fases de SCRUM Las diferentes fases del Scrum consisten en: pre-juego, juego y post-juego (ver Figura 4.1). Pre-juego Esta fase se divide en dos: planificación y arquitectura. 29

60 Figura 4.1: Fases de SCRUM [Pal11] Planificación: se define una nueva entrega basándose en un Backlog 6 que proporciona el cliente el coste y cronograma estimados. Si un nuevo sistema empieza a desarrollarse, esta fase consiste en conceptualización y análisis. Arquitectura: diseña el plan en el que los requisitos del Backlog son implementados. Esta fase incluye la creación o modificación de la arquitectura del sistema y el diseño de alto nivel. Las iteraciones se organizan en base a la prioridad que tienen asignada en el Product Backlog list. Además hay que tener en cuenta las dependencias que pueden existir entre las tareas. Juego En esta fase se lleva a cabo el desarrollo de los sprints, desarrollando la nueva funcionalidad, es decir, se lleva a cabo la ejecución de cada iteración. Son múltiples los sprints o ciclos usados para desarrollar el sistema. Dentro de un sprint la retroalimentación se obtiene con las reuniones diarias, y el control de la curva de progreso. En cada iteración son llevadas a cabo varias acciones: Planificación: se divide el trabajo de la iteración en varias tareas y se definen los objetivos de estas. Análisis de requisitos: se determinan los requisitos que se deben conseguir al desarrollar la iteración. 6 Lista de requisitos priorizada para desarrollar el proyecto. 30

61 Diseño: se diseñan diagramas esquemáticos para facilitar la comprensión de las acciones y tareas a realizar en cada iteración. Codificación: se implementa la funcionalidad de la iteración. Revisión: se lleva a cabo la verificación del sistema, revisando que no haya errores. Además hay que asegurarse de que se han cumplido los objetivos determinados. Post-juego Cuando se completa la iteración, incluyendo la documentación final y la prueba, se tienen que exponer al cliente los resultados del desarrollo y expecificar los requisitos cumplidos. Esto debe hacerse en una reunión llamada Sprint Review. Gracias a Scrum el cliente puede realizar cambios y reajustar el proyecto en el caso de que los resultados mostrados en la reunión cumplan sus expectativas [ODMR08] Roles y fases de Scrum Roles Scrum Para seguir la metodología Scrum es necesario definir los roles que seguirá el equipo de desarrollo. A continuación se exponen los diferentes roles que se han asignado a los diferentes integrantes de este proyecto (ver Cuadro 4.1). ROLES Cliente (Product Owner) Equipo desarrollador (Scrum Team) Director del equipo (Scrum Master) INTEGRANTES María José Santofimia Romero y Félix Jesús Villanueva Molina Alba Barón Rubio María José Santofimia Romero y Félix Jesús Villanueva Molina Cuadro 4.1: Roles de los integrantes del proyecto Para el caso particular de este proyecto no ha sido necesario recurrir al rol auxiliar de manager ni al de stakeholder. Fases Scrum En este apartado se describen las distintas iteraciones en las que se divide este proyecto basándonos en la metodología ágil Scrum. El desarrollo de este proyecto se divide en siete sprints o iteraciones, cada uno de ellos aporta una nueva funcionalidad ejecutable al proyecto principal. Cada sprint sigue el mismo esquema (ver Figura 4.2), siguiendo este se ha llevado a cabo la adaptación del proyecto PerSe a este modelo de trabajo. Las fases son las siguientes: Pre-juego 31

62 Figura 4.2: Ciclo de cada iteración [aut14] Planificación: basándose en los objetivos descritos en los objetivos (véase Capítulo 2) se debe construir un sistema de reconocimiento de acciones a partir de la información recogida por los sensores de un smartphone. Los sprints en Scrum tienen una duración comprendida entre 1 y 4 semanas, esta cuantía va variando según la complejidad de las tareas que implique la iteración. También ha de tenerse en cuenta que el desarrollo del proyecto se ha llevado a cabo solapado con la superación de las últimas asignaturas de la titulación de Grado en Ingeniería Informática. Esto afecta directamente a la dedicación que se le ha podido otorgar a la realización del proyecto. El Product Backlog List definido por el cliente es el siguiente: 1 o Objetivo: estudio de los sensores del Samnsung Galaxy S4 y de cómo interaccionar con ellos. 2 o Objetivo: recogida y etiquetado de datos con el smartphone y su puesta a disposición. 3 o Objetivo: envío de los datos recogidos hasta un servidor que procese éstos. 4 o Objetivo: procesamiento de los datos utilizando la transformada DWT y medidas estadísticas. 5 o Objetivo: generación de los archivos de entrenamiento para posteriormente utilizar el clasificador SVM. 6 o Objetivo: fases de entrenamiento y clasificación con LIBSVM 7. 7 o Objetivo: desarrollo del sistema de validación. Arquitectura: el Product Backlog presentado por el cliente contiene los objetivos a conseguir, ordenados por prioridad temporal, de forma que se debe seguir el orden 7 cjlin/libsvm/ 32

63 establecido en esta lista de trabajo para el desarrollo del proyecto. Es necesario mantener el orden porque las tareas tienen dependencia entre ellas y es necesario el resultado de una para realizar la siguiente. Por lo tanto el Sprint Planning queda definido de la siguiente manera: 1 o Iteración: desarrollo de una aplicación Android 8 para la recogida de datos de los sensores en archivos. 2 o Iteración: búsqueda de voluntarios y realización de las pruebas para la recogida de datos con el smartphone para el entrenamiento del sistema. 3 o Iteración: desarrollo de otra aplicación Android para el envío de los datos recogidos hasta un servidor que procese éstos y los emita en forma de ventana deslizante. 4 o Iteración: implementación del servidor que recibe los datos y los procesa. Para procesar los datos se utiliza la transformada DWT y también medidas estadísticas. 5 o Iteración: implementación del módulo que genera los archivos de entrenamiento para SVM. 6 o Iteración: creación del software que lleva a cabo el entrenamiento y clasificación con el módulo LIBSVM. 7 o Iteración: desarrollo del programa de validación del sistema, el cual genera matrices de confusión para ver los resultados. Juego Para llevar a cabo el Sprint Planning se ha recurrido a utilizar el gestor de proyectos de software libre «Redmine 9» (ver Figura 4.3), con el cual se ha organizado el trabajo en tareas para simplificar la coordinación entre los distintos integrantes del equipo. Figura 4.3: Diagrama de Gantt de Readmine Iteración 1: aplicación de recogida de datos de los sensores Planificación: implementación de una aplicación Android capaz de leer los valores que ofrecen los sensores del smartphone

64 Análisis de requisitos: la aplicación debe almacenar en archivos, etiquetados con la identificación del actor y el sensor, los valores que ofrecen los sensores para su posterior procesamiento. Diseño: la aplicación debe ser simple e intuitiva, para que todos los voluntarios puedan realizar las pruebas de forma independiente. Los valores de los sensores deben guardarse en archivos ordenados por eventos (ver Figura 4.4). Estos archivos deben ser almacenados siguiendo una jerarquía de directorios (ver Figura 4.5). Figura 4.4: Eventos del Acelerómetro Codificación: se desarrolla una aplicación Android, en lenguaje Java, para recoger los datos de los sensores en el smartphone Samsung Galaxy S4. Esta app ha de tener una interfaz sencilla en la cual el usuario debe introducir su nombre y elegir una actividad para grabarla. Revisión: cerciorarse de que se guardan todos los datos, aunque el teléfono se encuentre bloqueado y que se guardan en el archivo correcto. Iteración 2: recogida de datos con el smartphone Planificación: búsqueda de voluntarios, toma de contacto con la aplicación y posteriormente grabación de los datos. Idealmente, cada voluntario realiza las 14 acciones a predecir en el sistema. Análisis de requisitos: elaboración e impresión de los contratos de consentimiento para la protección de los datos personales. Utilización exclusiva del smartphone Samsung Galaxy S4 para hacer las pruebas, de modo que los valores sean semejantes aunque varíe el usuario. Diseño: las pruebas han de hacerse preferiblemente en un entorno apropiado, ya que existen acciones como: caerse, patada o puñetazo, que exigen tener algunos materiales para evitar accidentes (material deportivo como colchonetas o punching balls). Codificación: se llevan a cabo las pruebas de los voluntarios y se cumplimentan los formularios de consentimiento. Revisión: verificar que los datos se han organizado y almacenado correctamente y que todos los formularios de consentimiento se han firmado y completado debidamente. 34

65 Figura 4.5: Jerarquía de Directorios Iteración 3: aplicación para el envío de los datos recogidos hasta un servidor Planificación: implementación de una aplicación Android, en Java, que envía los datos recogidos en el directorio Sensores hasta un servidor TCP. Análisis de requisitos: los datos han de enviarse implementando una ventana deslizante. Esta ventana debe permitir modificar fácilmente sus parámetros de solapamiento y dimensión, para poder ajustar su precisión al completar el sistema. Diseño: la aplicación debe ser sencilla y debe ser flexible para poderla unir a la anterior aplicación en un futuro y hacer que el sistema envíe los datos a tiempo real. Junto a los eventos debe indicar el tipo de acción y el tipo de sensor. Codificación: se implementa la aplicación en la que se especifican varios tipos de eventos, ya que el smartphone ofrece 3 tipos de eventos según el tipo de sensor: 3 35

66 valores, 2 valores o 1 valor. Los sensores triaxiales ofrecen 3 valores, el GPS ofrece 2 y el resto de sensores 1. Revisión: verificar que los datos se envían correctamente, que las ventanas tienen el tamaño indicado y el solapamiento determinado en el código. Iteración 4: servidor que recibe los datos y los procesa con la transformada DWT y medidas estadísticas. Planificación: implementación de un servidor TCP en lenguaje Python que recibe los datos de la aplicación anterior y los procesa. Análisis de requisitos: los datos de los sensores deben procesarse en bloques, definidos por las ventanas. Cada ventana es procesada por la transformada DWT, con el objetivo de eliminar «ruido» de los datos como si de una señal analógica se tratase, de esta forma, se eliminan los picos de valores y los datos inservibles. Asimismo, los coeficientes devueltos por la transformada DWT deben ser procesados de nuevo, calculando su media, varianza, desviación típica, máximo y mínimo. Diseño: el diseño del servidor TCP es sencillo gracias al lenguaje Python. Los datos que recibe son procesados por funciones que permiten obtener de las cadenas de texto los datos que se necesitan, los valores y los tipos de sensor y de acción. Codificación: se lleva a cabo la implementación del servidor TCP utilizando paquetes Python tanto para el servidor TCP, para la DWT, como para las medidas estadísticas. De esta forma se reduce la complejidad, el tiempo y la probabilidad de errores, ya que es un software con el que ya se tiene la seguridad de un buen funcionamiento. El servidor procesa las cadenas de texto que recibe y las va convirtiendo en valores numéricos. Una vez obtenidos estos valores se procesan, por ventanas, en la DWT y después se calculan sus medidas estadísticas. Revisión: verificar que los cálculos son correctos y que se han tomado los datos del texto correctamente. Iteración 5: módulo que genera los archivos de entrenamiento para el clasificador SVM. Planificación: implementación de un módulo dentro del servidor que almacena los valores ya calculados en el formato adecuado para después poderlos procesar con LIBSVM y llevar a cabo el entrenamiento y la clasificación. Análisis de requisitos: los valores deben almacenarse en ficheros de forma correcta, para que pueda aceptarlos despúes el programa de entrenamiento con LIBSVM. Diseño: este módulo no debe ser muy extenso gracias a las facilidades que ofrece Python para el manejo de archivos. 36

67 Codificación: se implementa un módulo software capaz de escribir en ficheros organizados por el tipo de sensor, los valores procesados de cada ventana junto con la acción a la que pertenecen. Revisión: verificar que los ficheros tienen un formato correctos para el clasificador SVM, para ello es posible utilizar un script que valida los ficheros e informa de si son correctos o no (checkdata.py), pudiendo así corregir fallos. Iteración 6: software para el entrenamiento y clasificación con el módulo LIBSVM. Planificación: implementación de los programas de entrenamiento y clasificación. Análisis de requisitos: el algoritmo debe entrenar con todo el dataset para generar los modelos de las acciones. Diseño: el software debe leer todos los archivos de entrenamiento de un directorio y procesarlos con LIBSVM para generar los modelos de cada acción para cada sensor. De esta forma obtenemos 9 archivos con modelos, uno por cada sensor y en cada uno de ellos modelos de 14 acciones. Codificación: se lleva a cabo la implementación de varios archivos en el lenguaje de programación Python para el procesamiento de los archivos de entrenamiento y la generación de los modelos. Revisión: verificar que los modelos se han guardado correctamente y que la salida del programa es normal. Iteración 7: programa de validación del sistema. Planificación: implementación de mecanismos de validación del sistema implementando una versión reducida del algoritmo Leave-One-Out 10 (validación cruzada) y generando la matriz de confusión para cada uno de los sensores utilizados y los datos obtenidos. Análisis de requisitos: cada una de las pruebas de los voluntarios del dataset o conjunto de datos debe utilizarse primero en la fase de entrenamiento para obtener un modelo y después en la fase de clasificación para ver cómo responde y después almacenar este resultado en la matriz de confusión. Diseño: el sistema se valida con el modelo Leave-One-Out. Codificación: se lleva a cabo la implementación de un archivo en el lenguaje de programación Python que prueba cada uno de los elementos del dataset y almacena su resultado en 9 matrices de confusión, una por cada tipo de sensor. 10 schneide/tut5/node42.html 37

68 Revisión: verificar que todas las pruebas hayan sido procesadas y que las matrices se han generado y almacenado correctamente. Post-juego La fase de post-juego de cada sprint se presenta a continuación: Iteración 1: aplicación de recogida de datos de los sensores. Una vez terminado el sprint, el cual fue completado en 3 semanas, se mostró al cliente la aplicación en ejecución en la reunión Sprint Review. El cliente dio el visto bueno por lo que se pudo pasar a desarrollar la siguiente iteración. Iteración 2: recogida de datos con el smartphone. Esta iteración se llevó a cabo en un plazo de dos semanas. Dada la restricción de necesitar el modelo de móvil concreto Samsung Galaxy S4, algunas de las pruebas se han llevado a cabo parcialmente, ya que algunos voluntarios realizaron las pruebas en su hogar y no les fue posible completar las 14 acciones. Iteración 3: aplicación para el envío de los datos recogidos hasta un servidor. El desarrollo de esta aplicación se extendió durante 4 semanas. Para la implementación del algoritmo de ventana deslizante se utilizó un paquete de software desarrollado en la asignatura Estructura de Datos, de la titulación de Ingeniería Informática (a extinguir). Este paquete contiene estructuras de datos con la jerarquía de una cola, muy útiles para realizar el algoritmo de ventana deslizante. Iteración 4: servidor que recibe los datos y los procesa con la transformada DWT y medidas estadísticas. Esta iteración fue completada en 3 semanas. Se lleva a cabo la implementación del servidor TCP utilizando el paquete Python SocketServer 11. El servidor procesa las cadenas de texto que recibe y las va convirtiendo en valores numéricos. Una vez obtenidos estos valores se procesan, por ventanas, en la DWT utilizando el paquete Python de ésta, pywt 12, y después se calculan sus medidas estadísticas utilizando otra biblioteca de Python llamada numpy 13. Iteración 5: módulo que genera los archivos de entrenamiento para el clasificador SVM. Gracias a la simplificación que ofrece Python esta tarea sólo supuso una semana. Este módulo se reduce a pocas líneas de código en las cuales se van escribiendo en 9 ficheros todos los datos para el entrenamiento, un fichero para cada sensor. En esta fase también se incluye la generación de los archivos de entrenamiento de todo el dataset. 11 https://docs.python.org/2/library/socketserver.html 12 https://packages.debian.org/stable/python/python-pywt

69 Iteración 6: software para el entrenamiento y clasificación con el módulo LIBSVM. Esta iteración se ha llevado a cabo en un período de 2 semanas, aunque con cambios en los requisitos. La generación de los modelos con el dataset de 154 pruebas (154*9=1386 archivos de eventos) tarda en procesarse en un equipo con 4GB de RAM y un procesador de 4 núcleos 6 horas. Esto ha provocado cambios en la siguiente iteración, ya que no es posible realizar esta tarea una vez por cada prueba del dataset. Iteración 7: programa de validación del sistema. Ha sido imposible llevar a cabo la validación cruzada ya que hubieran sido necesarios 38 días de ejecución continua en el equipo (6 horas x 154 pruebas). Por tanto, se han hecho todas las pruebas con los modelos generales, los que SVM crea entrenando todo el dataset. Esta tarea se ha llevado a cabo en una semana. 4.2 Herramientas En este apartado se enumeran las herramientas, tanto hardware como software, que han hecho posible el desarrollo del proyecto PerSe Lenguajes Han sido necesarios varios lenguajes de programación para llevar a cabo este proyecto. A continuación se muestran todos ellos: Java 14 : lenguaje de programación desarrollado orientado a objetos. Este lenguaje se utiliza para el desarrollo de las apliaciones Android. Python 15 : lenguaje de programación interpretado, utilizado para la implementación del servidor y de los programas de entrenamiento y pruebas Medios hardware Para el desarrollo de este proyecto se han empleado los siguientes dispositivos: Un equipo portátil Asus K53E para la implementación del proyecto, con las siguientes caracerísticas: Procesador Intel R Core TM i3 2310M Memoria DDR MHz SDRAM 4GB 500 GB de Disco Duro Un smartphone Wiko Cink Peax 2 para probar las aplicaciones durante su desarrollo. Un smartphone Samsung Galaxy 4 para probar la aplicación durante su desarrollo, durante la etapa de entrenamiento y el resto de pruebas necesarias. 14 https://www.java.com/ 15 https://www.python.org/ 39

70 4.2.3 Medios software En el transcurso de este proyecto se han empleado diferentes herramientas y bibliotecas software. A continuación se detallan todas ellas: Sistemas operativos: Ubuntu 16 : bit con kernel generic instalado en el equipo portátil indicado en los medios hardware. Android 17 : es el sistema operativo con el que funciona el smartphone Samsung Galaxy S4. Documentación: Texmaker 18 : para editar tanto la memoria del anteproyecto como la del TFG, así como cualquier otra documentación adicional en L A TEX [Tal13]. Gimp 19 : para editar las imágenes y crear algunos gráficos. LibreOffice Draw 20 : para crear los gráficos. Bibtex 21 : para dar formato a listas de referencias en los documentos escritos en L A TEX. Desarrollo: Android SDK 22 : para el desarrollo de software para Android. Python-numpy 23 : para el módulo de medidas estadísticas. Python-pywt 24 : para procesar los datos de los sensores con la transformada DWT. SocketServer 25 : para implementar el servidor TCP que recibe los datos de los sensores. Mercurial 26 : para el control de versiones y poder compartir el proyecto entre los miembros del equipo usando a su vez un repositorio que se encuentra alojado en Bitbucket, en la cuenta del grupo de investigación de la Escuela Superior de Informática ARCO https://es.libreoffice.org/descubre/draw/ https://docs.python.org/2/library/socketserver.html

71 Capítulo 5 Desarrollo del Proyecto EN este capítulo se expone el proceso de desarrollo a través del cual se ha realizado el proyecto, estructurándolo en las diferentes iteraciones que se definieron en el apartado de Método y Fases de Trabajo (véase Capítulo 4). El sistema está modulado en diferentes secciones que implementan una funcionalidad concreta (ver Figura 5.3). 5.1 Aplicación de Recogida de Datos En este proyecto se quiere utilizar la información que ofrecen los sensores de un smartphone para poder saber qué acción está llevando a cabo la persona que porta el teléfono. Actualmente los teléfonos móviles cuentan con gran cantidad de sensores aunque muy a menudo los usuarios lo desconocen [Gal]. El dispositivo elegido para llevar a cabo el la recogida de datos ha sido el smartphone Samnsung Galaxy S4, por varios motivos: es un terminal con un gran número de sensores de todo tipo y, sobre todo, porque personas del entorno (amigos y familiares) cuentan con el terminal. Este último motivo es importante porque facilita el proceso de recogida de datos que se describirá en la siguiente iteración. El Samsung Galaxy S4 1 cuenta con nueve sensores (ver Figura 5.1) que pueden ser de gran utilidad para las tareas de reconocimiento de actividades humanas. Se describen a continuación: 1. Sensor Gestual: reconoce los gestos más comunes en la pantalla del dispositivo para, por ejemplo, poder mejorar las interfaces en el futuro. 2. Sensor de proximidad: este sensor detecta si hay un objeto a pocos centímetros de él, de forma que se puede saber si el usuario tiene, por ejemplo, el rostro cerca del terminal. 3. Giroscopio: gracias a su información podemos determinar la posición de nuestro dispositivo. Es muy utilizado en aplicaciones como juegos o lectores de documentos. 4. Acelerómetro: es capaz de detectar el movimiento del teléfono, de forma que podemos llegar a saber, por ejemplo, los pasos que está dando el usuario como haría un 1 El Samsung Galaxy S4 es un teléfono inteligente de altas prestaciones de la compañía Samsung Mobile lanzado al mercado el 14 de Marzo de

72 necesitamos una aplicación que almacene estos valores en archivos que podamos procesar posteriormente. Idealmente este sistema ha de recoger los valores de los sensores y procesarlos en tiempo real, pero esto es un proceso complejo. En este proyecto los datos se recogerán en una aplicación y otra será la encargada más tarde de enviar estos datos para ser procesados. Este sistema puede evolucionar después en un sistema en tiempo real. La aplicación se ha desarrollado para el sistema operativo Android, ya que el dispositivo Samsung Galaxy S4 funciona con este SO. Para desarrollar una aplicación para Android es necesario utilizar el SDK 2 de Android que funciona con el lenguaje de programación Java. El SDK de Android proporciona las bibliotecas de laapi y herramientas de desarrollo necesarias para crear, probar y depurar aplicaciones para Android. Para trabajar con el SDK de Android se ha utilizado el entorno de desarrollo ADT para iniciar rápidamente el desarrollo de la aplicación. Éste incluye los componentes del SDK de Android esenciales y una versión del IDE de Eclipse, lo que permite agilizar la instalación y la configuración del sistema para trabajar con Android. El objetivo de esta app (aplicación) se centra en la sencillez, para que sea intuitivo su funcionamiento. Consta de una única interfaz con dos botones principales: iniciar y parar; y un menú deslizante de 14 acciones: (1) Esperar: no se esta realizando ninguna acción, el usuario está parado. (2) Andar: el usuario está andando. (3) Correr: el usuario está corriendo. (4) Sentarse: el usuario se está sentando en un asiento. (5) Levantarse: el usuario se está levantando de un asiento. (6) Tumbarse: el usuario está tumbándose en una superficie horizontal. (7) Caerse: el usuario está sufriendo una caída. (8) Subir Escaleras: el usuario está subiendo escalones. (9) Bajar Escaleras: el usuario está bajando escalones. (10) Subir Ascensor: el usuario está subiendo en un ascensor. (11) Bajar Ascensor: el usuario está bajando en un ascensor. (12) Puñetazo: el usuario está dando un puñetazo. (13) Patada: el usuario está dando una patada. (14) Empujón: el usuario está dando un empujón

73 El usuario sólo tiene que escribir su nombre en la casilla correspondiente y elegir en el menú deslizante una de las 14 posibles acciones (ver Figura 5.3). Figura 5.2: App Recogida de Datos Cuando ya esté listo para llevar a cabo la prueba debe pulsar sobre el botón Iniciar y el fondo de la aplicación se verá de color azul turquesa (ver Figura 5.3) y además se mostrará el texto «Grabando» en una pequeña alerta en la pantalla. En ese momento debe colocar el teléfono dentro del bolsillo de su pantalón e inmediatamente después llevar a cabo la acción elegida. El terminal puede bloquearse de forma manual si el usuario lo ve conveniente y los datos se seguirán almacenando. Cuando la persona ha terminado de realizar su acción sólo ha de sacar el teléfono de su bolsillo y pulsar Parar, entonces el fondo volverá a ser blanco y el usuario podrá salir de la aplicación o escoger otra acción y volver a grabar. Si la persona repite la acción varias veces, esta se sobrescribe. De esta manera, si por algún caso, la prueba no se estuviera realizando bien, es muy sencillo para el usuario volver a pulsar Parar e Iniciar y la prueba errónea es eliminada y sustituida por la nueva. 44

74 Figura 5.3: App Recogida de Datos Grabando Como se explicó en el apartado del Método de Trabajo (véase Capítulo 4) los archivos que guardan los valores de los sensores han de estar estructurados según una jerarquía (ver Figura 5.4), ya que después serán procesados por otra aplicación. Esta jerarquía es muy sencilla: / sdcard0 / Sensores / Usuario_Accion / Usuario_Accion_Sensor. txt Por lo tanto se va a crear un directorio en la memoria externa por defecto del teléfono llamado «Sensores» en el cual se crearán tantos directorios como acciones haga el usuario. Cada uno de esos directorios tendrá 9 archivos, uno por cada sensor. En caso de que algún sensor no muestre ningún valor, es decir, que no genere ningún evento, el archivo se crea igualmente, aunque quedará vacío. En el menú de opciones de la aplicación podemos encontrar un menú con una opción que ofrece «Iniciar a los 5 segundos», esto quiere decir, que hasta pasados 5 segundos el sistema 45

75 Figura 5.4: Jerarquía de Directorios App Recogida de Datos no empezará a grabar. Esto puede ser muy útil si el sistema presenta problemas al predecir las acciones porque los primeros valores de las pruebas lo confundan, al estar el teléfono siendo introducido en el bolsillo y no ejecutando la acción en concreto Implementación Veamos ahora como se ha desarrollado la aplicación en el entorno ADT. Esta aplicación está implementada en un solo Activity, en un sólo archivo.java ya que aunque el código es suficientemente extenso como para modularlo en varios archivos, es un código bastante redundante. Esto es debido a que a menudo se repite el mismo código para los distintos manejadores de los 9 sensores, de forma que no puede reducirse pero tampoco tiene mucho sentido dividirlo. La primera tarea es leer los valores de los sensores, para ello hay que tener acceso a éstos, que los tiene que proporcionar el sistema operativo, ya que los sensores son elementos 46

76 hardware. Para poder consultar los valores de los sensores debemos importar las bibliotecas correspondientes a Sensor en el Activity: import android. hardware. Sensor ; import android. hardware. SensorEvent ; import android. hardware. SensorEventListener ; import android. hardware. SensorManager ; El caso del GPS es algo más especial, pertenece a otra biblioteca de Android distinta llamada Location, por lo que hay que incluir otras cabeceras para poder consultar este valor. import android. location. Location ; import android. location. LocationListener ; import android. location. LocationManager ; Además es necesario dar permisos a la aplicación para que pueda acceder a las funciones de Location. Estos permisos se deben definir en el manifiesto de la aplicación, AndroidManifest.xml: < uses permission android: name =" android. permission. ACCESS_ FINE_ LOCATION " /> < uses permission android: name =" android. permission. ACCESS_LOCATION_EXTRA_COMMANDS " /> Una vez ya tenemos preparado el sistema podemos crear una Activity para leer los sensores, siendo esta su cabecera: public class SensorActivity extends Activity implements SensorEventListener, LocationListener El siguiente paso es registrar los manejadores de eventos de cada tipo de sensor en la función que se ejecuta al iniciarse la aplicación Android, la función oncreate. Para registrar los sensores hay que solicitar el servicio al sistema operativo con la función getsystemservice para cada uno de los sensores: locationmanager = ( LocationManager ) getsystemservice ( Context. LOCATION_ SERVICE ); sensormanager = ( SensorManager ) getsystemservice ( SENSOR_ SERVICE ); sensordeproximidad = sensormanager. getdefaultsensor ( Sensor. TYPE_ PROXIMITY ) ; sensordeluz = sensormanager. getdefaultsensor ( Sensor. TYPE_ LIGHT ); sensoracelerometro = sensormanager. getdefaultsensor ( Sensor. TYPE_ ACCELEROMETER ); sensormagnetico = sensormanager. getdefaultsensor ( Sensor. TYPE_ MAGNETIC_ FIELD );... 47

77 Una vez solicitado el servicio se pueden registrar los sensores utilizando registerlistener. Esta funcionalidad está localizada en la función registrarsensores: locationmanager. requestlocationupdates ( LocationManager. GPS_PROVIDER, 1000, 10, this); sensormanager. registerlistener (this, sensoracelerometro, SensorManager. SENSOR_DELAY_NORMAL ); sensormanager. registerlistener (this, sensordeproximidad, SensorManager. SENSOR_DELAY_NORMAL ); sensormanager. registerlistener (this, sensordeluz, SensorManager. SENSOR_ DELAY_ NORMAL ); sensormanager. registerlistener (this, sensormagnetico, SensorManager. SENSOR_ DELAY_ NORMAL ); sensormanager. registerlistener (this, sensorgiroscopio, SensorManager. SENSOR_ DELAY_ NORMAL ); Como puede verse, el código se repite para cada tipo de sensor: GPS, acelerómetro, proximidad, luz, magnético, giroscopio, temperatura, humedad y barómetro. Por esta razón en este documento se mostrarán los listados parcialmente para evitar la redundancia de código. Una vez registrados los sensores podemos leer los eventos que se van produciendo gracias a la función onsensorchanged que se activa cada vez que un sensor lanza un evento. En estas funciones se ha implementado un bucle synchronized que funciona de «cerrojo» para el trabajo con distintos hilos de ejecución. Cada vez que un thread intenta acceder al bucle se cerciora de que no hay algún otro thread trabajando con ese objeto concreto en un bucle synchronized. Es un mecanismo clásico de semáforos o cerrojos para programación concurrente. El GPS de nuevo necesita un tratamiento especial, los eventos de este sensor los recibe la función onlocationchanged, que funciona de forma similar a la del resto de sensores, solo que al ser un único sensor no necesita ningún tipo de cerrojo. Dentro de este bucle synchronized se consulta qué tipo de sensor lanzó el evento y se trabaja según el tipo de sensor. Existen tres tipos de sensores según los valores que ofrecen por cada evento: Los triaxiales, que ofrecen valor x, y, z: acelerómetro, giroscopio y magnético. El GPS que ofrece 2 valores, latitud y longitud. Los que generan un solo valor: temperatura, barómetro, humedad, luz y proximidad. Pero no podemos generalizar los sensores según esas tres categorías en esta función, ya que necesitamos que cada sensor escriba sus datos en el fichero y dé información acerca de qué sensor se trata. 48

78 El valor que se lee del sensor se muestra por pantalla y se escribe en el fichero sólo si el usuario ha pulsado el botón Iniciar, con lo que la variable global GRABAR quedará a 1. De esta forma se controla de forma sencilla si hay que guardar o no los datos en el fichero. Si el botón ha sido pulsado los valores emitidos por el sensor se escriben a través del método escribir_externa. Este método escribe en un fichero almacenado en la memoria externa del teléfono, siguiendo la jerarquía definida anteriormente (ver Figura 5.4). A esta función se le ha de pasar la cadena a escribir y el descriptor del archivo correspondiente a ese sensor, que lo hemos abierto previamente con la función abrir_ficheros, cuando el usuario haya pulsado el botón Iniciar(ver Listado 5.1). synchronized (this){ switch( arg0. sensor. gettype ()){ case Sensor. TYPE_ PROXIMITY :... case Sensor. TYPE_ ACCELEROMETER :... case Sensor. TYPE_ LIGHT : masdata = arg0. values ; xl = masdata [0]; textviewluz. settext ("x: " + xl ); if( GRABAR ==1) escribir_externa ("\tx: " + xl +"\n",oluz ); break;... Listado 5.1: Escribir los valores en ficheros Para que esta escritura se pueda llevar a cabo es necesario añadir otro permiso al manifiesto de la app que permita que la aplicación pueda escribir en la memoria externa del teléfono: < uses permission android: name =" android. permission. WRITE_EXTERNAL_STORAGE " /> La elección de la memoria externa para el almacenamiento es sencilla, la memoria interna puede alojar también archivos que genere una aplicación, como lo son estos, pero sólo y exclusivamente se pueden leer desde la propia aplicación, por lo que no nos era útil. Es posible abrirlos si se tiene usuario root del teléfono, pero no era una opción viable. Alojándolos en la memoria externa, además de poderlos leer con normalidad, ahorramos espacio en la memoria del teléfono que suele ser más reducida. De esta forma ya tenemos los valores de los sensores almacenados en sus correspondientes ficheros (ver Figura 5.5). Se ha de observar que cada sensor lanza eventos con diferentes frecuencias; para determinar estas frecuencias se estudiaron unos cuantos ejemplos y se elaboraron tablas (ver Cuadro 5.1). De esta forma es fácil ver que hay de forma general dos tipos de sensores, los que generan 6 49

79 Figura 5.5: Ficheros de Eventos eventos por segundo y los que generan 1, a excepción del sensor de proximidad, que muestra 2 eventos por segundo. Estos valores se tendrán en cuenta a la hora de implementar el algoritmo de ventana deslizante, tanto para el tamaño de la ventana, como para el tamaño del solapamiento de los valores. 5.2 Recogida de Datos Para poder entrenar el sistema necesitamos un dataset (conjunto de datos) completo, en el que haya datos de todos los tipos de acciones y de todos los tipos de sensores. Además estos datos debemos tomarlos con diferentes usuarios porque los valores de los sensores no serán los mismos cuando una acción la lleva a cabo una persona que cuando la lleva otra. Por esta razón era necesario hacerlas pruebas con el mayor número de sujetos posibles. Para construir el dataset se ha contado con la participación de 16 voluntarios, aunque no todos realizaron las 14 acciones. Aproximadamente la mitad de las pruebas fueron tomadas con supervisión y en la misma sala; mientras que el resto fueron tomadas sin supervisión, los voluntarios hicieron las pruebas en diferentes momentos y después fueron facilitados al equipo. Los datos que toman los sensores, en principio no tienen significado, pero pueden ser interpretados (como se está tratando de hacer en este proyecto) con el objetivo de deducir sobre los movimientos que hizo la persona. Debido a esto, los datos almacenados pueden considerarse datos de carácter personal, así pues, es necesario recurrir a un formulario de consentimiento (ver Anexo B). Con anterioridad a la toma de datos, los voluntarios debían cumplimentar el documento 50

80 que se les facilitaba, en él se detalla el objetivo del proyecto y para qué fin serán tratados sus datos. Se toman algunos datos acerca del usuario y si éste está de acuerdo, lo firma y se procede a tomar la prueba (ver Anexo C). Se han tomado pruebas de 16 voluntarios, con un total de 154 acciones recogidas (ver Cuadro 5.2). Este dataset es el que utilizaremos para el entrenamiento del sistema, pero para poder usarlo necesitamos procesar esta información. 5.3 Envío de los Datos y Ventana Deslizante Cuando ya contamos con el dataset necesitamos procesar todos estos valores en otra aplicación, de forma que en un futuro estas aplicaciones puedan ser una sola y funcionar a tiempo real. Para el preprocesamiento de los datos se lleva a cabo un algoritmo de ventana deslizante. Este algoritmo, aunque guarda cierta semejanza con él, no es el utilizado en las conexiones TCP, éste está diseñado para recorrer los eventos de los sensores de una forma especial. Si imaginamos los eventos de los sensores como si de una señal analógica se tratara, podemos entenderlo de una forma más sencilla. Si se recorre la señal en pequeños bloques, para poder procesarla, se pierde cierta información. Esto es debido a que si se corta la señal se pierde la información relevante que haya a su alrededor. Esta información es útil para saber cómo es el entorno de esa porción de señal y así determinar sus características. Tiene cierta similitud a los filtros de imagen, por ejemplo el filtro Sobel 3, en los que se recorren los píxeles y se tienen en cuenta todos los de su alrededor para determinar el contorno de una imagen. Si se cogiera solo un pixel no se podría llegar a determinar si es el contorno o no, ya que se tienen en cuenta los factores que presentan los píxeles inmediatamente seguidos. De la misma manera debemos solapar los valores de los sensores en una ventana deslizante para no perder esos valores de sus alrededores que tanta información nos pueden proporcionar (ver Figura 5.6)

81 SENSOR Esperar Andar S. Escaleras B. Escaleras S. Ascensor B. Ascensor Correr Acelerómetro Barómetro Giroscopio GPS Humedad Luz Magnético Proximidad Temperatura Cuadro 5.1: Eventos por segundo EDAD SEXO N o ACCIONES Voluntario 1 23 M 13 Voluntario 2 15 M 12 Voluntario 3 23 M 9 Voluntario 4 23 H 2 Voluntario 5 23 H 14 Voluntario 6 22 H 9 Voluntario 7 24 H 14 Voluntario 8 22 H 8 Voluntario 9 55 M 1 Voluntario M 3 Voluntario M 2 Voluntario M 12 Voluntario M 14 Voluntario M 12 Voluntario H 12 Voluntario M 14 Cuadro 5.2: Pruebas tomadas a los voluntarios 52

82 Test RECOGIDA DE DATOS Archivos Eventos Sensores Creación Archivos Lectura de la Señal APP Recogida de Datos PRE-PROCESAMIENTO Y ENVÍO APP PerSe TCP Procesador de Archivos Eventos Sensores Ventana Deslizante Ventanas Cliente TCP PROCESAMIENTO DE DATOS Archivos Vectores de Características Señal caracterizada DWT Y Estadísticas Ventana Eventos Procesador Ventana Servidor TCP ENTRENAMIENTO Train Vectores de Características Entrenamiento Entrenador SVM Modelos VALIDACIÓN Matrices Confusión Generador Matrices Resultados Clasificador SVM Vectores de Características Validación

83 Figura 5.6: Ventana Deslizante Implementación Esta aplicación se divide en varios módulos que interactuan entre ellos (ver Figura 5.7), estos se describen a continuación. Leer ficheros La primera tarea al comenzar a desarrollar esta app es leer los ficheros que creamos con la aplicación anterior. Para ello se ha desarrollado la clase ProcesadorArchivos.java cuyo objetivo es leer un archivo de eventos creado por la app Recogida de Datos e interpretarlo, creando las estructuras de datos correspondientes. Para abrir los ficheros y leerlos se utiliza la clase de Java BufferedReader, File y FileReader y para recorrer el archivo de una forma eficaz y eficiente StringTokenizer. Esta última biblioteca permite recorrer el texto del archivo determinando qué tomamos por delimitador, de forma que es posible ir de coma en coma o de espacio en espacio. La función principal de esta clase es leer, la encargada de leer los archivos de tipo: Usuario_Accion_Sensor.txt Esta función está dividida en 3, por los ya mencionados tres tipos de sensores, de 1, 2 y 3 valores. Para cada uno de ellos debemos recorrer el archivo de diferente forma porque los tokens a recorrer son diferentes. Con la función parsedouble convertimos el texto en valores de doble precisión (ver Listado 5.2). 54

84 Figura 5.7: Diagrama de Secuencia PerSeTCP Ventana deslizante Cuando se procesa un evento, se almacena en una cola de eventos. Para la implementación de la cola se ha utilizado software desarrollado en la asignatura Estructura de Datos. Se trata de un paquete llamado colas que contiene diferentes clases de estructuras de datos siguiendo la jerarquía de una cola. Concretamente se ha usado la clase coladinamica. Esta clase permite crear colas de objetos y utilizar múltiples funciones como clonar o comparar. De esta manera hemos simplificado la implementación de este módulo. Se ha utilizado este tipo de estructura de datos ya que el flujo de datos de los eventos de los sensores se asemeja a una cola de datos y así facilitaríamos la implementación del algoritmo de ventana deslizante. Una vez tenemos la cola, necesitamos un objeto Evento para representar los datos. Como existen 3 tipos de sensores, se ha implementado una clase abstracta Evento, de la cual heredan 3 clases, una para cada tipo de sensor (ver Figura 5.8): Evento1, Evento2 y Evento3. Todo ello forma el paquete eventos. 55

85 Figura 5.8: Diagrama de clases paquete Eventos Una vez tenemos el objeto Evento podemos crear la cola de eventos que almacena los eventos de un sensor. El siguiente paso es procesar esta cola con el algoritmo de ventana deslizante, desarrollado en VentanaDeslizante.java. La implementación de VentanaDeslizante.java está ideada para dar muchas posibilidades a la hora de crear una ventana desde la clase principal. La ventana tiene un tamaño y un solapamiento variable, para ello se han creado tres tipos de constructores: Completo Este constructor define cada una de las posibles dimensiones y superposiciones de forma independiente, es decir, una por cada tipo de sensor. Cada ventana puede ser diferente si se desea. DIM_VENTANA_BAROMETRO = dim_ventana_barometro ; DIM_VENTANA_GIROSCOPIO = dim_ventana_giroscopio ; DIM_ VENTANA_ GPS = dim_ VENTANA_ GPS ;... SUPERPOSICION_BAROMETRO = superposicion_barometro ; SUPERPOSICION_GIROSCOPIO = superposicion_giroscopio ; SUPERPOSICION_ GPS = superposicion_ GPS ;... 56

86 Parcial En este constructor se definen dos tipos de tamaños, uno para los sensores que emiten eventos unas 6 veces por segundo y otro para los que emiten 1 vez por segundo. De esta forma hay dos tipos de ventana. \ textbf { DIM_VENTANA_PROXIMIDAD = tam_ventana1 ; DIM_VENTANA_TEMPERATURA = tam_ventana1 ; DIM_VENTANA_BAROMETRO = tam_ventana1 ; DIM_ VENTANA_ GPS = tam_ ventana1 ; DIM_ VENTANA_ HUMEDAD = tam_ ventana1 ; DIM_ VENTANA_ LUZ = tam_ ventana2 ; DIM_VENTANA_MAGNETICO = tam_ventana2 ; DIM_VENTANA_GIROSCOPIO = tam_ventana2 ; DIM_VENTANA_ACELEROMETRO = tam_ventana2 ; SUPERPOSICION_PROXIMIDAD = superposicion1 ; SUPERPOSICION_TEMPERATURA = superposicion1 ; SUPERPOSICION_BAROMETRO = superposicion1 ; SUPERPOSICION_ GPS = superposicion1 ; SUP ERPO SICI ON_ H UMEDA D = superposicion1 ; SUPERPOSICION_ LUZ = superposicion2 ; SUPERPOSICION_MAGNETICO = superposicion2 ; SUPERPOSICION_GIROSCOPIO = superposicion2 ; SUPERPOSICION_ACELEROMETRO = superposicion2 ;} Sencillo En este constructor se define un solo tipo de ventana, con una única dimensión de ventana y un único tamaño de superposición: DIM_VENTANA_BAROMETRO = tam_ventana ; DIM_VENTANA_GIROSCOPIO = tam_ventana ; DIM_ VENTANA_ GPS = tam_ ventana ;... SUPERPOSICION_BAROMETRO = superposicion ; SUPERPOSICION_GIROSCOPIO = superposicion ; SUPERPOSICION_ GPS = superposicion ;... Esta forma de crear los constructores permitirán en un futuro alterar estos valores para hacer más preciso el sistema, cogiendo más o menos valores alrededor de la muestra en cada ventana. La función más importante de esta clase es la función ventana_deslizante, en la cual se procesan los datos dando lugar al deslizamiento por los datos (ver Listado 5.3). 57

87 La función necesita: la cola de eventos aux que contiene todos los eventos con los que crean las ventanas, el tamaño y la superposición de la ventana y para tareas que se explicarán a continuación, el cliente y la acción. Se crea una nueva ventana y si es la primera ventana, se completa con los valores suficientes y se envía la ventana. Si la ventana ya está completa, quiere decir que no es la primera, por lo que hay que hacer desplazamientos. Un bucle se repite tantas veces como tamaño tenga la superposición, en él se elimina un valor y se agrega uno nuevo. De esta forma, como es una cola, cuando se elimina un valor, se elimina el más viejo y se introduce uno nuevo al final (ver Figura 5.9). Figura 5.9: Ejemplo Sencillo de Ventana Deslizante La diferencia es que en esta ventana, cada elemento es un evento, que contiene a su vez otros elementos. Veamos un ejemplo de ventanas de tamaño 5 y superposición 1 de eventos del sensor Magnético en la acción Andar: Evento3 [ Magnetico, 21 :29:52, x= 4.412, y= 5.346, z =25.923] Evento3 [ Magnetico, 21 :29:52, x= 4.733, y= 5.346, z =11.633] Evento3 [ Magnetico, 21 :29:52, x= 5.432, y= 5.346, z =6.338] Evento3 [ Magnetico, 21 :29:53, x= 1.245, y= 4.917, z =14.825] Evento3 [ Magnetico, 21 :29:53, x= 3.085, y= 4.917, z =21.032] Evento3 [ Magnetico, 21 :29:53, x= 3.085, y= 4.917, z =21.032] Evento3 [ Magnetico, 21 :29:53, x = 2.76, y = 4.917, z = ] Evento3 [ Magnetico, 21 :29:53, x= 3.732, y= 4.598, z =13.322] Evento3 [ Magnetico, 21 :29:53, x= 6.748, y= 4.598, z =5.668] Evento3 [ Magnetico, 21 :29:53, x = 2.07, y = 4.598, z =7. 678] 58

88 Evento3 [ Magnetico, 21 :29:53, x = 2.07, y = 4.598, z =7. 678] Evento3 [ Magnetico, 21 :29:54, x = 1.69, y = 4.081, z = ] Evento3 [ Magnetico, 21 :29:54, x= 3.791, y= 4.081, z =24.409] Evento3 [ Magnetico, 21 :29:54, x = 2.85, y = 4.081, z = ] Evento3 [ Magnetico, 21 :29:54, x= 3.283, y= 4.081, z =10.452] Una ventana contiene 5 eventos del sensor con sus valores x, y, z. Cada vez que se completa una ventana se envía a través de un cliente TCP hasta un servidor TCP. Este cliente se explica a continuación. Cliente La clase ClienteTCP.java es la encargada de enviar los datos al servidor. Inicialmente se desarrolló un cliente UDP, por su eficiencia, pero se comprobó que el servidor recibía algunos valores desordenados, lo que era un problema grave, ya que el orden de los eventos es un indicativo esencial en el sistema. Esto es debido a que la conexión UDP no ofrece seguridad en este aspecto, los paquetes pueden no llegar o llegar desordenados, lo que no es crucial en streaming u otras tecnologías, pero en este proyecto no era viable continuar con UDP. Por ello se implementó la conexión en TCP. El cliente TCP en java es relativamente sencillo e importando la clase Socket se tiene lo necesario para una conexión sencilla. Esta clase está dividida en tres funciones principales: conectar, enviar y desconectar. Conectar Esta función es la dedicada a establecer la conexión TCP con el servidor. Para ello se crea un socket con la IP y el puerto del servidor, que las proporciona el usuario en la interfaz, en un hilo de ejecución nuevo (new Thread). Una vez conectado se crea el flujo OutputStreamWriter para poder «escribir» en el servidor. Llegados a este punto ya podemos enviar los datos. public void conectar () { new Thread (new Runnable public void run (){ try { InetAddress serveraddr = InetAddress. getbyname ( ip); socket = new Socket ( serveraddr, puerto ); out = new BufferedWriter (new OutputStreamWriter ( socket. getoutputstream ())); } catch ( UnknownHostException e1) { e1. printstacktrace (); } catch ( IOException e1) { e1. printstacktrace (); } 59

89 } } }). start (); Enviar Para enviar los datos sólo necesitamos los datos a enviar, que en este caso son, el tipo de sensor, la acción y los valores de la ventana. Todos ellos se colocan en un buffer en formato String tal y como se quiere que se reciba en el Servidor. Como anteriormente se ha creado el flujo de escritura out sólo hay que usar la función write para enviar los datos. public void enviar ( String tipo, int accion, ArrayList < Double > values ) { try { String str = accion + " " + tipo + " " + values. tostring () + "\ n"; out. write ( str ); out. flush (); } } catch ( Exception e) { } e. printstacktrace (); Desconectar Cuando finalice la aplicación se ha de cerrar la conexión con el socket, utilizando la función close. public void desconectar (){ try { socket. close (); } catch ( Exception e) { e. printstacktrace (); } } Interfaz Cuando ya está todo el sistema preparado sólo queda la interfaz del usuario de la aplicación, llamada PerSeTCP. Se necesita poder hacer envíos de cada acción en concreto, por lo que se ha implementado un menú deslizante con todas las acciones para que el usuario elija. También se ha de establecer la IP y el puerto del servidor que va a recibir los datos. Cuando 60

90 haya introducido esos datos el usuario pulsa Conectar y la app conectará con el servidor. Una vez conectado se puede realizar el envío de la acción elegida pulsando Enviar. También se ofrece la posibilidad de enviar todas las acciones seguidas en el botón Enviar Todas Las Acciones. Estas acciones deben estar almacenadas según la misma jerarquía de la aplicación de Recogida de Datos, de esa forma, es posible grabar y justo después enviar sin tener que modificar la ruta de los archivos (ver Figura 5.10). Figura 5.10: Aplicación PerSeTCP La aplicación va mostrando mensajes cuando termina sus acciones: «Conexión solicitada», cuando el usuario pulsa conectar, o «Enviado», cuando envía todas las ventanas deslizantes de una acción. 5.4 Procesamiento de los Datos Para poder utilizar la DWT para procesar la señal de los sensores necesitamos un equipo con un sistema operativo que soporte la ejecución del lenguaje de programación Python, en 61

91 el que poder instalar el paquete necesario para la DWT. Esto es debido a que no es posible instalar en Android el software necesario para utilizar la DWT, ya que en Java no existe este paquete de software. Se ha utilizado el sistema operativo Ubuntu, sobre él se ha instalado el paquete Debian python-pywt 4 para poder calcular los valores DWT de la señal de los sensores. Es por este motivo por el cual se envían las ventanas deslizantes con los valores de los sensores a través de un cliente-servidor TCP. De esta manera, el servidor es el que se encarga de procesar los datos. Este servidor TCP se ha implementado en Python, utilizando la biblioteca SocketServer 5 para simplificar la tarea de implementación: class MyTCPHandler ( SocketServer. StreamRequestHandler ): def handle ( self ): while 1: try:... if name == " main ": HOST, PORT = sys. argv [1], 5000 server = SocketServer. TCPServer (( HOST, PORT ), MyTCPHandler ) server. serve_ forever () Su primera tarea es extraer de los datos que recibe los que necesita: la acción, el tipo de sensor y los datos (ver Figura 5.11). Para ello se utilizan las prácticas funciones de Python para el tratamiento de cadenas: strip, split y replace. strip elimina blancos y saltos de línea, split permite recorrer el texto en tokens y replace reemplaza caracteres por otros. De esta forma tan sencilla se obtienen todos los datos necesarios en accion, tipo y values. while 1: try: data = self. rfile. readline (). strip () if not data : return print data accion = data. split (" ",2) [0] tipo = data. split (" ",2) [1] data = data. split (" ",2) [2] s = data [1: 1]. replace (" ","") 4 https://packages.debian.org/stable/python/python-pywt 5 62

92 Figura 5.11: Extraer la Información en el Servidor values = s. split (",") Una vez obtenida la señal de los sensores se han de calcular los coeficientes DWT utilizando la librería previamente instalada, Python-Pywt. Transformada wavelet discreta DWT Este sistema tiene como objetivo el reconocimiento de acciones, por lo que está dentro del contexto de machine learning (aprendizaje automático). El sistema debe aprender, gracias a los datos, las diferentes características que tienen las señales de los sensores en cada tipo de acción. En el contexto de machine learning es cada vez más utilizado el análisis wavelet porque es capaz de mostrar aspectos de la señal que otras técnicas no logran encontrar. En este caso la señal es el flujo de datos de un sensor, que podría representarse en una gráfica al igual que cualquier otra señal. La transformada wavelet considera una función tanto en el tiempo como en la frecuencia y existen dos tipos: Discretas: son las utilizadas para codificar señales, por lo tanto se usa más en ingeniería e informática. Continuas: son las utilizadas para el análisis de señales, por lo que son más utilizadas en investigación científica. El uso de la transformada wavelet se da cuando el análisis se desea hacer en señales que 63

93 no son estacionarias, es decir, que sus contenidos de frecuencia cambian en el tiempo. La transformada discreta wavelet DWT permite descomponer la señal en aproximaciones y detalles. A este proceso se le denomina análisis y proporciona el doble de datos de los necesarios, esto se soluciona con el downsampling (disminución de resolución, decimación). Tras este proceso existe otro proceso de reconstrucción o síntesis que genera la señal a partir de los detalles y aproximaciones, consiguiendo de nuevo la señal original. Este proceso se realiza con la transformada wavelet discreta inversa. La DWT es similar a la transformada discreta de Fourier (DFT), pero aunque el análisis en frecuencia se puede dar utilizando la transformada de Fourier, puede ocurrir que dos señales totalmente diferentes en el dominio del tiempo tengan el mismo contenido de frecuencia, en cuyo caso un análisis empleando la transformada de Fourier no es eficaz. Además, la DFT usa funciones seno y coseno, mientras que DWT utiliza funciones escala y wavelets. Éstas reúnen la doble característica de ortogonalidad y soporte compacto en el espacio. Al aplicar DWT a una señal, esta proporciona una matriz de coeficientes, los coeficientes wavelet [GMMF04]. La implementación de la DWT se lleva a cabo a través de filtros para analizar las frecuencias altas y bajas. La resolución de la señal está dada por los filtros y la escala está dada por la decimación (downsampling). Existen dos tipos de filtros (ver Figura 5.12): Filtros para analizar la parte de frecuencias altas de la señal. Filtros para analizar la parte de frecuencias bajas de la señal. Estos filtros son de media banda, es decir, su frecuencia de corte es la mitad de la frecuencia máxima de la señal. El downsampling sirve para quitar una de cada dos muestras, esto disminuye la frecuencia. Para aumentarla se realizaría la operación contraria, unsampling [BAMQ05]. Extracción de características La extracción de características reduce la dimensionalidad de los datos, descartando el ruido y la información redundante y centrándose en la información clave contenida en la señal de los sensores. En esta fase se descompone la señal en sub-bandas constituyentes y se elige el número de niveles de descomposición en base a los componentes de frecuencia de dominio de la señal. Para este proyecto utilizamos el nivel Daubechies 4, que descompone la señal en 6 conjuntos de coeficientes, detalles en D1-D5 y un aproximación final en A5 (ver Figura 5.13) [SL11]. Esta teoría llevada a la práctica se reduce a una sóla línea de código, gracias al paquete 64

94 Figura 5.12: Filtros DWT para Python Pywt. Se procesa la señal de los sensores de la siguiente manera: coeficientes = pywt. wavedec ( values, db4, level =5) Utilizando DWT Daubechies 4 y un nivel de 5 pywt.wavedec nos devuelve 6 conjuntos de coeficientes: ca_5, cd_5, cd_4, cd_3, cd_2, cd_1; correspondiendo cada uno a un nivel de descomposición de la señal. De cada uno de estos conjuntos de coeficientes hay que calcular: media, desviación típica, varianza, máximo y mínimo. Esta operación se realiza con el objetivo de reducir el tamaño del vector de características. Para la realización de los cálculos estadísticos se ha utilizado la biblioteca numpy 6 que incluye múltiples funciones de ésta índole, además de las que se necesitan en este programa. Se crea una lista llamada medidas en la que se alojarán todos los resultados de las operaciones estadísticas y que se creará nuevamente en cada entrada de datos al servidor, ya que el servidor procesa cada petición por separado, es decir, que procesa ventana a ventana. medidas = [] for i in coeficientes : medidas. append (np. amax (i)) medidas. append (np. amin (i)) medidas. append (np. mean (i)) medidas. append (np.std (i)) 6 65

95 Figura 5.13: Descomposición de la Señal [SL11] medidas. append (np.var (i)) Se calculan todas las medidas de cada conjunto de coeficientes, lo que hace un total de: 6 conjuntos * 5 medidas = 30 resultados. Estos resultados han de ser almacenados en archivos que después utilizaremos con el clasificador. 5.5 Generación de los Archivos de Entrenamiento Los cálculos realizados de las medidas estadísticas se escriben en ficheros, diferenciando uno para cada tipo de sensor. El archivo se abre con la opción «añadir», de forma que las siguientes escrituras no eliminarán el contenido inicial. file = open ("./"+ tipo +". txt ", "a") buf = accion + " " x = 1 for m in medidas : buf += str (x) + ":" + str (m) + " " x += 1 66

96 buf += "\n" file. write ( buf. encode print medidas print " " file. close () ( utf 8 )) La forma de almacenar los datos en el fichero debe ser especial porque éste será un fichero de entrenamiento y debe respetar el formato de SVM (ver Figura 5.14). Figura 5.14: Formato de los Archivos de Entrenamiento SVM Finalmente se obtienen 9 ficheros que se alojan en el directorio en el que se haya ejecutado el servidor: Acelerometro.txt, Barometro.txt, Luz.txt, Magnetico.txt, GPS.txt, Giroscopio.txt, Proximidad.txt, Temperatura.txt y Humedad.txt. 5.6 Entrenamiento y Clasificación Una vez generados los archivos con los vectores de características que serán utilizados para la fase de entrenamiento del clasificador SVM se puede comenzar con el desarrollo de dicha etapa. La primera tarea es comprobar si los archivos que hemos generado son correctos, para ello se ha utilizado un script (checkfilesvm.py) para probar que los ficheros realmente cumplen con el formato necesario y no se ha cometido ningún fallo; este script lo proporciona LIBSVM [Cha14], la librería para Python de SVM. El uso de un clasificador SVM es una de las técnicas más utilizadas en tareas de aprendizaje automático o machine learning por sus buenos resultados [LMMGRGR07]. Su utilización en esta fase del proyecto tiene como objetivo la representación de la señal de los sensores en un modelo de espacio vectorial, donde las diferentes acciones se agrupan en regiones separadas en el espacio de representación 7. La técnica consiste en buscar un hiperplano que separe cada acción, maximizando el margen entre las acciones y el propio hiperplano (ver 7 Se generará un modelo para cada sensor. 67

97 Figura 5.15). El hiperplano se define a través de la siguiente función que después se optimiza: f(x) = w x + b Pero esta solución sólo resuelve problemas linealmente separables, por lo que se requiere la utilización de una función para redimiensionar el espacio. Se obtiene un nuevo espacio que será linealmente separable. Después, la redimensión se deshace, y así el hiperplano encontrado se transforma al espacio original, dando lugar a la función de clasificación [ZM09]. Figura 5.15: Ejemplo de maximización del margen con SVM Implementación Para la implementación de programa de entrenamiento desarrollado en Python se ha utilizado la biblioteca LIBSVM [CL11], mencionada anteriormente. Este software proporciona las funciones necesarias para entrenar y probar el sistema. En un programa en Python, Entrenamiento.py se ha importado el paquete svmutil, que facilita el trabajo de utilizar éstas funciones. Este programa necesita dos parámetros que se le han de introducir por línea de comandos: el archivo de entrenamiento y el directorio donde se desea almacenar el modelo generado como resultado de la fase de entrenamiento. from svmutil import import sys 68

98 fichero = sys. argv [1] dir_ modelos = sys. argv [2] La fase de entrenamiento debe realizarse una vez por cada sensor utilizado. Por lo tanto, para automatizar esta fase se ha recurrido al uso de la función split para seleccionar de toda la ruta únicamente el nombre del sensor utilizado en cada momento, de manera que después el modelo se guarde en el archivo correspondiente a ese sensor. Despúes se comienza el entrenamiento, utilizando la función svm_read_problem para acceder a los datos del problema. En este caso, estos datos estarán compuestos por los vectores de características extraídos de cada una de las ventanas temporales en las que se dividió la señal del sensor. La llamada a la función svm_problem sirve para crear un objeto con los datos que serán utilizados para calcular el modelo en la fase de entrenamiento. todo = fichero. split ("/") for palabra in todo : sensor = palabra. split (".",1) [0] y, x = svm_read_problem ( sys. argv [1]) prob = svm_problem (y, x) Una vez definido el problema, se establecen los parámetros: param = svm_ parameter () param. kernel_ type = LINEAR param.c = 10 Kernel lineal, que define la función lineal del hiperplano. El parámetro C controla el equilibrio entre el margen y el tamaño de la holgura entre las variables. Con los parámetros ya definidos sólo queda comenzar el entrenamiento, para ello se llama a la función svm_train con el problema definido y los parámetros. Hay que tener en cuenta que el ajuste de los parámetros se ha hecho en base a la recomendación genérica dada por los desarrolladores de la librería. Sería sin embargo interesante hacer un estudio empírico de cómo afecta el ajuste de estos parámetros a la precisión del sistema. Finalmente, una vez realizada la fase de entrenamiento y generado el modelo, se realiza una llamada a la función encargada de guardar una copia de ese modelo svm_save_model. Función que recibe como argumentos la ruta al archivo en el que se almacenará el modelo y la estructura de datos que tiene la copia del mismo. modelo = svm_train (prob, param ) svm_save_model ( dir_modelos +"/"+ sensor, modelo ) De esta forma ya está disponible el modelo para el conjunto de datos de entrenamiento 69

99 de un determinado sensor. Este modelo podrá ser utilizado posteriormente para la fase de clasificación junto con un conjunto de datos diferente. Este proceso deberá realizarse una vez por cada sensor utilizado durante la etapa de recogida de datos, siendo éstos un total de nueve sensores. Para simplificar y automatizar el proceso de entrenamiento se ha implementado un script bash llamado entrenar.sh (ver Listado 5.4). Este script ejecuta el programa Entrenador.py una vez por cada archivo que haya en el directorio de archivos de entrenamiento, que se le ha de pasar por línea de comandos. El script almacena los modelos que se generan en un nuevo directorio, que crea éste, llamado Modelos. Los modelos que genera svm_train pueden leerse, ya que se guardan en formato de texto plano, pero están hechos para ser interpretados por svm_predict. 5.7 Validación del Sistema Para probar el sistema se planificó utilizar el sistema de validación cruzada. Este sistema consiste en la implementación de la técnica Leave-One-Out, que básicamente consiste en entrenar el sistema con todos los datos del conjunto de datos menos uno, que se deja fuera para ser posteriormente utilizado como dato de entrada para la clasificación. Así, en este caso concreto, la implementación de esta técnica consistiría en entrenar, para cada sensor, con todos los archivos de entrenamiento (154 pruebas) menos una. Después, la prueba que ha quedado fuera del conjunto utilizado para el entrenamiento será utilizada en la fase de clasificación. Esta técnica consiste en repetir iterativamente este proceso de forma que todas las pruebas que componen el dataset hayan sido utilizadas al menos una vez como entrada del clasificador. El resultado obtenido en la clasificación de todas y cada una de las pruebas que han sido dejadas fuera de la etapa de clasificación servirán para el cálculo de la precisión del sistema desarrollado. Sin embargo, la implementación completa de esta técnica no ha sido posible debido al tiempo de computación requerido por la misma. El entrenamiento de las 154 pruebas tarda en ejecutarse 6 horas (en el equipo descrito en la Sección 4.2). Si se tienen 154 pruebas, se deben hacer 154 ciclos de entrenamientos de un conjunto de datos de 153 pruebas. Esto es aproximadamente: 6horas 154 = 924horas = 38, 5das Por tanto y debido a la limitación temporal marcada por la fecha de entrega de este trabajo, la realización de esta tarea fue inviable debido a que la última parte del desarrollo de este Trabajo Fin de Grado se ha llevado a cabo fuera del período docente. Por lo tanto, no se ha tenido acceso ni al centro de cálculo ni a equipos más potentes que pudieran dedicarse a la ejecución de estas pruebas. Se contaba únicamente con el equipo portátil empleado para el 70

100 desarrollo de este trabajo. La solución alternativa fue la implementación reducida de esta técnica de validación cruzada, probando cada una de las pruebas con los modelos generados con las 154 pruebas. Los modelos que se generan con todo el dataset fueron los utilizados para la validación. Para ver los resultados del sistema se necesitaba algún tipo de comparativa o de tabla. A su vez, no era eficiente ni viable comprobar de forma manual cada uno de los resultados de las pruebas, por lo que se determinó utilizar matrices de confusión. Las matrices de confusión 8 o de clasificación se encargan de determinar si los valores de predicción coinciden con los valores reales. La técnica consiste en contar todos los casos de cada tipo (en este caso acción) e ir sumándolos en la matriz (ver Figura 5.16). Figura 5.16: Ejemplo simplificado de Matriz de Confusión Implementación De nuevo se recurrió a Python para desarrollar el módulo de pruebas, el archivo Probar.py es el encargado de probar cada elemento del dataset. Para hacer esta prueba se necesita el archivo de entrenamiento de cada prueba por separado. Este trabajo no podía hacerse de forma automática, ya que el envío de los datos de una prueba debe hacerse desde la aplicación del teléfono

101 Para que no fuese necesario hacer 154 envíos, cambiando la prueba contenida en el directorio Sensores se hicieron unos pequeños cambios en el servidor para que archivara los archivos de entrenamiento según la acción (ServidorAcciones.py), de manera que, si los envíos se hacían por usuario, las pruebas se distinguirían, porque no hay acciones repetidas por el mismo usuario. De esta forma, sólo se hicieron 16 envíos, uno por cada voluntario de las pruebas. Una vez obtenidos todos los archivos de entrenamiento sueltos, se debían probar. Para ello se desarrolló Probar.py: from svmutil import import sys modelo = svm_load_model ( sys. argv [1]) b, a = svm_read_problem ( sys. argv [2]) p_label, p_acc, p_val = svm_predict (b, a, modelo ) print sys. argv [2] print p_ label print " " Este sencillo programa carga el modelo correspondiente al primer parámetro que se le pase por línea de comandos y lee el archivo de entrenamiento que se le pase como segundo parámetro. Después llama a svm_predict que es la función más importante, la que predice qué acción se está llevando a cabo según el modelo. El modelo corresponde a un tipo de sensor concreto, por lo que el archivo de entrenamiento que se le da también corresponde a ese sensor. Para hacer esto de forma automática se implementó el script (ver Listado 5.5) probar.sh, de otra forma habría que haber ejecutado Probar.py numerosas veces: 154pruebas 9sensores = 1386ejecuciones Este script sencillamente automatiza la tarea de probar cada uno de los archivos de una prueba con los modelos. Pero son 154 ejecuciones aún las que habría que hacer por lo que se elaboró otro script que automatizara esta tarea probartodo.sh (ver Listado 5.6). El resultado simplemente se muestra por pantalla, como se ha visto en Probar.py con lo que sólo es necesario el uso del operador > para guardar el resultado en un archivo. Este archivo Resultados.txt tiene el siguiente aspecto: 72

102 Accuracy = % ( 50/ 67) ( classification ) Sueltas / Alba /1/ Acelerometro. txt [2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0] Accuracy = 0 % ( 0/ 67) ( classification ) Sueltas / Alba /1/ Giroscopio. txt [2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0, 2.0] Accuracy = 25 % ( 3/ 12) ( classification ) Sueltas / Alba /1/ Humedad. txt [2.0, 2.0, 2.0, 1.0, 1.0, 2.0, 2.0, 1.0, 2.0, 2.0, 2.0, 2.0] Accuracy = 100 % ( 67/ 67) ( classification ) Sueltas / Alba /1/ Luz. txt [1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0]... Si se observa el primer caso, Accuracy = % representa el porcentaje de precisión de acierto que ha tenido. De las 67 posibilidades ha acertado 50, por lo que ha acertado el % de las veces. Cada uno de los valores de la matriz, representa qué acción ha interpretado el clasificador que se estaba haciendo durante el transcurso de esa señal. Este archivo es inmensamente largo, ya que contiene, 1386 pruebas. Para poder observar estos resultados de un solo vistazo se ha implementado un programa en Python que genera matrices de confusión a partir de este archivo de resultados, llamado matriz_confusion.py (ver Anexo A). En el se definieron varias funciones: construir: es la encargada de inicializar las listas que formarán la matriz con 0. def construir ( matriz ): for i in range ( 14) : matriz. append ([]) for j in range ( 14) : 73

103 matriz [i]. append (0) imprimir: es la dedicada a imprimir las matrices. def imprimir ( diccionario ): buf = "" for i in diccionario : buf +=i+"\n" for j in diccionario [ i]: buf += str (j)+"\n" buf +="\n" print buf return buf sumar: es la función que realiza las sumas de las matrices. Se ha de sumar una unidad a la posición que corresponda del diccionario, según la acción que se haya interpretado y el sensor al que pertenezca. def sumar ( diccionario, sensor, accion, linea ): vector = linea [1: 1]. split (",") for i in vector : diccionario [ sensor ][ accion ][ int (i. split (".") [0]) 1]+=1 Para comenzar se crean las 9 listas correspondientes a los 9 sensores y se inicializan a ceros con la función construir. Después se crea un diccionario en el cual la clave es el nombre del sensor y el valor es la lista correspondiente a ese sensor. De esta forma se obtiene una matriz, organizada por el nombre del sensor. acelerometro = [] barometro = [] giroscopio = [] gps = [] humedad = [] luz = [] magnetico = [] proximidad = [] temperatura = [] construir ( acelerometro ) construir ( barometro ) construir ( giroscopio ) construir ( gps ) construir ( humedad ) 74

104 construir ( luz ) construir ( magnetico ) construir ( proximidad ) construir ( temperatura ) diccionario = {" Acelerometro ": acelerometro," Barometro ": barometro," GPS " :gps," Magnetico ": magnetico," Humedad ": humedad," Luz ":luz," Giroscopio ": giroscopio," Proximidad ": proximidad," Temperatura ": temperatura } Cuando ya está la estructura de datos creada se comienza a leer el archivo Resultados.txt y se abre el flujo de un nuevo archivo para guardar las matrices una vez generadas. Después se crea una lista que contiene el desplazamiento numérico necesario para ir seleccionando las líneas del archivo de resultados. Hay 3 líneas por cada prueba, por lo que el desplazamiento se hace de 3 en 3: 3 = 3, 6, 9, 12, 15, 18, 21,..., 1386 file = open ("./ Resultados. txt ", "r") texto = file. read () file = open ("./ Matrices. txt ", "w") lineas = texto. split ("\n") desplazamiento = [] for i in range ( len ( lineas ) 1): if i % 3 == 0 : desplazamiento. append (i) Con los valores del desplazamiento en la lista ya es posible recorrer el texto para captar todos los valores del texto: el vector con todas las interpretaciones, la acción y el tipo de sensor. Para poder acceder a todos estos valores de nuevo se ha utilizado la función split. El vector de predicciones contiene cada una de las acciones que SVM ha determinado que corresponde a esos valores. Hay que recorrerlo y sumar las cantidades a las posiciones correspondientes de las matrices, para ello se utiliza la función sumar, explicada anteriormente. for i in desplazamiento : vector = lineas [ i +2] accion = lineas [i +1]. split (". txt ",2) [0]. split ("/") [2] sensor = lineas [i +1]. split (". txt ",2) [0]. split ("/") [3] sumar ( diccionario, sensor, int ( accion ) 1, vector ) file. write ( imprimir ( diccionario )) 75

105 Cuando el programa finaliza se ha generado un archivo Matrices.txt que contiene las 9 matrices en texto plano de la siguiente forma: Acelerometro [192, 197, 0, 0, 0, 0, 0, 0, 0, 69, 0, 0, 0, 0] [59, 5825, 10, 0, 0, 20, 0, 0, 0, 67, 0, 0, 0, 0] [2, 280, 183, 0, 0, 1, 0, 0, 0, 3, 0, 0, 0, 0] [3, 295, 1, 0, 0, 12, 0, 0, 0, 10, 0, 6, 0, 0] [2, 173, 1, 0, 0, 3, 0, 0, 0, 5, 0, 0, 0, 0] [8, 212, 3, 0, 0, 34, 0, 0, 1, 31, 1, 5, 0, 0] [2, 121, 4, 0, 0, 6, 0, 0, 0, 9, 1, 0, 1, 0] [5, 370, 6, 0, 0, 1, 0, 0, 0, 7, 1, 1, 0, 0] [5, 350, 16, 0, 0, 4, 0, 0, 0, 2, 0, 0, 0, 0] [88, 266, 1, 0, 0, 4, 0, 0, 0, 425, 1, 0, 0, 0] [97, 149, 0, 1, 0, 2, 0, 0, 0, 94, 1, 0, 0, 0] [24, 218, 4, 0, 0, 2, 0, 0, 0, 9, 0, 0, 0, 0] [12, 192, 18, 0, 0, 1, 0, 0, 0, 5, 0, 0, 1, 0] [3, 123, 0, 0, 0, 1, 0, 0, 0, 16, 0, 0, 0, 0] De esta forma de un vistazo se pueden observar los resultados del sistema, éstos serán analizados en la sección de resultados. 76

106 public void leer (){ File f = new File ( ruta ); BufferedReader texto ; StringTokenizer st = null; String tipo = tipo ( ruta ); int t= tipoentero ( tipo ); switch (t){ case 1: try { texto = new BufferedReader (new FileReader ( f)); while( texto. ready ()){ Evento aux = new Evento1 ( tipo ); st = new StringTokenizer ( texto. readline (), " \t"); aux. settiempo (st. nexttoken ()); st. nexttoken (); aux. setx ( Double. parsedouble (st. nexttoken ())); eventos. anadir ( aux ); } }catch ( IOException e) { e. printstacktrace (); } break; case 2:... aux. settiempo (st. nexttoken ()); st. nexttoken (); aux. setx ( Double. parsedouble (st. nexttoken ())); st. nexttoken (); aux. sety ( Double. parsedouble (st. nexttoken ())); eventos. anadir ( aux );... break; case 3:... aux. settiempo (st. nexttoken ()); st. nexttoken (); aux. setx ( Double. parsedouble (st. nexttoken ())); st. nexttoken (); aux. sety ( Double. parsedouble (st. nexttoken ())); st. nexttoken (); aux. setz ( Double. parsedouble (st. nexttoken ())); eventos. anadir ( aux );... break; default: Log.e(" Leer ", " Error al leer los archivos "); break; } } Listado 5.2: Leer ficheros 77

107 public void ventana_ deslizante ( Cola < Evento > aux,int tam_ ventana, int superposicion, ClienteTCP c, String accion ) throws CloneNotSupportedException { Cola < Evento > ventana = new coladinamica < Evento >() ; while(! aux. esvacia ()){ if( ventana. tamanio () < tam_ventana ){ // Se introducen los primeros valores for(int i =0;i< tam_ventana ;i ++) { if(! aux. esvacia ()){ ventana. anadir ( aux. primero ()); aux. quitar (); } } } } }else{ // Se realizan los desplazamientos con la superposicion elegida for(int i =0;i< tam_ventana superposicion ;i ++) { ventana. quitar (); if(! aux. esvacia ()){ ventana. anadir ( aux. primero ()); aux. quitar (); } } } enviarventana ( ventana,c, accion ); Listado 5.3: Ventana deslizante #! / bin / bash entrenador ="./ Entrenador.py" directorio ="./ Entrenamiento " if [ \$# eq 2 ]; then entrenador =$(expr $1) directorio =$(expr $2) fi if [ $# ne 2 a $# ne 0 ]; then echo " Indique el entrenador y el directorio de las pruebas o no indique nada. Por defecto :\ n Entrenador >./ Entrenador. py\ n Archivos de entrenamiento./ Entrenamiento )" exit 1 fi mkdir p " Modelos " archivos =$(ls $directorio ) for dir in $archivos do python $entrenador $directorio / $dir " Modelos " done Listado 5.4: Script para entrenar el sistema 78

108 #! / bin / bash if [ $# eq 2 ]; then probar =$(expr $1) modelos =$(expr $2) prueba =$(expr $2) fi if [ $# ne 3 ]; then echo " Formato :./ probar <Probar.py > <Modelos > <Prueba >" exit 1 fi archivos =$(ls $modelos ) for fichero in $archivos do python $probar $modelos / $fichero $prueba / $fichero. txt done Listado 5.5: Script probar.sh #! / bin / bash if [ \$# eq 3 ]; then pruebas =$(expr $3) modelos =$(expr $2) probar =$(expr $1) fi if [ $# ne 3 ]; then echo " Formato :./ probartodo <Probar.py > <Modelos > <Pruebas >" exit 1 fi carpetas =$(ls $pruebas ) for nombre in $carpetas do acciones =$(ls $pruebas / $nombre ) for numero in $acciones do ficheros =$(ls $pruebas / $nombre / $numero ) for fichero in $ficheros do sensor = $(echo $fichero cut d. f1) python $probar $modelos / $sensor $pruebas / $nombre / $numero / $fichero done done done Listado 5.6: Probar el Sistema 79

109

110 Capítulo 6 Resultados EN el siguiente capítulo se procede a explicar los resultados obtenidos después del desarrollo del proyecto. Toda la información acerca del proyecto, documentación y fuentes se encuentran en un repositorio público (véase https://bitbucket.org/arco group/ tfg.alba.baron). El objetivo principal de este proyecto es proporcionar un sistema capaz de reconocer acciones que hace una persona de forma autónoma. Para ello debe usar los datos que le ofrecen los sensores de su smartphone. Las matrices de confusión determinan el grado de acierto del sistema para cada sensor y para cada acción. En muchas de las acciones no se han conseguido buenos resultados en todos los sensores. Estas tablas permiten ver de una forma relativamente sencilla cómo funciona el sistema, qué sensor funciona mejor para predecir una acción concreta o qué acción no ha sido capaz de ser reconocida en ningún sensor. Algunos de los sensores han dado una baja respuesta, en algunos era previsible, ya que la información que ofrecen no tiene por qué representar un movimiento (barómetro, luz,...). Aún así, en este proyecto se decidió probar todos los sensores para ver cómo podían responder. También es posible utilizar el sistema para predecir otro tipo de actividades en las que sí pueden ser útiles este tipo de sensores, por lo que se decidió no eliminar ninguno. A continuación se analizan las diferentes matrices de confusión de los diferentes sensores. 6.1 Matriz de Confusión del Barómetro Matriz de confusión del Barómetro (ver Tabla 6.1): en esta matriz se puede ver claramente que la acción que se ha reconocido en mayor número con los datos del barómetro ha sido la número 2, es decir, andar. Tiene un total de 1423 aciertos de 2409 pruebas, lo que es una buena cifra. Pero si se observa, todas las acciones han sido confundidas con andar en mayor o menor número, lo que afecta también a la precisión del sistema respecto a la acción andar. Otra de las acciones que ha reconocido el sistema ha sido subir escaleras (8), pero de nuevo el sistema ha confundido todas las demás acciones alguna vez con esta. 81

111 El resto de acciones no se han reconocido en ningún caso correctamente confundiéndose casi el 100 % de las veces con andar o subir escaleras. Esto puede ser debido a que el barómetro mide la presión del aire y ésta no varia de una forma significativa en las diferentes acciones que se han querido predecir. Acción Cuadro 6.1: Matriz de confusión del Barómetro 6.2 Matriz de Confusión del Sensor Magnético Matriz de confusión del sensor Magnético (ver Tabla 6.2): en la matriz del sensor Magnético puede apreciarse que hay mucha más variedad en cuanto a las posibles confusiones con las acciones. La acción que más veces ha sido predecida con éxito ha sido andar (2), con 747 aciertos de 2271 pruebas. Pero ha sido confundida más veces, 805/2271, con subir en ascensor. Otra acción que ha sido reconocida con éxito un número importante de veces ha sido esperar (1), con 127 aciertos de 420 pruebas, con un número de confusiones menor con otras acciones. En el caso de la acción subir en ascensor (10), ha sido acertada 63 veces de 367 pero ha sido confundida con empujón (14) 90 veces. El resto de acciones han sido acertadas en muy pocas ocasiones y confundidas en la gran mayoría. Esto es debido a que el sensor magnético sirve para medir el campo magnético de la tierra y el smartphone lo utiliza para optimizar el uso del GPS, así que por si sólo no tiene por qué ofrecer demasiada información acerca de los movimientos de la persona. 6.3 Matriz de Confusión del Giroscopio Matriz de confusión del Giroscopio (ver Tabla 6.3): en el caso del giroscopio se ha formado una matriz de confusión bastante curiosa, las acciones se han confundido todas con andar (1) y en algunos caso con correr (2). 82

112 El giroscopio da información acerca de la dirección y el sentido en el que está colocado el teléfono. Estos valores pueden variar dependiendo de cómo introduzca el usuario el móvil en el bolsillo, más horizontal, más vertical, boca arriba o boca abajo; pero en líneas generales, el móvil estará en la misma posición o muy parecida en todos los usuarios. Si el terminal está en el bolsillo, su dirección no cambia durante la acción a no ser que el usuario cambie de posición. Es posible que por estas razones todas las acciones se confundan con andar, ya que es la acción de la que más minutos de prueba se han obtenido, y es más fácil encontrar alguna coincidencia. Por otro lado, se han identificado 5904 veces correctamente la acción andar de 5917 pruebas, lo que supone una buena cifra. 6.4 Matriz de Confusión del Acelerómetro Matriz de confusión del Acelerómetro (ver Tabla 6.4): el caso del acelerómetro es algo más complejo que los demás, cada acción ha dado unos resultados muy diferentes. El acelerómetro es uno de los sensores que mayor resultado debería dar ya que sus valores dependen directamente del movimiento. Podemos ver que hay algunas acciones que se confunden con otras, como en los casos anteriores, pero no de una forma tan sistemática, por lo que requerirá un análisis más exhaustivo. La acción (1), esperar, se ha interpretado tantas veces como andar que como esperar, confundiéndose también con subir escaleras (10), pero no se ha confundido con ninguna acción mas. La acción (2) andar ha tenido 5825 aciertos de 5981 pruebas, y aunque ha sido confundida en alguna ocasión con otras acciones (esperar, correr, tumbarse o subir en ascensor) son cifras bastante pequeñas en comparación con el número de aciertos. Se podría decir, que el acelerómetro es un buen sensor para predecir la acción andar. La acción (3) correr y la acción (10) subir en ascensor presentan un caso similar, tienen un considerable número de aciertos, pero ambas son confundidas con andar en muchas ocasiones. En el caso de correr, supera el número de aciertos, por lo que no es un buen resultado. En el caso de subir en ascensor, no supera el número de aciertos, queda bastante por debajo, pero aún así es una cifra considerable. No ocurre así con el resto de acciones, que son confundidas con andar principalmente. También acciones como subir en ascensor, patada, puñetazo o empujón son confundidas en muchas ocasiones con esperar, lo que es normal, ya que el usuario en esas acciones no se mueve en exceso y puede aparentar estar esperando. 83

113 Acción Cuadro 6.2: Matriz de confusión del sensor Magnético Acción Cuadro 6.3: Matriz de confusión del Giroscopio 84

114 6.5 Matriz de Confusión del Sensor de Temperatura Matriz de confusión del sensor de Temperatura (ver Tabla 6.5): la matriz de confusión del sensor de temperatura confunde prácticamente todas las acciones con andar. Esto puede ser debido a que la cantidad de minutos de pruebas grabadas durante la recogida de datos de la acción andar es cuantiosamente más grande que la del resto de acciones. Por ello, el sistema puede relacionar más fácilmente datos con esta acción, ya que tiene más modelos generados. En principio, la temperatura ambiental, alterada también por la temperatura corporal de la persona, no debería diferenciar en gran medida una acción de otra, ya que no varía en exceso según la acción. Puede estar determinada por la época del año o por la ropa que porte la persona. 6.6 Matriz de Confusión del Sensor de Humedad Matriz de confusión del sensor de Humedad (ver Tabla 6.6): el caso del sensor de humedad vuelve a presentar numerosas confusiones con andar, lo que vuelve a hacer sospechar que toma esa acción porque es de la que más datos se obtuvieron en la recogida de datos. Con el sensor de humedad ocurre una situación semejante a la del sensor de temperatura, depende directamente del ambiente, época del año, lugar e incluso de la ropa del usuario. Y por otra parte, no es un indicativo directo del movimiento o la posición de una persona, que son los datos más relevantes a la hora de predecir una acción física. 6.7 Matriz de Confusión del Sensor de Luz Matriz de confusión del sensor de Luz (ver Tabla 6.7): el sensor de luz se sitúa en la parte frontal del teléfono, por lo que dependerán de la posición en la que coloque el usuario el dispositivo en su bolsillo, los resultados que ofrezca. Si el usuario introduce el smartphone en su bolsillo con la pantalla mirando hacia su pierna recibirá muy poca o nada de luz; si por el contrario lo sitúa justo al revés, con la pantalla mirando hacia fuera, hacia el bolsillo, dependerá directamente de la opacidad de la tela de ese bolsillo la cantidad de luz que pueda llegar al dispositivo. Es por este motivo por el cual los resultados no son concluyentes, se confunde habitualmente cualquier acción con esperar (1) y en otras muchas ocasiones con cualquier otra acción, sin un patrón definido. 6.8 Matriz de Confusión del Sensor de Proximidad Matriz de confusión del sensor de Proximidad(ver Tabla 6.8): en este caso la matriz de confusión muestra muy pocos valores porque existen muy pocos eventos de este sensor en las pruebas. El sensor de proximidad determina si existe un objeto a 5 cm. de él, estando éste 85

115 Acción Cuadro 6.4: Matriz de confusión del Acelerómetro Acción Cuadro 6.5: Matriz de confusión del sensor de Temperatura 86

116 Acción Cuadro 6.6: Matriz de confusión del sensor de Humedad Acción Cuadro 6.7: Matriz de confusión del sensor de Luz 87

117 situado en la parte frontal del dispositivo. Por tanto, los valores de este sensor se producen cuando se introduce y se extrae el teléfono del bolsillo. Además, este valor varía entre el 0 (ningún objeto próximo) o 1 (un objeto próximo), lo que no permite jugar con los datos de la misma forma que el resto de los sensores. Cuando el dispositivo permanece dentro del bolsillo, el sensor de proximidad no debería generar ningún evento ya que todo el tiempo tiene un objeto próximo, no se le acerca ni se le aleja ningún objeto. Este sensor sería práctico en caso de portar el teléfono en un dispositivo de sujeción en el brazo, o en alguna parte visible del cuerpo. Acción Cuadro 6.8: Matriz de confusión del sensor de Proximidad 6.9 Matriz de Confusión del GPS Matriz de confusión del GPS (ver Tabla 6.9): en el caso del GPS los valores no son concluyentes porque no había muestras suficientes. El problema principal radica en que en el aproximadamente 90 % de las pruebas, éste no se ha conectado con ningún satélite. Esto se ha producido por varias causas: primeramente por hacerse las pruebas en entornos cerrados (edificios) y secundariamente por ser pruebas ejecutadas de forma rápida, con lo que el sensor no tiene tiempo suficiente para conectarse. 88

118 Acción Cuadro 6.9: Matriz de confusión del GPS 89

119

120 Capítulo 7 Conclusiones EN este capítulo se exponen las conclusiones alcanzadas fruto de la realización de este TFG, así como propuestas a posibles mejoras y líneas de trabajo que se abren a partir de este trabajo. 7.1 Conclusiones Este proyecto contenía 7 objetivos principales (ver sección 2): Estudiar los sensores del Samnsung Galaxy S4 y cómo interaccionar con ellos. Buscar voluntarios y recoger datos acerca de todas las acciones que se quieran predecir. Enviar la señal de los sensores recogidos hasta un servidor que procese éstos. Procesar la señal de los sensores utilizando la transformada DWT y más tarde con medidas estadísticas. Generar los archivos de entrenamiento para posteriormente utilizar el clasificador SVM. Entrenar el sistema con LIBSVM. Validar el sistema. A continuación se exponen las conclusiones de cada uno de ellos Interacción con los sensores de Samsung Galaxy S4 El primer objetivo del TFG consistía en estudiar los sensores del smartphone Samsung Galaxy S4 y desarrollar una aplicación para almacenar sus señales. Con lo cual no sólo había que captar la señal de los sensores y sino que también había que crear ficheros y almacenar esta señal en ellos de una forma ordenada. Así, podemos concluir que: Todo el proceso ha sido llevado a cabo por una aplicación Android, lo cual no ha supuesto ningún problema de implementación. La app recogía correctamente los eventos de los sensores del smartphone por lo que se pudo proceder a guardar estos en ficheros. 91

121 Se creó una jerarquía de directorios sencilla para el almacenaje de estos ficheros con sencillas operaciones con cadenas en java. De forma que quedaran ordenados por usuario y acción. Todo esto se llevó a cabo sin mayor problema, almacenando la jerarquía de directorios en la memoria externa del dispositivo. La interfaz de usuario fue modificada en varias ocasiones para poder garantizar su affordance (intuitiva), de modo que fuera fácil hacer correctamente las pruebas para los usuarios. Para ello se usaron cambios de color al grabar y botones en vez de menús. La aplicación almacenaba los valores sin problemas, pero se ha de tener en cuenta que la utilización continuada de los sensores consume una mayor cantidad de energía, lo cual es un problema en un dispositivo que funciona con batería. Por ello han se han de observar los resultados de todos los sensores con respecto a las acciones y determinar qué sensores verdaderamente útiles Buscar voluntarios y recoger datos Este segundo objetivo, que inicialmente no presentaba síntomas de dar problemas, fue una tarea compleja. La búsqueda de voluntarios para realizar las acciones y grabarlas no fue el problema, sino la limitación de tener que trabajar con el smartphone Samsung Galaxy S4, con el cual sólo contaba el director del proyecto y con el que contaban muy pocos voluntarios. Por ello se decidió, además de tomar pruebas a los voluntarios guiadas por el equipo, solicitar a voluntarios que tomaran pruebas en sus hogares o en su entorno y nos fueran enviadas. De esta forma se obtuvieron mayor número de pruebas pero no suficientes. Se puede concluir que la falta de un dataset completo ha impedido que la precisión de acierto del sistema sea suficiente. Las pruebas deberían haber sido más largas y más numerosas. Además deberían haberse realizado utilizando el sistema, ya incluido en la app, de Iniciar a los 5 segundos, de forma que los datos iniciales no correspondieran a la acción de meterse el móvil en el bolsillo, sino que ya comenzara la app a grabar cuando el voluntario estuviera llevando a cabo la acción en concreto. Además, deberían tomarse pruebas también al aire libre o en emplazamientos en los que el GPS pueda conectarse con un satelite y ofrecer información útil sobre la posición o la distancia recorrida de la persona. Con todas estas mejoras pueden darse unos resultados mucho mejores en las matrices de confusión Enviar la señal a un servidor que la procese Los datos almacenados en el paso anterior debían ser procesados por un algoritmo de ventana deslizante, para después poderlos caracterizar con la DWT. Se decidió implementar otra aplicación Android para este cometido, ya que esta tarea en un futuro deberá realizarse en tiempo real. Los datos recogidos de los sensores deberán enviarse directamente al servidor en forma de ventana deslizante, sin almacenarse en archivos previamente y posteriormente 92

122 ser procesados y enviados. Se procedió a implementar otra aplicación porque el convertir el sistema en un sistema a tiempo real es una tarea compleja que iba a suponer demasiado tiempo con el que no se contaba, de forma que se queda como tarea pendiente en la continuación de este sistema. Al implementar otra aplicación permite en un futuro hacer algo parecido a una «fusión» de ambas aplicaciones para el sistema en tiempo real. Esta aplicación, PerSeTCP fue más complicada que la anterior, ya que debía leer los ficheros, interpretarlos, procesar la señal de éstos por la ventana deslizante y enviarla a través de un cliente TCP hacia el servidor. De este proceso podemos concluir que: Captar la señal de los sensores de los archivos generados por la app de Recogida de Datos es una tarea extensa pero sencilla. Sólo es necesario desplazarse por el archivo guardando en objetos Evento los valores de los sensores. Es posible procesar una señal a través de una ventana deslizante de una forma semejante a como el protocolo TCP procesa su comunicación. Una ventana de un tamaño y solapamiento flexible es posible implementarla en Java con Android sin problemas y procesar con ella la señal de los sensores. Convirtiendo antes los eventos del sensor en objetos Evento y haciendo de la ventana deslizante una cola de eventos dinámica. La implementación de un cliente en la aplicación fue primeramente llevada a cabo con el protocolo UDP. Más tarde fue cambiada a TCP ya que las ventanas llegaban al servidor desordenadas o incluso se perdían. Esto es debido a que UDP no ofrece garantías acerca de la llegada de sus envíos, por ello se cambió a TCP, que sí ofrece estas garantías, porque solicita confirmación de recepción de cada paquete que envía Procesar la señal de los sensores El motivo principal de desarrollar este servidor y no realizar todo el procesamiento en la app Android fue la imposibilidad de procesar los datos por la DWT en el dispositivo. Se estudió la posibilidad de usar bibliotecas de LIBSVM para Java pero no se encontró esa posibilidad. También se estudió la posibilidad de ejecutar LIBSVM para Python en el dispositivo, con software especializado en la ejecución de éste lenguaje interprete en Android como lo es SL4A 1 pero no pudo ser posible ya que no se podía instalar el paquete necesario de pywt para la DWT. Volviendo al servidor, éste debía recibir la señal de los sensores en forma de ventanas y procesarla para obtener todos los valores numéricos del texto. Después éstos valores habían de procesarse ventana a ventana con la Transformada Discreta Wavelet DWT y los coeficientes de ésta con medidas estadísticas. Tras elaborar este módulo de procesamiento se puede concluir que: 1 93

123 Desarrollar el servidor en Python supuso una ventaja a la hora de implementar el resto de las tareas, ya que es un lenguaje intérprete y simplifica las tareas que conllevan estructuras de datos. A su vez existen múltiples funciones para Python que reducen el tiempo de implementación, como funciones para el tratamiento de cadenas o para el cálculo matemático. El cálculo de los coeficientes de la DWT quedó reducido a breves líneas de código con el paquete pywt. De la misma manera que el cálculo de las posteriores medidas estadísticas queda simplificado ya que gracias al paquete numpy, se tiene una función para calcular cada una de las medidas. De esta forma, en el mismo servidor se procesa cada ventana en su llegada, por la DWT y por las medidas estadísticas Generar los archivos de entrenamiento Con el objetivo de entrenar el clasificador se necesitaba generar un archivo de entrenamiento de cada sensor, en los cuales se incluirían los modelos generados a partir de todo el dataset. Los datos procesados por la DWT y las medidas estadísticas debían guardarse en el formato que indica LIBSVM para poder usar después este paquete para la clasificación. La generación de estos archivos fue una tarea sencilla de implementar en Python, en el mismo servidor. Gracias a sus numerosas funciones para trabajar con cadenas de texto, esta tarea se llevó a cabo sin problemas Entrenar el sistema con LIBSVM Una vez generados los archivos de entrenamiento había que entrenar con él el clasificador. Para esta tarea se debía implementar un módulo que utilizase el software para SVM, LIBSVM. Tras la implementación de este módulo de entrenamiento se puede concluir que: Con las funciones que proporciona este software para cargar los archivos de entrenamiento, para el entrenamiento en sí y para guardar los modelos generado, la implementación se realizó con éxito y no se observaron problemas. El tiempo de ejecución del entrenamiento fue más extenso de lo esperado, 6h, por lo que hubo que reestructurar el módulo de validación del sistema Validar el sistema Para validar el sistema, inicialmente se determinó utilizar el sistema de validación cruzada o Leave-One-Out, pero existieron problemas: Se obtuvieron 154 pruebas de voluntarios, que formaban el dataset, por lo que una validación cruzada hubiera supuesto 154 entrenamientos con un dataset de 153 pruebas. Esto fue imposible de llevar a cabo porque el tiempo de ejecución del entrenamiento de 154 pruebas tardaba 6 horas en ejecutarse, suponiendo así tardar unos 38,5 días en llevar a cabo las ejecuciones necesarias para la validación cruzada. 94

124 Se procedió entonces a llevar a cabo las pruebas de otro modo. Se probó el sistema con los modelos generados por todo el dataset (154 pruebas) y se obtuvieron las matrices de confusión gracias a un programa implementado en Python. De haber sido posible, se habría llevado a cabo la validación cruzada en algún centro dedicado a ello, en un centro de cálculo o en varias máquinas. Esto no pudo ser posible ya que esta parte del sistema se implementó fuera del calendario académico y no se tenía la posibilidad de acceder a otros equipos o al centro de cálculo. Es una tarea futura llevar a cabo este sistema de validación cruzada, que proporciona datos más fiables sobre cómo responde el sistema. 7.2 Propuestas Tras haber finalizado el desarrollo del sistema propuesto, son muchas las consideraciones a tener en cuenta en la evolución futura de este proyecto. A continuación se muestra una breve lista con las posibles mejoras o cambios que deberían estudiarse o llevarse a cabo en un futuro. 1. Sería recomendable descartar el uso de algunos de los sensores para reconocer el tipo de acciones que se han tenido en cuenta en este TFG, ya que incrementan el consumo de batería y en algunos casos no proporcionan información útil. Sensores como el GPS, el sensor de humedad o el sensor de luz, han mostrado no ser útiles, aunque sí pueden ser útiles para reconocer otro tipo de acciones. De esta forma se aumentaría la performance (rendimiento) del dispositivo y se reduciría el consumo de energía. 2. Llevar a cabo una mejor, mayor y más exhaustiva recogida de datos. 3. Contar con un equipo mayor para el entrenamiento del sistema y la validación. 4. Unificar todas los módulos del sistema para que funcionen en tiempo real, de manera que pueda obtenerse la acción que está llevando a cabo la persona portadora del smartphone en el momento en el que la está haciendo. 5. En caso hacer funcionar al sistema en tiempo real, se debería estudiar si es eficiente enviar las ventanas de forma continuada o hacerlo cada cierto tiempo. Asimismo habría que estudiar el tamaño de la ventana, para ajustarla lo máximo posible al inicio y fin de las acciones. 6. Obtener pruebas con el dispositivo en otro lugar distinto del bolsillo del pantalón, como en un dispositivo para sujetarlo al brazo o a la pierna, e incluso colocar algún tipo de dispositivo wearable que complemente los valores de los sensores del teléfono móvil, en otra parte del cuerpo. 7. Si existiese la posibilidad, intentar evitar tener que utilizar un servidor, de forma que el procesamiento del sistema se llevara por completo en el terminal móvil. Esto sería 95

125 posible si se prescindiera del uso del la DWT o si se sustituyera por otro sistema que pudiera llevarse a cabo sobre Android. 8. Utilizar la aplicación de recogida de datos para otras acciones diferentes a las contempladas en este TFG, como por ejemplo: acciones como viajar en medios de transporte, acciones que se llevan a cabo en un puesto de trabajo concreto, acciones que se realizan en situaciones de riesgo, etc. 9. Es posible incluir este sistema en un entorno de Smart City (ciudad inteligente), en la que todo está conectado y existen multitud de tipos de sensores. La persona funcionaría como un sensor más de la ciudad inteligente gracias a su dispositivo móvil, ofreciendo información de su situación y de sus acciones. Tras la realización de este TFG se ha publicado un artículo en conjunto con otros proyectos del grupo ARCO 2, de la Escuela Superior de Informática 3. El artículo, Implementing a holistic approach for the Smart City 4 fue presentado en The 2014 IEEE/WIC/ACM International Conference on Intelligent Agent Technology, en Varsovia en Agosto de El artículo presenta una solución global a la integración e implementación de nuevos servicios y dispositivos en el entorno de la Smart City (ciudad inteligente) [RPB + 14]

126 ANEXOS 97

127

128 Anexo A Generación de Matrices de Confusión Este anexo contiene la implementación del programa de generación de matrices de confusión a partir del archivo de resultados: matriz_confusion.py. #!/ usr / bin / env python # coding : utf 8; import sys import unicodedata def construir ( matriz ): for i in range ( 14) : matriz. append ([]) for j in range ( 14) : matriz [i]. append (0) def imprimir ( diccionario ): buf = "" for i in diccionario : buf +=i+"\n" for j in diccionario [ i]: buf += str (j)+"\n" buf +="\n" print buf return buf def sumar ( diccionario, sensor, accion, linea ): vector = linea [1: 1]. split (",") for i in vector : diccionario [ sensor ][ accion ][ int (i. split (".") [0]) 1]+=1 acelerometro = [] barometro = [] giroscopio = [] gps = [] 99

129 humedad = [] luz = [] magnetico = [] proximidad = [] temperatura = [] construir ( acelerometro ) construir ( barometro ) construir ( giroscopio ) construir ( gps ) construir ( humedad ) construir ( luz ) construir ( magnetico ) construir ( proximidad ) construir ( temperatura ) diccionario = {" Acelerometro ": acelerometro," Barometro ": barometro," GPS " :gps," Magnetico ": magnetico," Humedad ": humedad," Luz ":luz," Giroscopio ": giroscopio," Proximidad ": proximidad," Temperatura ": temperatura } file = open ("./ Resultados. txt ", "r") texto = file. read () file = open ("./ Matrices. txt ", "w") lineas = texto. split ("\n") desplazamiento = [] for i in range ( len ( lineas ) 1): if i % 3 == 0 : desplazamiento. append (i) for i in desplazamiento : vector = lineas [ i +2] accion = lineas [i +1]. split (". txt ",2) [0]. split ("/") [2] sensor = lineas [i +1]. split (". txt ",2) [0]. split ("/") [3] sumar ( diccionario, sensor, int ( accion ) 1, vector ) file. write ( imprimir ( diccionario )) 100

130 Anexo B Formulario de Consentimiento En este anexo puede verse el formulario de consentimiento que firmaron los voluntarios en la recogida de datos. Primeramente los voluntarios leyeron las condiciones en un documento informativo para poder dar su consentimiento en el formulario. 101

131 Escuela Superior de Informática de Ciudad Real ÉTICA DE LA INVESTIGACIÓN: FORMULARIO DE CONSENTIMIENTO DE LA MUESTRA Título del Proyecto: PerSen y LoCoMoTe Nombre del investigador: Alba Barón Rubio y Antonio Agudo Dirección de contacto del investigador: y Nombre del director del proyecto: María José Santofimia Romero Dirección de contacto del director del proyecto: SECCIÓN I: Información general 1. Le estamos pidiendo que participe en un estudio. 2. Usted no tiene que participar en el estudio. 3. Si dice que sí, puede dejar de participar en el estudio en cualquier momento. 4. Por favor tome todo el tiempo que necesite para decidir. SECCIÓN II: Sobre el estudio 1. Para qué firma este documento?: Lo firma para poder participar en el estudio. 2. Por qué se está haciendo este estudio de investigación?. Se trata de un estudio de investigación que pretende desarrollar un sistema que reconozca las actividades de las personas a partir de los datos de los sensores de su teléfono. Para ello, será necesario generar un dataset en el que se pueda asegurar que las personas están realizando las acciones con las que se ha entrenado el sistema. Por lo tanto, también será objetivo de este proyecto la generación de dicho dataset a partir de la grabación y etiquetado de escenarios concretos, donde se realice al menos un número relevante de las acciones con las que el sistema haya sido entrenado. Dichas acciones dependerán de las acciones disponibles en los datasets públicos ya que, utilizando un dataset para entrenar el sistema distinto del utilizado para su evaluación, se asegurará la validez del sistema propuesto. 3. Qué pasa si digo sí, quiero participar en el estudio?. si dice que sí: a) Realizaremos una grabación de los valores de los sensores que se produzcan mientras realiza sus actividades. b) Le daremos un formulario con preguntas para que usted conteste. c) Si quiere, podemos leerle las preguntas en voz alta y escribir sus respuestas en el formulario. d) Estas preguntas no tienen respuestas correctas o incorrectas. Puede saltar cualquier pregunta si no quiere contestarla. 4. Cuánto tiempo tomará el estudio?. El estudio tomará alrededor de veinte minutos de su tiempo.

132 Escuela Superior de Informática de Ciudad Real 5. Qué pasa si digo no quiero participar en el estudio?. Nadie le tratará de manera diferente. A usted no se le penalizará. Aunque no recibirá el beneficio de estar en el estudio, no perderá otro beneficio. 6. Qué pasa si digo que sí, pero cambio de opinión más tarde?. Usted puede dejar de participar en el estudio en cualquier momento. A usted no se le penalizará. Aunque no recibirá el beneficio de estar en el estudio, no perderá otro beneficio. 7. Quién verá mis respuestas?. Las únicas personas autorizadas para ver sus respuestas son las que trabajan en el estudio y las que se aseguran de que éste se realice de,manera correcta. Sus respuestas a la encuesta, su información, y una copia firmada de este documento se mantendrá bajo llave en nuestros archivos. Cuando compartamos los resultados del estudio, no incluiremos su nombre. Haremos todo lo posible para que nadie fuera del estudio sepa que usted participó en él. 8. Quién verá los valores de los sensores de sus movimientos?. Las únicas personas autorizadas para ver los valores de los sensores son las que trabajan en el estudio y las que se aseguran de que éste se realice de,manera correcta. Estos ficheros se mantendrán bajo llave en nuestros archivos. Cuando compartamos los resultados del estudio, no incluiremos su nombre. Haremos todo lo posible para que nadie fuera del estudio sepa que usted participó en él. 9. Cómo se usará y compartirá esta información?. a) Usaremos su información sólo para el estudio que se describe en este documento. b) Podemos compartir su malformación con otros miembros de la comunidad investigadora. c) Haremos todo lo posible para asegurarnos de que su información permanmezca privada. Sin embargo, si compartimos información con personas que no estén obligadas a cumplir con la Regla de Privacidad, la información dejará de estar protegida por esta Regla de Privacidad. Díganos si tiene alguna duda al respecto. 10. Por cuanto tiempo se usará mi información?. Durante la duración del proyecto. No usaremos ni compartiremos su información una vez terminado el estudio. 11. Me costará algo participar en el estudio?. No. 12. Participar en el estudio, me ayudará de alguna manera?. Participar en este estudio no le ayudará, pero podría ayudar al desarrollo y avance en el I+D+I. 13. Me pagarán por mi tiempo?. No. 14. Qué debo hacer si tengo preguntas?. Por favor, contacte con los miembros del proyecto, sí: a) Tiene alguna pregunta sobre el estudio. b) Tiene preguntas sobre sus derechos. c) Cree que se ha lesionado de alguna manera por participar en este estudio. 15. Se hacen cargo los miembros del proyecto en caso de que me produzca algún daño?. No.

133 Escuela Superior de Informática de Ciudad Real 16. Tengo que firmar este documento?. No. Fírmelo solamente si desea participar en el estudio. 17. Qué debo hacer si quiero participar en el estudio?. Tiene que firmar este documento. Le entregaremos una copia. Al participar en este documento esta diciendo que: a) Está de acuerdo con participar en el estudio. b) Le hemos explicado la información que contiene este documento y hemos contestado todas sus preguntas.

134 Escuela Superior de Informática de Ciudad Real ÉTICA DE LA INVESTIGACIÓN: FORMULARIO DE CONSENTIMIENTO DE LA MUESTRA Título del Proyecto: PerSen y LoCoMoTe Nombre del investigador: Alba Barón Rubio y Antonio Agudo Dirección de contacto del investigador: y Nombre del director del proyecto: María José Santofimia Romero Dirección de contacto del director del proyecto: 1. Sexo: Hombre / Mujer 2. Edad: Altura: Peso:... A cumplimentar por el participante Condiciones de aceptación a) Confirmo que he leído y entendido la hoja de información para el estudio anterior y he tenido la oportunidad de hacer preguntas. b) Entiendo que mi participación es voluntaria y que soy libre de retirarme en cualquier momento, sin dar razón. c) Estoy de acuerdo en participar en el estudio anterior. d) Estoy de acuerdo en que serán grabados los valores que ofrezcan los sensores en mis actividades e) Estoy de acuerdo en el uso de comillas anónimas en las publicaciones

135 Escuela Superior de Informática de Ciudad Real A cumplimentar por el investigador 1. Nombre de actor: Hora de comienzo de la grabación: Hora de finalización de la grabación: Observaciones: Incidencias: Nombre del Participante Fecha Firma Nombre del Investigador Fecha Firma

136 Anexo C Formularios de Consentimiento Firmados En el siguiente anexo se exponen algunos de los formularios de consentimiento firmados por los voluntarios, como muestra del proceso seguido para la obtención de los datos. No se exponen todos los documentos por evitar aumentar en exceso la extensión del documento. 107

137

138

139

140

141

142

143

144

GUIA RÁPIDA DE VNC Antonio Becerro 2005

GUIA RÁPIDA DE VNC Antonio Becerro 2005 Guia rápida de VNC Como acceder de forma remota a un ordenador y utilizar todos los programas del mismo Copyright (c) 2005 Antonio Becerro Martinez. Permission is granted to copy, distribute and/or modify

Más detalles

MANUAL CÁMARA DE MOWAY

MANUAL CÁMARA DE MOWAY MANUAL CÁMARA DE MOWAY Página 2 de 12 Copyright (c) 2011 Bizintek Innova, S.L. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License,

Más detalles

La diabetes tipo 1 vista por un diabético (2.0) José Antonio Becerra Permuy 25/03/2015

La diabetes tipo 1 vista por un diabético (2.0) José Antonio Becerra Permuy 25/03/2015 La diabetes tipo 1 vista por un diabético (2.0) José Antonio Becerra Permuy 25/03/2015 Quién soy? Diabetes Mellitus tipo 1 (DM1) desde los 12 años. Edad actual: 41. Informático (predisposición a cacharrear

Más detalles

Taller temático: Máquina a máquina Movilización de la Internet de las cosas

Taller temático: Máquina a máquina Movilización de la Internet de las cosas Programa Ministerial de la GSMA 2015: Informe de la sesión Taller temático: Máquina a máquina Movilización de la Internet de las cosas Lunes, 2 de marzo de 2015 La sesión fue organizada por Jeanine Vos,

Más detalles

Presentación Unidad ehealth de Telefónica

Presentación Unidad ehealth de Telefónica Presentación Unidad ehealth de Telefónica Telefónica presenta su nueva Unidad de Negocio de ehealth el 13 de julio en su nueva sede madrileña de Las Tablas con la presencia de la ministra de Sanidad, Trinidad

Más detalles

Dispositivo de Comunicación orientado a Servicios de Tele-asistencia, Seguimiento y Localización.

Dispositivo de Comunicación orientado a Servicios de Tele-asistencia, Seguimiento y Localización. Dispositivo de Comunicación orientado a Servicios de Tele-asistencia, Seguimiento y Localización. MobileTel es un dispositivo de comunicación GSM, orientado entre otros a los servicios de teleasistencia,

Más detalles

CEFIRE de Valencia Curso Iniciación a Edubuntu Código: 07VA66EA036

CEFIRE de Valencia Curso Iniciación a Edubuntu Código: 07VA66EA036 CEFIRE de Valencia Curso Iniciación a Edubuntu Código: 07VA66EA036 Sesión 5: 3 de diciembre de 2007 Actualizar el sistema en castellano Ponente: Bartolomé Sintes Marco. IES Abastos (Valencia) Curso Iniciación

Más detalles

INFORMACIÓN DEL PRODUCTO

INFORMACIÓN DEL PRODUCTO 1 Hospitales / Clínica Todo en un diseño Checkme Pro toma mediciones precisas de varios parámetros de signos vitales, y se puede utilizar en una amplia gama de escenarios de aplicación, incluyendo hospitales,

Más detalles

Bosch Care Solutions Protección y seguridad que mejoran la vida

Bosch Care Solutions Protección y seguridad que mejoran la vida Bosch Care Solutions Protección y seguridad que mejoran la vida 2 Una larga tradición en el cuidado Ante todo, lo que define al grupo Bosch, es que nuestros clientes nos importan. Tenemos el compromiso

Más detalles

SMART CITY EXPO WORLD CONGRESS

SMART CITY EXPO WORLD CONGRESS SMART CITY EXPO WORLD CONGRESS 18-20 NOVIEMBRE DE 2014 Dossier de prensa Smart City: del concepto a la realidad Las Smart Cities han pasado de ser un concepto tecnológico a una tendencia presente que busca

Más detalles

CORREO ELECTRONICO CON MOZILLA THUNDERBIRD

CORREO ELECTRONICO CON MOZILLA THUNDERBIRD Centro de Teleinformación (CTI) Unidad de Adiestramiento (CTI- Adiestramiento) CORREO ELECTRONICO CON MOZILLA THUNDERBIRD Versión 2.1 Ing. Andrea Muñoz Santibañez Mérida, Venezuela, 16 de Noviembre del

Más detalles

CETEM Centro Tecnológico del Mueble y la Madera de la Región de Murcia

CETEM Centro Tecnológico del Mueble y la Madera de la Región de Murcia CETEM Centro Tecnológico del Mueble y la Madera de la Región de Murcia Departamento de Electrónica y Domótica Dr. Rafael Maestre Ferriz Jornada Mobiliario Inteligente, CIS Madeira 1 Historia del centro

Más detalles

Teleprevención Sociocomunitaria. PREMIOS CONTRATOS Y PROYECTOS SMART CITIES 2014 Fundación Socinfo

Teleprevención Sociocomunitaria. PREMIOS CONTRATOS Y PROYECTOS SMART CITIES 2014 Fundación Socinfo Teleprevención Sociocomunitaria PREMIOS CONTRATOS Y PROYECTOS SMART CITIES 2014 Fundación Socinfo 1 Nombre del Proyecto: Teleprevención Sociocomunitaria MiAvizor (www.miavizor.es) Administración y creación:

Más detalles

Sistema de monitoreo remoto y evaluación de signos vitales en pacientes con enfermedades crónicas.

Sistema de monitoreo remoto y evaluación de signos vitales en pacientes con enfermedades crónicas. Sistema de monitoreo remoto y evaluación de signos vitales en pacientes con enfermedades crónicas. Grecia Areli López-Orozco 1, Juan Antonio Guerrero-Ibáñez 2, Erika Ramos-Michel 3 Universidad de Colima

Más detalles

La salud móvil Conectividad segura para las aplicaciones de salud móvil, bienestar y vivienda asistida

La salud móvil Conectividad segura para las aplicaciones de salud móvil, bienestar y vivienda asistida La salud móvil Conectividad segura para las aplicaciones de salud móvil, bienestar y vivienda asistida M2M.GEMALTO.COM/mHealth La tecnología M2M potencia la salud móvil La tecnología móvil está revolucionando

Más detalles

Resumen del Proyecto Fin de Carrera

Resumen del Proyecto Fin de Carrera XXVI CONVOCATORIA DE PREMIO Ingenieros de telecomunicación Resumen del Proyecto Fin de Carrera Título: Infraestructuras de telecomunicación en viviendas unifamiliares para soporte de nuevos servicios domóticos.

Más detalles

TECNOLOGÍA PARA GESTIÓN Y SUPERVISIÓN DE PERSONAL

TECNOLOGÍA PARA GESTIÓN Y SUPERVISIÓN DE PERSONAL TECNOLOGÍA PARA GESTIÓN Y SUPERVISIÓN DE PERSONAL ProxyGun en la nube... ProxyCloud Software web para gestión de rondas, servicios y mantenimientos diseñado para gestionar las actividades de personas y

Más detalles

Etapas del desarrollo

Etapas del desarrollo Capítulo 4 Etapas del desarrollo Este capítulo documenta la aplicación del modelo presentado anteriormente, para el caso de la detección y clasificación de eventos sísmicos sobre señales digitales. El

Más detalles

Internet de las Cosas y Educación a Distancia. Hugo A. Banda Gamboa, MSc, PhD CORDICYT, Quito - Ecuador

Internet de las Cosas y Educación a Distancia. Hugo A. Banda Gamboa, MSc, PhD CORDICYT, Quito - Ecuador Internet de las Cosas y Educación a Distancia Hugo A. Banda Gamboa, MSc, PhD CORDICYT, Quito - Ecuador Contenido La Transformación Digital Internet de las Cosas en Educación Conclusiones Dr. Hugo A. Banda

Más detalles

Catálogo de Servicios

Catálogo de Servicios Catálogo de Servicios Fecha: 14 de mayo de 2013 Índice 1 Presentación... 3 2 Servicios de Consultoría SQL Server... 4 2.1 Monitorización servidores SQL Server... 4 2.2 DBA Remoto... 5 2.3 Consolidación

Más detalles

MYWELLNESS CLOUD. You and your members, everywhere.

MYWELLNESS CLOUD. You and your members, everywhere. MYWELLNESS CLOUD Extiende los límites de tu instalación. Conecta con tus clientes donde quiera que estén: en el gimnasio, en casa, de viaje. Mywellness cloud es la nueva plataforma tecnológica de aplicaciones

Más detalles

Primer Informe Doctoralia Salud e Internet 2015

Primer Informe Doctoralia Salud e Internet 2015 Primer Informe Doctoralia Salud e Internet 2015 Realizado en colaboración con: Índice 1. Introducción... 3 2. Nuevos perfiles de pacientes... 5 3. Nuevos flujos de información y comunicación... 8 4. Más

Más detalles

v.1.0.0 DOSSIER SISTEMAS DE SEGURIDAD 2015

v.1.0.0 DOSSIER SISTEMAS DE SEGURIDAD 2015 v.1.0.0 DOSSIER SISTEMAS DE SEGURIDAD 2015 SISTEMAS DE SEGURIDAD Expertos en el sector SEGUREMACS, empresa dentro del grupo, homologada por el Ministerio del Interior (Dirección General de la Policía y

Más detalles

Proyecto PLUMA Plataforma Universal Microcontrolada Aplicaciones didácticas e industriales

Proyecto PLUMA Plataforma Universal Microcontrolada Aplicaciones didácticas e industriales Proyecto PLUMA Plataforma Universal Microcontrolada Aplicaciones didácticas e industriales DOCUMENTACIÓN PARA LA FABRICACIÓN Y PUESTA EN FUNCIONAMIENTO DE LA PLATAFORMA PLUMABOT PEB06 Placa Bluetooth y

Más detalles

Redes de próxima generación: seguridad para hoy y mañana

Redes de próxima generación: seguridad para hoy y mañana Redes de próxima generación: seguridad para hoy y mañana La protección contra las amenazas del presente en redes diseñadas para satisfacer las necesidades del pasado hace vulnerables a las empresas. E

Más detalles

El monitoreo de una variable física requiere supervisión permanente de señales que

El monitoreo de una variable física requiere supervisión permanente de señales que Capítulo 1 Marco Contextual 1.1. Formulación del problema 1.1.1. Definición del problema El monitoreo de una variable física requiere supervisión permanente de señales que varían con el tiempo. Tal información,

Más detalles

Oportunidades de financiación en la Silver Economy

Oportunidades de financiación en la Silver Economy Oportunidades de financiación en la Silver Economy Contenidos Programas europeos o H2020 o AAL o COSME Programas nacionales o Plan estatal de investigación científica y técnica y de innovación Programas

Más detalles

DISFRUTE DE LA EFICACIA DE LA NUBE. DESCUBRA TODO LO QUE LA NUBE PUEDE HACER POR SU NEGOCIO.

DISFRUTE DE LA EFICACIA DE LA NUBE. DESCUBRA TODO LO QUE LA NUBE PUEDE HACER POR SU NEGOCIO. DISFRUTE DE LA EFICACIA DE LA NUBE. DESCUBRA TODO LO QUE LA NUBE PUEDE HACER POR SU NEGOCIO. Las aplicaciones en la nube suponen tanto un cambio de paradigma en la gestión de los centros de datos y la

Más detalles

Internet de (todas) las cosas. Dr. Luis Felipe Vargas Ruiz

Internet de (todas) las cosas. Dr. Luis Felipe Vargas Ruiz Internet de (todas) las cosas Dr. Luis Felipe Vargas Ruiz Septiembre 2015 Este programa cuenta con el apoyo de importantes organismos para garantizar su alcance, impacto y éxito de los resultados 4 Que

Más detalles

FORMACIÓN DEL PROFESORADO PARA LA EDUCACIÓN INCLUSIVA RECOMENDACIONES CLAVE

FORMACIÓN DEL PROFESORADO PARA LA EDUCACIÓN INCLUSIVA RECOMENDACIONES CLAVE FORMACIÓN DEL PROFESORADO PARA LA EDUCACIÓN INCLUSIVA RECOMENDACIONES CLAVE Introducción Este documento resume las conclusiones y recomendaciones del proyecto Formación del profesorado para la educación

Más detalles

Programación en Capas.

Programación en Capas. Programación en Capas. Ricardo J. Vargas Del Valle Universidad de Costa Rica, Ciencias de Computación e Informática, San José, Costa Rica, 506 ricvargas@gmail.com Juan P. Maltés Granados Universidad de

Más detalles

Los mayores ante las TIC (Edad & Vida. Valladolid. Julio 2013) Las TIC como herramientas de gestión de servicios sociosanitarios

Los mayores ante las TIC (Edad & Vida. Valladolid. Julio 2013) Las TIC como herramientas de gestión de servicios sociosanitarios Los mayores ante las TIC (Edad & Vida. Valladolid. Julio 2013) Las TIC como herramientas de gestión de servicios sociosanitarios Josep Pascual Director Técnico Asistencial La mayor plataforma integral

Más detalles

DIGITAL WAITER CARLOS ANDRES PEDRAZA VALDERRAMA RAMIRO ALBERTO PEDRAZA SANCHEZ

DIGITAL WAITER CARLOS ANDRES PEDRAZA VALDERRAMA RAMIRO ALBERTO PEDRAZA SANCHEZ 1 DIGITAL WAITER CARLOS ANDRES PEDRAZA VALDERRAMA RAMIRO ALBERTO PEDRAZA SANCHEZ CORPORACION UNIVERSITARIA MINUTO DE DIOS TECNOLOGIA EN INFORMATICA SOACHA 2012 2 DIGITAL WAITER CARLOS ANDRES PEDRAZA VALDERRAMA

Más detalles

Contenido 1.1 INTRODUCCIÓN... 3 1.1 QUÉ ES LA WEB?... 4 1.1.1 ESTRUCTURA DE LA WEB... 4 1.1.2 LOS SITIOS WEB... 5 1.2 EVOLUCIÓN DE LA WEB... 5 1.

Contenido 1.1 INTRODUCCIÓN... 3 1.1 QUÉ ES LA WEB?... 4 1.1.1 ESTRUCTURA DE LA WEB... 4 1.1.2 LOS SITIOS WEB... 5 1.2 EVOLUCIÓN DE LA WEB... 5 1. Palabras clave Página web, web, e-learning, world wide web, dominio, servidor, HTML, internet, Inteligencia Artificial, Data Web, web 1.0, web 2.0, web 3.0, web 4.0, Bullying cibernético, Streaming. Contenido

Más detalles

Carestream RIS. Creación de un flujo de trabajo

Carestream RIS. Creación de un flujo de trabajo Creación de un flujo de trabajo Carestream RIS Un nuevo enfoque para automatizar el flujo de trabajo en su empresa Carestream RIS Necesita un flujo de trabajo mejor, pero se le plantean cuestiones relacionadas

Más detalles

peos yectos Proyec Europe Susana Fernández Nocelo Responsable gestión proyectos europeos Plataforma Innovación Mayo 2013

peos yectos Proyec Europe Susana Fernández Nocelo Responsable gestión proyectos europeos Plataforma Innovación Mayo 2013 Proyec yectos toseuro Europe peos Susana Fernández Nocelo Responsable gestión proyectos europeos Plataforma Innovación Mayo 2013 Innovar para transformar Innovar para generar valor qué es eso de la plataforma

Más detalles

LoCoMote: Localizing and Recognizing on-the-move Citizen

LoCoMote: Localizing and Recognizing on-the-move Citizen UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA GRADO EN INGENIERÍA INFORMÁTICA TRABAJO FIN DE GRADO LoCoMote: Localizing and Recognizing on-the-move Citizen Antonio Agudo Mansilla Febrero,

Más detalles

Sistema de localización para personas con Alzheimer

Sistema de localización para personas con Alzheimer 121 Sistema de localización para personas con Alzheimer JAIME-PEREZ, Nestor*, MORALES-REYES, Eunice, GILBON-ABURTO, Antonio y PACHECO-REYES, Jimmy Recibido Julio 12, 2015; Aceptado Septiembre 19, 2015

Más detalles

IP Office: La solución de comunicaciones TODO EN UNO para la pequeña y mediana empresa

IP Office: La solución de comunicaciones TODO EN UNO para la pequeña y mediana empresa IP Telephony Contact Centers Mobility Services DESCRIPCIÓN GENERAL IP Office de Avaya IP Office: La solución de comunicaciones TODO EN UNO para la pequeña y mediana empresa Brinde mejor atención al cliente...

Más detalles

INTRODUCCIÓNA LAS REDES MANETS

INTRODUCCIÓNA LAS REDES MANETS SIMULACIÓN DE PROTOCOLOS DE ENRUTAMIENTO PARA REDES MÓVILES AD-HOC MEDIANTE HERRRAMIENTA DE SIMULACIÓN NS-3 INTRODUCCIÓNA LAS REDES MANETS Outline 1. Qué son las redes MANETs? 2. Para qué se utilizan?

Más detalles

CITIC EN PROYECTOS EUROPEOS

CITIC EN PROYECTOS EUROPEOS CITIC EN BREVE Constituido el 13 de Marzo de 2002, como Fundación Privada sin ánimo de lucro bajo el amparo del Plan Director de Innovación y Desarrollo Tecnológico para Andalucía (2001-2003). Un Patronato

Más detalles

IDSEC Control Salud. IP&ID Consulting. contacto@ipidcontuling.com www.ipidconsulting.com

IDSEC Control Salud. IP&ID Consulting. contacto@ipidcontuling.com www.ipidconsulting.com 2010 IDSEC Control Salud IP&ID Consulting. contacto@ipidcontuling.com www.ipidconsulting.com RESUME Desde hace cuatro años las clínicas privadas de la capital empezaron a sentir los efectos de la sobrecarga

Más detalles

NUEVAS HERRAMIENTAS DE MANTENIMIENTO FERROVIARIO PREDICTIVO APROVECHANDO LAS TIC

NUEVAS HERRAMIENTAS DE MANTENIMIENTO FERROVIARIO PREDICTIVO APROVECHANDO LAS TIC NUEVAS HERRAMIENTAS DE MANTENIMIENTO FERROVIARIO PREDICTIVO APROVECHANDO LAS TIC Trilla Castelló, Alexandre Ingeniero de procesamiento de datos TLS España y Portugal, ALSTOM TRANSPORTE S.A. Coca Sola,

Más detalles

Qué tengo que hacer?

Qué tengo que hacer? Quiero tener una app Qué tengo que hacer? por Dale Pablo Somos una startup tecnológica lanzada en 2014 Hacemos hardware y software Algunos datos sobre nosotros Formada por ingenieros con experiencia Pertenecemos

Más detalles

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

La importancia de la innovación de los distribuidores en sistemas, servicios y soluciones para crear ofertas integrales

La importancia de la innovación de los distribuidores en sistemas, servicios y soluciones para crear ofertas integrales IDC TECHNOLOGY SPOTLIGHT La importancia de la innovación de los distribuidores en sistemas, servicios y soluciones para crear ofertas integrales Julio de 2014 Adaptado de Supporting Datacenter Environments:

Más detalles

Servicios de infraestructura. Aplicaciones web

Servicios de infraestructura. Aplicaciones web 10 Julio 2013 Servicios de infraestructura Compílela o tráigala y nosotros la ejecutamos Windows Azure proporciona infraestructura a petición que se escala y se adapta a las necesidades cambiantes de cada

Más detalles

SISTEMAS AVANZADOS DE TELEASISTENCIA EN EL HOGAR

SISTEMAS AVANZADOS DE TELEASISTENCIA EN EL HOGAR SISTEMAS AVANZADOS DE TELEASISTENCIA EN EL HOGAR Julio Montejano Domínguez Consultor Master Marketing de Administraciones Públicas. Telefónica Empresas 1 Blanca SISTEMAS AVANZADOS DE TELEASISTENCIA EN

Más detalles

CMIS. Certus Management Information System TM

CMIS. Certus Management Information System TM CMIS Certus Management Information System TM Qué hay que mejorar para obtener la máxima rentabilidad y eficacia Minimizar costos, maximizar el tiempo de actividad y mostrar un trabajo bien hecho : estos

Más detalles

IBM Software Documento informativo Liderazgo de ideas. Marzo 2013

IBM Software Documento informativo Liderazgo de ideas. Marzo 2013 IBM Software Documento informativo Liderazgo de ideas Marzo 2013 El valor de integrar el desarrollo de aplicaciones móviles y la gestión de dispositivos móviles Cierre la brecha de la seguridad en las

Más detalles

El valor de una infraestructura optimizada

El valor de una infraestructura optimizada El valor de una infraestructura optimizada El Estudio del Estado del CIO 2006 (CIO Research, 2006) muestra que los CIO están buscando, cada vez más, introducir, de forma proactiva, soluciones de tecnología

Más detalles

Uso de un motor de restricciones bajo dispositivos Android

Uso de un motor de restricciones bajo dispositivos Android Uso de un motor de restricciones bajo dispositivos Android Gonzalo Hernández 1, Camilo Villota Ibarra 2, James Muñoz Coronel 3, Harold Muñoz Muñoz 4 Universidad de Nariño, Facultad de Ingeniería, Departamento

Más detalles

Dos de cada tres hogares disponen de conexión de banda ancha a Internet, un 8,0% más que en 2011

Dos de cada tres hogares disponen de conexión de banda ancha a Internet, un 8,0% más que en 2011 3 de octubre de 2012 Encuesta sobre Equipamiento y Uso de Tecnologías de Información y Comunicación (TIC) en los Hogares Año 2012 Dos de cada tres hogares disponen de conexión de banda ancha a Internet,

Más detalles

Curso Avanzado de Programación en Dispositivos Móviles con Android

Curso Avanzado de Programación en Dispositivos Móviles con Android 2013 Curso Avanzado de Programación en Dispositivos Móviles con Android Pablo Formoso Ayudas del programa de consolidación y estructuración de unidades de investigación competitivas: Agrupación Estratégica

Más detalles

Solución IP Office de Avaya

Solución IP Office de Avaya Solución IP Office de Avaya La solución completa para las necesidades de su empresa Redes convergentes de voz y datos Gestión de relaciones con los clientes Comunicación unificada Con el soporte de: Laboratorios

Más detalles

Tecnología 3D. en el diseño de moda. Una revolución en el sector

Tecnología 3D. en el diseño de moda. Una revolución en el sector Tecnología 3D en el diseño de moda Una revolución en el sector Hace tres décadas, el uso de la tecnología en tres dimensiones (3D) en el sector de la moda se limitaba a unos pocos fabricantes muy innovadores,

Más detalles

INFORME RESUMEN. Están los Aprendices del Nuevo Milenio. alcanzando el nivel requerido?

INFORME RESUMEN. Están los Aprendices del Nuevo Milenio. alcanzando el nivel requerido? INFORME RESUMEN Están los Aprendices del Nuevo Milenio alcanzando el nivel requerido? Uso de la tecnología y resultados educativos en PISA Instituto de Tecnologías Educativas Departamento de Proyectos

Más detalles

Red de Bomberos Europeos de la FSESP Informe sobre la duración de la jornada de trabajo y la jubilación

Red de Bomberos Europeos de la FSESP Informe sobre la duración de la jornada de trabajo y la jubilación Red de Bomberos Europeos de la FSESP Informe sobre la duración de la jornada de trabajo y la jubilación Introducción Los pasados días 12 y 13 de julio de 2006, la FSESP convocó una reunión de afiliados

Más detalles

Optimización de redes industriales DEVICENET

Optimización de redes industriales DEVICENET Advanced Industrial Automation Optimización de redes industriales DEVICENET comunicaciones transparentes DeviceNet es una red industrial que permite conectar en red y administrar a distancia una amplia

Más detalles

Capítulo 1: Introducción

Capítulo 1: Introducción Capítulo 1: Introducción El presente trabajo se ubica en el área de administración de redes inalámbricas de computadoras y tiene como objetivo crear una propuesta de solución para permitir un manejo más

Más detalles

Oferta de Trabajos Fin de Grado Grado en Ingeniería de Telecomunicación. Curso Académico 2013-2014

Oferta de Trabajos Fin de Grado Grado en Ingeniería de Telecomunicación. Curso Académico 2013-2014 Oferta de Trabajos Fin de Grado Grado en Ingeniería de Telecomunicación Curso Académico 2013-2014 Febrero 2014 Contenido Bases de datos en sistemas de bajos recursos... 3 Red de sensores con comunicaciones

Más detalles

Implantación de las TIC en el sector sanitario

Implantación de las TIC en el sector sanitario Mesa Interregional: SALUD e I+D+i Mesa redonda: innovación asistencial, TIC, telemedicina Implantación de las TIC en el sector sanitario Javier Valero Criado Secretaría Plataforma evia 4 de diciembre de

Más detalles

Sesión 5: Wine. Proyecto de formación en centros CEIP Benimamet Valencia

Sesión 5: Wine. Proyecto de formación en centros CEIP Benimamet Valencia Proyecto de formación en centros CEIP Benimamet Valencia Sesión 5: Wine Ponente: Bartolomé Sintes Marco. IES Abastos (Valencia) Fecha: 25 de marzo de 2011 PFC CEIP Benimamet (Valencia). Bartolomé Sintes

Más detalles

Presentación de Servicios

Presentación de Servicios Presentación de Servicios La Empresa En moddogroup llevamos más de 15 años dedicándonos por completo a la ayuda en la gestión del comerciante minorista, planteando soluciones múltiples a los nuevos retos

Más detalles

HERRAMIENTAS TECNOLÓGICAS PARA EL APRENDIZAJE BASADO EN PROYECTOS

HERRAMIENTAS TECNOLÓGICAS PARA EL APRENDIZAJE BASADO EN PROYECTOS X CONGRESO INTERNACIONAL DE INGENIERIA DE PROYECTOS VALENCIA, 13-15 Septiembre, 2006 HERRAMIENTAS TECNOLÓGICAS PARA EL APRENDIZAJE BASADO EN PROYECTOS F.Buendía, E. De la Asunción Abstract The current

Más detalles

-----INFORME NACIONAL - ESPAÑA---

-----INFORME NACIONAL - ESPAÑA--- Informe europeo de evaluación sobre reconocimiento de aprendizaje a distancia -----INFORME NACIONAL - ESPAÑA--- Proyecto SMEs & e-learning (SMEELEARN) ERASMUS+ KA2 [2014-1-UK01-KA202-001610] http://www.sme-elearning.net

Más detalles

Historia de revisiones

Historia de revisiones Binary Rain Glosario Versión 1.1 Historia de revisiones Fecha Versión Descripción Autor 17/08/2012 1.0 Creación del documento Carolina Trias 18/08/2012 1.1 Revisado y corregido por SQA Mercedes Marzoa

Más detalles

AVAYA. Microsoft Business Solutions. Caso de estudio de solución para los socios de negocios

AVAYA. Microsoft Business Solutions. Caso de estudio de solución para los socios de negocios AVAYA Proveedor de telefonía agrega clientes nuevos con Comunicaciones y la solución CRM combinadas Microsoft Business Solutions Caso de estudio de solución para los socios de negocios PROVEEDOR DE TELEFONÍA

Más detalles

DOMÓTICA Y DISCAPACIDAD:

DOMÓTICA Y DISCAPACIDAD: uía DOMÓTICA Y DISCAPACIDAD: La vivienda inteligente GOBIERNO DE ESPAÑA MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES SECRETARÍA DE ESTADO DE SERVICIOS SOCIALES, FAMILIAS Y DISCAPACIDAD IMSERSO UNIÓN EUROPEA

Más detalles

PAUTA: un Sistema Integrado para el Apoyo y Asistencia de Pacientes Polimedicados

PAUTA: un Sistema Integrado para el Apoyo y Asistencia de Pacientes Polimedicados PAUTA: un Sistema Integrado para el Apoyo y Asistencia de Pacientes Polimedicados A. J. GARCÍA TEJEDOR, I. SERRANO BRONCANO CEIEC - Centro de Innovación Experimental del Conocimiento. Universidad Francisco

Más detalles

Bienvenidos a Therapy Autocuidados

Bienvenidos a Therapy Autocuidados Bienvenidos a Therapy Autocuidados Bienvenidos a una nueva era en el cuidado de la salud y la calidad de vida especialmente de nuestros mayores - Tensiómetro(con autochequeo de calibración) - Pulsioxímetro,

Más detalles

Recogida y análisis de datos de accidentes de tráfico urbanos en Europa: Estudio de encuesta

Recogida y análisis de datos de accidentes de tráfico urbanos en Europa: Estudio de encuesta Botanical Garden of the University of Valencia (Spain) 14-15/June/7 Recogida y análisis de datos de accidentes de tráfico urbanos en Europa: Estudio de encuesta Urban Accident Analysis Systems Project

Más detalles

EL CENTRO DE DATOS Y LA NEUTRALIDAD EN CONECTIVIDAD Y CLOUD

EL CENTRO DE DATOS Y LA NEUTRALIDAD EN CONECTIVIDAD Y CLOUD EL CENTRO DE DATOS Y LA NEUTRALIDAD EN CONECTIVIDAD Y CLOUD Significado, importancia actual e implicaciones futuras INTRODUCCIÓN El uso generalizado de las TI, la movilidad, las redes sociales, el big

Más detalles

Sistema Automatizado para la Firma y el Estampado Electrónico de Tiempo (Safet)

Sistema Automatizado para la Firma y el Estampado Electrónico de Tiempo (Safet) Sistema Automatizado para la Firma y el Estampado Electrónico de Tiempo (Safet) Antonio Araujo Brett 1 Víctor Bravo 1 1 Fundación Centro Nacional de Desarrollo e Investigación en Tecnologías Libres Nodo

Más detalles

KinBehR KINect for human BEHaviour Recognition

KinBehR KINect for human BEHaviour Recognition KinBehR KINect for human BEHaviour Recognition Tecnologías y Sistemas de la Información Alumno: Rubén Cantarero Navarro Directores: María José Santofimia Romero y Juan Carlos López López Contexto 2 KinBehR

Más detalles

En resumen, los estudios del título de grado de enfermería van encaminados a que los futuros titulados:

En resumen, los estudios del título de grado de enfermería van encaminados a que los futuros titulados: 3 OBJETIVOS 3.1 Competencias generales y específicas. Según el Libro Blanco para la Titulación de Grado en Enfermería de la ANECA, los OBJETIVOS GENERALES DE LA TITULACIÓN se establecen en los siguientes

Más detalles

UNIVERSIDAD DE OVIEDO

UNIVERSIDAD DE OVIEDO UNIVERSIDAD DE OVIEDO ESCUELA POLITÉCNICA DE INGENIERÍA DE GIJÓN MÁSTER EN INGENIERÍA INFORMÁTICA TRABAJO FIN DE MÁSTER SPRING ROO ADD-ONS PARA PROTOTIPADO RÁPIDO JAVIER MENÉNDEZ ÁLVAREZ JULIO 2014 UNIVERSIDAD

Más detalles

Introducción a Plone y Zope. Presentación introductoria sobre Plone y las tecnologías utilizadas, como Zope y Python.

Introducción a Plone y Zope. Presentación introductoria sobre Plone y las tecnologías utilizadas, como Zope y Python. Introducción a Plone y Zope Presentación introductoria sobre Plone y las tecnologías utilizadas, como Zope y Python. Licencia Copyright (c) 2008 Carlos de la Guardia. Copyright (c) 2008 Leonardo Caballero.

Más detalles

Plataforma para la creación de webs docentes como apoyo en la enseñanza de nivel superior

Plataforma para la creación de webs docentes como apoyo en la enseñanza de nivel superior Plataforma para la creación de webs docentes como apoyo en la enseñanza de nivel superior Platform for creating web teachers and teaching support in education Miriam Zulma Sánchez-Hernández, 1 * Kenia

Más detalles

25 años. Soluciones de Voz y Videoconferencia 2015-2016. de innovación

25 años. Soluciones de Voz y Videoconferencia 2015-2016. de innovación 25 años de innovación Soluciones de Voz y Videoconferencia 2015-2016 Soluciones de voz Audioconferencia IP Salas pequeñas (cobertura de 2,1 m) SoundStation IP 5000 Gama CX Optimizada para Conferencias

Más detalles

Capítulo 4: Diseño de la solución basada en software. 4.1 Diseño general del sistema y especificaciones de los componentes

Capítulo 4: Diseño de la solución basada en software. 4.1 Diseño general del sistema y especificaciones de los componentes Capítulo 4: Diseño de la solución basada en software 4.1 Diseño general del sistema y especificaciones de los componentes El sistema constará de tres elementos fundamentales: los clientes, el punto de

Más detalles

Premio de la Federación Internacional al Fomento del Servicio Voluntario

Premio de la Federación Internacional al Fomento del Servicio Voluntario Premio de la Federación Internacional al Fomento del Servicio Voluntario Nombre de la Sociedad Nacional Categoría a la que se presenta la convocatoria 1 Cuáles son las repercusiones de los servicios específicos

Más detalles

El Programa Erasmus + contribuirá a la consecución de los objetivos de la Estrategia Europa 2020:

El Programa Erasmus + contribuirá a la consecución de los objetivos de la Estrategia Europa 2020: 1- Qué es el programa ERASMUS +? ERASMUS + es el programa de la UE en los ámbitos de la educación, la formación, la juventud y el deporte para el período 2014-2020. Está diseñado para apoyar los esfuerzos

Más detalles

COMPETITIVIDAD Y DERECHOS DE PROPIEDAD INDUSTRIAL

COMPETITIVIDAD Y DERECHOS DE PROPIEDAD INDUSTRIAL COMPETITIVIDAD Y DERECHOS DE PROPIEDAD INDUSTRIAL AMPARO FERNÁNDEZ GONZÁLEZ Subsecretaria Ministerio de Industria, Turismo y Comercio Presidenta Oficina Española de Patentes y Marcas Cuando en el año 1986

Más detalles

PLATAFORMA TECNOLÓGICA ESPAÑOLA PARA LA ADOPCIÓN Y DIFUSIÓN DE LAS TECNOLOGÍAS ELECTRÓNICAS, DE LA INFORMACIÓN Y LA COMUNICACIÓN.

PLATAFORMA TECNOLÓGICA ESPAÑOLA PARA LA ADOPCIÓN Y DIFUSIÓN DE LAS TECNOLOGÍAS ELECTRÓNICAS, DE LA INFORMACIÓN Y LA COMUNICACIÓN. PLATAFORMA TECNOLÓGICA ESPAÑOLA PARA LA ADOPCIÓN Y DIFUSIÓN DE LAS TECNOLOGÍAS ELECTRÓNICAS, DE LA INFORMACIÓN Y LA COMUNICACIÓN. Mapa de tecnología para demanda temprana Foro Transfiere Málaga, 12 Febrero

Más detalles

Personalización de calzado en el punto de venta

Personalización de calzado en el punto de venta 29 El proyecto europeo Fit4U tiene como objetivo impulsar la personalización y la asistencia para la selección de calzado basado en las características y necesidades del usuario, mejorando así las prestaciones

Más detalles

Guía para la Autoevaluación de la Gestión de la Innovación Empresarial

Guía para la Autoevaluación de la Gestión de la Innovación Empresarial Guía para la Autoevaluación de la Gestión de la Innovación Empresarial MODELO, CUESTIONARIO Y BUENAS PRÁCTICAS DE GESTIÓN EN INNOVACIÓN EMPRESARIAL Octubre 2009 Guía para la autoevaluación de la Gestión

Más detalles

Cómo estar allí, cada vez que necesita estar OPTIPLEX 755. LA GUÍA DELL PARA OPTIPLEX 755 CON LA TECNOLOGÍA DEL PROCESADOR INTEL vpro

Cómo estar allí, cada vez que necesita estar OPTIPLEX 755. LA GUÍA DELL PARA OPTIPLEX 755 CON LA TECNOLOGÍA DEL PROCESADOR INTEL vpro Cómo estar allí, cada vez que necesita estar LA GUÍA DELL PARA OPTIPLEX CON LA TECNOLOGÍA DEL PROCESADOR INTEL vpro Cómo estar allí, cada vez que necesita estar Qué pasaría si pudiera simplificar las operaciones

Más detalles

Toda red debe ser administrada.

Toda red debe ser administrada. SYSTIMAX Solutions imvisiontm. Gestión de Infraestructura. Simplificada. 1 Toda red debe ser administrada. La cuestión es CÓMO? La visión: Lograr el éxito comercial a partir de una mejor administración

Más detalles

PARANINFO DIGITAL MONOGRÁFICOS DE INVESTIGACIÓN EN SALUD ISSN: 1988-3439 - AÑO IX N. 22 2015 Disponible en: http://www.index-f.com/para/n22/396.

PARANINFO DIGITAL MONOGRÁFICOS DE INVESTIGACIÓN EN SALUD ISSN: 1988-3439 - AÑO IX N. 22 2015 Disponible en: http://www.index-f.com/para/n22/396. PARANINFO DIGITAL MONOGRÁFICOS DE INVESTIGACIÓN EN SALUD ISSN: 1988-3439 - AÑO IX N. 22 2015 Disponible en: http://www.index-f.com/para/n22/396.php PARANINFO DIGITAL es una publicación periódica que difunde

Más detalles

no hay salud sin agentes sanitarios

no hay salud sin agentes sanitarios Resumen de orientación Una verdad universal: no hay salud sin agentes sanitarios + alianza mundial en pro del personal sanitario Resumen de orientación Objetivo El objetivo de este informe es establecer

Más detalles

SISTEMA DE RECONOCIMIENTO FACIAL Y REALIDAD AUMENTADA PARA DISPOSITIVOS MÓVILES

SISTEMA DE RECONOCIMIENTO FACIAL Y REALIDAD AUMENTADA PARA DISPOSITIVOS MÓVILES Revista de investigación Editada por Área de Innovación y Desarrollo, S.L. Envío: 16-06-2012 Aceptación: 18-06-2012 Publicación: 19-06-2012 SISTEMA DE RECONOCIMIENTO FACIAL Y REALIDAD AUMENTADA PARA DISPOSITIVOS

Más detalles

PORTAFOLIO PRODUCTOS Y SERVICIOS

PORTAFOLIO PRODUCTOS Y SERVICIOS PORTAFOLIO PRODUCTOS Y SERVICIOS 1. SOLUCIONES INTEGRALES EN TIC Compañía De Tecnologías De La Información Y La Comunicación S.A.S. COMTIC S.A.S., es una empresa colombiana dedicada al diseño e implementación

Más detalles

Decidir cuándo autenticar en dispositivos móviles a partir de modelos de machine learning 1

Decidir cuándo autenticar en dispositivos móviles a partir de modelos de machine learning 1 Decidir cuándo autenticar en dispositivos móviles a partir de modelos de machine learning 1 En los dispositivos móviles como tablets o teléfonos celulares se tiene la opción de implementar o no un sistemas

Más detalles

Aumente sus oportunidades con PowerMaster-33. www.visonic.com/spain/es/expand

Aumente sus oportunidades con PowerMaster-33. www.visonic.com/spain/es/expand Aumente sus oportunidades con PowerMaster-33 www.visonic.com/spain/es/expand Obtenga las ventajas de PowerMaster-33 Mejor para usted Solución fiable tanto para los mercados residenciales como de PYMES

Más detalles

Sistemas Philips de control y monitorización remotos

Sistemas Philips de control y monitorización remotos Sistemas Philips de control y monitorización remotos Gestión inteligente del alumbrado vial y urbano Reducción del gasto energético Mantenimiento más eficaz Menos emisiones de CO2 Mayor seguridad Minimización

Más detalles

TEMA 3: SISTEMAS OPERATIVOS.

TEMA 3: SISTEMAS OPERATIVOS. TEMA 3: SISTEMAS OPERATIVOS. 1. QUÉ ES UN SISTEMA OPERATIVO? 2. SISTEMAS OPERATIVOS GRÁFICOS. 3. SISTEMAS OPERATIVOS MÓVILES. 4. EL ENTORNO DE WINDOWS PARA PC. 5. LA APLICACIÓN DEL TEMA. 6. ACTIVIDADES.

Más detalles

GUIA DEL CURSO DESARROLLO DE APLICACIONES EN ANDROID

GUIA DEL CURSO DESARROLLO DE APLICACIONES EN ANDROID GUIA DEL CURSO DESARROLLO DE APLICACIONES EN ANDROID ÍNDICE 1. INTRODUCCIÓN...3 2. PROFESORES...4 3. RESUMEN DE CONTENIDOS POR UNIDAD FORMATIVA...5 4. OBJETIVOS POR UNIDAD FORMATIVA...6 5. DISTRIBUCIÓN

Más detalles

NOMBRE DEL EXPERIMENTO AUTOR CATEGORÍA PALABRAS CLAVE QUÉ SE PRETENDE MOSTRAR? DIRIGIDO A. Construye y Controla tu Robot en un día.

NOMBRE DEL EXPERIMENTO AUTOR CATEGORÍA PALABRAS CLAVE QUÉ SE PRETENDE MOSTRAR? DIRIGIDO A. Construye y Controla tu Robot en un día. NOMBRE DEL EXPERIMENTO Construye y Controla tu Robot en un día. AUTOR Juan Antonio Holgado Terriza Marcelino Cabrera Cuevas Jesús Luis Muros Cobos Sandra Rodríguez Valenzuela CATEGORÍA Tecnología PALABRAS

Más detalles

Una transición a Windows 7 sin problemas, automatizada y totalmente personalizada

Una transición a Windows 7 sin problemas, automatizada y totalmente personalizada Windows 7 Caso de Éxito Una transición a Windows 7 sin problemas, automatizada y totalmente personalizada Resumen País: España Industria: Administración Pública Perfil Castilla-La Mancha ocupa un territorio

Más detalles