Mlogger: An Automatic Blogging System by Mobile ... - Springer Link

Mlogger: An Automatic Blogging System by Mobile Sensing User Behaviors Jun-Zhao Sun1,2, Jiehan Zhou2, and Timo Pihlajaniemi2 2

1 Academy of Finland, Finland Department of Electrical and Information Engineering, University of Oulu Oulu, Finland {junzhao.sun,jiehan.zhou,tp}@ee.oulu.fi

Abstract. Context-awareness is the leading feature of pervasive computing. Blog is one of the first and key elements in social computing. In the emerging pervasive social computing paradigm, an interesting topic is how to blog with user behaviors automatically associated. In this paper, we present Mlogger, an automatic blogging system that can detect, recognize and track user behaviors and associate them with new blog entries. In the system, Sun SPOTs are used for sensing raw behavioral data. A Mlogger back-end system is designed to process those raw data and infer high-level user behavioral information such as “what the user is doing, and where, when, and with whom?”. Associated with the inferred information, a new entry about user behaviors can be created and published automatically. Keywords: Pervasive social computing, blog, user behavioral information, wireless sensor networks.

1 Introduction Social computing is the collaborative and interactive aspect of online behavior. The term can be understood in contrast to personal computing, which describes the behavior of isolated users. Social computing represents the intersection of social behavior and computational systems. Social computing is closely related to Web 2.0, which is regarded as the framework of applications supporting the processes of social computing. Blogs, among others, is one of the most popular applications of social computing. Other applications include wikis, Twitter, RSS, instant messaging, multiplayer gaming and open source development, as well as social networking and social bookmarking sites. Pervasive computing comes into being and penetrates everyday objects and activities. Context awareness is one important component in pervasive computing. The collection of context information relies heavily on various sensors deployed in physical environments. Recent advances in wireless communications and electronics have enabled the development of low-cost, low-power, multifunctional sensor nodes that are small in size and communicate in short distances by wireless radios. These tiny sensor nodes that consist of sensing, data processing, and communicating components, leverage the idea of sensor networks. Sensor networks represent significant Z. Yu et al. (Eds.): UIC 2010, LNCS 6406, pp. 650–664, 2010. © Springer-Verlag Berlin Heidelberg 2010

Mlogger: An Automatic Blogging System by Mobile Sensing User Behaviors

651

improvement over traditional sensors. The concept of micro-sensing and wireless connection of sensor nodes promises many new application areas e.g. military, environment, health, home, to name a few. Merging social computing and pervasive computing promises a new computing paradigm, pervasive social computing. One joint point studied in this paper is how to automatically add entries to a blog by tracking users’ behaviours. Here, user behavior is the context information, the detection, recognition and tracking of which relies mostly on techniques like various sensor techniques. The relevant user behavioral information is broad, varying from time, location and route to group and activity, and even motion. Existing research in automatic and context-associated blogging focuses on geoblogging [1] that attaches specific geographic location information to blog entries via geotags. Geotagging is the process of adding geographical identification metadata to various media such as photographs, video, websites, or RSS feeds and is a form of geospatial metadata [2]. By searching a list of tagged blogs and pictures, users can select areas of specific interest to them on interactive maps. Along with the combination of GPS Phones and GSM localization, geoblogging has led to the moblogging, where blog entries are tagged with exact position of the user [3]. In addition to geographic location information, there is other contextual information regarding user behaviors that could be explored for blogging. In this paper, we describe Mlogger, an automatic blogging system by mobile sensing the user behavioral information. In Mblogger, we use mobile sensing devices for sensing the user’s daily behaviors. Mlogger analyzes and infers the raw data and automatically generates a new post to the user’s blog. For the purpose of rapidly prototyping, the mobile sensing devices chosen in this paper is Sun SPOTs, an embedded hardware module that is equipped with accelerometer, temperature and light sensors as well as radio communication capacity. The remainder of this paper is organized as follows. Section 2 briefly introduces the Sun SPOTs platform. Section 3 analyzes the requirements and proposes the architecture. Detailed design and implementation of front-end and back-end systems are presented in Section 4 and 5, respectively. Section 6 analyzes related work. Finally, Section 7 concludes the paper.

