LoCoMote: Localizing and Recognizing on-the-move Citizen

Transcripción

1 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, 2015

2

3 LOCOMOTE: LOCALIZING AND RECOGNIZING ON-THE-MOVE CITIZEN

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 LoCoMote: Localizing and Recognizing on-the-move Citizen Autor: Antonio Agudo Mansilla Director: Dr. Félix Jesús Villanueva Molina Director: Dra. María José Santofimia Romero Febrero, 2015

6

7 Antonio Agudo Mansilla Puertollano Spain c 2015 Antonio Agudo Mansilla 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 Las ciudades representan plataformas donde las personas viven y trabajan, donde las empresas llevan a cabo sus actividades y prestan numerosos servicios. Las ciudades inteligentes o Smart City ofrecen servicios públicos interactivos y eficientes que permiten simplificar y facilitar la vida del ciudadano en su relación con la ciudad. La Smart City permite maximizar la economía, la sociedad, el bienestar y el desarrollo sostenible. Es esta oferta de servicios públicos la que nos lleva a prestar un especial interés a los teléfonos inteligentes o Smartphones, los cuales son plataformas sensoras muy avanzadas que pueden ser utilizadas para obtener información muy valiosa sobre los usuarios de estos dispositivos y el entorno en el que estos se desenvuelven. Es precisamente esta captación de sensorización la que motiva este Trabajo Fin de Grado, pues la misma puede abrir la puerta a tareas mas elaboradas de adaptación del contexto a las necesidades de los usuarios. Este proyecto pretende determinar la acción que esta realizando el individuo en base a los valores recogidos a través de los sensores disponibles en el Smartphone. El desarrollo de este sistema se ha dividido en varias etapas: una de automatización de la recogida de valores de sensorización, otra etapa de envío de los datos al servidor, reducción del vector de características mediante medidas estadísticas, caracterización de la señal mediante Clustering con k-means y finalmente una etapa de aprendizaje automatizado y clasificación con SVM. Este desarrollo ha supuesto la implementación de varias aplicaciones para Android, un sistema cliente servidor y varias implementaciones en Python que como resultado nos proporcionan un sistema de reconocimiento de acciones en tiempo real. Este sistema implementado servirá a otras aplicaciones para dar servicios avanzados para la Smart City. Estos servicios pueden ir desde la gestión del tráfico de una ciudad, como servicios privados para alguna determinada empresa, hasta la utilización en servicios de seguridad al ciudadano. En cualquier caso, el resultado de la tarea de reconocimiento debe proporcionarse de una manera estandarizada al framework de gestión de la Smart City, para que estos puedan ser utilizados de manera automática por otros servicio más elaborados. V

12

13 Abstract Cities represent platforms where people live and work, where businesses take place undertaking their activities and provide their services. Smart City support the offer of interactive and efficient public services enhancing the citizen s quality of life. Smart Cities also maximize the economy, the society, the well-being and a sustainable development. In order to realize these goals, this project will make use of Smart-phones. These are advanced sensor platforms which can be used to obtain information about their users and the environment. Precisely, this data capture is the driver for this final degree project. The main objective of the Smart City is to develop new thorough applications with the aim of easing the needs of the users. This project is intended to determine the action performed by the Smartphone s user by means of the sensor information. The software development is made up of several stages: the automation of the collecting data process, the data transmission to the server, the reduction of the characteristics vector with statistical methods, the sign characterization by means of Clustering with k-means and finally, the automatic learning and classification with SVM. This development has led to different implementations such as various applications for Android, a client-server system and several Python applications. As a result, this project offers a real-time action recognition system. This implemented system will be used to provide advanced services for the Smart City. These services can undertake from the traffic management of a city, to the private services for an specific company, or to the security services targeted to the citizen. In any case, the result of the recognition task must be supplied in a standard way to management framework of the Smart City so that they could be used by other thorough-going services. VII

14

15 Agradecimientos Han pasado ya 6 años desde que empezara esta etapa de mi vida. Durante este tiempo he podido crecer tanto académicamente como personalmente, cambiando significativamente mi forma de pensar, siendo ahora otra persona distinta a la que era antes. El final de esta etapa supone nuevos retos para mí y el comienzo de una nueva etapa de mi vida en la cual ya no estarán muchas de estas personas que me han acompañado durante estos años. En primer lugar quiero agradecer a mi familia el apoyo mostrado y en especial a mis padres Antonio y Ana por inculcarme unos valores y su apoyo incondicional. Sin ellos no habría llegado hasta donde estoy hoy. A Raúl por ser una de las personas que me ha hecho creer en mi mismo y enseñarme que con trabajo y esfuerzo todo es posible, haciéndome crecer tanto deportivamente como personalmente. El mejor compañero que he tenido. A Alicia por ser mi apoyo en esta última etapa de mi vida universitaria, estando en los momentos buenos y malos conmigo, consiguiendo centrarme para poder completar con éxito este último tramo de carrera. También debo dedicarle especialmente a mis buenos amigos Rober, Alba, María, Puche, Delia, Carlos, José que han conseguido que el día a día sea más llevadero con nuestros momentos de kellys y maquetas. Y a mis compañeros Isaac, Nanu, Nando, Lucía, Tati no sería lo mismo sin vosotros. Finalmente quiero agradecer a María José el gran trabajo que ha realizado conmigo, aguantándome durante todo el desarrollo del proyecto y por su manejo con las tildes. Has conseguido que todo sea mas fácil estando siempre cunado lo necesitaba. Muchas gracias por todo. Antonio IX

16

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

18

19 Índice general Resumen Abstract Agradecimientos Índice general Índice de cuadros Índice de figuras Índice de listados Listado de acrónimos V VII IX XIII XVII XIX XXI XXIII 1. Introducción La Smart City Los sensores del Smartphone Sensor gestual Sensor de proximidad Giroscopio Acelerómetro Magnetómetro Sensor de temperatura y humedad Barómetro Sensor de luz RGB GPS y posicionamiento Aplicaciones Objetivos Objetivo general XIII

20 2.2. Objetivos específicos Recogida de la información de sensorización Grabación de los casos controlados Transmisión smartphone-servidor Caracterización de la señal Entrenamiento Pruebas de los modelos Aplicación en tiempo real Clasificación Antecedentes PerSe Reconocimiento de acciones humanas Trabajos anteriores Reconocimiento de acciones con sensores Clustering Clustering con k-means SVM Metodología y Fases de Trabajo Scrum El proceso Los roles en Scrum Roles de Scrum aplicados a este proyecto Fases de Scrum aplicados a este proyecto Herramientas Lenguajes Medios hardware Medios software Desarrollo del Proyecto Aplicación para la recogida de datos Implementación Recogida de datos «Dataset» Realización de una conexión Cliente-Servidor y envió de los datos Implementación xiv

21 5.4. Caracterización de la señal Implementación Entrenamiento y pruebas Implementación Aplicación y servidor final Implementación Resultados del Proyecto Resultados por sensores Acelerómetro Barómetro Giroscopio Humedad Magnético Temperatura Observación de los resultados Repositorio Publicación Conclusiones Conclusiones Recogida de la información de sensorización Grabación de los casos controlados Transmisión Smartphone-Servidor Caracterización y clasificación de la señal Entrenamiento Pruebas o evaluación de la fiabilidad de los modelos Aplicación en tiempo real para el reconocimiento de acciones Clasificación Propuestas de futuro A. Grabación de las pruebas 85 B. Formulario de Consentimiento 91 C. Formularios de Consentimiento Firmados 95 Referencias 107 xv

22

23 Índice de cuadros 4.1. Roles asignados a las personas de este proyecto XVII

24

25 Índice de figuras 1.1. Sensores Samsung Galaxy S Clustering con k-means: Paso Clustering con k-means: Paso Clustering con k-means: Paso Clustering con k-means: Paso Hiperplano Iteraciones en Scrum Samsung Galaxy S App: Recogida de datos App: Recogida de datos: Acciones App: Recogida de datos: Grabando App: LoCoMoteTCP App: LoCoMoteTCP: Clases App: LoCoMote App: LoCoMoteTCP: Grabando App: LoCoMote: Clases Tasa de acierto: Acelerómetro Matriz de confusión: Acelerómetro Tasa de acierto: Barómetro Matriz de confusión: Barómetro Tasa de acierto: Giroscopio Matriz de confusión: Giroscopio Tasa de acierto: Humedad Matriz de confusión: Humedad Tasa de acierto: Magnetómetro Matriz de confusión: Magnetómetro XIX

26 6.11. Tasa de acierto: Temperatura Matriz de confusión: Temperatura A.1. Grabación acciones: Esperar A.2. Grabación acciones: Andar A.3. Grabación acciones: Montar en bici A.4. Grabación acciones: Subir escaleras A.5. Grabación acciones: Puñetazo A.6. Grabación acciones: Patada xx

27 Índice de listados 5.1. «SensorActivity.java» «SensorActivity.java» «SensorActivity.java» «ProcesadorArchivos.java» «VentanaDeslizante.java» «VentanaDeslizante.java» «LoCoMoteActivity.java» «Servidor.py» «Servidor.py» «Servidor.py» «Servidor.py» «Servidor.py» «Servidor.py» «Clustering.py» «Clustering.py» «Clustering.py» «Entrenamiento.py» «Probar.py» «SensorActivity.java» «SensorActivity.java» «Servidor.py» XXI

28

29 Listado de acrónimos TFG SVM DWT HAR ARCO GPS GLONASS ITSI Trabajo Fin de Grado Support Vector Machine Discrete Wavelet Transform Human Action Recognition Computer Architecture and Networks Global Positioning System Global Navigation Satellite System Instituto de Tecnologías y Sistemas de Información XXIII

30

31 Capítulo 1 Introducción EN las ultimas décadas el desarrollo de la tecnología en las ciudades está permitiendo abordar nuevos paradigmas que hace años eran impensables. Según datos publicados [pen] en el año 2011 los Smartphone tenían una tasa de penetración entre la población española de un 41 %, tasa que en el 2013, transcurriendo solo dos años, se duplicó llegando a un 84 %, frente al 72 % global. Estamos frente a un gran incremento de este tipo de dispositivos entre la ciudadanía, lo que nos permite plantearnos nuevos retos utilizando este tipo de tecnología. Los teléfonos inteligentes o Smartphones actuales son plataformas sensoras muy avanzadas que pueden ser utilizadas para obtener información muy valiosa sobre los usuarios de estos dispositivos y el entorno en el que estos se desenvuelven. Es precisamente esta capacidad de sensorización la que motiva este proyecto o Trabajo Fin de Grado (TFG) pues la misma puede abrir la puerta a tareas más elaboradas de adaptación del contexto a las necesidades de los usuarios. Esta estrategia puede ser una opción mucho más viable que la de desplegar una serie de sensores a lo largo del cuerpo de la persona, pues el móvil es un elemento que va con nosotros a todas partes. Esta nueva gama de teléfonos inteligentes nos permiten, por lo tanto, no sólo estar conectados todo el tiempo, sino también monitorizados. La gestión que se haga de esos datos de monitorización podrá dar lugar a funcionalidades muy diversas y dispares, pero siempre tendentes a proporcionar nuevos servicios al usuario, adaptados al contexto. Este TFG pretende determinar la acción que esta realizando el individuo en base a los valores recogidos a través de los sensores disponibles en un Smartphone. Para ello, desarrollaremos una aplicación para un terminal Samsung Galaxy S4 en el que no sólo automatizaremos la recogida de valores de sensorización (sensor gestual, sensor de proximidad, giroscopio, acelerómetro, sensor geomagnético, sensor de temperatura y humedad, barómetro, sensor de luz RGB, GPS y posicionamiento) sino que también se encargará de la comunicación de dichos datos y resultados del proceso de reconocimiento de acciones a un middleware o framework de comunicación que gestionará los servicios que se ofrecen en la Smart City y que se nutrirá de la información de reconocimiento ofrecida por los terminales móviles. De manera más particular, de entre las diferentes conductas o acciones contempladas en 1

32 este trabajo, se ha puesto un especial énfasis en el la búsqueda de patrones de conductas violentas, determinadas por la presencia de acciones como dar patadas o puñetazos, lo cual, podría ser muy útil para prevenir acciones violentas y mejorar la vida en la Smart City. 1.1 La Smart City La población mundial se concentra en torno a las ciudades, lo que está provocando un incremento de la urbanización dentro de ella, a la vez que un incremento de la necesidad de motorización. Las ciudades representan plataformas donde las personas viven y trabajan, donde las empresas llevan a cabo sus actividades y prestan numerosos servicios. Son entornos urbanos con una demanda creciente de eficiencia, calidad de vida y desarrollo sostenible. Por todos estos motivos han de plantearse novedades en la gestión de las ciudades, utilizando las TIC, consiguiendo así una ciudad inteligente o Smart City. [Sma] Este concepto de ciudad inteligente permite ofrecer servicios públicos interactivos y eficientes que simplifiquen y faciliten la vida del ciudadano en su relación con la ciudad. La Smart City permite maximizar la economía, la sociedad, el bienestar y el desarrollo sostenible. Este proyecto se contextualiza en el marco de la Smart City, entendiéndola aquí como ese área urbana que consta de infraestructuras, plataformas inteligentes y redes, de forma que las personas estén cada vez más conectadas entre sí y también con sus propios dispositivos. Esto incluye dispositivos y objetos físicos que comúnmente no disponen de conectividad: coches, electrodomésticos, edificios, etc. En este tipo de contextos planteados por el paradigma de la Smart City, también las propias personas y sus teléfonos móviles pueden funcionar como un sensor dentro de la misma ciudad [tel]. Una vez integrado en la misma, el usuario del teléfono móvil podrá ser considerado un sensor más de los muchos que hay desplegados a lo largo de la ciudad. 1.2 Los sensores del Smartphone Los dispositivos móviles (en este caso los teléfonos inteligentes o Smartphones) pueden utilizarse para controlar parámetros de la calidad de vida. Los dispositivos móviles actuales utilizan sensores integrados tales como el acelerómetro, brújulas, GPS, micrófonos, camas, etc. Para la realización de este TFG se ha escogido la utilización de un Samsung Galaxy S4 1, Smartphone que se utilizará para la captación de los datos. Este tipo de Smartphone nos va a proporcionar una serie de sensores (ver Figura ) con los que vamos a poder realizar la captación de los datos de los usuarios. Y con ellos html

