MINT: Model for location INference using Tracking
Sistema pervasive de recomendaci´
on de trayectorias basado en
localizaci´
on
Proyecto de Grado presentado al
Departamento de Ingenier´ıa de Sistemas y Computaci´on por
Andrea Carolina Buitrago
Asesora: Claudia Luc´ıa Jim´enez
Para optar al t´ıtulo de Ingeniera de Sistemas y Computaci´on
Universidad de los Andes Julio de 2014
´
Indice
1. Introducci´on 5
1.1. Problema a resolver . . . 5
2. Objetivos 7 2.1. Objetivo General . . . 7
2.2. Objetivos Espec´ıficos . . . 7
2.3. Consideraciones y restricciones . . . 7
3. Contexto y Antecedentes 8 3.1. Contexto del proyecto . . . 8
3.1.1. MAGPIE . . . 8
3.1.2. Budgie . . . 8
3.2. Antecedentes . . . 9
3.2.1. Sistemas de recomendaci´on m´ovil basados en localizaci´on . . . 10
3.2.2. Sistemas de predicci´on de movilidad . . . 11
3.3. Resumen . . . 11
4. Estrategia de soluci´on 13 4.1. Atributos de calidad . . . 13
4.2. Recolecci´on de datos . . . 15
4.2.1. Procesamiento del aceler´ometro . . . 16
4.2.2. Detecci´on de Movimiento . . . 18
4.2.3. Control del muestreo GPS . . . 20
4.3. Limpieza de datos . . . 21
4.3.1. Detecci´on de trayectorias y lugares visitados . . . 22
4.3.2. Filtro de trayectorias . . . 23
4.3.3. Detecci´on de lugares visitados . . . 23
4.3.4. Unificaci´on y enriquecimiento . . . 24
4.4. Procesamiento y an´alisis . . . 24
4.4.1. Inferencia del pr´oximo lugar . . . 24
4.4.2. Identificaci´on de tr´afico . . . 26
4.4.3. Generaci´on del cl´uster . . . 27
4.5. Alcance . . . 30
5. Descripci´on de la soluci´on 32 5.1. Contexto . . . 32
5.2. Despliegue . . . 32
5.3. Budgie MINT . . . 33
5.3.1. Controlador principal de la aplicaci´on . . . 34
5.3.2. Modelo de desplazamiento del usuario . . . 35
5.3.3. Constructor local de inferencias . . . 36
5.3.4. Comunicaciones externas . . . 38
5.3.5. Manejador de persistencia . . . 38
5.3.6. Monitoreo . . . 39
5.3.7. Diferencias con versiones anteriores de Budgie . . . 42
5.4. Main Processor . . . 43
5.4.1. Procesador de datos . . . 44
5.4.2. Administrador del cluster . . . 45
5.4.3. Constructor de inferencias . . . 47
5.4.4. Generador de alertas y recomendaciones . . . 47
5.4.5. Comunicaciones externas . . . 47
6. Implementaci´on 49
6.1. Budgie MINT . . . 49
6.2. Main Processor . . . 51
6.3. Web Server . . . 54
7. Pruebas y resultados 57 7.1. Dataset . . . 57
7.2. Recolecci´on de datos . . . 58
7.3. Limpieza de datos . . . 59
7.4. Procesamiento y an´alisis . . . 60
7.4.1. Predicci´on . . . 60
7.4.2. Generaci´on del cluster y recomendaciones . . . 61
8. Conclusiones y trabajo futuro 63
´
Indice de figuras
1. Modelo principal de Budgie. . . 9
2. Variables relevantes en Budgie. . . 10
3. Diagrama de contexto. . . 13
4. Atributos de calidad aplicaci´on m´ovil Budgie MINT. . . 14
5. Atributos de calidad del back-end. . . 14
6. Flujo de procesamiento de datos. . . 14
7. Sistema de recolecci´on de datos. . . 15
8. Muestras del aceler´ometro para un dispositivo est´atico . . . 16
9. Mediciones del aceler´ometro para diferentes movimientos . . . 17
10. Diagrama de flujo del procesamiento de los datos del aceler´ometro . . . 19
11. Sistema de limpieza. . . 21
12. Gr´afico de una trayectoria y un lugar visitado . . . 22
13. Ejemplo de trayectoria con una medici´on anormal . . . 23
14. Ejemplos de trayectorias filtradas . . . 23
15. Etapa de procesamiento y an´alisis . . . 25
16. Modelo de aprendizaje de m´aquina. . . 25
17. Ejemplo de una trayectoria con tranc´on . . . 27
18. Proceso realizado para obtener una estructura con los lugares relevantes y las trayectorias. . 27
19. Conceptos de DBSCAN paraM inP ts= 4. . . 29
20. Ejemplos del modelo de similitud de trayectorias. . . 30
21. Diagrama de contexto. . . 32
22. Diagrama de despliegue. . . 32
23. Diagrama de componentes Budgie MINT. . . 33
24. Diagrama de clases orquestador. . . 34
25. Diagrama de clases del modelo de desplazamiento del usuario. . . 35
26. Componente constructor local de inferencias. . . 36
27. Diagrama de clases constructor local de inferencias. . . 37
28. Componente comunicaciones externas . . . 38
29. Estructura de archivos Budgie Tracker [10]. . . 39
30. Columnas de los registros de los sensores. . . 39
31. Componente de monitoreo. . . 40
32. Diagrama de clases del monitoreo. . . 42
33. Diagrama de componentes Main Processor. . . 43
34. Diagrama de clases procesador de datos. . . 44
35. Flujo de procesamiento para la realizaci´on del cluster. . . 45
36. Diagrama de componentes comunicaciones externas. . . 47
37. Diagrama de componentes del servidor web. . . 48
38. Vista de trayectorias realizadas por el usuario. . . 49
39. Ejemplos del modelo de similitud de trayectorias. . . 50
40. Ejemplos de trayectorias filtradas . . . 52
41. Diagrama de despliegue. . . 53
42. P´agina principal. . . 55
43. P´agina de un usuario. . . 55
44. Formulario para realizar la predicci´on del lugar a visitar por un usuario. . . 56
45. Resultados de las predicciones del lugar a visitar por un usuario. . . 56
46. Distribuci´on de los datos en los usuarios del dataset. . . 57
47. Distribuci´on de los datos de acuerdo a los sensores. . . 58
´
Indice de tablas
1. Comparaci´on de proyectos evaluados y MINT . . . 12
2. Par´ametros de la etapa de recolecci´on de datos . . . 21
3. Par´ametros de la etapa de limpieza . . . 24
4. Par´ametros de la etapa de procesamiento y an´alisis . . . 31
5. Codificaci´on de las caracter´ısticas usadas en el algoritmo de aprendizaje . . . 36
6. Managers y Listener usados en Budgie MINT . . . 40
7. Discretizaci´on usada para las diferentes caracter´ısticas de un lugar visitado. . . 45
8. Discretizaci´on usada para las diferentes caracter´ısticas de un lugar visitado. . . 46
9. Matriz de adjacencia del grafo. . . 46
10. Valores para los par´ametros de la etapa de recolecci´on de datos . . . 51
11. Valores de par´ametros de la etapa de limpieza de datos . . . 51
12. Caracter´ısticas del dataset GeoLife [23]. . . 52
13. Especificaci´on de la infraestructura. . . 54
14. Valores de los par´ametros de la etapa de procesamiento y an´alisis . . . 54
15. Caracter´ısticas del dataset obtenido. . . 57
16. Pruebas de bater´ıa . . . 59
17. Caracter´ısticas del dataset obtenido. . . 59
18. Resultados de predicciones en BudgieMINT . . . 61
1.
Introducci´
on
En la actualidad, la amplia adopci´on de los dispositivos m´oviles as´ı como el r´apido y diverso crecimiento de la informaci´on disponible en la Web, han generado una serie de retos y oportunidades para el mundo de la computaci´on que contienen requerimientos diferentes a aquellos propuestos por sistemas tradicionales.
En los ´ultimos a˜nos la tecnolog´ıa de dispositivos m´oviles ha tenido una gran penetraci´on a nivel mundial, donde en el 2013 se calcul´o que existen cerca de 6.8 billones de suscripciones m´oviles (al rededor del 96 % de la poblaci´on mundial) [1]. ´Esta tecnolog´ıa ha transformado la manera como vivimos y se ha convertido en una herramienta indispensable, ya que no solo nos ha permitido una r´apida comunicaci´on sino que se ha convertido en un punto de acceso a la informaci´on. Adem´as, la inclusi´on de sensores embebidos en los dispositivos m´oviles como GPS, aceler´ometro, c´amara, micr´ofono y bluetooth, entre otros, ha permitido el desarrollo de aplicaciones enfocadas a la salud, turismo o el entretenimiento que antes no podr´ıan haber sido consideradas.
Debido a la ubicuidad de los dispositivos m´oviles y al hecho de que estos posean sensores, ha nacido el inter´es en desarrollar sistemas pervasive m´oviles que aprovechen ´estas caracter´ısticas para percibir las acciones y el contexto del usuario de manera no invasiva. De esta manera, se podr´an ofrecer servicios no intrusivos que mejoren la experiencia y calidad de la vida humana sin exigir una atenci´on explicita o consciente [2][3]. Por lo tanto, es posible brindarle al usuario un ambiente inteligente que infiera a partir del contexto y el perfil del usuario la informaci´on que es relevante.
Entre los campos que han adquirido mayor importancia en los sistemas pervasive m´oviles, se encuentra el desarrollo de sistemas de informaci´on pervasive basados en localizaci´on, estos sistemas utilizan la posici´on, contexto y perfil del usuario para acceder o producir informaci´on relacionada con la ubicaci´on en la que se encuentra [4]. La importancia que han adquirido estos sistemas se debe a la alta relaci´on que existe entre la posici´on de un usuario, las actividades que realiza y los servicios que requiere. Adem´as, la reciente ubiquidad de los dispositivos m´oviles en la vida de los usuarios, as´ı como a la posibilidad de acceder a la localizaci´on de ´estos por medio de sus sensores, ha permitido un mayor desarrollo de este tipo de sistemas.
En particular, es relevante desarrollar sistemas pervasive de recomendaci´on y generaci´on de alertas basados en localizaci´on y h´abitos del usuario, pues estos pueden responder al problema de obtenci´on de la informaci´on de manera no intrusiva gener´andole alertas relevantes al usuario en momentos cr´ıticos. Los anteriores sistemas poseen m´ultiples aplicaciones en ´areas de mercadeo, publicidad, y turismo, donde conocer los intereses de los usuarios en relaci´on a su localizaci´on da la oportunidad de ofrecerles contenido relevante en el lugar adecuado para as´ı adquirir posibles clientes.
1.1.
Problema a resolver
La problem´atica que se desea tratar ocurre en el contexto de movilidad de una ciudad, donde en muchas ocasiones es dif´ıcil predecir el tiempo de llegada a un lugar; lo anterior es causado porque dicho tiempo depende de la ruta que se tome, el momento del d´ıa, el medio de transporte e, incluso, en cierta medida del clima. ´Esta problem´atica afecta a todas las personas que se movilizan en una ciudad, y, por ello mismo, se puede afirmar que cualquier persona con un dispositivo m´ovil ´esta en capacidad de aportar informaci´on valiosa sobre el estado del tr´afico en la ruta que est´a tomando/tom´o para dirigirse a su casa, trabajo, reuni´on, . . . etc. Por lo tanto, si se conociera dicha informaci´on de todas las personas en una ciudad, ser´ıa posible tomar una decisi´on m´as acertada sobre qu´e ruta tomar para llegar a un lugar espec´ıfico.
El problema presentado no es desconocido y ha tenido m´ultiples aproximaciones, no obstante, es debido a los diferentes factores que afectan la movilidad de una ciudad que no ha sido resuelto por completo. Adicionalmente, se debe resaltar que en el presente proyecto no se desea solamente realizar una estimaci´on de tiempos de llegada a un lugar en una ciudad, sino, ofrecerle un servicio invisible a un usuario que le brinde informaci´on relevante en momentos relevantes. En particular, deben resaltarse las diferencias entre la aplicaci´on GoogleNow y el sistema que se desea desarrollar en este proyecto, ya que esta aplicaci´on ha recibido especial atenci´on recientemente por su utilidad para la movilizaci´on en una ciudad. Las diferencias
entre estos dos sistemas yacen en dos hechos, por un lado en este proyecto se desea realizar predicciones sobre el pr´oximo lugar que el usuario visitar´a a partir de la informaci´on hist´orica que se posee y los datos del calendario, es decir, se incluyen muchos m´as lugares en las predicciones adem´as de la casa y el trabajo de un usuario. Por otro lado, las recomendaciones no solo ser´an alertas de tr´afico, sino sugerencias de rutas alternativas que son usadas por otros usuarios. Finalmente, se debe se˜nalar que la aplicaci´on GoogleNow no funciona si no existe una conexi´on a internet disponible en el dispositivo, mientras que se desea que la aplicaci´on desarrollada en este proyecto funcione, aunque con m´argenes de error m´as altos, en un contexto de poca conectividad.
Debido a que esta problem´atica afecta a todas las personas que se movilizan en una ciudad, son dichas personas los principales interesados en encontrar una posible soluci´on. Sin embargo, en la medida en que ´
este problema afecta el transporte p´ublico de una ciudad, pueden existir entidades interesadas en conocer y monitorear el tr´afico, para as´ı tomar medidas de acuerdo con dicha informaci´on.
Teniendo en cuenta la anterior problem´atica, el presente proyecto tiene como principal objetivo desarrollar un sistema pervasive que permita la adquisici´on y recuperaci´on de datos de movilidad de sus usuarios, para realizar la generaci´on tanto de recomendaciones como de alertas relevantes para un usuario de acuerdo con su localizaci´on y a sus h´abitos, en particular, a su calendario.
2.
Objetivos
2.1.
Objetivo General
Realizar el dise˜no e implementaci´on de MINT (Model for location INference using Tracking), un sistema pervasive compuesto por una aplicaci´on m´ovil Android y un back-end que permita:
- Adquirir y recuperar datos de movilidad de las personas que usen la aplicaci´on m´ovil.
- Generar alertas relevantes para la movilidad del usuario basadas en la localizaci´on actual de ´este y la informaci´on de su calendario.
2.2.
Objetivos Espec´ıficos
Desarrollar e integrar un componente a la arquitectura ya disponible del proyecto MagPie para el an´alisis y generaci´on de alertas basadas en los datos de localizaci´on.
Definir y desarrollar un modelo de alertas que utilice los datos de localizaci´on del usuario y su calendario, as´ı como la informaci´on de localizaci´on adquirida para generar alertas relevantes.
Desarrollar e integrar un componente Android al proyecto Budgie que permita realizar la adquisici´on y procesamiento b´asico de los datos de localizaci´on.
Desarrollar un componente Android que permita geolocalizar los lugares a los cuales el usuario debe ir de acuerdo con su calendario personal.
2.3.
Consideraciones y restricciones
Las principales consideraciones para el proyecto se encuentran en el desarrollo de la aplicaci´on m´ovil, pues esta no debe consumir de manera excesiva e innecesaria los recursos del dispositivo m´ovil. En particular, se resaltan las siguientes consideraciones,
- Los dispositivos m´oviles poseen bater´ıa limitada que puede ser consumida f´acilmente por la lectura de sensores o el excesivo procesamiento. Por lo tanto, se debe procurar usar adecuadamente los recursos del dispositivo para as´ı aprovecharlos sin degenerar el funcionamiento de ´este para el usuario.
- Al realizar el an´alisis de los datos es necesario considerar el contexto de no conectividad, por ser este un recurso que no es constante en los dispositivos m´oviles. Adicionalmente, es necesario identificar los casos en los cuales el usuario apaga los sensores, cierra la aplicaci´on o apaga por completo el dispositivo. Por otro lado, se busca desarrollar un sistema pervasive por lo cual la aplicaci´on debe requerir poca interacci´on con el usuario, de tal manera que se le ofrezca un servicio invisible.
3.
Contexto y Antecedentes
3.1.
Contexto del proyecto
3.1.1. MAGPIE
El proyecto MagPie (ManaGing Pervasive Information Environment), realizado dentro del grupo de investigaci´on COMIT, busca dise˜nar y desarrollar sistemas pervasive que respondan de manera efectiva al problema de inundaci´on de la informaci´on a trav´es del an´alisis del contexto, sentimiento, preferencias y perfil de un usuario [5]. En la actualidad, el proyecto posee sistemas de recomendaci´on con dos enfoques: por un lado, se encuentran aquellos que funcionan en un contexto de consumo de contenido y, por lo tanto, son sistemas basados en la construcci´on de perfiles de usuario y su inter´es en ciertos temas. Por otro lado, se han desarrollado sistemas de recomendaci´on que a partir de los sensores disponibles en dispositivos m´oviles realizan un reconocimiento de actividades y generan recomendaciones acordes a dichos datos.
De manera m´as espec´ıfica, en el contexto de consumo de contenido se han desarrollado tres sistemas de recomendaci´on de contenidos correspondientes a Mag-E [5], MagPie Prompter [6] y MagPie DREAM[7]. En el primero, se desarroll´o un sistema con conciencia emocional que permit´ıa predecir el inter´es de un usuario en un contenido basado en su postura y expresi´on facial, dicha informaci´on era usada posteriormente para realizar recomendaciones de contenido relevantes para el usuario. Por su parte, en MagPie Prompter[6] se realiza un monitoreo de la interacci´on del usuario con el sistema para establecer el inter´es que tiene un usuario en un contenido espec´ıfico. Adicionalmente, en este proyecto se propone un sistema de an´alisis de contenidos que permite por medio de m´ultiples heur´ısticas categorizar los documentos de acuerdo con los temas que son de inter´es para el usuario [6]. Finalmente, el proyecto MagPie DREAM[7] es un sistema de recomendaci´on pervasive de contenidos dentro de una comunidad, este trabajo realiza una implementaci´on de las arquitecturas propuestas en Mag-E y MagPie Prompter, con un ´enfasis en inferir los intereses del usuario de manera din´amica teniendo en cuenta los cambios de estos a lo largo del tiempo.
Adicionalmente, se han desarrollado m´ultiples proyectos en aplicaciones m´oviles que buscan consumir y/o extender los trabajos realizados en tanto en Mag-E como en MagPie Prompter, dichos trabajos corresponden a clientes Android [8] y iOS [9] que permiten tanto el monitoreo como la recomendaci´on de contenido usando los sensores disponibles en un dispositivo m´ovil, en particular la pantalla t´actil.
Con respecto a los sistemas de recomendaci´on basados en dispositivos m´oviles, se han realizado dos proyectos: Budgie [10] y Destreza [11]. Destreza, busca ofrecer una soluci´on adaptativa y din´amica al problema de identificaci´on de patrones en diferentes individuos, ya que se encontr´o que no es v´alido usar las mismas heur´ısticas de tiempo en todos los usuarios para analizar sus patrones de comportamiento, pues existen individuos que poseen patrones que se repiten en periodos de tiempo m´as largos o cortos [11]. Por lo tanto, en Destreza se propone un modelo de an´alisis de flujos de datos adaptativo que permite de manera din´amica obtener patrones de comportamiento en escenarios pervasive.
3.1.2. Budgie
Budgie plantea un modelo para la inferencia de patrones de comportamiento a partir de los sensores de un dispositivo m´ovil. Posteriormente, se quieren usar dichos patrones para la generaci´on de alertas y notificaciones pertinentes en una comunidad [10]. Por lo tanto, Budgie mejora la calidad del servicio de los dispositivos m´oviles al permitir que su comportamiento dependa de la actividad que el usuario est´a realizando. El proyecto MINT corresponde a una continuaci´on del sistema Budgie.
El modelo general de Budgie se presenta en la figura 1, como se puede observar est´a compuesto por tres submodelos: el primero identifica y define la actividad que el usuario est´a realizando, esto lo hace por medio del procesamiento de los sensores y el calendario en los dispositivos m´oviles. A partir de las actividades identificadas, el segundo modelo realiza la detecci´on de patrones de comportamiento. Finalmente, el ´ultimo
modelo usa los patrones encontrados para generar alertas y notificaciones relevantes para los usuarios [10].
Figura 1: Modelo principal de Budgie.
En el primer modelo, se definen 5 tipos de actividades: shift activity (actividad asociada al transporte), labor activity (actividad asociada al trabajo), academic activity (actividad asociada a estudiar), leisure and hobbies (actividades deportivas o de ocio) y finalmente, basic activity que corresponde a aquellas actividades que no pueden ser clasificadas en ninguna de la anteriores [10]. Adicionalmente, en el modelo se plantea que una actividad se puede especificar a partir de la respuesta a las siguientes preguntas: ¿D´onde est´a ocurriendo? ¿C´omo est´a ocurriendo? ¿Con qui´en? ¿Cu´ando? Donde cada una de estas preguntas utiliza diferentes sensores y variables para obtener una respuesta [10].
A partir del an´alisis de los diferentes tipos de actividades se realiza una definici´on de qu´e variables son relevantes en cada una de ellas, dicha definici´on se observa en la figura 2. La principal ventaja de esta identificaci´on de variables relevantes se encuentra en poder caracterizar una actividad en t´erminos de aquellos sensores que realmente permiten diferenciar o identificar dicha actividad. Adicionalmente, permite realizar un mejor seguimiento de la evoluci´on de las actividades a lo largo del tiempo [10].
Con respecto al modelo de reconocimiento de patrones, en Budgie se proponen dos mecanismos para llevarlo a cabo: detecci´on de tipos predefinidos de patrones con un margen de error y la construcci´on de wavelets para la predicci´on de posibles valores futuros. En particular, en [10] se implementa el primer mecanismo para tres tipos de patrones: constante, peri´odico y lineal.
Por su parte, el modelo de generaci´on de alertas se desarrolla a partir de la siguiente l´ogica: se realiza una b´usqueda de patrones en los datos del usuario, al encontrar alguno se comparan los valores esperados de acuerdo con el patr´on y los valores generados en la realidad; a partir de las diferencias encontradas en la comparaci´on se determinan las alertas y recomendaciones relevantes.
Es importante se˜nalar que Budgie tiene entre sus objetivos desarrollar una aplicaci´on pervasive escalable, por lo cual cada uno de estos modelos es realizado por medio de t´ecnicas para el acceso y tratamiento de la informaci´on altamente escalables.
En MINT, al igual que en Budgie, se utilizan los datos de los sensores de un dispositivo m´ovil para establecer comportamientos del usuario y generar alertas relevantes. Sin embargo, el inter´es de ´este proyecto se encuentra en la actividad “shift activity” definida en Budgie y el uso de esta informaci´on dentro de una comunidad para generar alertas relevantes de tr´afico o rutas alternativas. Adem´as, se utilizan ciertos sensores cuyo uso fue planteado en Budgie pero no implementado por completo.
3.2.
Antecedentes
Se identificaron dos tipos de sistemas relevantes para el proyecto llevado a cabo, por un lado, los sistemas de recomendaci´on m´oviles basados en localizaci´on y por otro lado, aquellos sistemas de predicci´on de movilidad a partir de datos hist´oricos. Adicionalmente, existen ciertos proyectos que corresponden a h´ıbrido
Figura 2: Variables relevantes en Budgie.
entre estos dos tipos.
3.2.1. Sistemas de recomendaci´on m´ovil basados en localizaci´on
La aplicaci´on de turismo propuesta por Meehan et al. [12] hace recomendaciones de sitios de turismo a visitar a partir de datos del contexto del usuario, como lo son su localizaci´on, momento en el tiempo, clima y perfil demogr´afico. El sistema es un h´ıbrido que utiliza recomendaciones dadas por filtros colaborativos y por sistemas de recomendaci´on basados en contenidos. Lo anterior es realizado por medio de un sistema inteligente que determina la importancia de los diferentes datos del contexto para tomar una correcta decisi´on sobre qu´e recomendarle al usuario. El sistema es desarrollado utilizando redes neuronales artificiales y an´alisis por componentes [12].
A diferencia del anterior trabajo, en MINT se da una menor importancia al perfil demogr´afico de una persona, en particular porque para determinar esta variable muchas veces es necesario ir en contra de los principios pervasive y pedirle al usuario que responda preguntas espec´ıficas sobre s´ı mismo. Por otro lado, en MINT se desea tener en cuenta la informaci´on hist´orica de los usuarios para realizar predicciones relevantes, lo cual no es analizado en [12].
La aplicaci´on presentada en [13] busca hacer recomendaciones de restaurantes de acuerdo con la localizaci´on de los usuarios, esto es realizado a partir de un filtro colaborativo basado en localizaci´on. De esta manera, los diferentes usuarios dan calificaciones a los restaurantes y, a partir de estos datos, as´ı como de la localizaci´on de los usuarios se generan recomendaciones. La principal diferencia entre esta aplicaci´on y la desarrollada en este proyecto es que se desean analizar tramas de GPS para ofrecer recomendaciones, no solo la localizaci´on actual del usuario. Por otro lado, en el presente proyecto se busca consumir la informaci´on dada por el calendario del usuario para realizar recomendaciones pertinentes.
I’m feeling LoCo [14] es un sistema pervasive de recomendaci´on de sitios a visitar basado en localizaci´on. Este sistema parte de variables geoespaciales, el tipo de transporte del usuario, la inferencia de preferencias de este y su estado de ´animo para realizar recomendaciones pertinentes [14]. LoCo utiliza los datos del GPS y los cambios en el aceler´ometro para establecer un contexto del usuario y para determinar su modo de transporte por medio de un modelo escondido de Markov; posteriormente, se usa esta informaci´on para para filtrar los lugares cercanos que pueden ser relevantes para el usuario de acuerdo con sus preferencias inferidas en la red social foursquare [14]. Adicionalmente, el sistema realizado se enfoca en conservar el contexto pervasive, donde la ´unica informaci´on que da el usuario es su estado de ´animo.
Con respecto a la aplicaci´on desarrollada en [14], se observa nuevamente que en MINT se tienen en cuenta las trayectorias habituales del usuario para realizar las recomendaciones, as´ı como la informaci´on dada por su calendario. Por otro lado, en MINT se desea desarrollar un sistema escalable, lo cual no se tiene en cuenta en el desarrollo del sistema planteado en [14].
La aplicaci´on CityVoyager [15] desarrollada por Takeuchi y Sugimoto es un sistema de recomendaci´on de tiendas basado en los lugares que el usuario ha visitado anteriormente. CityVoyager tiene dos fases, en la primera realiza la identificaci´on de los lugares visitados por el usuario analizando aquellas posiciones en las cuales las se˜nales de GPS pierden su disponibilidad constantemente, pues se asume que en esos puntos el usuario entro a alg´un lugar; posteriormente, se usan las visitas pasadas para determinar si una tienda es preferida por un usuario, esto es realizado calculando la media de las visitas pasadas cercanas a la tienda y asumiendo que el usuario tiene una preferencia por dicho establecimiento si el valor de la media es similar a la posici´on real de la tienda [15]. El anterior procedimiento se ejecuta para todas las tiendas (de las cuales se dispone una base de datos) y, de esta manera se identifican las tiendas preferidas por cada uno de los usuarios. Finalmente, la segunda etapa de CityVoyager consiste en la recomendaci´on de tiendas cercanas por medio del uso de filtros colaborativos y la posici´on del usuario. En particular, se implementa una funci´on de similitud que selecciona a partir de una lista de tiendas preferidas otras tiendas similares [15]. Adem´as, se realiza una divisi´on de la ciudad en ´areas cuya caracter´ıstica principal es que es posible desplazarse f´acilmente entre dos puntos que se encuentran en una misma ´area.
La aplicaci´on CityVoyager tiene muchas caracter´ısticas en com´un con el presente proyecto, entre ellas el uso de la informaci´on hist´orica del usuario para realizar recomendaciones pertinentes. Sin embargo, la principal diferencia que se tiene con CityVoyager es que en MINT se busca analizar las trayectorias m´as recorridas por el usuario para darle recomendaciones relevantes con respecto su desplazamiento en la ciudad. Adem´as, se desea implementar un sistema escalable.
3.2.2. Sistemas de predicci´on de movilidad
Entre las aplicaciones comerciales de recomendaci´on m´oviles para desplazamiento en ciudades destacan Waze [16] y GoogleNow [17], la primera de estas es una aplicaci´on basada en la informaci´on dada por una comunidad, que ofrece informaci´on de tr´afico y recomendaci´on de rutas de navegaci´on. De esta manera, los usuarios pueden colaborar de dos maneras: activamente, informando eventos que ocurren en una cierta ruta o bien, navegando por la ciudad con la aplicaci´on Waze abierta, permitiendo recopilar datos de tr´afico. Adicionalmente, a medida que los usuarios contribuyen informaci´on, Waze establece niveles de confianza para ellos, lo cual causa que se pueda tener informaci´on ver´ıdica en todo momento. ´Esta aplicaci´on, a diferencia de MINT, requiere interacci´on directa del usuario para su correcto funcionamiento, lo cual va en contra de los sistemas pervasive. Por otro lado, aunque este sistema genera alertas, Waze no realiza predicciones sobre los lugares a donde se dirigir´a el usuario de acuerdo con su calendario, y ´este es un requerimiento fundamental en la aplicaci´on a desarrollar en el presente proyecto. Finalmente, Waze consume de manera excesiva los recursos del dispositivo m´ovil, lo cual se desea evitar en la aplicaci´on a desarrollar.
Con respecto a GoogleNow, es una aplicaci´on que utiliza la informaci´on dada por Waze y otros servicios para generar recomendaciones pertinentes para el usuario en cualquier momento y sobre casi cualquier tema. Con respecto a las recomendaciones de movilidad, se observa que esta aplicaci´on identifica la posici´on de la casa y el trabajo de sus usuarios, al igual que la ruta m´as frecuente tomada por el usuario para llegar a dichos lugares y genera recomendaciones si hay tr´afico particularmente pesado en dicha ruta.
3.3.
Resumen
La revisi´on del contexto y los antecedentes del proyecto permiti´o identificar aquellas caracter´ısticas que permiten resolver el problema planteado as´ı como las maneras en que algunas han sido implementadas en otros proyectos. Por lo tanto, en la tabla 1 se plantea una comparaci´on entre los proyectos evaluados y el
proyecto a desarrollar con respecto a las caracter´ısticas mas relevantes identificadas. Tabla 1: Comparaci´on de proyectos evaluados y MINT
Requerimiento Trabajos presentados MINT
Consumo de datos de geolocalizaci´on [12][13][14] S´ı
Consumo de datos de red S´ı
Consumo de datos del calendario S´ı
Consumo de informaci´on del tiempo [12] Deseable
Uso de redes sociales [12][14] No
Identificaci´on del perfil del usuario [12][14] No
Estrategias de limpiado de datos S´ı
Estrategias de sensado eficiente S´ı
Identificaci´on de h´abitos de desplazamiento [15] S´ı Recomendaci´on a partir de h´abitos de desplazamiento [15] S´ı
Soluci´on escalable [12] S´ı
Identificaci´on de lugares relevantes para un usuario [15] S´ı Identificaci´on de trayectorias habituales para un usuario [16][17] S´ı Identificaci´on de trayectorias posibles entre dos puntos S´ı
Predicci´on del siguiente lugar a visitar S´ı
Predicci´on de tiempo de viaje entre dos lugares [16][17] Deseable
Recomendaci´on de rutas alternativas S´ı
4.
Estrategia de soluci´
on
El prop´osito de MINT es la obtenci´on y modelado de datos de movilidad de usuarios a partir de dispositivos m´oviles para realizar predicciones sobre las posiciones futuras de un usuario y poder generar alertas relevantes para ´este. Se plantea como soluci´on para este problema un sistema compuesto por una aplicaci´on m´ovil que permita registrar los datos de movilidad, un back-end de procesamiento que realice inferencias sobre los usuarios y genere las alertas pertinentes y, finalmente, una aplicaci´on web para el acceso centralizado a la informaci´on de todos los usuarios. La arquitectura general se presenta en la figura 3 y posee el mismo dise˜no del sistema Budgie presentado en [10].
Figura 3: Diagrama de contexto.
Para cumplir sus objetivos MINT recoge datos de movilidad de los usuarios por medio de la aplicaci´on m´ovil, estos datos son procesados en el back-end donde el sistema Main Processor busca detectar comportamientos anormales en las v´ıas de la ciudad, por ejemplo, si existe tranc´on. Adicionalmente, luego de extraer sus caracter´ısticas relevantes se consolidan estos datos con los obtenidos por otros usuarios del sistema, para as´ı generar un conocimiento unificado de la movilidad en la ciudad.
Por su parte, los datos recogidos en la aplicaci´on m´ovil Budgie MINT tambi´en son procesados para as´ı inferir h´abitos del usuario en t´erminos de los lugares que m´as visita y los caminos que m´as toma. Esta informaci´on permite, en algunos casos, realizar predicciones sobre la movilidad de un usuario y, aprovechando la informaci´on consolidada del back-end, es posible generar alertas y recomendaciones relevantes para el usuario.
4.1.
Atributos de calidad
A partir del problema planteado y la soluci´on general anteriormente descrita se establecen los siguientes atributos de calidad que deben guiar el dise˜no de la soluci´on tanto de la aplicaci´on m´ovil como del backend. En las figuras 4 y 5 se describen los atributos de calidad que se manejan dentro de la aplicaci´on m´ovil Budgie MINT y el back-end, respectivamente.
Figura 4: Atributos de calidad aplicaci´on m´ovil Budgie MINT.
Figura 5: Atributos de calidad del back-end.
A partir de la soluci´on presentada anteriormente y teniendo en cuenta los atributos de calidad, se realiza una descripci´on del flujo de procesamiento de datos a lo largo de MINT y la manera como estos son manejados en cada etapa. Los componentes del flujo se presentan en la figura 6.
Figura 6: Flujo de procesamiento de datos.
En el primer componente del flujo de procesamiento se atienden los principales problemas de la recolecci´on de datos de movilidad, donde se busca hacer un buen uso de los recursos del dispositivo sin perder informaci´on relevante para la etapa de procesamiento y an´alisis. Por su parte, en el componente de limpieza se realiza el modelado de los datos en trayectorias y lugares visitados por un usuario, adicionalmente, se realiza el filtrado de datos anormales, donde se considera anormal aquel dato que claramente est´e fuera del patr´on del flujo inmediato. Finalmente, en el componente de procesamiento y an´alisis se utiliza el modelo de movilidad ya generado para un usuario para realizar predicciones del siguiente lugar que visitar´a. Adicionalmente, a partir de los datos de toda la comunidad se realiza el proceso de generaci´on de alertas.
A continuaci´on se presenta en mayor profundidad la estrategia de soluci´on para cada una de las etapas del flujo de procesamiento de datos.
4.2.
Recolecci´
on de datos
Este componente est´a basado en el sistema BudgieTracker desarrollado en [10] y BudgieTrackerV2 desarrollado en [11], de esta manera, se conservan los componentes que permiten adquirir los datos de los sensores de localizaci´on, redes Wi-Fi, perfil del usuario y calendario. As´ı mismo, permanecen en el sistema el componente encargado de orquestar la toma de datos y los componentes relacionados con la persistencia, envi´o de los datos y el administrador de notificaciones.
Sin embargo, con el objetivo de usar de manera adecuada los recursos del dispositivo se adiciona al sistema un componente que permite la obtenci´on de los datos del aceler´ometro y su procesamiento. Por su parte, se agregan dos componentes que permiten la detecci´on de movimiento y el control del muestreo realizado por el GPS. Finalmente, se elimina el sensor de procesos del sistema pues no brinda informaci´on relevante para MINT.
La figura 7 muestra las relaciones entre los principales elementos de la etapa de recolecci´on de datos.
Figura 7: Sistema de recolecci´on de datos.
Adicionalmente, para mayor claridad a continuaci´on se presenta en la descripci´on de los sensores usados y el tipo de mediciones que se obtienen de estos.
Aceler´ometro:Mide la aceleraci´on aplicada al dispositivo en todos los ejes, de esta manera, las mediciones de este sensor corresponden a la aceleraci´on en el ejex,y yz en un momento dado.
Calendario: Permite obtener los datos de eventos en el calendario del dispositivo m´ovil, en particular, es posible conocer el t´ıtulo, fecha de inicio y fin del evento, asi como su descripci´on y duraci´on.
GPS: Permite conocer la latitud, longitud y altitud del dispositivo m´ovil. Adicionalmente, es posible conocer qu´e tan precisa es ´esta medida. Es importante se˜nalar que el API de Android para consumir datos del GPS permite tambi´en conocer cu´al es la velocidad del dispositivo de acuerdo con las mediciones de GPS
realizadas. La anterior caracter´ıstica ser´a usada para determinar si el dispositivo est´a en movimiento.
Perfil del usuario:El perfil de recepci´on de llamadas que el usuario posee actualmente. El valor medido corresponde a una cadena de caracteres que indica el perfil en el cual se encuentra el usuario.
Redes Wi-Fi:Permite obtener una lista de las redes WiFi detectadas por el dispositivo m´ovil, adem´as, para cada red se posee la direcci´on del access point, el nombre de la red y si el dispositivo est´a conectado o no a dicha red.
A continuaci´on se explicar´an los elementos adicionados para la recolecci´on de los datos.
4.2.1. Procesamiento del aceler´ometro
El aceler´ometro es un sensor que permite identificar r´apidamente si un usuario est´a o no en movimiento ya que mide la fuerza de aceleraci´on sobre el dispositivo y, por lo tanto, se ve afectado por cualquier acci´on que el usuario ejecute con este. Adem´as, este sensor tiene como principal ventaja que su lectura gasta poca bater´ıa en los dispositivos m´oviles, por lo cual su uso es pertinente para establecer si un usuario se encuentra o no en movimiento.
Sin embargo, el procesamiento de los datos del aceler´ometro puede ser complicado, ya que por cada muestra se obtiene un arreglo multidimensional de la fuerza de aceleraci´on para cada uno de los ejes, por lo que es necesario implementar estrategias de an´alisis de la informaci´on que unifiquen los datos de los diferentes ejes. Por otro lado, el aceler´ometro es un sensor bastante sensible, en particular, dos muestras consecutivas pueden tener valores bastante diferentes, causando que sea incorrecto tomar una decisi´on basada ´unicamente en una muestra. Adicionalmente, la velocidad de muestreo es dependiente del dispositivo m´ovil y puede tomar valores desde milisegundos hasta centenas de milisegundos, por lo que se pueden obtener muchos datos en un corto tiempo. Las anteriores problem´aticas se observan m´as claramente en la figura 8 en la cual se presentan 5 muestras consecutivas del aceler´ometro en cada uno de los ejes para un dispositivo quieto, donde la diferencia temporal entre la primera muestra y la quinta muestra tomada es menor a un segundo.
Figura 8: Muestras del aceler´ometro para un dispositivo est´atico
La figura 8 permite observar claramente que para un eje dos muestras consecutivas pueden tener cambios significativos de valores; adem´as, una misma muestra puede presentar valores distintos en diferentes ejes. En particular, se debe resaltar la diferencia entre la fuerza de gravedad para los ejes x, y y, que se encuentran entre 0.1 y 0.25, y los valores obtenidos para el ejez que oscilan en 9.8, lo cual es efecto de la gravedad.
A partir de estas observaciones se decide como primera estrategia de an´alisis trabajar sobre ventanas de datos del aceler´ometro, de esta manera, se analiza el comportamiento de un grupo de datos a lo largo de
una ventana de tiempo para as´ı poder inferir el comportamiento general durante dicho tiempo.
Por otro lado, se llevaron a cabo diferentes experimentos para encontrar caracter´ısticas diferenciadoras en los datos del aceler´ometro para un dispositivo en movimiento (en diferentes posiciones) con respecto a uno quieto. Los resultados permitieron concluir que siempre que un eje est´a en movimiento hay un aumento en el promedio de la fuerza aceleraci´on sobre dicho eje, sin embargo, este aumento depende del movimiento que se est´e realizando y del dispositivo con el cual se est´a trabajando. Adem´as, los experimentos permitieron concluir que los movimientos usuales de desplazamiento de una persona (una persona desplaz´andose con el m´ovil en la mano o en un bolsillo) suelen ´unicamente causar un aumento en el promedio de la fuerza de aceleraci´on en dos de los tres ejes dados por el aceler´ometro, pues el tercer eje suele ser afectado ´unicamente por la gravedad. Las anteriores conclusiones se pueden observar claramente en la figura 9, en la cual se comparan las mediciones en cada uno de los ejes para un dispositivo en movimiento (dentro del bolsillo de alguien) y un dispositivo quieto sobre una mesa durante alrededor de 5 minutos.
(a) Mediciones para un m´ovil quieto sobre una mesa con la pantalla hacia arriba.
(b) Mediciones para un m´ovil en el bolsillo de una persona mientras esta camina.
Figura 9: Mediciones del aceler´ometro para diferentes movimientos
Los experimentos realizados tambi´en permitieron establecer movimientos anormales que no brindan informaci´on relevante sobre si el dispositivo m´ovil se est´a desplazando o no, un ejemplo se observa en la figura 9. Los movimientos anormales se identifican cuando en muestras cercanas se presenta el efecto de la gravedad en diferentes ejes, es decir, inicialmente en algunas muestras el eje z presenta la fuerza de la gravedad, y posteriormente el ejey la presenta durante otras muestras. Estos movimientos usualmente est´an asociados con cambios abruptos de la posici´on del dispositivo, como cuando el usuario saca su m´ovil del bolsillo para leer una notificaci´on.
Las conclusiones obtenidas por los experimentos permitieron establecer la aproximaci´on a la identificaci´on de movimiento a partir de una ventana de datos del aceler´ometro. Inicialmente se busca el eje en el cual se est´a aplicando la fuerza de la gravedad en cada muestra de la ventana, si se encuentra que durante la ventana existen muchas muestras con diferentes ejes en los que se presentan la gravedad, entonces se elimina la ventana por estar asociada con un movimiento anormal. De lo contrario, se realiza un promedio
de las muestras en cada uno de los ejes en los cuales no se presenta la fuerza de la gravedad, pues como fue observado, estos presentan un aumento en su promedio si el dispositivo se encuentra en movimiento. Finalmente, se compara el promedio en cada uno de los ejes con un valor, el cual es altamente dependiente del dispositivo m´ovil y, de ser superior a ese valor s asume que hay una aceleraci´on en este eje.
La figura 10 presenta el flujo realizado para procesar el aceler´ometro. Adicionalmente, a continuaci´on se realizara una descripci´on del proceso.
Inicialmente (1) se tomann muestras consecutivas y se analizan para poder establecer el movimiento del usuario. El valor den tiene una gran importancia en el proceso ya que debe ser lo suficientemente grande para determinar un patr´on dentro de la ventana, pero lo suficientemente peque˜no como para que el sistema pueda reaccionar r´apidamente si el usuario se mueve.
Posterior a la divisi´on en ventanas, en (2) se ejecuta un filtro pasa bajas sobre sobre cada muestra de cada ventana con el objetivo de conocer la fuerza de gravedad en cada eje. Esto es realizado por medio de un promedio de las muestras de la entrada, que suprime cualquier variaci´on de los datos, permitiendo obtener la fuerza de gravedad [18][19]. Este filtro tiene un par´ametro correspondiente aαque permite establecer qu´e tanto efecto tienen las mediciones pasadas en el valor actual de la gravedad.
La f´ormula asociada con el filtro para establecer la gravedad en un ejeeluego dekmuestras es,
gravedade,k=α∗gravedade,k−1+ (1−α)∗aceleracione,k (1)
Dondegravedade,kes la gravedad sobre el ejeepara la muestra n´umerok, yaceleracione,k es la medida de
la fuerza de aceleraci´on n´umerok sobre el ejee.
A continuaci´on, en (3) se usa la fuerza de gravedad calculada en cada eje para identificar en qu´e direcci´on (x,y oz) se encuentra la fuerza de la gravedad en cada muestra. De manera espec´ıfica, el eje para el cual el valor absoluto de la gravedad sea superior a 6m/s2, es aquel que se considera como que est´a siendo afectado
por la gravedad.
Posteriormente, en (4) se eval´ua si al menos un 20 % de las muestras dentro de la ventana presentan la fuerza de la gravedad en diferentes direcciones. De cumplirse esta condici´on, la ventana es descartada ya que se considera que el dispositivo m´ovil se est´a movimiento en muchos ejes, lo cual es un comportamiento abrupto de una persona jugando o movi´endose de manera anormal y no corresponde con el comportamiento normal de una persona desplaz´andose por la ciudad.
Finalmente, por cada ventana se calcula un promedio de todos los valores de aceleraci´on en todos los ejes para aquellas muestras que tengan la direcci´on de la fuerza de la gravedad m´as com´un dentro de la ventana. Posteriormente, el promedio se compara con un valorthreshold y, de ser superior, se puede considerar que el dispositivo est´a en movimiento. De esta manera, el detector de movimiento recibe un valor booleano por cada ventana de datos v´alida que indica si hay o no movimiento.
4.2.2. Detecci´on de Movimiento
El elemento de detecci´on de movimiento recibe como entradas los datos procesados del aceler´ometro, las redes WiFi disponibles y la velocidad del dispositivo calculada por el GPS. A partir de estos valores y de los datos previamente obtenidos, genera una suma ponderada de la probabilidad de que el dispositivo est´e en movimiento dada por cada sensor. Finalmente, se considera este valor como la probabilidad de que el dispositivo se encuentre en movimiento. Por lo tanto, la probabilidad de que el dispositivo se encuentre en movimiento se calcula de la siguiente manera,
pM ov=α1∗pM ovacc+α2∗pM ovW iF i+α3∗pM ovGP S (2)
Las probabilidades de movimiento de acuerdo con cada sensor son explicadas a continuaci´on.
La probabilidad de que el dispositivo se est´e moviendo de acuerdo con el aceler´ometro se calcula a partir de los resultados de movimiento de las ´ultimas m ventanas, de esta manera la probabilidad pM ovacc es
movimiento) dividido enm.
SeaM el conjunto con los resultados del aceler´ometro para las ´ultimasmventanas,
pM ovacc=
|{m:m∈M∧m=true}|
|M| (3)
Con respecto a la probabilidad de que el dispositivo est´e en movimiento de acuerdo con las redes WiFi, este valor se determina haciendo una comparaci´on por similitud entre las ´ultimas r listas de redes WiFi observadas, ya que si dos mediciones de WiFi cercanas en tiempo no son similares, es probable que el usuario se haya movido. De esta manera,pM ovW iF icorresponde al n´umero de mediciones que no presenta similitud
con la medici´on WiFi anterior dividido enr.
Sea R el conjunto con los resultados de las ´ultimasrredes WiFi observadas y seasim(ri, rj) la funci´on
que evalua la similitud de dos listas de redesri, rj, donde la funci´on retorna un valor booleano true si las
dos listas de redes son similares, es decir, si hay una diferencia de menos de k redes en sus listas; por el contrario, si la anterior condici´on no se cumple la funci´onsim(ri, rj) retorna false.
pM ovW iF i=
|{ri−1, ri:ri−1∈R∧ri∈R∧sim(ri−1, ri) =f alse}|
|M| (4)
Finalmente, el c´alculo de la probabilidad de que el dispositivo est´e en movimiento de acuerdo con las mediciones del GPS se realiza haciendo un promedio de las ´ultimass estimaciones de velocidad del GPS y estableciendo que siempre que la velocidad de dicho promedio sea superior a lostkm/hentonces se asume que el usuario est´a en movimiento. Por lo tanto, pM ovGP S tiene dos valores posibles correspondientes a 0
cuando el promedio calculado es menor atkm/hy 1 de lo contrario.
4.2.3. Control del muestreo GPS
La inclusi´on del elemento de detecci´on de movimiento permite implementar una pol´ıtica de obtenci´on de datos del GPS de acuerdo con los movimientos del usuario. De manera espec´ıfica, se usa el algoritmo de backoff exponencial el cual disminuye la frecuencia de las mediciones cada vez que se detecta que el usuario est´a quieto, dicho de otra manera, se aumenta el tiempo entre peticiones al GPS para evitar mediciones innecesarias.
La f´ormula utilizada se presenta en 5, donde c corresponde al n´umero de veces que el componente Detector de movimiento ha detectado que el usuario est´a quieto. Es importante se˜nalar que el valor de c se reinicia cada vez que el usuario se encuentra nuevamente en movimiento.
tiempoM uestreo(c) =1 2 ∗(2
c−1) (5)
Adem´as, en la pol´ıtica de obtenci´on de datos se establece un l´ımite inferior y superior de frecuencia de mediciones, para que a´un con el usuario completamente quieto se realice m´ınimo una medici´on cada media hora y de estar el usuario en constante movimiento, una medici´on cada medio minuto, ya que se consideran tiempos pertinentes para realizar un seguimiento adecuado del usuario. Es importante se˜nalar que esta pol´ıtica de obtenci´on de datos del GPS fue planteada en [10], aunque su implementaci´on no se llev´o a cabo en ese proyecto.
Para terminar esta etapa, en la siguiente tabla se presenta un resumen de los par´ametros que es necesario establecer para el funcionamiento del componente de recolecci´on de datos,
Tabla 2: Par´ametros de la etapa de recolecci´on de datos
Par´ametro Descripci´on
n Tama˜no en n´umero de muestras de una ventana de datos del aceler´ometro threshold Valor con el cual se determina si hay una aceleraci´on
m N´umero de ventanas que se comparan con el valor actual del aceler´ometro
r N´umero de listas de redes que se comparan con la lista actual de redes detectadas
k N´umero de redes de diferencia entre dos listas para que estas se consideren no similares
t Velocidad en km/h que permite determinar si un usuario se est´a movimiento
s N´umero de mediciones de la velocidad GPS que se comparan con la medici´on actual para determinar si un usuario est´a en movimiento
α1 Peso de las mediciones del aceler´ometro al determinar si el usuario est´a o no
en movimiento
α2 Peso de las mediciones de red al determinar si el usuario est´a o no en movimiento
α3 Peso de las mediciones del GPS al determinar si el usuario est´a o no en
movimiento
4.3.
Limpieza de datos
Este componente recibe como entradas los datos de los sensores, los cuales son limpiados y procesados para obtener un modelo del historial de desplazamientos del usuario en t´erminos de dos objetos: trayectorias y lugares visitados. Un diagrama general del sistema de limpieza se presenta en la figura 11.
Figura 11: Sistema de limpieza.
A continuaci´on se realizar´a una definici´on formal de estos objetos para posteriormente explicar los diferentes componentes de la etapa de limpieza.
Trayectoria
Se define una trayectoria como una serie de puntos P = (p1, p2, . . . , pn−1, pn) donde se asume que cada
punto posee tres atributos: latitud, longitud y una fecha. Adicionalmente, se deben cumplir las siguientes condiciones para que esta serie de puntos sea considerado una trayectoria,
pi+1.f echa > pi.f echa, para∀pi∈P (6)
Por otro lado, una trayectoria tiene asociados aquellos lugares visitados por el usuario que hacen parte de ella. En la figura 12a se presenta una trayectoria.
(a) Una trayectoria (b) Un lugar visitado
Figura 12: Gr´afico de una trayectoria y un lugar visitado
Lugar Visitado
Un lugar visitado es una regi´on en la cual el usuario se ha quedado durante un intervalo de tiempo espec´ıfico. De esta manera, corresponde a una serie de puntos consecutivos cercanos en espacio y en tiempo cumpliendo las siguientes caracter´ısticas,
Dados una serie de puntos consecutivosP = (pm, pm−1, . . . , pn−1, pn)
Distancia(pm, pi)6Dl, para∀pi∈P, m < i6n (8)
|pn.f echa−pm.f echa|>Tl, para∀pi∈P, m < i6n (9)
Un lugar visitado posee como atributos una latitud y longitud, correspondientes al promedio de los valores de los puntos consecutivos que define dicho lugar; adem´as, tambi´en se caracteriza por la hora de entrada y salida, el d´ıa de la semana en el que fue visitado, la cantidad de veces que ha sido visitado y la fecha de la ´
ultima visita. Por otro lado, posee dos atributos opcionales si estos se encuentran disponibles, estos son un evento de calendario asociado y una lista de redes detectadas por el dispositivo m´ovil desde el lugar visitado.
La anterior aproximaci´on para obtener un modelo del historial de desplazamiento del usuario es bastante sencilla e intuitiva, sin embargo, modelos similares ya han sido usados en otras investigaciones tales como [20] y [21], probando que es una representaci´on adecuada del problema.
4.3.1. Detecci´on de trayectorias y lugares visitados
Este componente realiza la extracci´on de las trayectorias y los lugares visitados de los datos de GPS, para ello se recorre cada uno de los datos de la trama buscando puntos sucesivos que cumplan las ecuaciones 6 y 7 para trayectorias, o bien las ecuaciones 8 y 9, para encontrar lugares visitados.
Adicionalmente, a medida que se recorren los datos del GPS se buscan aquellos puntos que presentan diferencias temporales menores a cierto valor t y diferencias espaciales superiores a un cierto valorDt con
respecto a la medici´on anterior, estos datos suelen verse como el punto p4 de la figura 13. Se asume que estos puntos son errores por ser desplazamientos grandes en corto tiempo, lo cual es un comportamiento anormal que no suele corresponder con la realidad sino es causado por errores del GPS al realizar la medici´on. Por lo tanto, estos puntos son eliminados de las trayectorias.
Figura 13: Ejemplo de trayectoria con una medici´on anormal
4.3.2. Filtro de trayectorias
Este componente elimina trayectorias que son poco informativas para la comunidad, ya que se encontr´o que suele ser muy com´un obtener trayectorias cortas o con un ´area muy peque˜na (trayectorias tipo ovillo), como las mostradas en la figura 14. Estas trayectorias no ofrecen informaci´on para la comunidad pues son muy cortas, sin embargo se descartan en este punto pues son ´utiles para calcular los lugares relevantes de un usuario, ya que es probable que est´en asociadas al lugar de trabajo o vivienda de la persona.
(a) (b)
(c) (d)
Figura 14: Ejemplos de trayectorias filtradas
Por lo tanto, se filtran aquellas trayectorias que tengan un n´umero de puntos menores a un par´ametron
o cuya ´area sea menor aa.
4.3.3. Detecci´on de lugares visitados
Este componente se encarga de generar lugares visitados para los eventos del calendario, pues se asume que estos siempre corresponder´an a un lugar visitado, aunque no se posea informaci´on espacial asociada a estos. Posteriormente, en la etapa de unificaci´on se buscara enriquecer estos lugares visitados con informaci´on del GPS o de las redes WiFi.
4.3.4. Unificaci´on y enriquecimiento
Finalmente, en este componente se realiza una b´usqueda temporal por los lugares visitados identificados por el GPS para establecer si el tiempo en el cual el usuario permaneci´o en alg´un lugar corresponde tambi´en con alg´un evento o una lista de redes WiFi identificadas. Es decir, se buscan aquellos eventos en el calendario y datos de redes que sean similares temporalmente a los lugares visitados encontrados en la trama del GPS, donde la similitud temporal se da cuando la diferencia entre los tiempos de inicio o fin entre el lugar visitado y el evento o la medici´on de redes es menor a Tl. Lo anterior permite enriquecer los lugares con datos
adicionales para as´ı poder evaluar a partir de un mayor n´umero de variables si el usuario se encuentra o no en uno de estos lugares.
Las trayectorias y lugares visitados obtenidos en esta etapa de procesamiento conformaran un modelo del desplazamiento del usuario que permitir´a inferir informaci´on sobre este, como sus h´abitos, as´ı como generar recomendaciones relevantes para este.
Es importante se˜nalar que el anterior proceso es iterativo, es decir, constantemente se est´an analizando los datos de GPS, redes WiFi y calendario para construir el modelo de la historia de los desplazamientos del usuario.
Al igual que en la secci´on anterior, la tabla 3 presenta los par´ametros que hacen parte de esta etapa.
Tabla 3: Par´ametros de la etapa de limpieza
Par´ametro Descripci´on
4T M´axima diferencia temporal entre dos mediciones sucesivas GPS para ser considerados parte de la misma trayectoria
Tl M´ınima diferencia temporal entre mediciones GPS para ser considerados parte
de un lugar visitado
Dl M´axima diferencia espacial entre dos mediciones GPS para ser considerados
parte de un lugar visitado
Tt M´ınima diferencia temporal entre dos mediciones GPS sucesivas
Dt M´ınima diferencia espacial entre dos mediciones GPS sucesivas
n N´umero m´ınimo de puntos de localizaci´on que debe contener una trayectoria
a Area m´ınima que debe poseer una trayectoria´
4.4.
Procesamiento y an´
alisis
Esta etapa posee dos componentes: en el primero se realizan inferencias sobre la informaci´on del usuario, mientras que el segundo est´a enfocado en utilizar la informaci´on de cada usuario del sistema para generar conocimiento unificado sobre la movilidad y usarlo para beneficio de los mismos usuarios. De esta manera, el primer componente tiene como entradas el modelo de desplazamiento de un usuario obtenido en la etapa de limpieza, y busca establecer a partir de este cual ser´a el pr´oximo lugar a visitar por un usuario; adem´as, en este etapa se desean identificar alertas de tr´afico en la v´ıa en la cual el usuario se encuentra.
Por su parte, el segundo componente recibe como entrada el modelo de desplazamiento de todos los usuarios del sistema as´ı como sus la inferencia del pr´oximo lugar a visitar. A partir de los primeros datos se genera un cl´uster con informaci´on de la movilidad en la ciudad, el cual permite realizar recomendaciones de posibles trayectorias a tomar en caso de que el usuario lo requiera.
Un esquema general de esta etapa se muestra en la figura 15.
4.4.1. Inferencia del pr´oximo lugar
A partir de las condiciones espacio-temporales actuales del usuario se quiere predecir cu´al ser´a el pr´oximo lugar visitado para as´ı dar recomendaciones relevantes a partir de esta informaci´on. El anterior requerimiento se puede observar como un problema en el cual se desea obtener un modeloSque prediga un valor de salida
y a partir de un vector de entradax, dondeycorresponde al pr´oximo lugar a visitar yxson las condiciones espacio-temporales actuales. Este tipo de problemas pueden ser resueltos por t´ecnicas de aprendizaje de
Figura 15: Etapa de procesamiento y an´alisis
m´aquina supervisadas siempre y cuando se posea un conjunto de datos{xi, yi} n
i=1que permitan entrenar un
modelo en este caso se utilizan los datos hist´oricos que se conocen del usuario como el conjunto de datos de entrenamiento.
Figura 16: Modelo de aprendizaje de m´aquina.
La aproximaci´on al problema por medio de t´ecnicas de aprendizaje de m´aquina supervisada requiere adem´as de un conjunto de datos de entrenamiento, una representaci´on apropiada de estos que corresponda a caracter´ısticas ´utiles y diferenciadoras, de tal manera que se pueda obtener un buen modelo con un algoritmo de aprendizaje. De esta manera, se seleccionaron las siguientes caracter´ısticas para representar un dato espacio-temporal del usuario:
- Posici´on geogr´afica - Hora del d´ıa - D´ıa de la semana
- Valor booleano indicando si es d´ıa de fin de semana o no. - Condiciones clim´aticas
Es importante se˜nalar que estas caracter´ısticas deben ser codificadas para que sea posible utilizarlas en un algoritmo de aprendizaje de m´aquina.
Se analizaron diferentes escenarios y se concluy´o que es necesario plantear dos modelos de inferencia para conocer el pr´oximo lugar a visitar, donde estos difieren en la cantidad de informaci´on espacio-temporal que se posea. Por lo tanto, se plantea un modelo sin memoria y un modelo con memoria.
El primer modelo, correspondiente al generado sin memoria, usa ´unicamente un dato espacio-temporal del usuario para realizar la predicci´on; este modelo es relevante en aquellos casos en los cuales no se ha podido hacer un seguimiento de la movilidad del usuario (sea porque este apag´o los sensores o porque estos no estaban disponibles en el ´area en la que ´este se encontraba), por lo cual, ´unicamente se pose un dato de la posici´on actual del usuario y se desea realizar una predicci´on a partir de dicha informaci´on. De esta manera, es posible tratar el problema de predecir el siguiente lugar como un problema de clasificaci´on, en el cual se quiere clasificar el pr´oximo lugar al que ir´a el usuario en alguno de los lugares visitados definidos por sus datos hist´oricos. Por lo tanto, se seleccionan como algoritmos apropiados para resolver este problema: Naive Bayes y Random Tree Forest.
El segundo modelo tiene memoria, es decir, los datos a partir de los cuales genera la predicci´on corresponde a la trayectoria desde el ´ultimo lugar que el usuario ha visitado. Al igual que en el anterior modelo, este problema se puede considerar como la clasificaci´on del pr´oximo lugar en alguno de los lugares que el usuario ha visitado previamente, sin embargo, a diferencia del modelo anterior, en este caso se posee m´as informaci´on sobre el contexto en el cual se encuentra el usuario. De manera m´as espec´ıfica, al tener una trayectoria del usuario es posible establecer si esta es similar a alguna trayectoria ya recorrida antes, por lo cual ser´ıa posible establecer con una mayor confianza el pr´oximo lugar a visitar. Se seleccionaron como algoritmos apropiados para resolver este problema: Modelo de Markov Escondido y una red din´amica bayesiana.
4.4.2. Identificaci´on de tr´afico
Esta etapa tiene como entrada el modelo de desplazamiento del usuario, en este se busca la trayectoria actual o m´as reciente que se posea, pues a trav´es de an´alisis sobre esta es posible obtener la velocidad promedio y establecer si existe un tranc´on o no, lo cual permite generar alertas en tiempo real relevantes para aquellos usuarios que tomen estas v´ıas.
Adicionalmente, a partir de los datos recientes de movilidad tambi´en se podr´ıan identificar comportamientos anormales en la ciudad, tales como manifestaciones y accidentes, sin embargo, este tipo de alertas requerir´ıan conocer los comportamientos usuales en las diferentes v´ıas para as´ı poder identificar un comportamiento anormal, lo cual requiere estudios adicionales por lo que no se tienen en cuenta en MINT.
Los datos de movilidad usados para identificar las caracter´ısticas de tr´afico anteriormente mencionadas deben ser parte de una trayectoria, adem´as, deben tener un m´ınimo de puntos k y un ´area superior a a. Las anteriores caracter´ısticas permiten seleccionar trayectorias relevantes, y eliminar aquellas corresponden a usuarios caminando en sus casas o en otros lugares.
Con respecto a la velocidad promedio de la trayectoria se calcula como la diferencia en distancia y tiempo del punto inicial de la trayectoria y el punto mas reciente de esta.
Por su parte, para establecer si hay tranc´on en una v´ıa se realiza un an´alisis de la trayectoria buscando “puntos tranc´on”, estos se definen de manera similar a los lugares visitados por un usuario, con la diferencia principal de que poseen un distancia m´ınima de menor tama˜no que los lugares visitados. Por lo tanto, dados una serie de puntos consecutivosP = (pm, pm−1, . . . , pn−1, pn), se tiene un punto tranc´on si
Distancia(pm, pi)6Dt, para∀pi ∈P, m < i6n (10)
|pn.f echa−pm.f echa|>Tt, para∀pi∈P, m < i6n (11)
De esta manera, si se encuentran varios “puntos tranc´on” consecutivos con una diferencia temporal menor a T minutos entre ellos se considera que hay un tranc´on en estos puntos de la trayectoria. Esta heur´ıstica permite identificar los trancones en los cuales un usuario se mueve lentamente a lo largo de una trayectoria.
Figura 17: Ejemplo de una trayectoria con tranc´on
4.4.3. Generaci´on del cl´uster
Los datos hist´oricos de desplazamiento de los usuarios pueden ser valiosos para una comunidad en la medida en que diferentes personas pueden tener lugares visitados en com´un, de ser as´ı, es posible que compartan o no trayectorias de llegada a dichos lugares; en el caso en que efectivamente compartan una trayectoria, estos usuarios pueden dar informaci´on relevante sobre el estado de tr´afico de dicha trayectoria, lo cual puede ser usado para generar alertas. Por su parte, en el caso en el cual dos usuarios visiten un mismo lugar con trayectorias diferentes es posible usar dichas trayectorias como alternativas para llegar a dicho lugar en casos especiales.
Por lo tanto, se observa que para la miner´ıa de la informaci´on de desplazamiento es relevante generar una estructura que permita relacionar f´acilmente los diferentes lugares que los usuarios visitan y las relaciones en t´erminos de trayectorias entre estos. De esta manera, se realiza un cl´uster de lugares relevantes similares en condiciones espacio-temporales, y posteriormente, a partir de los cl´usters generados se forma un grafo dirigido donde cada arco corresponde a una trayectoria entre alguno de lugares que hace parte del cl´uster origen y alguno de los lugares que parte del cluster destino. Finalmente, se genera un ´ındice espacial que mejora el desempe˜no de operaciones de acceso a la informaci´on del grafo. El proceso descrito se presenta en la figura 18.
Figura 18: Proceso realizado para obtener una estructura con los lugares relevantes y las trayectorias.
Inicialmente se tienen los lugares visitados por los diferentes usuarios, a partir de estos se generan los clusters, posteriormente se realiza un grafo y finalmente, se realiza un ´ındice espacial.
Los clusters son realizados por medio del algoritmo de clustering basado en densidad DBSCAN (Density-Based Spatial Clustering of Applications with Noise), este es una especificaci´on del algoritmo OPTICS (Ordering points to identify the clustering structure), el cual ha sido ampliamente usado para generar clusters espaciales, tal y como se observa en [20] y [21]. Entre las principales razones para usar dicho algoritmo est´an que este no requiere un conocimiento previo del n´umero de clusters que se deben generar y que permite identificar clusters de tama˜no irregular e ignorar puntos dispersos, pues son considerados como ruido.
estos consisten en objetos que deben contener un n´umero m´ınimo de objetos (M inP ts) en una vecindad de tama˜noε. De esta manera, los principales par´ametros del algoritmo corresponden a M inP tsyε.
A continuaci´on se presentaran las principales definiciones en las cuales se fundamenta el algoritmo DBSCAN. Posteriormente, se realizar´a una explicaci´on de este.
Objeto central (Core Object)
Es un objeto en cuya vecindad de tama˜noεhay al menosM inP tsobjetos [24]. SeaD el conjunto de todos los objetos.
SeaNε(q) el subconjunto deDque contiene laε-vecindad de q.
Entonces, q es un objeto central si,
Nε(q)≥M inP ts (12)
Objeto directamente alcanzable por densidad (Directly Density Reachable)
Un objeto pes directamente alcanzable por densidad por un objetoq si pertenece a su vecindad yqes un objeto central.
Es decir, se deben cumplir las siguientes ecuaciones [24],
p∈Nε(q) (13)
Nε(q)≥M inP ts (14)
Objeto alcanzable por densidad (Density Reachable)
Un objetopes alcanzable por densidad por un objetoqsi hay una serie de objetosp1, ..., pn∈D donde
p1 =p, tal que se cumple que todopi+1 es directamente alcanzable por densidad porpi [24].
Objetos conectados por densidad (Density Connected)
Un objeto pest´a conectado por densidad con un objeto qsi existe un objeto o ∈D que sea alcanzable por densidad por p y q [24]. La principal diferencia de la anterior relaci´on con la definici´on de alcanzable por densidad yace en que la relaci´on conectados por densidad es sim´etrica; mientras que alcanzables por densidad no lo es, ya que para serlo requerir´ıa necesariamente que tantoq comopsean objetos centrales, y esta es una condici´on que no siempre se cumple.
Los conceptos anteriores se presentan gr´aficamente en la figura 19.
Por lo tanto, el algoritmo DBSCAN busca formar clusters que consistan en conjuntos de objetos que est´en mutuamente conectados por densidad y donde se encuentren todos los objetos que pueden ser alcanzados por densidad desde cualquier objeto central que se encuentre en el cluster.
Con respecto al funcionamiento de DBSCAN, inicialmente se poseen todos los objetos que se desean agrupar sin procesar, para cada uno de estos objetos se buscan sus vecinos y se verifica si se posee un objeto central de acuerdo a los valores de ´epsilon y MinPts seleccionados. Si se encuentra un objeto central, se marca como procesado y se agregan sus vecinos a una lista para expandir el cluster. El proceso de expansi´on del cluster consiste en recorrer la lista generada y agregar cada objeto al cluster si este no pertenece a ning´un otro cluster. Adem´as, se verifica si el objeto corresponde a un objeto central, y de ser as´ı se agregan sus vecinos a la lista que se est´a recorriendo. El anterior proceso se ejecuta hasta que todos los objetos han sido procesados [24].
Relevancia de una alerta y recomendaci´on de trayectorias
A partir de una alerta asociada con una trayectoria es posible usar el cluster para identificar los usuarios para los cuales es relevante la alerta, as´ı como para generar recomendaciones de trayectorias alternativas.