2 Mlogger Platform The platform for developing Mlogger is Sun SPOT [4], as shown in Fig. 1. Sun SPOT (Sun Small Programmable Object Technology) is an embedded hardware modules developed by Sun Microsystems as an experimental platform for developers to build sensor-based devices and applications. The dimension is only 41x23x70 mm, of 54 grams. The device is equipped with a 180 MHz 32 bit ARM920T CPU, 512K RAM, and 4M Flash memory. It also includes three on-board sensors, accelerometer, temperature and light sensors. It has the USB interface for connecting to a PC. SPOT communicates using 2.4 GHz IEEE 802.15.4 radio with integrated antenna, including the base-station approach for networking. In addition to the free-range Sun SPOTS, there are also basestation Sun SPOTs. The basestation connects to a development machine (e.g. a PC) and allows the developer to write programs that can run

652

J.-Z. Sun, J. Zhou, and T. Pihlajaniemi

on the PC and use the basestation's radio to communicate with remote Sun SPOTs, and also to deploy and debug applications on remote Sun SPOTs. SPOT supports mesh network by using IPv6/LowPan and AODV (Ad-hoc On-demand Distance Vector) protocols for ad hoc multihop networking and routing.

(a) A Sun SPOT

(b) A typical configuration

Fig. 1. Sun SPOT platform and a typical configuration of a multi-hop network

The Sun SPOT is a Java programmable embedded device designed for flexibility. It is programmed almost entirely in Java to allow regular programmers to create projects that used to require specialized embedded system development skills. It is built on the Squawk, an open-source J2ME CLDC 1.1 and MIDP 1.0 capable Java Virtual Machine. Standard Java IDEs (e.g. NetBeans) can be used to create Sun SPOT applications. The development tools also include an Emulator that is capable of running a Sun SPOT application on a PC for testing a program before deploying it to a real SPOT, or if a real SPOT is not available. One of the major design goals of Sun SPOTs was to provide a tool for rapidly prototyping sensor-based applications. There have been a number of projects based on it. We choose it to be the platform of our project mostly because it is able to sense surroundings and easy to program.

3 Mlogger Design Requirements and Architecture A Mlogger scenario we consider in this paper is described as follows. A user brings a free-range Sun SPOT all the time when he is in his daily routine. The SPOT keeps recording, periodically, the surroundings by sensing the environmental data. When the free-range SPOT carried by the user is in the range of a basestation SPOT, the free-range SPOT uploads all the samples to the basestation. The computer is able to analyze the data, to infer the information like what the user was doing, and when, where, how and with whom. The inferred information will be eventually constructed into one post that can be sent to the user’s blog. To realize the above scenario, we need a Mlogger system in the support of sensing and recording raw data involved in the moments of a mobile user, and generating raw data into high-level information about who was doing what, where, when and how.


653

The key functionalities lie in data collection and data processing. The former relates to how the flow of sensing data is sampled, transmitted and stored, while the latter concerns how to analyze and explain the data to obtain high-level information related to user behavior. Other design requirements are on data storage, data illustration, new blog post creation and publishing, setting capacities, performance, etc. We propose the Mlogger architecture illustrated in Fig. 2. As shown in the figure, the system consists of three parts: SPOTs, host PC, and blog server. SPOTs connect to host PC via wireless network, through basestation SPOT that is connected to the host PC by USB cable. The host PC has connection to the Internet, so that new posts can be uploaded to a particular blog site specified by the user.

Fig. 2. Mlogger Architecture Overview