33 llevar a cabo la caracterización de las acciones que se quieren reconocer en este TFG. Figura 1.1: Sensores Samsung Galaxy S Sensor gestual El Samsung Galaxy S4, nos proporciona un sensor de infrarrojos que permite detectar movimientos que se producen por encima de la pantalla del Smartphone. [Senb] Sensor de proximidad El sensor de proximidad del Samsung Galaxy S4 es un transductor que detecta objetos o señales que se encuentran cerca del elemento sensor, utilizando para ello un sensor de infrarrojos. Este sensor produce un tipo de radiación electromagnética y térmica, de mayor longitud de onda que la luz visible, pero menor que la de las microondas. Este tipo de sensor está entre los denominados sensores fotoeléctricos, los cuales producen una respuesta a las variaciones de la intensidad de la luz. [Sene] Giroscopio El giróscopo o giroscopio es un dispositivo mecánico que sirve para medir, mantener o cambiar la orientación en el espacio de nuestro dispositivo. Está formado esencialmente por un cuerpo con simetría de rotación que gira alrededor del eje de dicha simetría. Cuando el giróscopo se somete a un momento de fuerza que tiende a 3

34 cambiar la orientación de su eje de rotación, tiene un comportamiento aparentemente paradójico, ya que cambia de orientación girando respecto de un tercer eje, perpendicular tanto a aquel respecto del cual se lo ha empujado a girar, como a su eje de rotación inicial. [Senc] Acelerómetro El acelerómetro está pensado para detectar y medir cualquier tipo de aceleración que sufra el Smartphone. La aceleración desde un contexto físico, es una medida vectorial que nos indica el cambio de velocidad por unidad de tiempo. Esta aceleración no es la misma que la aceleración en coordenadas necesariamente, es la asociada con el fenómeno de peso experimentado por una masa de prueba que se encuentra en el marco de referencia del dispositivo. [Sena] Magnetómetro Es un dispositivo que nos permite cuantificar la señal magnética que recibe nuestro dispositivo. Esta señal magnética o magnetismo varía en función del lugar de la tierra en que te encuentras, lo que se denomina campo magnético terrestre (la magnetósfera). [Send] Sensor de temperatura y humedad El sensor de temperatura y humedad, por un lado contiene un sensor de temperatura, destinado a la medición de la temperatura ambiente y por otro lado contiene en su interior también un sensor de humedad, que nos va a proporcionar las medidas del vapor de agua presente en el aire. [Senb] Barómetro El barómetro que contiene el Smartphone nos va a proporcionar los valores relacionados con la presión atmosférica. La presión atmosférica es el peso por unidad de superficie que ejerce la atmósfera. [Senb] Sensor de luz RGB Un sensor de luz es un dispositivo electrónico que responde al cambio en la intensidad de la luz. En concreto este dispositivo contiene un sensor de luz RGB que detecta varios espectros de colores, en concreto detecta el rojo, el azul, el verde y el blanco. [Senb] GPS y posicionamiento El Samsung Galaxy S4 nos proporciona servicios de GPS y GLONASS, los cuales nos proporcionan unos eficientes sistemas globales de navegación por satélite. El GPS es el sistema creado por medios estadounidenses mientras que los servicios de posicionamiento de GLONASS [GLO] son proporcionados por la Federación Rusa. Estos dos sistemas integrados en el dispositivo nos permite determinar por todo el mundo 4

35 la posición del dispositivo, con una precisión que en algunos casos llega a ser de tan solo unos metros de fallo. El sistema GPS [GPS] funciona mediante una red de 24 satélites en órbita, con trayectorias sincronizadas para cubrir toda la superficie de la tierra. Cuando un dispositivo quiere saber su localización GPS, en primer lugar debe detectar como mínimo 4 satélites de los que recibirá su identificación y la hora de reloj de cada uno de ellos.con base en estas señales, el aparato sincroniza el reloj del GPS y calcula el tiempo que tardan en llegar las señales al equipo y de tal modo mide la distancia al satélite mediante "triangulación"(método de trilateración inversa), la cual se basa en determinar la distancia de cada satélite respecto al punto de medición. Conocidas las distancias, se determina fácilmente la propia posición relativa respecto a los tres satélites. 1.3 Aplicaciones Este proyecto está pensado para que la aplicación resultante pueda correr en un nivel inferior y dar soporte a otras aplicaciones de más alto nivel, esto quiere decir que, el resultado de este trabajo servirá a otras aplicaciones para dar servicios avanzados para la Smart City. Estos servicios pueden ir desde la gestión del tráfico de una ciudad, como servicios privados para alguna determinada empresa, como para la utilización en servicios de seguridad al ciudadano. En cualquier caso, el resultado de la tarea de reconocimiento debe proporcionarse de una manera estandarizada al framework de gestión de la Smart City, para que estos puedan ser utilizados de manera automática por otros servicio más elaborados. Así, un ejemplo de esto sería una aplicación que podría ser utilizada por la policía para detectar posibles situaciones anómalas en el tráfico que pudieran deberse a un accidente o algún acontecimiento que necesite ser supervisado y gestionado por ellos. Se acelerarían así los procesos de atención a sucesos detectando, por ejemplo, que una masa de población se desplaza rápidamente desde el mismo punto y hacia la misma dirección cuando ese no es el patrón de comportamiento común en ese momento. Una vez detectadas estas situaciones se podrían enviar agentes más rápidamente al lugar por si se tratara de algún incidente grave. También se podría utilizar para dar al ciudadano una vista clara de las carreteras de la ciudad para poder calcular el camino mas rápido a un punto cualquiera, evitando atascos, carreteras cortadas, etc. Este proyecto ofrece un servicio del cual se podrán aprovechar una gran cantidad de posibles aplicaciones futuras que darán nuevos servicios más elaborados al ciudadano de la Smart City. 5

36

37 Capítulo 2 Objetivos EN este capítulo se describen, a partir de los objetivos propuestos en el Anteproyecto, los objetivos que se marcan para el desarrollo de este (TFG). También se va a mostrar el ámbito y alcance que se espera conseguir tras la realización del mismo. 2.1 Objetivo general El objetivo general de este trabajo, como indica su título TFG «Localizing and Recognizing on-the-move Citizen», es la localización y el reconocimiento de ciudadanos en movimiento en la ciudad y más concretamente, el reconocimiento de las acciones que estos ciudadanos están realizando. Para ello se va a crear un sistema compuesto por una aplicación Android y un servidor, que a través de la recogida de la información de sensorización proporcionada por el dispositivo móvil (los datos recogidos por los sensores y el GPS del teléfono) reconocerá las acciones que el ciudadano está realizando en cada momento. Para ello, ha sido necesario obtener un patrón en base a los valores medidos y el conocimiento previo de las distintas acciones a considerar. Dicha información previa se habría obtenido de un entrenamiento para el reconocimiento de las acciones previamente definidas. Como consecuencia de esto el resultado final de este TFG será una aplicación que en tiempo real pueda realizar un reconocimiento de acciones del usuario del dispositivo móvil. 2.2 Objetivos específicos El desarrollo de este sistema conlleva la creación de una serie de elementos software, así como una serie de mecanismos que den soporte a su interoperabilidad. Esto va a crear un flujo de datos que se va a desplazar desde la captura de la información sensoras hasta el servidor que acabará proporcionando un resultado conforme a la actividad reconocida en base a los patrones o modelos de que el sistema dispone. Para poder conseguir este objetivo de una forma exitosa, debemos plantearnos una serie de objetivos específicos con los cuales poder llevar a cavo el objetivo principal. Estos objetivos específicos son: Recogida de la información de sensorización. Grabación de los casos controlados. Transmisión Smartphone-servidor. 7

38 Caracterización y clasificación de la señal. Entrenamiento. Pruebas o evaluación de la fiabilidad de los modelos obtenidos. Aplicación en tiempo real para el reconocimiento de acciones. Clasificación. A continuación se va a presentar el alcance de cada uno de estos objetivos específicos Recogida de la información de sensorización En esta parte del proyecto se persigue la creación de una aplicación que dé respuesta a las necesidades de una recogida controlada de la información de sensorización proporcionada por el dispositivo móvil. Además de esto, esta información de sensorización recogida va a ser almacenada de forma ordenada en la memoria interna del dispositivo móvil para su posterior tratamiento. Esto se hará a través de un sistema de ficheros y archivos donde se guardará, en un directorio, con el nombre del voluntario, los diversos archivos correspondientes a cada una de las acciones grabadas, como se explicará en el Capítulo Grabación de los casos controlados Una vez tenemos completado el objetivo anterior, se va a proceder a realizar la grabación de un conjunto de casos controlados «dataset». Para ello se recogerán los datos para los casos de estudio planteados, para cada sensor y para cada una de las acciones consideradas. Para ello, en primer lugar se va a buscar a un conjunto de 15 voluntarios que van a ser los encargados de realizar las pruebas. Estos 15 voluntarios bajo supervisión y con la aplicación realizada en el objetivo anterior, serán los encargados de realizar una grabación controlada de cada una de las acciones. Para la grabación de las mismas se les otorgará a cada uno de los voluntarios la información (ver Anexo A) necesaria para que puedan realizar cada una de las acciones con éxito. Con esta grabaciones conseguiremos obtener un conjunto de datos buenos que nos servirán para la posterior generación de los modelos de comportamiento Transmisión smartphone-servidor En esta sección se va a llevar a cabo el objetivo de realizar una conexión Cliente-servidor entre la aplicación en Android y un servidor alojado en un portátil, determinado además el formato que deberán llevar los datos enviados. Para ello en primer lugar, se van a preprocesar lo datos recogidos creando una ventana deslizante que recorrerá los datos obtenidos, proporcionando una serie espacios temporales que contendrá la información de sensorización contenida en un tramo de tiempo específico. Estas ventanas temporales van a ser posteriormente enviadas, una a una, a un servidor alojado 8

39 en un ordenador. Esto se hará creando una conexión Cliente-Servidor entre el dispositivo móvil y el ordenador que contendrá el servidor. Con ello podremos establecer una conexión a través de la que se enviarán todas las ventanas temporales de los datos de sensorización recogidos. El resultado de este objetivo sera una aplicación para el dispositivo móvil que pueda realizar el preprocesamiento y el envío de datos. Y por otro lado, el receptor del envío de estos datos que será el servidor Caracterización de la señal Completado el objetivo anterior, llegamos a la fase de caracterización donde se va a buscar reducir el vector de características de la señal recibida en el servidor, aplicando sobre el vector de características una serie de medidas estadísticas y un Clustering. Esto se hará realizando a cada ventana deslizante 5 medidas estadísticas (media, máximo, mínimo, desviación típica y varianza). Con esto tendremos cada ventana deslizante descrita con un conjunto de medidas estadísticas. Y posteriormente se procederá a una caracterización de la señal mediante la utilización del Clustering sobre el conjunto de medidas estadísticas. Se va a utilizar para ello un método de agrupamiento no jerárquico, como es el Clustering con K-means. Una vez caracterizada la señal se debe hacer un molde para que la salida del Clustering tenga el mismo formato que se va a utilizar en el proceso de entrenamiento. Una vez realizados estos dos pasos se obtendrá como resultado un conjunto de datos caracterizados, que podrán ser entregados al entrenador para la generación de los modelos Entrenamiento Ahora es el turno de realizar el último paso de la fase de entrenamiento. Con los datos de sensorización ya caracterizados y moldeados de forma que puedan ser leídos por el sistema de entrenamiento, se va a proceder a crear los modelos que van a caracterizar las acciones. Esto se hará a través de una maquina de entrenamiento «support vector machine» o un entrenamiento supervisado Pruebas de los modelos Una vez creados los modelos se debe probar que estos son correctos. Para ello se plantea el objetivo de obtener una serie de medidas sobre la validez de los modelos obtenidos en la etapa anterior. Estas mediciones nos deben dar como resultado la tasa de acierto que tiene cada modelo y el número de veces que se equivoca y en qué acciones se producen esos errores, utilizando para ello una matriz de confusión. Para ello se utilizarán los modelos que se crearon con anterioridad en la fase de entrenamiento y se le pasarán los datos recogidos en la fase de grabación. Con la utilización de herramientas de clasificación de SVM se va a conseguir como resultado las diferentes tasas 9

