Fehér, Gábor

Lajtha, Balázs

Nagy, Ádám Zsolt

Szincsák, Tamás

EKE Repository of Publications

User activity recognition on mobile clientsfor Smart Public Transport Services∗Ádám Zsolt Nagyab, Gábor FehérabBalázs Lajthaab, Tamás SzincsákbaBudapest University of Technology and EconomicsDepartment of Telecommunication and Media Informaticsfeher@tmit.bme.hu, adam.zsolt.nagy@gmail.comlajtha.balazs@tmit.bme.hubInter-University Centre for Telecommunications and Informaticssztamas89@gmail.comAbstractIn the field of smart city mobile applications based on crowdsourced data,the automation of the data collection process is a substantial requirement.Continuous user interaction can not be expected and feedback heavy solu-tions can discourage the masses from participating. Luckily, the currentlyavailable mobile devices already carry the sensors we need and large numberof developer tools are at our disposal to overcome this issue. Mobile sensorscan provide two important information we can benefit from: the user’s lo-cation and the user’s activity. On a large scale the sensory data may varydue to the diversity of the devices, thus reassurance from the user and strictsupervision of collected information can not be neglected. Although a greatnumber of solutions already had come to realization regarding user activityrecognition, they usually serve as stand-alone solutions as they are not bindto solve a specific problem. In urban environments these solutions carry agreat potential. In this paper we would like to share our experiences in useractivity recognition, present a sensory module implemented using the latestGoogle API-s for Android platform and how can it function as a valuableasset of a Smart Public Transport Service.Keywords: Smart Cities, Public Transport, Crowdsensing, Participatory Sens-ing, User Activity Recognition∗Held on the hosted workshop: “Workshop on Smart Applications for Smart Cities”.Proceedings of the1st International Conference and Exhibition on Future RFID TechnologiesEszterhazy Karoly University of Applied Sciences andBay Zoltán Nonprofit Ltd. for Applied ResearchEger, Hungary, November 5–7, 2014. pp. 135–142doi: 10.17048/FutureRFID.1.2014.1351351. IntroductionIn the era of Internet of Things, the penetration of crowd-sourcing applicationsis increasing. The spread of wearable computing devices open new horizons inthe field of pervasive computing. Crowdsourcing systems offer new solutions toproblems that otherwise would be resolved by building costly infrastructure or bydeployment of information systems. That is the reason why crowd-sourcing playsan important role in Smart City applications. Building on the power of the crowdextends our possibilities. Through smartphones, citizens can contribute to thesystem thus shape their urban environment. It is a win-win situation for both theurbanites and the city administration[7]. For instance, in public transportation,dynamic timetables, schedule informations, live transit informations, user-reviews,status informations could extend the basic service purely based on participatorysensing (mobile sensing), while the transport agency receives valuable feedbacksand information for the further improvement of the system.Such a Smart City transportation service intends to collect information throughsmartphones used as data-collecting agents. Due to the advancements in the mobileindustry, today’s devices carry a variety of sensors ranging from position- to severaltypes of environment sensors. As smartphones became commonly used accessoriesthat no ones likes to leave at home, they can provide precious sensory informationreflecting traffic conditions. The user’s position, acceleration and speed can onlybe put to good use if we are also aware of the context: we can connect our mea-surements to specific traffic events. Such context can be obtained automaticallyby recognizing the user’s current activity: user is on foot, user is not moving, useris in a vehicle, etc. We would like to show that evaluating the chain of detectedactivities, major traffic events such as stops can be recognized.In mobile environment this process must be done in an energy-efficient waythrough the analysation of movement patterns and acceleration data. Several re-searches already have been conducted on this subject with promising results[6, 5, 8].However, they mostly put the emphasis on the recognition process itself. Our studyfocuses more on practical approaches and the building-in of the results. Instead ofanalysing raw acceleration data we started to work on our solution using existingdeveloper API-s for Android platform upon which we developed our own sensorymodule. This module is created to fit our social public transport information sys-tem, responsible for the recognition of user activity and the gathering of othersensory information. The main goal of this service is to create a city’s completetransit timetable based on user feedbacks.The rest of the paper is structured as follows. In the first section we presentthe architecture of our proposed Smart Public Transport Service. It is followed byour implementation of the sensory module, finally by the procession of user contextinformation on server side.136 Á. Zs. Nagy, G. Fehér, B. Lajtha, T. Szincsák2. The architecture of the Smart Public TransportServiceThe scheme of aforementioned service can be found on Figure 1. It consists ofa server side and client applications (TrafficSense) running on smartphones. Wefocus on the role of this client application which is responsible for gathering contextinformation from the user. Gathered data is then written into simple text files incsv (comma separated values) format, finally, these logs are sent to the server forevaluation.Client Application - TrafficSenseClient application logicSensory module Local data storage-Log file- Local databaseServer sideUnprocesseddata storageServer sidelogicProcesseddatastorageSyncExtended serviceContextUserFigure 1: Scheme of our proposed Smart Public Transport Service3. TrafficSense3.1. Acquisition of user activity dataIn order to exploit available best practices, the sensory module has been createdusing Activity Recognition API and Location API included in the GooglePlaySer-vices library[3]. As it provides the input upon which the detection logic is built,it’s purpose is to collect all the related sensory information available on the user’sdevice. Upon further investigation of technical constraints and possibilities pro-vided by the API-s, we concluded that the following attributes are valuable forautomatic detection of traffic events: the user’s physical activity, user’s locationand the detection of a significant motion.Recognized user activity is the most precious information we can acquire throughthe sensors. The best and most energy efficient approach to do this is to analyseUser activity recognition on mobile clients for Smart Public Transport Services 137acceleration data. However, with the User Activity Recognition API evaluationof raw sensor data is not necessary because processed results are sent through aregistered Google client object. The received data object contains the result ofthe evaluation procedure, which is hidden from the developers. The API allowsus to distinguish 8 types of clearly detectable user activities (including “activityunknown” and “user is tilting the phone”), amongst which 4 is in the focus of ourinterest as they are reflecting the movement-activities of a travelling person:• User is walking• User is running• User is in a vehicle• User is still (not moving)In the received result object a set of detected activities are present as they couldalso fit the same movement pattern with a certain probability. To increase theutility of the detected activity events for our service, we break down the results to2 components:• User activity: detected activity with the highest probability• User state: is user moving or not (still or moving?)Determining whether the user is moving or not comes from examining the prob-ability of “user is still” activity in the set of results. As these 2 states exclude eachother, the probability of moving is simply calculated 1 − Pstill. Certain trafficevents can be evaluated relying only on this chunk of information. As shown inanother section of this document, a great number of physical public transportationstops can be located based only on this attribute.Paired with geolocation data, the phases of a travelling session can be observedand tracked on a map, for example: the user is walking, then stops, gets in avehicle, then multiple stop/in vehicle events change one another, then user startsto walk etc.. This way, user activities are bonded to physical locations making itcapable to detect stops, possible trips, line interconnections even real-time trafficinformations. In crowded cities the distances of public transport related eventshappen close to one another thus the confidence of the measured location datashould not exceed a couple of meters in order to be able to separate them. Other-wise, the uncertainty of measured data (detected activities for example) is too bigand can not be accurately pinpointed on the map. Examples for user activitis withdifferent accuracies are presented on Figure 2. GPS is the only location sensor thatcan provide such accuracy, if the connection with the satellites is not disrupted.This issue still persists in heavily urbanized environments because GPS signal getslost too often which is caused by tall buildings or underground travelling. Wifi/cellbased positioning is also used, however their accuracy may vary. Another setbackof always querying the sensor for the best available location (via GPS for example)is the issue of power consumption.138 Á. Zs. Nagy, G. Fehér, B. Lajtha, T. Szincsák(a) Located user activitieswith bad accuracy(b) Located user activities withhigh accuracyFigure 2: Visualized log filesAbove Android level 4.3 a composite sensor called significant motion sensor isavailable[4]. Being a one shot-sensor (trigger), it goes off when the user makes amovement that can lead to a change in the user’s location. It is mostly used forimproving battery life in location based services by turning off sensors during idlestates. However it can be used as a stop detector as well. If a certain amount oftime passes after setting the trigger and it still does not fire off possibly meansthe user is not moving. Most often in this case the mobile phone is away from theuser. This method provides better results for stop detection than the one basedon the Activity API yet we decided not to use this approach in our service. Onthe distribution chart about 35% of the Android operation systems are above 4.3which means most of the users would not be able to participate[1].The way participants use their phones also affects the quality of activity recog-nition. Previous studies already proved that phones held in trouser pockets producemore accurate activity results than phones carried in hand[5, 6, 8]. Most of thetime users only take out their phones to do something actively with it: browsing,chatting, playing, calling etc. Thus we presume that annotating the activity datawith “screen on” and “screen off” events could separate these two cases and give abetter understanding of the results.3.2. Energy consumption of the applicationWe experienced a minor setback in battery life when letting continuously run theclient application in the background. All sensors operate with the highest sam-pling rate, using GPS location whenever it is possible to produce the most accurateresults for baseline measurements. Even if the most recent Android systems im-User activity recognition on mobile clients for Smart Public Transport Services 139plement impressive power saving strategies (turning off sensors when idle, or useris still) battery drainage is still significant. The measured battery life is about 10hours which leads to a very unpleasant user experience. The battery life is depictedon Figure 3. As a solution we automatically tune sensors based on battery levelthresholds.-200204060801001200 2 4 6 8 10 12Battery level [%]Time [h]NormalTrafficSense runningTrafficSense running (regression)Figure 3: The application’s impact on battery life. Tool: Trepnprofiler plugin for Eclipse. Device: Nexus 4, Android 5.0 “Lollipop”4. Procession of activity related data on server sideThe set of activity data that come from users are processed on server side. Asthe continuously sent data contains always just a tiny piece of information on theexamined area, it means they are only worth to be processed batched with otherones. The storage of incoming reports is taking place continuously, while processingonly happens periodically. At the moment we are trying to identify the positionof the stations from the data. For this purpose, the detected user activity is beingused as well as the coordinates and the accuracy of the measurements. The receivedlog files containing the results are annotated with timestamp, however, the recordsare not necessarily written in historical order so they have to be sorted. In orderto detect possible stations/stops, we are looking for transitions in the activity,“activity edges”, which are the following:• transition between still - in vehicle• transition between walking - in vehicle• transition between running - in vehicleThe states or the “user is still” activity itself is not enough because during quicktransfers it may happen that the passenger does not stop at all. As the deter-mination of user location also happens by cell/wifi, in order to prevent distortion140 Á. Zs. Nagy, G. Fehér, B. Lajtha, T. Szincsákof results caused by inaccurate inputs, there is an accuracy limit (which is nowset to 100 meters), above which measurements are discarded. Entries satisfyingthe criteria are put into the database by the following method: the probabilitythat a circle (represented by a center of latitude and longitude and the radius asthe accuracy in meters) marks a station/stop is inversely proportional to its area.These “circles” may overlap each other and the more frequently they occur in aplace, the more certain that those places are real stations or other stop locations(for example: crossroad). In order the system to be reliable, a sufficiently largeuser-base is required, whose daily communal activities cover as much segment ofthe city as possible.The task which is estimated to be the most resource-requiring is the recognitionof the potential stations amongst the collected “station-circles”. In order to decreasethe number of calculations required, we decided to rasterize the area (segment of thecity) which needs to be observed. The raster points are square-shaped in ideal caseand they are big enough so that the error of the procedure is still moving betweenacceptable limits (comparable to the mistake of a good GPS sign). The mappingof coordinates to grid points have been made by EPSG 3857 projection, which isan approximation of the Mercator projection[2]. The zoom level can be adjusted,we set it to 15 based on the tests. The size of the tile is 256×256, according to theindustrial standard. This fulfils our earlier criterion in the territory of Hungary:one grid point is around 3.8× 3.8 meters big. We store two values per grid point:the chance a station can be found at that point (32 bit float), and the number ofmeasurements used to calculate the probability (32 bit integer). In this manner,the size of a tile is exactly 512 kB. One of the main advantage of the solution isthat the area which needs to be processed is not required to be defined in advance,the tiles can be created as needed. Another advantage is that the results can beprojected one-to-one onto any layers of publicly accessible maps (Google Maps,OpenStreetMap, etc.) without doing any additional processing. An example formapping is preneted on Figure 4.Figure 4: Results for a single trip with one transfer. Estimatedlocation of stops (red) compared to the real location of stops (blue)User activity recognition on mobile clients for Smart Public Transport Services 1415. ConclusionWe came to conclusion that the detection of stops and transits is possible, howeverfurther evaluation of results is necessary. The perfect trade-off between acceptablesensor information and low battery consumption is yet to be determined in orderto maximize user experience and increase the everyday-usability of the application.The development of a “reassurance” module is in sight, which actively involvesthe user in the data collection process, thus manual reassurance of events greatlyincrease the detectability of stops or transits. Our client application is alreadypublicly available for download so the collection of real data has begun. For theimplementation of our client we only used tools which are freely available and easy-to-use, demonstrating a very practical approach. As of today, the communicationbetween the server and client only goes one way. We hope that if enough partici-pants contribute and share information, we can provide an unremarkable extendedpublic transport service and create online timetables for any city.AcknowledgmentThe publication was supported by the TAMOP-4.2.2.C-11/1/KONV-2012-0001project.References[1] Android version distribution. https://developer.android.com/about/dashboards/index.html?utm_source=ausdroid.net#Platform. Accessed: 2014-12-06.[2] Epsg 3857. http://spatialreference.org/ref/sr-org/6864/. Accessed: 2014-10-06.[3] Google api-s. https://developer.android.com/google/play-services/location.html. Accessed: 2014-12-06.[4] Significant motion sensor. http://source.android.com/devices/sensors/sensor-types.html#significant_motion. Accessed: 2014-12-06.[5] Ling Bao and Stephen S. Intille. Activity recognition from user-annotated accelerationdata. In Proc. Pervasive (2004), pages 1–17, 2004.[6] Jonathan Lester Tanzeem Choudhury Gaetano Borriello. A practical approach torecognizing physical activities. In Proc. Pervasive 2006, pages 1–16, 2006.[7] R. Szabo K. Farkas M. Ispany A.A. Benczur N. Batfai P. Jeszenszky S. Laki A. VagnerL. Kollar Cs. Sidlo R. Besenczi M. Smajda G. Kover T. Szincsak T. Kadek M. KosaA. Adamko I. Lendak B. Wiandt T. Tomas A. Zs. Nagy G. Feher. Framework forsmart city applications based on participatory sensing. In CogInfoCom 2013, 4thIEEE International Conference on Cognitive Infocommunications, 2013.[8] Jennifer R. Kwapisz Gary M. Weiss Samuel A. Moore. A practical approach to rec-ognizing physical activities. SIGKDD Explorations, 14:74–82, 2010.142 Á. Zs. Nagy, G. Fehér, B. Lajtha, T. Szincsák

User activity recognition on mobile clients for Smart Public Transport Services

http://publikacio.uni-eszterhazy.hu/26/1/FutureRFID.1.2014.135.pdf

User activity recognition on mobile clients for Smart Public Transport Services

Abstract

Similar works

Full text

Available Versions

EKE Repository of Publications