The core module inside SPOTs is the data monitor. It keeps sensing the surroundings by using the equipped sensors according to the sampling setting parameters like sample rate and duration. As the SPOT is moving with the user, the basestation SPOT is not always available in range. Therefore, data samples as well as the corresponding time stamp need to be first stored to the local Flash memory, and later sent to the host PC when the basestation is available. The architecture allows multiple SPOTs to share one host PC. In this case, each SPOTs is recognized to be one user. Consequently, the sampling data in SPOT is transmitted to the host PC in a stream, which is organized into tables and stored into a database. The sensing parameters can be read and set by the user with a sampling settings interface. Data stored in the database can be retrieved with various conditions by the user. Two common ways of data access are snapshot query and time-based query. The snapshot query returns all the data fields for a given time point, while time-based query shows a specific attribute changing over a time interval. Raw sensing data is not the purpose. Instead, what really of interest is the information about user’s activities. The host PC is responsible for processing the raw data by using a data processing module, for analyzing the data stored in the database, detecting special events, and recognizing user’s behavior. Advanced algorithms are needed

654


for the analysis, event detection and behavior recognition. After behavior recognition, the user can interact with the blog server for updating and publishing a new post to his blog. Publishing a new post to a blog site is straightforward, since most blog service provider provides simple protocol and data API for making new posts. The Mlogger system can be easily divided into two parts: • The front-end software is to operate on free-range SPOTs to sample data and send to the basestations. • The back-end software is to operate on host PC to collect and store data, show and analyze data, and create and publish new posts to user’s blog. The two parts of software communicate with each other for sending/receiving sensor data as well as new settings. The following two sections describes the software design of the two parts.

4 Front-End Design and Implementation of Mlogger The main task of the front-end software in free-range SPOTs is to sample, in a periodical fashion, data from all the on-board sensors, and transmit data to the basestation whenever it is in the radio range. The class diagram is shown in Fig. 3.

Fig. 3. Front-end class diagram

1. The core of the structure is the PeriodicTaskScheduler class, which is provided for running a task, such as taking samples, at a regular interval using the timer/counter hardware. The PeriodicTaskScheduler class also tries to establish a radio connection with the basestation SPOT and host PC, by periodically broadcasting a connection request and listen to response on a pre-defined port number. When the basestation is found and a radiogram connection has been established, the routine will setup both PacketReceiver and PacketTransmitter services to handle communications with the host PC in terms of data and settings transmissions.


655

2. The PacketReceiver class is used to receive commands from the host application and dispatch them to PacketHandler class to handle the command. Possible packet types include packet used to specify new settings to the sensor monitors, to request current settings of the monitors, and to request a status report. The PacketTransmitter class handles sending reply packets back to the host PC in response to the received requests. It also packages the sensor readings together with its time stamp into a radio datagram and send to the host PC. Data packets are put into a PacketQueue first, and will not be sent out until the connection is established. 3. The AccelMonitor class controls and reads data from the SPOT's accelerometer according to the local settings, and sends the host a telemetry stream of accelerometer readings via Radiogram packets. The local settings include the scale, calibration, and sample interval. Readings sent to the host PC include time stamp, current acceleration, magnitude of the current total acceleration, relative acceleration, as well as the inclination or tilt of one axis with respect to the total acceleration. 4. The TempMonitor class controls and reads data from the SPOT's temperature sensor according to the local settings, and sends the host a telemetry stream of temperature readings via Radiogram packets. Each reading is associated with the time stamp which is sent together with the data in one packet. 5. The LightMonitor class controls and reads data from the SPOT's light sensor according to the local setting on the sample interval, and sends the host a telemetry stream of light sensor readings via Radiogram packets. The return value is of integer type ranging from 0 to 740. Each light sample is associated with the time stamp which is sent together with the data in one packet. 6. The SpotsMonitor class implements the function of recording all the other freerange as well as basestation SPOTs met by the current SPOT, by periodically broadcasting a connection request and listen to response on a pre-defined port number. Once a response datagram is received, the IEEE address is extracted from the datagram and sent to the host PC together with the time stamp.