40 de acierto que tienen los modelos sobre unos casos de estudio, sabiendo que estos casos de estudio son las grabaciones de sensorización que se captaron de forma controlada para crear los mismos modelos que ahora se prueban Aplicación en tiempo real Una vez comprobado que los modelos son válidos, es decir, nos aportan una fiabilidad al sistema se va a proceder a crear una aplicación para Android que reconozca las acciones que realiza el usuario del dispositivo móvil en tiempo real. Esta nueva aplicación que se va a implementar tendrá como funcionalidad, por un lado, la captura de los datos de sensorización del dispositivo móvil y por otro lado la creación de una conexión Cliente-Servidor para poder comunicar los datos al servidor externo Clasificación En última instancia y como cierre del proyecto se creará el servidor que recibirá los datos de sensorización capturados por la aplicación en Android desarrollada en el objetivo anterior, teniendo que realizar la caracterización y clasificación de estos datos. El resultado será la predicción de la acción que está realizando el usuario del dispositivo móvil. 10

41 Capítulo 3 Antecedentes EN este capítulo se van a revisar los trabajos antecedentes al desarrollado en este TFG, enmarcados en el contexto del reconocimiento de acciones, tanto a través del uso de sensores como a través de otras técnicas. También se revisarán las técnicas de aprendizaje máquina o machine learning empleadas por este TFG para el desarrollo del sistema de reconocimiento de acciones. 3.1 PerSe En primer lugar se revisará el proyecto PerSe [Bar14], presentado como TFG por la alumna Alba Barón Rubio y cuyo inicio fue coetáneo al de este proyecto. El proyecto PerSe busca dar una mayor independencia a las personas de la tercera edad, proporcionando una mejora en su calidad de vida y una mayor participación en la sociedad. Para ello, este proyecto propone el uso de un Smartphone para dar soporte al reconocimiento de acciones. El usuario de esta aplicación podrá desarrollar una vida normal, a la vez que la aplicación nos proporcionaría información detallada acerca de su actividad, a modo de registros o logs de actividad. Si bien este propyecto planteó las bases de un reconocimiento de acciones humanas utilizando los sensores de un Smartphone, por diferentes cuestiones no fue posible el desarrollo de un reconocimiento en tiempo real, siendo necesario el almacenamiento de los registros en el móvil y un posterior tratamiento de los mismos para reconocer las actividades realizadas. Además, las tasas de acierto obtenidas por el sistema, descrito a continuación, hacía necesario plantearse la posibilidad de implementar otra metodología que mejorara las mismas. La fase de entrenamiento en PerSe consta de varias etapas: En primer lugar realiza una recogida de datos. Esto se consigue capturando los valores de los sensores para cada una de las acciones. Esta recogida se realiza con un Samsung Galaxy s4. En segundo lugar, se procede a un preprocesamiento de la señal recogida en el paso anterior, este preprocesamiento se realiza por medio de una ventana deslizante, que 11

42 será posteriormente enviada a un servidor, que corre sobre una plataforma PC donde se realizará el procesamiento necesario para la caracterización y clasificación de la señal. Una vez el servidor recoge los datos enviados por la ventana deslizante se procede a realizar la caracterización de la señal. Para ello el método propuesto es el de la Transformada Discreta Wavelet DWT. Una vez realizada esta caracterización se procede a realizar una reducción del vector de características proporcionado por DWT, aplicando un conjunto de medidas estadísticas a los coeficiente proporcionados por la DWT. Una vez se tiene la reducción del vector de características, como paso final, se realiza en primer lugar el entrenamiento del sistema con el que se obtendrá un modelo de las acciones consideradas, para cada sensor. Para ello se utilizará un clasificador SVM. El resultado final obtenido en PerSe es un sistema capaz de realizar un modelo de comportamiento con los datos capturados. Además, se proporciona diversas herramientas para poder comprobar el porcentaje de acierto de estos modelos. Con el proyecto LoCoMote, se pretende, por un lado, intentar mejorar los resultados obtenidos en la fase de entrenamiento en el proyecto PerSe, utilizando técnicas diferentes para la categorización de la señal, así como desarrollar un sistema que pueda reconocer en tiempo real las acciones que están realizando por los usuarios del Smartphone. 3.2 Reconocimiento de acciones humanas El reconocimiento de las acciones humanas recibe cada vez mas atención por parte de los investigadores del campo de la visión por ordenador. Este interés está motivado por el gran rango de aplicaciones a las que podría aplicarse. La capacidad de monitorizar automáticamente las actividades humanas puede ser muy práctico para su uso en zonas vulnerables como son aeropuertos, fronteras, lobbies de edificios, es decir, zonas de gran interés para la policía, ejércitos, etc. También puede ser útil para proporcionar servicios a la población civil en el día a día en una Smart city. El reconocimiento de acciones humanas o Human Action Recognition[Edw14] (HAR) nos plantea un complejo problema debido al gran numero de factores, que directa o indirectamente afectan a la recogida. Puesto que no existen dos personas iguales vamos a tener diversas diferencias tanto físicas (constitución física, ropa, etc.) como en la forma en que cada persona realiza diversas acciones, las cuales vamos a intentar identificar en este TFG. Las acciones humanas llevan consigo asociadas un componente tanto espacial como temporal, los cuales son características aleatorias. Esto nos lleva a que la realización de una misma acción nunca transcurra de la misma forma. 12

43 En la actualidad, el área del HAR es un campo de investigación que esta en constante expansión debido al gran numero de aplicaciones potenciales. Los métodos para el reconocimiento son diversos pero podrían agruparse en grupos: Existe una corriente más tradicional en la que se soluciona este problema mediante el emparejamiento de patrones, en la que se extrae un patrón de una secuencia de datos dada y se compone un modelo de conducta. Por otro lado tenemos otra forma de resolver este problema a través de los modelos de espacios de estados, que definen un espacio de estados en el que cada punto de este espacio representa un evento de la acción, esto proporciona un modo compacto de describir la acción. En este TFG se pretende realizar una serie de modelos a través del emparejamiento de patrones. Esta rama se caracteriza por el bajo coste computacional durante la clasificación pero puede tener una extracción de características muy compleja Trabajos anteriores Como dijimos con anterioridad, el área del reconocimiento de acciones humanas es un campo muy activo y en constante expansión, por lo que anterior a este TFG se pueden encontrar diferentes antecedentes de trabajos que persiguen el reconocimiento de acciones humanas, de los cuales vamos a resaltar algunos de ellos: Human motion analysis: A review [AC99]:, motivados por el gran número de potenciales aplicaciones que plantea el ámbito del análisis del movimiento humano, tales como el análisis de rendimiento deportivo, la vigilancia, las interfaces hombre-maquina, almacenamiento y recuperación de imágenes basadas en contenido y la vídeo-conferencia. Este documento ofrece una visión general de las diversas tareas relacionadas con el análisis del movimiento del cuerpo humano. Centrándose en tres áreas: El análisis del movimiento con partes del cuerpo humano. El seguimiento del movimiento del cuerpo humano con cámaras simples o múltiples Y el reconocimiento de las actividades humanas desde secuencias de imágenes El análisis del movimiento de partes del cuerpo humano implica la segmentación de bajo nivel del cuerpo en segmentos conectados por articulaciones, recuperando la estructura 3D del cuerpo humano utilizando proyecciones 2D en una secuencia de imágenes. The visual analysis of human movement: A survey [Gav99]: debido a que la capacidad de reconocer a los humanos y las actividades que realizan es la clave para que 13

44 una máquina pueda interactuar de forma inteligente y sin esfuerzo en un ambiente humano. Esta publicación identifica una serie de aplicaciones prometedoras además de proporcionar una visión general de la evolución este ámbito. El alcance de esta publicación se limita a trabajar con el movimiento de todo el cuerpo humano o solo con el movimiento de las manos. 3.3 Reconocimiento de acciones con sensores Como se puede comprbar en la sección anterior, el campo del reconocimiento de acciones humanas consta de muchos avances en el campo del análisis por visión, pero nosotros en este TFG vamos a plantear el reto del reconocimiento de acciones a través de sensores. Los sensores permiten a las computadoras percibir el mundo que les rodea. Mediante el uso de sensores, como pueden ser el termostato o fotocélulas, un ordenador podría tener conciencia de las condiciones de temperatura en la que se encuentra o la iluminación del espacio. En los últimos años, el despliegue de redes multisensores se ha vuelto muy popular. Estas redes pueden incluir diferentes tipos de sensores, como son cámaras, sistemas de localización, micrófonos, etc. Mediante el uso de las redes de sensores los sistemas informáticos pueden tener una mejor información sobre el espacio que les rodea. Dado la gran utilidad y gran crecimiento que esta teniendo en la actualidad el reconocimiento de acciones en humanos con sensores, en este TFG pretende la caracterización de una serie de acciones a través de los datos recibidos por medio de sensores. Una tarea común en el procesamiento es el reconocimiento de la situación o entorno percibido, a priori existe un conjunto de etiquetas que describen cada situación, por lo que el problema puede abordarse como un problema de clasificación donde cada tarea debe ser clasificada añadiéndole así una etiqueta. Dado que esta clasificación va a tener que realizarse, ahora el problema es encontrar un modelo o patrón que relacione los datos de cada lectura o situación con las etiquetas de la misma. Para ello tenemos que determinar qué sensores nos proporciona información útil para determinar la acción, ya que algunos sensores nos proporcionan datos con demasiado ruido, los cuales no son útiles para la identificación y pueden llevar a confusión. La aplicación de las redes de sensores para el reconocimiento de la actividad humana está recibiendo una especial atención en los últimos años por su potencial aplicación en vigilancia, interacción persona-ordenador o inteligencia ambiental. Los sistemas de reconocimiento de la actividad humana puede integrarse perfectamente con los sistemas existentes como se muestra a continuación: Intelligent environment for monitoring Alzheimer patients [CJM08]: en esta pu- 14

45 blicación se propone un sistema que puede monitorizar a pacientes de Alzheimer. Si un paciente cae al suelo, el sistema puede alertar a una enfermera para asistirlo lo mas rápido posible. Development of intelligent multisensor surveillance systems with agents [PJ07]: en esta otra publicación se propone la integración de estas redes de sensores para la detección de actividades prohibidas o ilegales, avisando en caso de suceder a las autoridades pertinentes. Accelerometer-Based Transportation Mode Detection on Smartphones [SH]: en este estudio se analizan los datos obtenidos a través del acelerómetro para determinar cuál es el medio de transporte en el que el usuario se desplaza. En su estudio se buscan patrones en los valores extraídos del acelerómetro para saber si el usuario del Smartphone está andando, en tren, bus, etc. Preprocessing Techniques for Context Recognition from Accelerometre Data [DF10]: en este otro trabajo podemos encontrar un grupo de diferentes técnicas con las que se puede tratar la señal del acelerómetro. Esto es empleado para la realización del tratamiento de los datos. También muestra la arquitectura usada para llevar a cabo el proceso de reconocimiento. How Anyone Could Secretly Track Your Smartphone [Dai13]: en este trabajo se pone en evidencia no solo la importancia que los Smartphone tienen en cuanto al número de sensores que ponen a nuestra disposición, sino que además, algunos de estos sensores son tan característicos que dichas peculiaridades podrían ser utilizados para algo más que para lo que fueron pensados inicialmente. Así, el estudio realizado por el Dr. Hristo Bojinov de la universidad de Stanford, estudia la verificación de la hipótesis de que no existen dos Smartphones con un acelerómetro totalmente idéntico, lo que se cree que se podría controlar nuestra navegación al identificar nuestro Smartphone a través del acelerómetro. Mobile sensor data collector using Android smartphone [WJY12]: en este trabajo se nos presenta un sistema que utiliza como base un Smartphone que recoge muestras de los sensores y los envía a un servidor central. La finalidad de este sistema es utilizar las redes de sensores corporales para aplicaciones sanitarias. Para ello se ha construido un mecanismo más eficiente para lograr una buena conexión bluetooth y una ejecución automática de la aplicación a través de la tecnología NFC. Opportunistic radio SLAM for indoor navigation using smartphone sensors [FR12]: en este trabajo se presentan los resultados experimentales de un sistema que utilizando solamente los sensores disponibles en un Smartphone proporciona un sistema de posicionamiento en interiores, sin conocimiento previo de planos. Este proyecto fue desarrollado para equipos que operan un periodo prolongado sin señal del GPS. Este 15

46 sistema se centra en la técnica de posicionamiento DPSLAM adecuada para su uso por una persona sin conocimiento previo de la zona de operaciones donde se encuentra. 3.4 Clustering El clustering o algoritmo de agrupamiento [clu], es un método por el cual se procede a el agrupamiento de una serie de posiciones vectoriales de acuerdo a un criterio. Estos criterios pueden ser por distancia o similitud de estas posiciones vectoriales o vectores. Distancia: se debe determinar cómo medir la cercanía. Esto se hace en función de la distancia entre los puntos, generalmente utilizando la distancia euclídea, pero también existen otro tipos de de distancias mas robustas o que permiten extenderla a variables discretas. Similitud: para poder medir la similitud entre dos puntos tenemos varios métodos, el más utilizado es la matriz de correlación entre los NxN casos. Sin embargo, existen otras formas diferentes de medir la similitud como los algoritmos basados en la maximización de una propiedad estadística llamada verosimilitud. Por norma general, los vectores del mismo grupo (llamados clústers) suelen tener en común algunas de sus propiedades. Una vez se tiene el conocimiento de los clústers se puede tener una descripción sintética de un conjunto de datos multidimensionales complejos. Por ello esto es muy útil en la minería de datos. Esta descripción sintética es posible gracias a que se va a crear un representante característico del grupo que va a sustituir a todos los elementos de este grupo. Se puede decir que, en algunos contextos, el clustering podría ser una técnica de aprendizaje no supervisado, ya que encuentra para un determinado conjunto de puntos o vectores una relación o característica común. El clustering nos va a ser muy útil ya que nos va a realizar una reducción de los puntos de nuestra muestra, creando puntos representativos los cuales contendrán las características comunes respecto al conjunto de puntos pertenecientes a cada clúster. Esto nos permitirá pasar de un conjunto de puntos desordenado a otro ya bien caracterizados y preparados para el entrenamiento o clasificación. Existen dos grandes técnicas para el agrupamiento de casos: Agrupamiento jerárquico [Agr]: en términos de minería de datos, el agrupamiento jerárquico es un método de análisis que pretende construir una jerarquía de grupos, generalmente dividido en dos grupos: aglomerativas y divisivas. Los resultados de estas mezclas aglomerativas y divisiones son representados en forma de dendrograma [den]. Un dendrograma es una representación gráfica, en forma de árbol, que va organizando los datos de forma que se van formando subcategorias 16

47 según se van dividiendo hasta que llegan al nivel de detalle deseado. Este tipo de representaciones permiten apreciar perfectamente las relaciones de agrupación entre los datos o grupos. En general estos dos tipos de agrupamiento jerárquico son demasiado lentos para los grandes grupos de conjuntos, la complejidad de un agrupamiento aglomerativo es de O(n 3 ), y la de un agrupamiento divisivo con búsqueda exhaustiva es de O(2 n ) lo que es aún peor. Agrupamiento no jerárquico: en este tipo de agrupamiento también denominado de las k-medidas, los grupos vienen determinados de antemano y las observaciones se van asignando a los grupos en función de su cercanía. Ejemplos de agrupamiento no jerárquico son los métodos de k-mean y k-medioid. Este tipo de agrupamiento es muy útil para grandes bases de datos, en las que el clustering jerárquico no es posible. Una desventaja del agrupamiento no jerárquico es que no tiene en cuenta la naturaleza de la información que va a clasificar o agrupar, este tipo de clustering realiza las agrupaciones independientemente de su relevancia interpretativa Clustering con k-means Debido a la gran cantidad de datos con los que vamos a tratar hemos decidido realizar un agrupamiento no utilizando el método de k-mean. El método de clustering con K-means [Kme] es un método de vector de cuantificación, utilizado para el procesamiento de señales. Es uno de los métodos más utilizados para el análisis de conglomerados en la minería de datos. El clustering con k-means pretende proporcionar n observaciones en k clusters en los que cada observación pertenece a la agrupación más cercana. Este proceso da como resultado el particionado del espacio en celdas de Voronoi. Dado un conjunto de observaciones (x1, x2,..., xn), donde cada observación tiene d dimensiones vectoriales, el clustering con k-means apunta a una partición de las n observaciones en k(<= n) y establece S = S1, S2,..., Sk a fin de minimizar la suma de cuadrados dentro de la agrupación. Expresado de una forma matemática: arg mín k i=1 x j S i X j µ i 2 Generalmente y, dado su utilización, el clustering con k-means utiliza el algoritmo k- means, aunque también es conocido como algoritmo de Lloyd, una técnica de refinamiento iterativo. Dado un conjunto inicial de K centroides (m1, m2,..., mk). El algoritmo se va alternando entre los dos pasos que se muestran a continuación. Paso de asignación: asigna cada observación al grupo con la media más cercana, de acuerdo con el diagrama de Voronoi generado por los centroides. 17

48 S (t) i = X p : { X p m (t) i X p m (t) j 1 j k} Paso de actualización: calcula los nuevos centroides como el centroide de las observaciones en el grupo. m (t+1) i = 1 S (t) i x j x S (t) j i Las iteraciones paran, es decir, se considera que el algoritmo ha convergido cuando las asignaciones a los grupos ya no cambian. A continuación, vamos a ver un ejemplo gráfico del funcionamiento de el clustering con k-means. En primer lugar se crean los k centroide iniciales (en el caso del ejemplo k = 3). estos son generados aleatoriamente dentro de un conjunto de datos, en el ejemplo los podemos diferenciar al mostrarlos en colores (ver Figura ). Figura 3.1: Clustering con k-means: Paso 1 Posteriormente, se procede a generar k grupos que son asociados a los k centroides creados inicialmente, tal que cada punto estará contenido en el grupo del centroide más cercano a su posición (ver Figura ). Cada centroide de lo k grupos deben ser recalculados en función a los puntos que contiene cada centroide (ver Figura ). Los pasos dos y tres deben ser repetidos hasta que se logre una convergencia (ver Figura )

49 Figura 3.2: Clustering con k-means: Paso 2 Figura 3.3: Clustering con k-means: Paso 3 Figura 3.4: Clustering con k-means: Paso SVM La máquina de soporte vectorial o máquina de vector de soporte (Support Vector Machines 5, SVM) consiste en un conjunto de algoritmos que proporcionan los medios para un aprendizaje supervisado. Esta serie de algoritmos han sido desarrollados por Vladimir Vapnik y su equipo en los laboratorios AT&T. [SVM] La idea de SVM es que teniendo un conjunto de puntos dados, donde cada uno de los puntos va a pertenecer a una categoría especifica SVM va a generar un modelo, con el cual se va a poder predecir en el momento a qué categoría corresponderá a este nuevo punto, desconocida en principio. SVM busca encontrar un hiperplano con el que se van a separar de una forma óptima el conjunto de puntos de una clase con respecto a los pertenecientes a otra

50 Entendemos como hiperplano [hip] a una extensión del concepto de plano, es decir, dependiendo del espacio en el que nos situemos, un hiperplano se puede corresponder con diferentes formas geometricas, por ejemplo en un espacio unidimensional (una recta), un hiperplano sería el punto que dividiría la recta en dos mitades. En un espacio bidimensional (como seria un plano xy), el hiperplano se correspondería con una recta que dividiría el plano en dos mitades. Si nos posicionamos en un espacio tridimensional, éste sería un plano que dividiría el espacio en dos mitades. Este concepto puede ser también explicado para espacios de más dimensiones donde los objetos divisores se llaman hiperplanos. Como podemos observar (ver Figura ) vemos como el hiperplano situado en un espacio tridimensional separa dos grupos de puntos que tienen características idénticas con los demás miembros del grupo y diferentes con los miembros de los otros grupos. Figura 3.5: Hiperplano El concepto de separación óptima, es donde reside la característica fundamental de las SVM. SVM busca siempre el hiperplano que proporcione esta separación óptima, buscando la máxima separación entre el hiperplano y los puntos

51 Capítulo 4 Metodología y Fases de Trabajo EN esta sección se va a describir tanto la metodología seguida para la realización de este TFG, como las fases del trabajo en las que éste se ha dividido. También se se van a nombrar y definir las herramientas que se han necesitado. La metodología utilizada para el desarrollo de este TFG es una metodología de desarrollo ágil[met], basada en el desarrollo iterativo e incremental, donde los requisitos y soluciones van a ir evolucionando mediante la colaboración de grupos auto-organizados y multidisciplinares. Existen muchos tipos de metodologías de desarrollo ágil, las cuales minimizan los riesgos del desarrollo del software realizando entregas en lapsos cortos. Para este TFG se ha utilizado Scrum. 4.1 Scrum La metodología de desarrollo Scrum [Scr] 1 es un tipo de metodología de desarrollo ágil en la que se recogen un conjunto de buenas practicas (conjunto de acciones que conducen a buenos resultados) para trabajar de manera colaborativa, es decir, en equipo y obtener unos buenos resultados en el producto final. Scrum se basa en una serie de fundamentos[fun]: Iterativo e incremental: un desarrollo incremental de los requisitos del proyecto. Estos se producen en bloques temporales de corta duración y fijos (estos incrementos o iteraciones suelen ser de un mes como máximo y de hasta dos semanas como mínimo), lo que provoca entregas parciales del producto final en cortos periodos de tiempo. Esta es una de las principales características por la que hemos decidido utilizar esta metodología frente a otras posibles, ya que a través de las entregas parciales conseguimos ver en tiempo real prototipos del avance del proyecto, evitando así, de una manera rápida, posibles desviaciones en la línea base. Periodización de requisitos por valor y coste: Scrum da prioridad a los requisitos en función del valor para el cliente y del coste para el desarrollo en cada una de las iteraciones, con esto se consigue que para un proyecto dado se le proporcione el mejor

52 resultado posible. Además es necesario calcular periódicamente, para cada iteración, la prioridad de los requisitos, según el valor que le da el cliente en ese nuevo instante de tiempo y su coste para el desarrollo. Control empírico del proyecto: al realizar un incremento iterativo e incremental del proyecto, el cliente puede observar cada cierto periodo de tiempo el avance del proyecto con lo que puede tomar decisiones sobre el avance de éste. Por otro lado esto también nos permite tener al equipo sincronizado diariamente y realizando las adaptaciones necesarias al proyecto. Potenciación del equipo: la realización de las entregas en pequeños periodos de tiempo compromete al equipo a realizar la entrega de unos determinados requisitos y para ello se debe otorgar a los mismos la autoridad pertinente para la organización del trabajo. Comunicación y colaboración entre equipo y cliente: el equipo debe colaborar conjuntamente con el cliente para la creación de listas de requisitos, replanificaciones del producto, proporcionar estimaciones, aportar de mejoras, planificación de cada iteración, etc. Además, al finalizar cada iteración el equipo debe demostrar al cliente los requisitos completados. Timebox: es la técnica por la cual se fija un tiempo máximo para conseguir unos objetivos o la realización de una determinada tarea. Con esto se acuerda previamente la realización de un requisito en el tiempo limitado que se le va a otorgar, favoreciendo así la periodización de requisitos y forzando la toma de decisiones. Todo esto lleva a que Scrum nos aporte soluciones a problemas como costes disparatados, mala calidad del producto, entregas que se alargan demasiado, entregas que no se adaptan a lo que el cliente necesita, etc El proceso En Scrum cada iteración tiene que proporcionar un resultado completo, es decir, un incremento del producto final a entregar y que pueda ser entregado con el mínimo esfuerzo al cliente cuando lo necesite. En un principio el cliente debe priorizar los objetivos según el valor que éstos le aportan, en términos de coste. De esta manera se crea una lista de requisitos del producto y estos quedan repartidos en iteraciones y entregas. Esta lista se puede replanificar por el cliente con vistas a la siguiente iteración. A partir de aquí las actividades que se suceden serían las siguientes: Planificación de la iteración «Pre-game phase»: el primer día de la iteración se debe realizar una reunión de planificación, la cual, tiene dos partes: 22

53 En primer lugar, se realiza una selección del requisito, en ella el cliente debe entregar la lista de requisitos priorizada «Product Backlog List» al equipo que consultara las dudas acerca de la lista al cliente y se comprometerán entre ambos los requisitos más prioritarios que se deben llevar a cabo en esta iteración. De esta forma si el cliente lo viera necesario podrían ser entregados al final de la iteración. La selección de requisitos no debe durar mas de 4 horas como máximo. En segundo lugar, se lleva a cabo la planificación de la iteración «Sprint Planning», donde el equipo realiza una estimación del esfuerzo que se va a realizar en la iteración y cada miembro del equipo se auto-asignara las tareas de la lista de tareas de la iteración. La planificación tampoco puede durar mas de 4 horas como máximo. Ejecución de la iteración «Development phase»: en esta fase se lleva a cabo el desarrollo del proyecto, es decir, la ejecución de cada iteración. El equipo en esta fase debe realizar diariamente una reunión de sincronización «Scrum Daily Meeting», en la que cada miembro del equipo explica su avance desde la anterior reunión y puede ver el trabajo realizado por el resto de sus compañeros y así poder realizar las adaptaciones necesarias que permitan realizar su compromiso adquirido con anterioridad. Durante la iteración, el scrum master (Facilitador) será el encargado de que se llegue al cumplimiento del compromiso eliminando obstáculos y protegiendo al equipo, además de asegurándose de que el equipo no merme su productividad. Inspección y adaptación «Post-game phase»: el último día de la iteración se realizará una reunión «Sprint Review» en la que se revisará todo el trabajo realizado. En una primera parte se realizará una demostración, en la que el equipo debe presentar al cliente todos los requisitos de la iteración completados, de forma que sea un incremento del producto que pueda ser entregado. Esta demostración no debe durar mas de 4 horas Y en una segunda fase retrospectiva, el equipo analiza su forma de trabajar y cuáles han sido sus problemas durante la ejecución de la iteración, para lograr de manera continuada mejorar su productividad. La duración también debe ser inferior a 4 horas Los roles en Scrum La metodología Scrum propone para su desarrollo diferentes roles [Bah11] que deben formalizarse al principio del proyecto. Estos roles son tres y se corresponden con: product owner o dueño del proyecto, scrum master, scrum team. Además, como se mostró en los puntos anteriores Scrum permite que todas aquellas personas que pertenezca al grupo de los interesados en el producto, como pueden ser inversores, usuarios, etc., puedan formar parte del proyecto. Esto se realiza respetando los roles previamente citados y participando como audiencia. 23