5 Back-End Design and Implementation of Mlogger In general, the sensor data is sent to the base station SPOT that further moves the data into the host PC via USB cable. In the PC phase, the data is tabularized, saved and presented both as tables and as diagrams with time as x-axis. Furthermore, the data is processed to find out when and what happened to whom. The result of this processing is sent to a blog site. Below we first introduce the design of the database, classes and user interface. We then explain the data processing algorithms. Finally, we describe the blog entry creation and publishing. 5.1 Database, Class Structure, and User Interfaces 1. Database. The Mlogger database is the center of operations of the host PC tasks. It contains several tables for all the data and settings used in the system, including

656


• A Settings table containing the user preferences of the SPOT users, that can be retrieved from there when new settings are sent to the free range SPOTs. • A Readings table containing the sensor data received from the free range SPOTs, that can be retrieved and displayed. • A contact table containing all the met SPOTs in form of the IEEE 64-bit addresses and groups, to be used for activity recognition. • A behavior table containing the sequence of recognized activities together with the time-location information. • A blog entries table containing entries are not sent right away, from where the user may retrieve them and edit them. The interface between the Java code and the MySQL code is the mysql-connectorjava plugin. 2. Class structure. Fig. 4 illustrates the class structure of the host PC tasks. The listening, packet handling and receiving are performed by the DataReceiverSaver class. This class also creates an instance of the ActionSolver class, which then does the data processing as regards the deriving of the context information from raw data. The DataReceiverSaver listens for transmissions of free range SPOTs at port number 43. If the IEEE address of a transmitting SPOT matches one in the Settings table, the new settings are sent over. The host also listens for transmissions of free range SPOTs at port 67 for the incoming sensor data to be saved into the Readings table.

Fig. 4. Back-end class diagram

3. User interface. The user interface is handled by the MDL_GUIView class, which is an extension of the FrameView interface. Its main window's File menu has two choices: SPOTSettings and Logs. The former open the Settings GUI that lets the user enter the desired settings into the MySQL database table Settings for safekeeping, and then send them to the user’s free range SPOT on the basis of the its IEEE address. The latter opens a Jdialog window with three choices: Light Sensor Log, Temp Sensor Log, and Acceleration Log. By entering the IEEE address of a SPOT, the log is rendered on the basis of the sensor data saved in the Readings database table.


657

5.2 Data Processing Algorithms The algorithms are used to analyze raw readings to derive information including when, who, what, and where, as described below. 1. When. Timing information is easy to be obtained, as each sensor data is associated with a time stamp. To construct the new entry to blog, only start time of any new activity is needed. 2. Who. With the SpotsMonitor class in front-end free-range SPOT, all the other free-range as well as basestation SPOTs met by the user’s SPOT will be recorded in form of the IEEE address. At the host PC, user is able to group these SPOTs into different groups. The groups include hosts, family, friends, colleagues, classmates, strangers, and so forth. This forms a Contact Table, as an example shown in Table 1, which is saved in the database. Table 1. Example Contact Table Address 0014.4F01.0000.2E20 0014.4F01.0000.2E21 0014.4F01.0000.2E22 0014.4F01.0000.2E23 0014.4F01.0000.2E24 0014.4F01.0000.2E25 0014.4F01.0000.2E26 0014.4F01.0000.2E27

Type basestation basestation free-range free-range free-range free-range free-range free-range

Name Home PC Office PC Juliet Kitty Bob Boss Eric Sb. 1

Group host host family family friends colleagues colleagues strangers

3. What. The user’s activity can be detected and recognized by analyzing the raw sensor data, in particular the accelerometer data to classify the motions. The recognition method is based on a set of IF-THEN fuzzy rules as follows. IF IF IF IF IF

SPOT’s SPOT’s SPOT’s SPOT’s SPOT’s

Motion Motion Motion Motion Motion

is is is is is

Still THEN Low THEN Medium THEN High THEN Extreme THEN

Activity is Staying; Activity is Driving; Activity is Biking; Activity is Walking; Activity is Running;