54 Cada uno de estos roles tiene asociada una serie de características, funciones y aptitudes como mostraremos a continuación. Product owner: el dueño del producto debe ser la única persona con la autoridad suficiente para decidir qué tipo de funcionalidades y características funcionales va a tener el producto final. El product owner es el representante de todas las partes interesadas en el producto, es decir, el cliente, los usuarios del software, etc. El product owner tiene una serie de responsabilidades y funciones básica, las cuales vamos a describir a continuación: En primer lugar es el responsable de canalizar las necesidades que tiene el negocio, con lo que tiene que saber interpretar las necesidades específicas de las partes interesadas en el producto y retransmitirlas al scrum team. En segundo lugar debe buscar maximizar el valor para el negocio, es decir, buscar el llamado retorno de la inversión (ROI), mirando siempre por los intereses del negocio. Como última responsabilidad, es el encargado de revisar los prototipos del producto e ir adaptándole correctamente sus funcionalidades, analizando si existen mejoras que puedan otorgar un mayor valor para el negocio. Scrum master: es el encargado de fomentar e instruir sobre los principio ágiles de Scrum al scrum team. Sobre el recae una gran cantidad de funciones y responsabilidades, como vamos a ver a continuación: El scrum master es el responsable de garantizar la correcta aplicación de Scrum, es decir, debe asegurarse de que se realiza desde la correcta transmisión de sus principios a las altas gerencias, como de una prevención de la inversión de los roles en el desarrollo del proyecto ágil. También sera el responsable de resolver los posibles conflictos que surjan en el desarrollo del proyecto e impidan o entorpezcan el progreso del proyecto. Debe ser capaz de motivar al scrum team, creando un buen clima dentro de él y fomentando la auto-gestión del equipo, impidiendo la intervención de terceros. Scrum team: equipo que será el encargado de llevar a cabo cada iteración. Es un equipo de desarrolladores multidisciplinario, compuesto por programadores, diseñadores, arquitectos, testers, etc., que de una forma auto-organizada serán los encargados de desarrollar el producto final Roles de Scrum aplicados a este proyecto En esta sección vamos a mostrar en relación a lo visto en la sección anterior cómo se han asignado los roles de Scrum a este proyecto. Estos roles se han asignado de la siguiente manera (ver Cuadro 4.1). 24

55 ROL Product Owner (Cliente) Scrum Master (Director del equipo) Scrum Team (Equipo desarrollador) ASIGNACIÓN María José Santofimia Romero María José Santofimia Romero Antonio Agudo Mansilla Cuadro 4.1: Roles asignados a las personas de este proyecto Fases de Scrum aplicados a este proyecto Esta sección describe en las cuales se ha organizado el desarrollo de este proyecto (ver Figura ). Este TFG se ha dividido en 6 iteraciones, cada una de estas iteraciones va a corresponder con un incremento que aporta una nueva funcionalidad al sistema. Figura 4.1: Iteraciones en Scrum Pre-game phase En una primera fase se va a realizar la planificación del proyecto, esto se hace en función de los objetivos expuestos (véase 2). Como bien dijimos anteriormente cada una de estas iteraciones va a durar entre 1 y 4 semanas, dependiendo del número y la dificultad de las tareas que se deban completar en cada iteración. El cliente en primer lugar ha presentado al equipo su «Product Backlog». Esta lista de objetivos contiene un orden de prioridades, las cuales son otorgadas en función a la prioridad señalada por el cliente. A continuación se van a mostrar tanto la «Product Backlog» entregada por el cliente, como el «Sprint Planning» realizado por el scrum team

56 Product Backlog List Objetivo 1: Realizar una recogida de la información de sensorización que nos proporciona el dispositivo móvil. Objetivo 2: Realizar una grabación supervisada de casos de estudio «Dataset». Objetivo 3:Realizar una conexión Cliente-Servidor entre el dispositivo móvil y el ordenador para realizar una transmisión de los datos. Objetivo 4: Realizar una caracterización de la señal recogida de los datos de sensorización. Objetivo 5: Realizar el entrenamiento del sistema para obtener como resultado los modelos de comportamiento. Objetivo 6: Realizar las pruebas pertinentes a los modelos, obteniendo las tasas de acierto. Objetivo 7:Realizar una aplicación que en tiempo real realice la recogida de los datos y los envié al servidor. Objetivo 8:Realizar la caracterización y el entrenamiento de los datos recibidos del anterior objetivo. Sprint Planning Iteración 1: Realizar una aplicación para Android que recoja los datos de los sensores y los guarde en memoria interna. Iteración 2: Realización del «Dataset». Iteración 3: Realización de una aplicación que envíe los datos de «Dataset» al servidor. Iteración 4: Realizar la caracterización de los datos a través de medidas estadísticas y Clustering con K-means. Iteración 5: Realizar el entrenamiento de los datos y la realización de las pruebas de los modelos resultantes. Iteración 6: Realizar una aplicación que en tiempo real capture los datos de sensorización, enviándolos al servidor y realizando la caracterización y clasificación de estos. Game phase Una vez ya tenemos bien definido el «Sprint Planning», se puede proceder a la realización de cada uno de los «Sprints» contenidos en él. 26

57 Iteración 1 Planificación: Se va a realizar una aplicación que recoja y guarde los datos de sensorización. Análisis de requisitos: Las lecturas de los sensores del dispositivo móvil deben ser capturados y almacenados. Diseño: Se va realizar un estudio sobre las posibles formas en que se pueden recoger y la mejor manera de almacenar los datos. Codificación: Tras la realización del estudio de las posibles formas de recogida y almacenamiento de los datos, se va a proceder a la recogida de los mismos cuando se detecte una nueva lectura en alguno de los sensores del dispositivo móvil. Además, en ese mismo instante que se captura esa nueva lectura se va a almacenar en la estructura de ficheros correspondientes, donde el directorio será el nombre del voluntario que está grabando las pruebas y su interior va a contener los archivos con el nombre de las acciones que graba. Revisión: Se comprobará que tras la realización de una grabación todos los datos son almacenados correctamente y los datos almacenados se corresponden con las mediciones de los sensores. Iteración 2 Planificación: Se va a realizar las grabaciones controladas de los casos de estudio. Análisis de requisitos: Realizar la grabación de los datos que compondrán en «Dataset». Diseño: Se debe estudiar como realizar de una forma controlada y supervisada la grabación de las acciones para el «Dataset». Codificación: Tras el estudio de los diferentes espacio donde se van a realizar las acciones y de las diferentes acciones que se van a llevar a cabo, se procederá a realizar un guión que deberán seguir cada uno de los voluntarios. Una vez completado se procederá a la captación de 15 voluntarios que realizaran estas capturas controladas de la forma prevista en el guión. Revisión: Se debe comprobar una vez realizada la grabación de cada una de las acciones de los 15 voluntarios, que estas grabaciones están almacenadas correctamente y su contenido es correcto. Iteración 3 Planificación: Realización de una aplicación y un servidor que puedan trasmitir los datos del «Dataset» Análisis de requisitos: Crear una conexión Cliente-Servidor y transmitir los datos del dispositivo móvil y al servidor. 27

58 Diseño: Se va a estudiar las diferente posibilidades existentes para realizar el envió de los datos del móvil al servidor. Codificación: Una vez decidido el formato que se utilizara para realizar el envió de los datos, se debe recoger los datos del móvil y aplicarles este formato para realizar el envió, el servidor recibirá los datos y los almacenara en archivos de texto. Revisión: Se va a comprobar que los datos que se enviaron desde el cliente (dispositivo móvil) son concordantes con los datos recibidos en el servidor. Iteración 4 Planificación: Se va a realizar la caracterización de la señal. Análisis de requisitos: Realizar las medidas estadísticas y el Clustering a la señal recibida. Diseño: Se estudiara que tipo de medidas estadísticas se deben utilizar y que tipo de Clustering se utilizara para la caracterización. Codificación: En primer lugar se va a proceder a realizar una serie de medidas estadísticas (media, máximo, mínimo, desviación típica y varianza) para caracterizar la señal. Y en segundo lugar se recogerá la salida de esta caracterización y se le realizara un método de agrupamiento no jerárquico, e los cuales se a decidido utilizar un Clustering con K-means. Revisión: Se verificará que una vez caracterizada la señal, la ejecución de esta iteración da como resultados la serie de datos correcta. Iteración 5 Planificación: Se va a proceder a la realización de un entrenamiento guiado y el estudio de los datos Análisis de requisitos: Realizar el entrenamiento mediante la librería SVM y probar los resultados. Diseño: Se estudiara la mejor forma de calcular los resultados obtenidos de los modelos para ver sus tasas de acierto. Codificación: A través de un entrenamiento guiado se van a realizar los modelos de comportamiento del sistema, fundamentales para la realización posterior del sistema. Para poder garantizar que estos modelos son viables, se va a realizar un estudio de ellos, sacando como resultado la tasa de acierto de cada uno de ellos. Revisión: Se comprobara que las tasas de acierto son correctas con los resultados obtenidos por los modelos. Iteración 6 28

59 Planificación: Realizar una aplicación que recoja los datos de sensorización y los envié a un servidor que este a su vez realice la clasificación de los datos. Análisis de requisitos: Integración de los requisitos anteriores en una sola aplicación en tiempo real. Diseño: Se va a estudiar la realización de una aplicación fácil e intuitiva, y la mejor forma de realizar el envió, caracterización y clasificación de los datos. Codificación: En esta iteración vamos a recuperar código utilizado en las 5 iteraciones anteriores. Para crear por un lado un aplicación capaz de recoger la información de sensorización en tiempo real y por otro lado crear un servidor que realice la caracterización realizada en la iteración 3 y después una clasificación de estos datos. Revisión: Se recogerán los resultados de la clasificación y se contrastaran con la acción que esta realizando el usuario para ver si se corresponden. Post-game phase En esta sección vamos a mostrar las fases de post-game o inspección y adaptación del trabajo de cada iteración: Iteración 1 Esta fase del proyecto fue completada en un tiempo de 4 semanas. Una vez completada la iteración, esta fue expuesta al cliente en la reunión «Sprint Review». El cliente examinó la aplicación de recogida de datos y comprobó el cumplimiento de las especificaciones expuestas. Por lo que el equipo procede a la siguiente iteración. Iteración 2 Esta fase del proyecto fue completada en un tiempo de 1 semana. Tras varias reuniones con el manager del equipo, se llevo a cabo un guión para realizar las grabaciones y se procedió a su realización. Los datos recogidos fueron presentándose al cliente en la reunión «Sprint Review». Quedando este satisfecho por los datos recogidos. Iteración 3 Esta fase del proyecto fue completada en un tiempo de 2 semanas. Una vez completada la iteración, y expuesta al cliente en la reunión «Sprint Review». Visto que los datos eran traspasados de forma correcta. Se procedió a pasar a la siguiente iteración. Iteración 4 Esta fase del proyecto fue completada en un tiempo de 4 semanas. Debido a la dificultad de implementar el algoritmo de Clustering, y la adaptación de formatos entre los algoritmos de clasificación y entrenamiento. Se necesito de varias reuniones con el manager del proyecto hasta que se dió con el mejor procedimiento para la conexión entre el módulo de medidas estadísticas y el algoritmo de Clustering. Los resultados 29

60 de esta iteración fueron expuestos al cliente en la reunión «Sprint Review». Donde pudo comprobar que los requisitos de caracterización de la señal eran completados correctamente. Por lo que se avanzó a la siguiente iteración. Iteración 5 Esta fase del proyecto fue completada en un tiempo de 1 semana. Debido a las facilidades que nos aportaban las librerías de entrenamiento. una vez realizado el entrenamiento se presentaros los resultados de los modelos al cliente en la reunión «Sprint Review» quedando este satisfecho con los resultados obtenidos. Iteración 6 Esta fase del proyecto fue completada en un tiempo de 4 semanas. La implementación de un sistema a tiempo real, provocó un gran número de reuniones con el manager del proyecto para estudiar la mejor estrategia a seguir. Debido a que se debía implementar funcionalidades de las 5 iteraciones anteriores en un solo paso. Una vez finalizado se le entrego al cliente el sistema en la reunión «Sprint Review» donde comprobó que se cumplía con la funcionalidad del sistema planteado. Una vez terminada la ultima iteración, el proyecto se ha concluido. Como el cliente no realizó ninguna alteración respecto a la especificación inicial, por lo que se ha respetado el «Sprint Planning» que se planteó inicialmente. Una vez acabadas todas las iteraciones el equipo muestra al cliente el resultado final de todo el sistema realizando varias pruebas que demuestran su correcto funcionamiento. Por lo que el el producto final cumple con las expectativas que el cliente tenia en él. 4.2 Herramientas En esta sección se van a citar las diferentes herramientas que se han utilizado para la realización del proyecto. Vamos a hablar tanto de los lenguajes utilizados como los medios software y hardware que han sido empleados Lenguajes Para la realización del código de este TFG se han utilizado dos lenguajes: Java 3 : es un lenguaje de programación de propósito general, concurrente y orientado a objetos. Java fue diseñado para poder tener tan pocas dependencias de implementación como fuera posible. Este lenguaje va a ser utilizado para las aplicaciones que corren en el teléfono, es decir, en las aplicaciones de Android. Python 4 : es un lenguaje de programación interpretado que hace hincapié en una sintaxis que favorezca un código legible. Python proporciona una programación orientada

61 a objetos, programación imperativa y en menor medida programación funcional. Utilizaremos este lenguaje para la realización de los servidores, Clustering, entrenamiento y pruebas Medios hardware Para el desarrollo de las aplicaciones nos hemos ayudado de los siguientes medios hardware: Un equipo Acer E MJ, con el cual hemos desarrollado todo el código del proyecto. Este equipo está compuesto de un Procesador Intel R Core TM i5 4210U Memoria de 4 GB DDR3 L 1000 GB HDD de Disco Duro. Un Smartphone Samsung Galaxy S4 para probar la aplicación durante su desarrollo Un Bq Aquaris 5.0 para la prueba de la aplicación durante el desarrollo Medios software En el desarrollo del proyecto se han utilizado diferentes medios software para la realización del mismo. Sistemas operativos Android 5 : sistema operativo con el cual funciona el móvil y sobre el que van a correr las aplicaciones resultantes del proyecto. Ubuntu 6 : bits, sistema con el cual vamos a realizar todo el desarrollo del código y la elaboración de la documentación. Documentación Texmaker 7 : editor con el cual se ha elaborado la documentación tanto del anteproyecto como del proyecto. Microsoft Office 8 : para la realización de los gráficos. Desarrollo Android SDK 9 : herramienta para el desarrollo del código en Android, además proporciona una pasarela con el móvil