In the rules, the feature “SPOT’s Motion” is calculated by: SPOT’s Motion = AVG (abs(acceleration magnitude-1.0)), where shifting window size is 5s (30 samples by default settings) with 50% window overlap. As no training data set is available at the moment, there is no way to train the fuzzy classifier to learn, and thus the classifier is designed from prior knowledge and expertise based on empirical data as shown in Fig 5 [5]. Accordingly, the membership functions are defined in Fig. 6.

658


Fig. 5. The sample sensor trace with the user walking for ~150 seconds, then running until the ~225 second mark, then entering a car and driving for the remainder of the recording (with stops at the ~260 and ~325 second marks, and parking in a lot starting at the ~450 second mark). [5].

1 low

medium

high

extreme

0.5 0

still 0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Motion

Fig. 6. Membership functions for the linguistic terms of Motion

4. Where. It is not easy to detect where the user is, without having any geographical information obtained from e.g. GPS or cellular tower. However, in this paper, in particular for the purpose of blogging, we are more interested in the places where user stays in, instead of the location where the user is at. A user’s daily routine appears to be changing between different places at different time. The changes of user’s locations are interleaved by movements of some ways like walking, running, biking or driving. A finite state machine (FSM) is shown in Fig. 7 to illustrate the situation. At any moment, a user is either at state “At-place”, meaning a fixed place like home, office, restaurant, supermarket, or “On-road”, meaning the periods of changing the places. After the “On-road”, the user may move to a new place or return back to the original place. movement On-road

At-place

movement changed

staying

Fig. 7. State machine for modeling user behavior

As described above, user’s activity at a time (i.e. status of motion: staying, walking, running, biking or driving) can be detected. In consequence, user’s activity can be modeled by a sequence of moving status interleaved by staying. According to the activity information, user’s current state can be determined. Fig. 8 shows an example sequence of place changing and movements over a weekday. It is worth noting here


659

that user in movement, for example walking at home or in the office, does not necessarily means the state is On-road. Similarly, the status of staying does not directly lead to an At-place state, in considering the examples of short stop during biking and car stop because of traffic light.

Driving Walking Staying On-road At-place 0

3

6

9

12

15

18

21

Hour

Fig. 8. State determination based on activities. The short thin vertical lines represents short period of walking and staying that have been considered as invalid and thus absorbed.

The algorithm for assigning a state to a motion is given below. IF (Motion==Staying) THEN IF (Valid(Motion) THEN State=At-place; ELSE State=On-road; //to absorb short staying between movements ELSE //Motion is not Staying IF (Valid(Motion)) THEN State=On-road; ELSE State=At-place; //to absorb short movement between staying In the algorithm, two filtering rules are defined to absorb the temporary activities. A Boolean function Valid is used to test if a motion is temporary activity or valid one. The function is defined according to prior knowledge and empirical data, as given in Table 2. Fig. 8 also shows the state transitions for the sequence of activity in the same figure. Table 2. Valid of motions Motion Motion period Valid(Motion)

Staying >90s T

Walking >60s T

Running >30s T

Biking >20s T

Driving >10s T

Next, when state is At-place, we need to determine at what place the user is exactly during the period. To recognize a user’s current place needs to jointly consider the information of “who” and “when”, i.e. which SPOTs are met during the period and at what time. In doing this, user’s input on the names of the most possibly visited places is needed, as well as the association with the SPOTs in his contact list and the time in a day. Table 3 shows a typical example. It is worth noting that the table is for weekday only. For weekend, another table can be given by using the same way. Also, in the

660


last row of Table 3 the most possible place is given, in case nobody is met during a whole At-place state, with respect to the majority of time staying at the At-place state. With such a table in mind, the place recognition algorithm is nothing more than to firstly determine who have been met during the At-place state duration, and next search the table to assign a appropriate place accordingly. When multiple SPOTs have been met during one At-place state, the one list first in the table is adopted. In other words, contacts in the table have different priorities. For example if the user met both the Home PC and Kitty during 9:00 to 11:00, then the user is at home instead of daycare; if the user met both Kitty and Juliet during 11:00 to 13:00, then the user is at daycare instead of cafeteria. Detailed description of the algorithm is omitted here. Table 3. User’s input on places in association with met SPOTs and time in a weekday

Home PC Kitty Juliet Bob Boss Strangers None

21:007:00 home home home home work home home

7:009:00 home home home home work home home

9:0011:00 home daycare elsewhere elsewhere work work work

11:0013:00 home daycare cafeteria cafeteria cafeteria cafeteria cafeteria

13:0017:00 home daycare elsewhere elsewhere work work work

17:0019:00 home home elsewhere elsewhere work elsewhere elsewhere

19:0021:00 home home home elsewhere work home home

5.3 Blogging The user whose action has been deciphered has to have the option of editing or deleting the blog entry prior to sending. However, prior to this phase, the user needs to save his or her desired settings and preferences to the SPOT via the MySQL database or use default settings. If the mobile user has decided to apply manual blog entry editing, he or she will need to perform that function prior to the sending, or the entry is not sent In our implementation, the user’s blog is chosen to be at site blogspot, with an account named mobilelogger (URL: http://mobilelogger.blogspot.com/). In Fig. 4, the DataReceiverSaver class also takes care of the blogging of the result of the processing, using the libraries and API of com.google.gdata, provided by Google. The object instance of com.google.gdata.client.blogger.BloggerService is created in the main method of DataReceiverSaver, and given as parameter to its run()-method. Blogging can be conducted in a periodical fashion, for example once every half an hour. This is easy and straightforward, but of less accuracy and efficiency. Our approach is to choose the time to perform the blogging to be at the moments when “situation is changed”. The idea is based on the fact that, interesting events worthy of blogging usually happens during particular time interval with some changes of related observations like user’s activity and temperature. Here, situation is defined to be all the information regarding the user, including the recognized information about where, who and what as well as the temperature and light information obtained from the sensors at the time. Assume one new entry is going to cover the happenings of one


661

whole day. One line in the entry corresponds to a particular event that might be interesting to the user to enrich with his/her detailed experience, feelings, thoughts, etc. Followings are the cases that a new line is to be inserted. • • • •

New lines need to be inserted to a new blog entry whenever the user’s place is changed. Also, line inserting is to be done at the event when user meets a free-range or basestation SPOT) or the SPOT met before has gone. Similarly, events are significant and need to be put into an entry when user’s movement status is changed. Finally, significant changes of temperature and light are to be marked in an entry. For temperature and light, a change is defined as when: abs (AVG (values (t to t+30s))-AVG (values (t-30s to 5)) > Threshold. For temperature, the threshold is set to 2 Celcius; for light, it is set to 25. In other words, the temperature is categorized into bins of width 2 Celcius, and for light the width of bins is 25.

6 Related Work The work presented in this paper is closely related to two research areas, one is human behaviour recognition and modelling, the other is automatic and contextassociated blogging. The problem of behaviour recognition and modelling has been an active research topic for a long time, and still remains very challenging. There has been a huge number of research carried out in many communities, such as computer vision and graphics, AI and pattern recognition, context-awareness for pervasive and ubiquitous computing, smart environment, intelligent user interface, social computing, and data mining. It would not be possible and necessary to go through all the existing solutions on this direction in this paper. Almost all the existing research aim to recognize human behaviour to the best accuracy. One the other hand, the behaviour to be recognized is expected to be as exact as possible. One difference of our work from the existing research is that its goal of successful recognition is in a coarse-grained fashion. Our work does not require very precise recognition of user’s exact behavior . For example, it would be enough to know that user is at home, no matter he is seating in a sofa or lying in bed. The information provided by the recognition algorithms is to be used as a reminder to the blogger who is going to edit, change, and correct the suggestions and add more details when creating new entry to his blog. Existing research in automatic and context-associated blogging are mainly in the area of geoblogging [1]. Geoblogging attaches specific geographic location information to blog entries via geotags. Geotagging [2] is the process of adding geographical identification metadata to various media such as photographs, video, websites, or RSS feeds and is a form of geospatial metadata. These data usually consist of latitude and longitude coordinates, though they can also include altitude, bearing, distance,

662


accuracy data, and place names. In Moblogging [3], blog entries are tagged with exact position of the user. While the basic idea of Geoblogging is the same as ours: tagging blog entries with extra metadata, we are aiming at broader context association than only geographical information. This of course depends on the rich availability of sensors in various modalities as well as corresponding data processing and information fusion algorithms for behavioral recognition.

7 Discussions In this paper, we aim to practice the merging of the two popular computing paradigms, pervasive and social computing, by proposing Mlogger, a novel architecture and system for blogging with user behavioral information automatically associated. Using Sun SPOTs as the platform for collecting real-time data like moving, temperature, and light. Off-line data processing is employed to detect, recognize and track user behavior and associates it with new blog entries. Regarding the proposed architecture, it is important to note that, even though the proposed architecture places the data processing algorithms into the back-end (i.e., the host PC), an alternative way is to put simple algorithms into the front-end (i.e. the free-range Sun SPOTs) which enables the activity recognition being conducted immediately over the raw readings. In this way, the time and energy for transmitting a big amount of raw data can be saved, because only the recognition results need to be sent to the host PC. This is only applicable to algorithms that do not need very much history data, or the case in which algorithms need to be adjusted or changed during the operation. As for the front-end design, by putting data processing algorithms to front-end, only the activity recognition results need to be sent to the back-end. In our design however, all raw readings are transmitted. Between the two extreme choices, one compromised approach is that, the Sun SPOTs receive event subscriptions from the host PC applications, and notify host applications only when the events occur. In the simplest case, subscribed events are represented in the form of upper and lower thresholds to the sensor readings. For recognizing user’s activity, as the main focus of this paper is in proposing the architecture instead of the activity recognition, we use relatively simple approach here based on fuzzy-rules. More advanced methods for activity recognition based on accelerometer can be found in [6-13]. One reason is that, data needed for training advanced models is not available at the moment. Moreover, as behavioral information is just used as reminder for user blogging, the required accuracy is not as high as other context-aware applications. It is not easy to detect the user’s position without having any geographical information. Fortunately, given the output information on when, who, and what that have been recognized, plus temperature and light samples, we can recognize user’s current places by fusing all the available information with suitable algorithms. Obviously, time plays a very clear role in determining user’s location. Thus, models conditioned on both the hour of day as well as weekday or weekend need to be developed for clustering locations and sequence of locations, provided that training data is available.


663

In this paper however, since no training data is available, we use a sample approach based on empirical knowledge. When training data is available, the model can be detailed by separating each day (Monday, Tuesday, etc.) in one week, and small time interval (e.g. every 15 min) in a day. We plan to extend our model in a number of ways. First, we are going to get the prototype fully evaluated, to be deeply aware of the field experience and to gather feedback from users, as well as to evaluate and improve the adopted algorithms. Secondly, when enough data has been collected from long-term running of the prototype, the proposed algorithms are to be trained with parameters learned and adjusted. Third, new advanced algorithms are to be developed and tested. On this direction, there are following things under plan: 1) to develop new advanced algorithms that take advantage of e.g. HMM, neural networks, and other AI techniques; 2) to employ more sophisticated signal processing techniques, for example to differentiate the 3axis data, to use FFT to find out the frequency features, to explore the periodical features in walking, running and biking; 3) to elaborate user activities and locations, for example to name more places user frequently visits. Currently the information of user activity and location is too coarse. 5) to consider and fuse with other sensor data obtained from various sources, like light, temperature, etc. Finally, we are planning to use some other platforms with more capacities in environment and user sensing. More and more advanced smart phones are released onto the market, like Apple iPhone, Nokia Nseries, Google Nexus One. These devices are equipped with a lot of sensors including 1) wireless connectivity like 2G/2.5G/3G, Wi-Fi, Bluetooth, IrDA, radio, etc.; 2) user interfaces like keyboard, touch screen, microphone, camera, etc.; 3) embedded sensors like ambient light sensor, accelerometer, compass, barometer and temperature sensor, light phototransistor, humidity sensor, etc. By using the extremely rich capacity of sensing the surroundings, a lot of data and information can be obtained, which enables more accurate and detailed recognition of user behavior as well as more fancy applications. Acknowledgement. The financial support by the Academy of Finland (Project No. 113950) is gratefully acknowledged. The authors would like to thank the students in Software Project course, Hongwei Ge and Fang Yang for implementing the front-end part of the Mlogger system.