62 Mercurial 10 : es un sistema de control de versiones multiplataforma, nos proporciona una forma de mantener todo el código y documentación actualizado y versionado. Eclipse 11 : es una plataforma que nos proporciona un conjunto de herramientas de código abierto para el desarrollo del proyecto. La vamos a utilizar junto con el plugin SDK para el desarrollo de las aplicaciones en Java para el móvil. Gedit 12 : es un editor de texto que destaca por su sencillez y que ha sido utilizada para desarrollo del código en python

63 Capítulo 5 Desarrollo del Proyecto ESte capítulo describe el proceso desarrollo seguido en este TFG enumerando las diferentes iteraciones en que se ha dividido este proceso de desarrollo y que fueron definidas anteriormente (ver Capítulo 4). 5.1 Aplicación para la recogida de datos En esta primera parte del proyecto se pretende realizar una aplicación en Android llamada Recogida de Datos que nos permita poder realizar la captura de la información sensora del dispositivo móvil. Para la realización de este proyecto hemos utilizado un Samsung Galaxy S4 (ver Figura ). Se eligió este dispositivo por el amplio abanico de posibilidades que nos ofrece, ya que nos va a permitir recoger la información de los siguientes sensores: Figura 5.1: Samsung Galaxy S4 Acelerómetro: nos va a permitir realizar mediciones sobre las aceleraciones o cambios de velocidad a los que este sometido el dispositivo

64 Barómetro: nos va a dar información sobre la presión atmosférica del espacio en el que se encuentra el dispositivo. Giroscopio: nos indicará si el dispositivo sufre algún cambio de orientación. GPS: nos permite determinar en todo el mundo la posición exacta del dispositivo. Sensor de luz: va a responder ante cualquier cambio de intensidad de la luz, dándonos mediciones de éstas. Magnetómetro: cuantifica la fuerza magnética recibida por el dispositivo. Sensor de proximidad: indicará si se encuentra algún dispositivo cerca de la pantalla del dispositivo móvil. Sensor de temperatura: nos proporcionará las mediciones sobre la temperatura a la que está sometido el dispositivo. Todos estos sensores nos van a proporcionar un conjunto de datos que serán utilizados para desarrollar un sistema que nos permita predecir qué actividad estará realizando el usuario del dispositivo. Esta aplicación desarrollada nos ofrece una interfaz de usuario (ver Figura 5.2) fácil e intuitiva para el usuario. En esta interfaz, en primer lugar se ha introducido un EditText donde el usuario deberá introducir el texto correspondiente al nombre del usuario, si éste no lo introduce al iniciar la grabación saltará un mensaje de error. Figura 5.2: App: Recogida de datos En segundo lugar, se va a incorporar en la aplicación un menú desplegable (ver Figura 5.3) para que el usuario seleccione la acción que desea grabar. El usuario podrá elegir entre un diverso grupo de acciones que se pretenden caracterizar en este sistema: 34

65 Figura 5.3: App: Recogida de datos: Acciones 1. Esperar 2. Andar 3. Correr 4. Montar en bici 5. Ir en coche 6. Subir escaleras 7. Bajar escaleras 8. Subir ascensor 9. Bajar ascensor 10. Puñetazo 11. Patada Una vez que el usuario ya tenga seleccionada la acción que va a proceder a grabar, se debe iniciar la grabación. Para ello, la aplicación contiene dos botones iniciar y parar. Para que sea más sencilla esta aplicación para el usuario se ha determinado que, cuando se inicie la grabación, el color del fondo cambie (ver Figura 5.4), y al parar la grabación este fondo vuelva a su color inicial. Así conseguiremos tener una aplicación más intuitiva. Como detalle en la aplicación, también se irán mostrando las diversas lecturas que realiza de cada sensor. Todos los datos que son capturados en el proceso de grabación serán guardados en un directorio, el cual se encontrará en la memoria interna del teléfono. Para cada uno de los 35

66 Figura 5.4: App: Recogida de datos: Grabando sensores se creará dentro de este directorio un archivo con su nombre donde se guardarán todas las lecturas de este sensor sabiendo que el Usuario será el nombre introducido por el usuario y la Acción la seleccionada por el usuario en el menú desplegable. Nuestro directorio de ficheros contendrá un directorio llamado Usuario_Acción el cual contendrá 9 archivos, uno para cada sensor a los que llamaremos Usuario_Acción_Sensor.txt. Siendo Sensor el nombre del sensor del que provienen los datos. Tenemos que citar que esta aplicación fue creada conjuntamente para la realización de la captura de datos tanto de los datos de este proyecto, como de los datos del proyecto Per- Se [Bar14] Implementación En esta sección vamos a ver los pasos más importantes que se han llevado a cabo en la implementación de esta aplicación. En primer lugar para almacenar las lecturas de los sensores se deben crear los flujos de datos a través de los cuales vamos a poder realizar las escrituras en los archivos. Esto se va a conseguir de la siguiente manera (ver Listado 5.1). Como se muestra en el listado, así crearíamos el flujo de datos del acelerómetro. Para la realización del resto de flujos de datos solo se deberá repetir esta acción para cada uno de los sensores. Una vez creado los flujos de datos, ya podemos recoger los datos de los sensores y guardarlos en memoria. Esto lo conseguimos tal y como se describe en Listado 5.2. Con esto vamos a conseguir que cuando exista una nueva lectura en uno de los sen- 36

67 String sensores = ruta. getabsolutepath () +"/ Sensores "; String usuario = nombre + "_" + accion ; sensores = sensores +"/"+ usuario ; oacelerometro = new OutputStreamWriter (new FileOutputStream (new File ( sensores, usuario +" _Acelerometro. txt "))); Listado 5.1: «SensorActivity.java» sores se realizaren dos acciones. Una de ellas será la de mostrar en la pantalla del Smartphone los datos recogidos y la otra siempre que el el sistema esté grabando será la de guardar en el archivo correspondiente los datos con el método escribir_externa (ver Listado 5.3). Este método es el encargado de escribir los datos recogidos en cada uno de los archivos de los sensores. Esto se realiza escribiendo en el flujo de datos perteneciente al sensor, la hora y los datos correspondientes a las lecturas realizadas al sensor. public void onsensorchanged ( SensorEvent arg0 ) { synchronized (this){ switch( arg0. sensor. gettype ()){ case Sensor. TYPE_ ACCELEROMETER : masdata = arg0. values ; xa = masdata [0]; ya = masdata [1]; za = masdata [2]; textviewacelerometro. settext ("x: " + xa + "\ny: "+ ya + "\nz: "+ za); if( GRABAR ==1) escribir_externa ("\tx: " + xa + "\ty: "+ ya + "\tz: "+ za +"\n",oacelerometro ); break; }}} Listado 5.2: SuppressLint (" SimpleDateFormat ") public void escribir_ externa ( String texto, OutputStreamWriter fout ){ DateFormat dateformat = new SimpleDateFormat (" HH: mm: ss"); if ( Environment. MEDIA_ MOUNTED. equals ( Environment. getexternalstoragestate ())){ try{ fout. append ( dateformat. format (new Date ())+"\t"+ texto ); }catch ( Exception ex){ Log.e(" Escribir ", " Error al escribir fichero "); }}} Listado 5.3: «SensorActivity.java» 37

68 5.2 Recogida de datos «Dataset» En esta parte del proyecto se va a realizar la grabación de un conjunto de datos de acciones para la realización de los futuros modelos. Para ello nos vamos a ayudar de la aplicación que se ha creado en la anterior sección. En primer lugar hemos buscado a 15 voluntarios, los cuales serán los responsables de realizar las 11 acciones seleccionadas previamente. Para ello a estos 15 voluntarios se les ha entregado un guión (ver Anexo A), el cual deben leer y seguir para la realización correcta de las acciones. Para la realización de este guión previamente se ha estudiado cómo se iban a realizar cada una de las acciones, es decir, se ha estudiado dónde realizar la grabación de cada una de ellas. Finalmente se decidió realizar las acciones como subir y bajar escaleras en el edificio Fermín Caballero de la ESI. Las pruebas de puñetazo y patada en los laboratorios del grupo ARCO localizados en el ITSI y por último, las pruebas de andar, correr, montar en bici y coche en el parking del ITSI. Una vez teníamos decididos los espacios donde se iban a grabar las pruebas, se decidió la mejor manera de realizar cada una de las acciones, tanto en la forma en que se realizarían como la duración de las mismas. Estas cuestiones se explicaron detalladamente en el guión que se les dio a los usuarios (ver Anexo A). También adjunto a esto se les entregó un formulario de consentimiento (ver Anexo B) para poder realizar la grabación de las misma de los que algunos ejemplos de autorizaciones firmadas se pueden ver en Anexo C. Con todo esto bien definido, se procedió a la realización de las pruebas quedando con cada uno de los voluntarios individualmente. La realización de estas grabaciones no supuso más de 50 minutos de grabación con cada uno de ellos. Una vez completadas todas las grabaciones, teníamos completos el Dataset que nos ofrece una serie de casos de estudio controlados y supervisados en su grabación. 5.3 Realización de una conexión Cliente-Servidor y envió de los datos. Para la realización de esta sección se han creado por un lado una aplicación para Android, que será la responsable del envió de los datos y por otro lado un servidor en Python que será el encargado de la recepción de los datos. En primer lugar se creó la aplicación (ver Figura 5.5) llamada LoCoMoteTCP para el dispositivo móvil que dará soporte a la lectura y envío de los de los datos. Esta aplicación consta de una interfaz compuesta de: Un menú desplegable Spinner que contendrá todas las acciones que contiene del Dataset. Dos EditText uno para introducir la IP del servidor y el segundo para introducir el puerto del servidor. 38

69 Figura 5.5: App: LoCoMoteTCP Y 3 botones Conectar, Enviar y Enviar todas las acciones. Para la utilización de esta aplicación en primer lugar, el usuario debe introducir el IP y puerto del servidor y pulsar el botón de Conectar o de lo contrario no se podrá llevar a cabo el envío con éxito. Una vez realizada la conexión, la aplicación nos permite realizar dos tipos de envíos: Si se desean enviar los datos de un determinado tipo de acción solo tendrá que seleccionar en el menú despegable cual de las acciones quiere enviar y pulsar el botón Enviar. Si por el contrario quiere enviar los datos de todas las acciones solo deberá pulsar el botón Enviar todas las acciones Esta aplicación se ha implementado sobre 3 clases (ver Figura 5.6) que permiten cumplir con los requisitos de la funcionalidad requerida: LoCoMoteActivity: es la clase principal y será la encargada de arrancar la interfaz y la responsable de lanzar las funcionalidades de las otras dos clases, coordinándolas para el correcto funcionamiento del sistema. ProcesarArchivos: va a ser la responsable de crear las colas de eventos. Para ello, en primer lugar va a leer los ficheros del dispositivo móvil que contiene los datos del Dataset. Esto se va a conseguir creando una lectura BufferedReader sobre los ficheros que contienen esta información, que procesará línea a línea el contenido de los ficheros. Los archivos con la información lectora contienen los datos estructurados de la siguiente forma: 39

70 Figura 5.6: App: LoCoMoteTCP: Clases 17:43:45 x: y: z: Por lo que utilizando un token podemos ir segmentando las líneas y recogiendo los datos que nos interesan. Con cada línea crearemos una clase evento que contendrá en su interior los datos de los valores (x, y, z) y la hora en que se recogió en el caso del ejemplo. Tenemos que decir que existen tres tipos de clase eventos, las cuales se corresponderán con el número de variables que tengan cada uno de los ficheros. Existirá un evento para 3 variables (x, y, z), otro para 2 variables (x, y) y un tercero para solo una variable (x), en todos ellos se recogerá la hora en que se grabo esas medidas. Una vez guardada cada línea en su clase evento se procederá a guardarlo en una cola de eventos. Por lo tanto, como resultado de todo esto, esta clase nos proporcionará una cola de eventos que se corresponde con la transformación del archivo que contenía las lecturas del sensor. VentanaDeslizante: esta clase va a ser la responsable de realizar los envíos al servidor. Para ellos en primer lugar recogerá la cola de eventos creada en ProcesarArchivos. Para el envió de los datos de esta cola se va a crear una ventana deslizante que irá recorriendo esta cola de eventos. Esta ventana empezará llenándose cuando se inicializa, sabiendo que el tamaño predefinido de la ventana será de 5. El siguiente paso a seguir sería el desplazamiento de la ventana por la cola, esto se realizará dejando una superposición con la ventana anterior que este caso está predefinido a 1. Por lo que la nueva 40

71 ventana contendrá un evento de la ventana anterior y 4 eventos nuevos procedentes de la cola. Este último paso se repetirá hasta que la cola de estadísticas haya sido recorrida completamente. Tenemos que decir que la cola de eventos está ordenada en orden cronológico, es decir, por orden de lectura. Por lo que la ventana deslizante irá introduciendo en su interior los eventos de esta cola siguiendo ese orden. Cada vez que se completa una ventana, tanto si es en el llenado de la ventana la primera vez, o en cada uno de los desplazamientos completos, se va a enviar esta ventana al servidor. Con esta aplicación se pretende que el envió al servidor de los datos del Dataset sea de una forma ordenada y en estricto orden cronológico. Como veremos el envío se realiza en bloques temporales debido a que posteriormente se realizará una caracterización y entrenamiento o clasificación de estos bloques. En segundo y último lugar se creó en Python un servidor Servidor.py el cual va a ser el responsable de la recepción de todos los datos que nos manda la aplicación del dispositivo móvil. Y también será el responsable del almacenamiento de estos datos en archivos de texto. Para poder poner en marcha el servidor solo hace falta poner en un terminal: $ python Servidro.py <<IP>> Tenemos que decir que esta aplicación, también se ha utilizado para el envió de datos en el proyecto PerSe [Bar14] Implementación En esta sección vamos a ver los pasos más importante llevados a cabo para realizar la implementación de esta aplicación. LoCoMoteTCP Empezaremos comentando los detalles de la aplicación para Android. Para poder explicar el funcionamiento de la clase principal LoCoMoteActivity debemos primero explicar lo siguiente: La clase ProcesarArchivos será la encargada de leer los archivos que se contienen en la memoria interna del teléfono. En especial se consigue con el método leer (ver Listado 5.4). Este método es el encargado de abrir el archivo y recorrerlo línea a línea guardando sus datos en una cola de eventos. En el caso del listado se muestra como para el caso de un evento de 3 variables, se procede a primero leer la línea, después 41

72 a separarla con un token e ir recorriéndola, guardando cada uno de los valores en su correspondiente variable. Como punto final esta nueva estadística se añadirá a la cola de estadísticas. texto = new BufferedReader (new FileReader ( f) ); while( texto. ready ()){ Evento3 aux = new Evento3 ( tipo ); st = new StringTokenizer ( texto. readline (), " \t"); 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 ); } Listado 5.4: «ProcesadorArchivos.java» Por otro lado también es muy interesante explicar cómo funciona la clase VentanaDeslizante. Esta clase va a ser la encargada de realizar los envíos al servidor. En el código (ver Listado 5.5) como podemos observar se da acceso a las dos posibilidades detalladas con anterioridad. Por un lado si la ventana estuviera vacía que sería la primera parte del código procederíamos a llenar la ventana con los primeros elementos de la cola de eventos. Pero si por el contrario la ventana ya está llena, se debe proceder a desplazarla quitando de ella su tamaño menos la superposición y llenando los huecos que se han quedado desocupados con los primeros elementos de la cola de eventos. Cada vez que la ventana deslizante está llena, ya sea en primer llenado o en los posteriores desplazamientos, se va a llamar al método enviarventana (ver Listado 5.6) que será el encargado de enviar cada ventana al servidor. Una vez visto el funcionamiento de estas dos clases, vamos a ver como funciona la clase principal que es la encargada de manejarlas. Para ello se ha implementado el método procesararchivos que tendrá contenido gran parte de la funcionalidad de esta iteración. En él (ver Listado 5.7), en primer lugar se van a recorrer todos los directorios que contengan en su nombre el nombre de la acción determinada. Para cada uno de estos directorios primero se llamará a la clase procesararchivos que se encargará de realizar la cola de eventos como mostramos anteriormente. Y en segundo lugar si esta cola no es vacía, procederá llamando a la clase ventanadeslizante a realizar el envió de cada una de las ventanas al servidor. 42