References 1. 2. 3. 4. 5.

Geoblogging, Wikipedia, http://en.wikipedia.org/wiki/Geotagging Geotagging, Wikipedia, http://en.wikipedia.org/wiki/Geotagging Moblogging, Wikipedia, http://en.wikipedia.org/wiki/Mobile_blogging SunSPOTWorld, http://www.sunspotworld.com/ Welbourne, E., Lester, J., LaMarca, A., Borriello, G.: Mobile Context Inference Using LowCost Sensors. In: Strang, T., Linnhoff-Popien, C. (eds.) LoCA 2005. LNCS, vol. 3479, pp. 254–263. Springer, Heidelberg (2005), doi:10.1007/11426646_24 6. Michael, K., McNamee, A., Michael, M.G., Tootell, H.: Location-Based Intelligence – Modeling Behavior in Humans using GPS. In: Proceedings of the International Symposium on Technology and Society (ISTAS 2006), New York (June 2006), doi:10.1109/ ISTAS.2006.4375889

664


7. Ermes, M., Parkka, J., Mantyjarvi, J., Korhonen, I.: Detection of Daily Activities and Sports With Wearable Sensors in Controlled and Uncontrolled Conditions. IEEE Transactions on Information Technology in Biomedicine 12(1), 20–26 (2008), doi:10.1109/ TITB.2007.899496 8. Eagle, N., Pentland, A.: Eigenbehaviors: Identifying Structure in Routine. Behavioral Ecology and Sociobiology 63(7), 1057–1066 (2009), doi:10.1007/s00265-009-0830-6 9. Baek, J., Lee, G., Park, W., Yun, B.-J.: Accelerometer Signal Processing for User Activity Detection. In: Negoita, M.G., Howlett, R.J., Jain, L.C. (eds.) KES 2004. LNCS (LNAI), vol. 3215, pp. 610–617. Springer, Heidelberg (2004) 10. Jia, N.: Detecting Human Falls with a 3-Axis Digital Accelerometer. Analog Dialogue 43 (July 2009) 11. Brezmes, T., Gorricho, J.-L., Cotrina, J.: Activity Recognition from Accelerometer Data on a Mobile Phone. In: Omatu, S., Rocha, M.P., Bravo, J., Fernández, F., Corchado, E., Bustillo, A., Corchado, J.M. (eds.) IWANN 2009. LNCS, vol. 5518, pp. 796–799. Springer, Heidelberg (2009), doi:10.1007/978-3-642-02481-8_120 12. Lee, M.-h., Kim, J., Kim, K., Lee, I., Jee, S.H., Yoo, S.K.: Physical Activity Recognition Using a Single Tri-Axis Accelerometer. In: Proceedings of the World Congress on Engineering and Computer Science (WCECS 2009), San Francisco, USA, vol. 1, pp. 14–17 (October 2009) 13. Jeong, D.-U., Do, K.-H., Chung, W.-Y.: Implementation of the Wireless Activity Monitoring System Using Accelerometer and Fuzzy Classifier. International Journal of Information Systems for Logistics and Management 3(2), 115–120 (2008)