73 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{ 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.5: «VentanaDeslizante.java» public void enviarventana ( Cola < Evento > ventana, ClienteTCP c, String accion ){ ArrayList < Double > valores =new ArrayList < Double >() ; valores = getvalores ( ventana ); String tipo = ventana. primero (). gettipo (); c. enviar (tipo, accionentero ( accion ),valores ); } Listado 5.6: «VentanaDeslizante.java» También es interesante saber con qué criterio se llama a este método procesararchivos. Cuando el usuario quiere enviar solamente los datos de un tipo de acción determinada, se llamará a este método poniendo el nombre de la acción. Pero si por el contrario se quiere enviar todos los datos, se procederá a llamar a este método con todos los nombres de las acciones. Servidor Como se muestra (ver Listado 5.8) se ha decidió que la IP del servidor será proporcionada en el primer argumento del ejecutable y que el puerto del servidor venga ya predefinido, en este caso el puerto Por otro lado el manejador (ver Listado 5.9) se quedará en un bucle infinito esperando a recibir los datos del cliente. Estos datos serán guardados en un fichero como veremos en la siguiente sección, debido a que a la hora de caracterizar la señal se modificaron los datos de data y se modificó el formato del guardado. 43

74 public static void procesararchivos ( VentanaDeslizante vd, String accion ) throws CloneNotSupportedException { ProcesadorArchivos p = null; Cola < Evento > aux = new coladinamica < Evento >() ; } ArrayList < File > archivosaccion = new ArrayList < File >() ; File raiz = new File ( ruta. getabsolutepath ()+"/ Sensores /"); if ( raiz. exists ()){ archivosaccion = listardirectorio ( raiz, accion ); for(int i =0; i< archivosaccion. size ();i ++) { p = new ProcesadorArchivos ( archivosaccion. get ( i). getabsolutepath ()); p. leer (); aux = p. geteventos (). clone (); if(! aux. esvacia ()) vd. ventana_deslizante (aux,vd. DIM_ VENTANA_ ACELEROMETRO, vd. SUPERPOSICION_ ACELEROMETRO, c, accion ); } AnadirEscribir (" Enviado "); } else{ AnadirEscribir (" No hay archivos "); } Listado 5.7: «LoCoMoteActivity.java» if name == " main ": HOST, PORT = sys. argv [1], 5000 server = SocketServer. TCPServer (( HOST, PORT ), MyTCPHandler ) server. serve_ forever () Listado 5.8: «Servidor.py» 5.4 Caracterización de la señal La caracterización de la señal se va a realizar mediante dos procesos y en dos pasos diferentes. Por un lado se ha producido la realización de una serie de medidas estadísticas, se ha decidido que estas sean realizadas dentro del archivo Servidor.py por lo que una vez se reciben en el servidor las señales de las ventanas deslizantes, a esta ventana se le van realizar las siguientes medidas estadísticas. Media Máximo Mínimo Desviación típica Varianza 44

75 class MyTCPHandler ( SocketServer. StreamRequestHandler ): def handle ( self ): while 1: try: data = self. rfile. readline (). strip () if not data : return except KeyboardInterrupt : sys. exit () Listado 5.9: «Servidor.py» Cabe destacar que estas medidas estadísticas serán procesadas según el tipo de evento que se recibe. Por ejemplo, si se recibe un evento con valores en (x, y) se le harán estas 5 medidas a los valores de x y estas 5 medias a los valores de y, por lo que como resultado final tendremos 10 valores. Si el evento fuera de 3 (x, y, z) obtendríamos 15 valores y si fuera de 1 (x) tendríamos 5 valores. Una vez realizadas estas medidas se procederá al guardado de ellas en un archivo de texto. Se va a crear un archivo para cada sensor en el cual se guardara una secuencia de números. Esta secuencia para un evento de 1 variable seria la siguiente: Donde tendríamos un primer valor que en este caso es el 11 que se corresponde con la etiqueta asignada para la acción y justo después los 5 valores estadísticos. Las etiquetas de las acciones se corresponderán con las siguientes acciones. 1. Esperar 2. Andar 3. Correr 4. Montar en bici 5. Ir en coche 6. Subir escaleras 7. bajar escaleras 8. Subir ascensor 9. Bajar ascensor 10. Puñetazo 11. Patada Por lo que toda línea que se inserte en estos ficheros tendrán una etiqueta correspondiente a la acción. Cada vez que se guarda una nueva ventana se añadirá al fichero correspondiente por 45

76 lo que por ejemplo nuestro fichero barómetro.txt contendrá una secuencia como la mostrada a continuación Donde se puede ver repetido siempre el mismo patrón, la etiqueta correspondiente a la acción y después los 5 valores estadísticos. La segunda parte de la caracterización se va a realizar en el archivo Clustering.py, en el se va a realizar un método de agrupamiento no jerárquico llamado Clustering con k-means. Este archivo va a leer los archivos que anteriormente se han creado en el servidor, los cuales ya contendrán todos los datos que se recogieron en el Dataset. En el procedimiento de lectura de estos archivos se van a crear los puntos con los que va a trabajar el Clustering, cada punto será la secuencia de números que continúan a las etiquetas de las acciones. En el caso expuesto anteriormente la primera escritura se correspondería con los números Si eliminamos la secuencia de la acción. Las coordenadas del primer punto se corresponderían con las de [942.9, , , , ], esto para un evento de solo una variable, si el evento fuera de 2 ó 3 variables los puntos tendrían 10 ó 15 valores en sus coordenadas. Una vez creados todos los puntos. Se procederá a realizar el Clustering (ver Capitulo 3. Al Clustering le vamos a pasar el numero de Clusters que queremos que nos cree, que en nuestro caso será 2. El proceso de Clustering en primer lugar genera estos dos centroides de forma aleatoria y les asigna los puntos mas cercanos, una vez se le asignan estos puntos se debe volver a calcular la posición de los centroides en función de los puntos asignados. Estas dos etapas de asignación y actualización se sucederán hasta que la asociación a los grupos ya no cambien. Por lo que el resultado final del proceso de Clustering será las coordenadas de los dos clusters y los puntos que están en su zona de influencia. Una vez tenemos estos calculados vamos a proceder a guardar los resultados del proceso, para ello se creará una archivo de datos para cada sensor, por ejemplo para el caso del acelerómetro Clustering_Acelerometro.txt. En cada uno de ellos se guardará la etiqueta de la acción seguido de la distancia de las coordenadas de cada uno de sus puntos a los dos clusters, es decir, se pondría primero la diferencia en valor absoluto de la distancia de cada una de las coordenadas del punto al cluster 1 y después las del punto al cluster 2. Por ejemplo, el acelerómetro tendría 15 valores por lo que la salida de su Cluster serían 30 valores. 11 1: : : : : : : : : : : : :

77 14: : : : : : : : : : : : : : : : : Como se ve, primero va la etiqueta de la acción y va seguido de los 30 valores, los cuales van precedidos de una nueva etiqueta. Este formato de salida nos está impuesto debido a que el posterior entrenamiento que se va a realizar requiere este formato. Para poder realizar el Clustering de un fichero solo se necesita introducir en un terminal: $ python Clustreing.py <<dir_fichero>> Para la posible realización del Clustering de todos los archivos a la vez se ha creado Clustering.sh. Se decidió no realizarle el Clustering ni al sensor de luz ni al de humedad por la poca información útil que nos aporta así como a las mediciones de GPS. Por lo que estos sensores han sido descartados para la continuación del proyecto, provocando que este ejecutable no le realiza el Clustering a estos archivos. Para la ejecución del ejecutable solamente se necesita escribir en la terminal. Teniendo en la misma carpeta los archivos de texto de cada sensor como se citó previamente. $./Clustering.sh Implementación En esta sección vamos a ver los pasos más importante llevados a cabo para realizar la implementación de esta aplicación. Servidor.py Para poder realizar las medidas estadísticas a la ventana que nos llega al servidor hemos tenido que realizar varios pasos. En primer lugar (ver Listado 5.10) vamos a coger los datos recibidos en el servidor y separar las secuencias recogiendo la acción, el tipo, y los datos y convirtiendo estos datos por medio de la función split en una lista de números. Una vez tenemos ya realizada esta separación vamos a proceder a crear una estructura la cual contendrá los datos de estos. Para ello y sabiendo que tenemos datos de 3 tipos, es decir, tenemos eventos con una dimensión, eventos con dos y eventos con 3 debemos crear estructuras de 1,2 y 3 dimensiones. Para guardar en estas estructuras los datos se ha creado el método separarvariablesxyz que por ejemplo en el caso del acelerómetro (ver Listado 5.11) recorrerá la lista de valores guardada en values y los irá almacenando cada uno en la lista de la variable que le corresponda. 47

78 data = self. rfile. readline (). strip () if not data : return accion = data. split (" ",2) [0] tipo = data. split (" ",2) [1] data = data. split (" ",2) [2] s = data [1: 1]. replace (" ","") values = s. split (",") Listado 5.10: «Servidor.py» def separarvariablesxyz ( struct, values ): cont = 0 i = 0 if struct. tipo == 3: while(i<len( values )): if cont == 0: struct.x. append (float( values [i])) cont = cont +1 elif cont == 1: struct.y. append (float( values [i])) cont = cont +1 elif cont == 2: struct.z. append (float( values [i])) cont =0 i=i+1 Listado 5.11: «Servidor.py» Una vez se han guardado los valores en la estructuras correspondientes se procede a realizarle las medidas estadísticas en el orden citado anteriormente creando el método medidasestadisticas que será el encargado de realizarlas. A este método se le pasa por parámetros la estructura que contiene los datos y una matriz llamada medidas donde se guardará el resultado de la realización de estas medidas estadísticas. Para el caso del acelerómetro (ver Listado 5.12). En último lugar se procederá a guardar los datos en el archivo de texto, el cual tendrá en nombre del sensor que se ha procesado. Para ello (ver Listado 5.13) se abre el archivo de texto de tal forma que se añadan los datos y no se sobre-escriban. Y se procede a asignarle el formato predefinido previamente, el cual es primero la etiqueta de la acción seguida de los valores contenidos en medidas. Clustering.py En cuanto a la implementación del archivo Clustering.py cuenta de tres pasos. En un primer lugar se va a proceder a convertir el archivo de texto en la sucesión de puntos para ello y sabiendo el formato que tiene el archivo, se ha implementado la siguiente función (ver Lis- 48

79 def medidasestadisticas ( struct, medidas ): if struct. tipo == 3: medidas. append (np. amax ( struct.x)) medidas. append (np. amin ( struct.x)) medidas. append (np. mean ( struct.x)) medidas. append (np.std ( struct.x)) medidas. append (np.var ( struct.x)) medidas. append (np. amax ( struct.y)) medidas. append (np. amin ( struct.y)) medidas. append (np. mean ( struct.y)) medidas. append (np.std ( struct.y)) medidas. append (np.var ( struct.y)) medidas. append (np. amax ( struct.z)) medidas. append (np. amin ( struct.z)) medidas. append (np. mean ( struct.z)) medidas. append (np.std ( struct.z)) medidas. append (np.var ( struct.z)) Listado 5.12: «Servidor.py» file = open ("./"+ tipo +". txt ", "a") buf = str( accion )+" " for m in medidas : buf += str(m) + " " file. write ( buf. encode file. close () ( utf 8 )) Listado 5.13: «Servidor.py» tado 5.14). En ella se abre el archivo cogiendo los datos contenidos en él. Como explicamos con anterioridad cada punto tendrá primero la etiqueta y luego 5, 10 ó 15 valores dependiendo del tipo de sensor. Por lo que procedemos a coger y guardar esos 5, 10 ó 15 puntos eliminando el valor de la etiqueta. Por ejemplo en el caso del acelerómetro que tiene 15 valores, realizaríamos lecturas de 16 valores. Procederíamos a quitarle la etiqueta y crearíamos un nuevo punto con esos 15 valores. En último lugar se añade este nuevo punto a una lista de puntos. A continuación se procede a la realización del Clustering a esta lista de puntos creada anteriormente, para ello se ha utilizado el método kmeans (ver Listado 5.15). En él se van a realizar los pasos de asignación y actualización. Se realizará el proceso explicado con anterioridad (ver Capítulo 3). En primer lugar se generarán los centroides de forma aleatoria y se le asignarán los puntos mas cercanos, una vez se le asignan estos puntos se debe volver a calcular la posición de los centroides en función de los puntos asignados. Estas dos etapas de asignación y actualización se sucederán hasta que la asociación a los grupos ya no cambien. En última instancia se procederá a la escritura de los resultados en los fichero (ver Lista- 49

80 def leerpuntos ( txt ): f = open("./"+ Tipo ( txt )+". txt ") n_var = n_variables ( Tipo ( txt ))+1 msg = f. read () f. close () msg. replace ("\n"," ") data = msg. split (" ") n_ datos = len( data ) n_ puntos = ( n_datos 1)/ n_ var i=0 puntos = [] m = [] accion = "" while i <= n_datos 1: if (i %n_var ==0) : accion = str( data [i]) if (i %n_var ==1) and i!=1: p = Point (m) p. accion = accion puntos. append (p) m = [] if i!= n_datos 1 and i %n_ var! =0: m. append (float( data [i])) i +=1 return puntos Listado 5.14: «Clustering.py» do 5.16). Esta escritura debe ser en el formato correcto que nos pide la entrada del entrenamiento. El cual deberá contener la etiqueta de la acción seguida de los dígitos, precedidos a su vez por una numeración Etiq_Accion 1 : x 1 2 : x 2 3 : x 3... Los valores que se van a guardar en este archivo van a ser la distancia de cada punto a los dos centroides, expresado la diferencia de sus posiciones vectoriales en valor absolutos. Se colocará primero la distancia del punto al primer centroide y en segundo lugar la distancia del punto al segundo centroide. En el caso del acelerómetro los primeros 15 valores corresponderían a la distancia al primer centroide y los siguientes 15 al segundo centroide. Y obtendríamos una salida como podemos ver a continuación. 11 1: : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

81 def kmeans ( points, k, cutoff ): initial = random. sample ( points, k) clusters = [ Cluster ([ p]) for p in initial ] loopcounter = 0 while True : lists = [ [] for c in clusters ] clustercount = len( clusters ) loopcounter += 1 for p in points : smallest_ distance = getdistance ( p, clusters [0]. centroid ) clusterindex = 0 for i in range( clustercount 1): distance = getdistance ( p, clusters [ i +1]. centroid ) if distance < smallest_ distance : smallest_ distance = distance clusterindex = i +1 lists [ clusterindex ]. append (p) biggest_ shift = 0.0 for i in range( clustercount ): shift = clusters [i]. update ( lists [i]) biggest_ shift = max( biggest_ shift, shift ) return clusters Listado 5.15: «Clustering.py» 5.5 Entrenamiento y pruebas En primer lugar se ha creado Entrenamiento.py. Para la realización del entrenamiento nos vamos a ayudar la funcionalidad que nos aportan las librerías lib_svm, con ellas se puede realizar un entrenamiento guiado del sistema y nos proporcionará como salida un modelo. Esto simplifica mucho esta etapa del proceso ya que teniendo los datos ya en el formato determinado que te pide la librería, paso que se hizo en el punto anterior. Solamente debemos utilizar la función svm_train, pasándole los parámetros indicados. Para ello solamente tenemos que poner en la terminal. $ python Entrenamiento.py <<dir_archivo>> <<dir_modelos>> Como se puede observar, como primer argumento le pasaremos el archivo de texto perteneciente a la salida del Clustering realizado en la sección anterior y como segundo argumento el directorio donde queremos que se almacene el modelo resultante del proceso. Como ya ocurrió con anterioridad también se ha creado un ejecutable Entrenamiento.sh con el cual se crearán los 6 modelos de forma automática, solo se deberá introducir en la terminal. $./Entrenamiento.sh Cabe decir que Entrenamiento.sh se ha utilizado también para la realización del proyecto PerSe [Bar14]. 51

82 def EscribirFichero ( txt, clusters ): for i in clusters : for j in i. points : p =[] for k in range(j.n): p. append ( dis (j. coords [k], clusters [0]. centroid. coords [k])) for l in range(j.n): p. append ( dis (j. coords [l], clusters [1]. centroid. coords [l])) file = open ("./"+" Clustering_ "+ Tipo ( txt )+". txt ", "a") buf = j. accion + " " x = 1 for m in p: buf += str(x) + ":" + str(m) + " " x += 1 buf += "\n" file. write ( buf. encode ( utf 8 )) file. close () Listado 5.16: «Clustering.py» En segundo lugar se ha creado un archivo en Python llamado Probar.py en la cual ayudándonos nuevamente de la librerías de lib_svm vamos a realizar las pruebas de los modelos. Con esto conseguiremos sacar las tasas de acierto de cada uno de nuestro modelos ya que nos proporcionará como salida el porcentaje de acierto que ha tenido nuestro modelo y nos imprimirá cuántas veces ha clasificado erróneamente y qué etiqueta le ha asignado erróneamente. Para la ejecución de este archivo se debe introducir en la terminal. $ python Probar.py <<dir_modelo>> <<dir_archivo>> Como primer argumento se le va a pasar la dirección donde esta el modelo que queremos probar y como segundo argumento se le debe introducir el fichero correspondiente a la salida del Clustering que se quiere probar. Como salida de realizar esta acción obtendremos: Accuracy = : 2312, 2.0: 2328, 3.0: 1524, 4.0: 1687, 5.0: 3405, 6.0: 1362, 7.0: 631, 8.0: 12, 9.0: 24, 10.0: 1530, 11.0: 1624 [ Probar.py, Modelos/Acelerometro, Modelos/Archivos/Clustering_Acelerometro.txt ] [2.0, 10.0, 10.0,..., 10.0, 1.0, 1.0, 1.0, 1.0, 1.0] En el cual, como se dijo con anterioridad, vemos el porcentaje de acierto y en la segunda línea las veces que se a clasificado cada una de las acciones Implementación En esta sección vamos a ver los pasos más importante llevados a cabo para realizar la implementación de esta aplicación. 52

83 Entrenamiento.py La implementación (ver Listado 5.17) es muy sencilla, gracias a la librería lib_svm. Solamente debemos recoger como parámetros el fichero de la salida del Clustering y el directorio donde se guardara el modelo resultante. Después de estos con las funciones svm_read_problem pasándole el fichero de datos del Clustering se encargará de leerlo. Una vez hecho esto solo queda ajustar los parámetros y llamar a la función svm_train que nos devolverá el modelo resultante. fichero = sys. argv [1] dir_ modelos = sys. argv [2] todo = fichero. split ("/") for palabra in todo : sensor = palabra. split (".",1) [0] sensor = sensor. split ("_",1) [1] y, x = svm_read_problem ( sys. argv [1]) prob = svm_problem (y, x) param = svm_ parameter () param. kernel_ type = LINEAR param.c = 10 modelo = svm_train (prob, param ) svm_save_model ( dir_modelos +"/"+ sensor, modelo ) Listado 5.17: «Entrenamiento.py» Probar.py Si la implementación del entrenamiento era sencilla, la realizada para poder probar los modelos (ver Listado 5.18) también lo es gracias a esta librería. Utilizando las funciones svm_load_model y svm_read_problem vamos a poder leer los dos archivos que se le pasan como argumento, es decir, el modelo y los casos de prueba. Una vez realizado esto solamente hay que llamar a la función svm_train con los argumentos que nos dan las funciones anteriores, y nos proporcionará una serie de valores, el más interesante es el p_label que contendrá en su interior la matriz de predicciones que le pasaremos al método accion que nos proporcionara de una forma fácil a la vista cuántas predicciones de cada acción se han precedido. 5.6 Aplicación y servidor final Como resultado de las 5 secciones anteriores, se han creado 6 modelos de comportamiento, los cuales van a poder caracterizar las 11 acciones que citamos anteriormente. Ahora vamos a realizar un sistema que en tiempo real pueda realizar la clasificación de nuevos datos utilizando los modelos de comportamiento creados. Para ello se van a implementar por un 53

84 def accion (p): accion = 1 accion_ repes = 1 m = {1.0:0,2.0:0,3.0:0,4.0:0,5.0:0,6.0:0,7.0:0,8.0:0,9.0:0,10.0:0,11.0:0} a = len(p) for i in range(a): b = int (p[i 1]) m [p[i 1]] = m[p[i 1]] + 1 print m 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 ) accion ( p_label ) Listado 5.18: «Probar.py» lado una aplicación en Android que va a ser la responsable de recoger los datos del teléfono y realizar cada cierto tiempo un envío de estos datos al servidor. Por otro lado, se va a crear un servidor que realice la caracterización y clasificación de estos nuevos datos. En primer lugar se implementó la aplicación en Android (ver Figura 5.7) llamada «Lo- CoMote», que nos va a permitir tanto la recogida de la información sensora como el envío de esta información al servidor en tiempo real. Esta aplicación consta de una interfaz muy intuitiva la cual tiene: Figura 5.7: App: LoCoMote 54

85 Dos «EditText» uno para la IP y otro para el puesto del servidor. Y tres botones Iniciar, Para y Conectar. El usuario de la aplicación debe introducir la IP y puerto del servidor y darle al botón Conectar. Si el usuario no realiza esta acción antes de empezar a grabar, los datos no llegarán al servidor. Una vez realizado esto, el usuario ya solo tiene que pulsar el botón Iniciar para empezar la grabación y pulsar Parar cuando desee pararla. También como ocurriera anteriormente cuando el sistema esté grabando se cambiará el fondo de la pantalla de color (ver Figura 5.8), para que este sistema sea mas intuitivo. Figura 5.8: App: LoCoMoteTCP: Grabando Ahora esta nueva aplicación antes de enviar los datos al servidor, les realizará una serie de medidas estadísticas, para lo que hemos utilizado clase Estadisticas. Por lo que esta aplicación se estructurara de la siguiente manera (ver Figura 5.9). Las clases VentanaDeslizante y ProcesadorArchivos contendrán la misma funcionalidad que veíamos en capítulos anteriores. Por otro lado vamos a crear el servidor que será el encargado de realizar el Clustering y clasificación de los datos. Este servidor es más complejo que el anterior ya que contiene la funcionalidad que antes se contenía en 3 archivos diferentes. La salida de este servidor será por terminal y nos irá proporcionando la acción que está realizando el usuario. Para poder ejecutar el servidor se sebe introducir lo siguiente en la terminal. $ python Servidor.py <<IP>> <<Puerto>> <<dir_modelos>> 55

86 Figura 5.9: App: LoCoMote: Clases En este caso al servidor se le van a pasar 3 parámetros: En primer lugar la dirección IP del dispositivo donde esta alojado el servidor. El puerto donde va a estar escuchando el servidor. Y por último la dirección del directorio que contiene los modelos creados en el entrenamiento Implementación En esta sección vamos a ver los pasos más importante llevados a cabo para realizar la implementación de esta aplicación. LoCoMote Esta aplicación va a coger código de las dos aplicaciones para Android creadas previamente, lo que agilizará el proceso de implementación, pero se han añadido funcionalidades muy importantes. La primera de estas funcionalidades es poder realizar la clasificación de los datos en tiempo real. Para ello hemos decidido enviar los datos cada 5 segundos. Eso lo vamos a conseguir añadiéndole al método guardardatos un contador (ver Listado 5.19). Esto se va a implementar capturando inicialmente un tiempo time_start que será comparado en este método. Si al entrar al método el tiempo final es mayor al tiempo inicial + 5 segundos se procede a lanzar 56