US20170109656A1

US20170109656A1 - Data-driven activity prediction

Info

Publication number: US20170109656A1
Application number: US15/294,509
Authority: US
Inventors: Diane J. Cook; Bryan Minor; Janardhan Rao Doppa
Original assignee: Washington State University WSU
Current assignee: Washington State University WSU
Priority date: 2015-10-16
Filing date: 2016-10-14
Publication date: 2017-04-20
Also published as: US11551103B2; US20200019887A1

Abstract

A physical environment is equipped with a plurality of sensors (e.g., motion sensors). As individuals perform various activities within the physical environment, sensor readings are received from one or more of the sensors. Based on the sensor readings, activities being performed by the individuals are recognized and the sensor data is labeled based on the recognized activities. Future activity occurrences are predicted based on the labeled sensor data. Activity prompts may be generated and/or facility automation may be performed for one or more future activity occurrences.

Description

RELATED APPLICATION

This application claims the benefit of U.S. Provisional Application No. 62/242,654, filed Oct. 16, 2015, which is hereby incorporated by reference.

STATEMENT CONCERNING GOVERNMENT INTEREST

The invention described herein was developed based on work supported by the National Science Foundation under grants 0900781, 1262814, and 1543656, and by the National Institute of Biomedical Imaging and Bioengineering under grant R01EB015853. Accordingly, the Government may have certain rights in this application.

BACKGROUND

Smart environments (e.g., homes or other environments fitted with a plurality of sensors) are currently being used for a variety of uses including, for example, medical monitoring, energy efficiency, and ubiquitous computing applications. Using smart environments, sensor data can be gathered and analyzed to recognize activities (e.g., activities of daily living), and this activity data can be used in various applications including, for example, security systems and computer games. Activity recognition focuses on identifying and labeling activities that have occurred in the past or may be occurring in the present.
Activity recognition data can be used to consider activity prediction and activity prompting. Existing activity prediction techniques are typically implemented to predict the next activity that will occur within a smart environment. Existing activity prompting applications typically require manual input of a user's daily schedule or predefined activity steps.

SUMMARY

In a smart environment (e.g., a home or other environment fitted with a plurality of sensors) equipped with various types of sensors, activities performed by individuals within the smart environment can be recognized. Based upon sensor data gathered from the smart environment and the recognized activities, future occurrences of one or more activities within the smart environment can be predicted. Having the predicted future occurrences of one or more activities can further enable an activity prompting application, which can be used to prompt individuals (e.g., individuals with memory impairment) associated with the smart environment to perform particular activities at the predicted activity occurrence times. In addition, facility automation in support of predicted activities may also be implemented.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The various features described herein may, for instance, refer to device(s), system(s), method(s), and/or computer-readable instructions as permitted by the context above and throughout the document.

BRIEF DESCRIPTION OF THE DRAWINGS

The Detailed Description below is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.

FIG. 1 is a pictorial diagram of an example implementation environment.

FIG. 2 is a pictorial diagram of an example data flow during activity occurrence prediction.

FIG. 3 is a pictorial diagram of an example data flow during data-driven activity prompting.

FIG. 4 is a block diagram illustrating select components of an example activity prediction server implemented to support data-driven activity prediction within a smart environment.

FIG. 5 is a flow diagram of an example process for performing data-driven activity prediction within a smart environment.

FIG. 6 is a flow diagram of an example process for training an activity occurrence predictor.

FIG. 7 is a flow diagram of an example process for performing facility automation based on data-driven activity prediction.

FIG. 8 is a block diagram illustrating select components of an example personal computing device implemented to support data-driven activity prompting.

FIG. 9 is a flow diagram of an example process for performing data-driven activity prompting.

DETAILED DESCRIPTION

The data-driven activity prediction techniques described herein utilize activity-labeled sensor events to learn an individual's normal routine and generate predictions based upon received and labeled sensor event data. The predictions include predicted times of next activities and can also be used to support an activity prompting application.
Smart environments include homes, apartments, workplaces, and other types of spaces that are equipped with any of a variety of types of sensors, controllers, and a computer-driven decision making process. Such smart environments enable ubiquitous computing applications including, for example, applications to support medical monitoring, energy efficiency, assistance for disabled individuals, monitoring of aging individuals, or any of a wide range of medical, social, or ecological issues. The types of sensors that may be employed to establish a smart environment may include, for example, wearable sensors that are attached to a particular user, cameras, microphones, or less obtrusive sensors (e.g., motion sensors, door sensors, temperature sensors, etc.) that are placed at various locations within the environment.
Many smart environments enable the ability to detect, track, and identify residents, as well as recognize specific activities. Examples of specific activities that may be recognized include, but are not limited to, sleeping, bathing, bed-to-toilet transition, grooming, preparing/eating breakfast, watching TV, cleaning the bathroom, working at the computer, preparing/eating lunch, preparing/eating dinner, cleaning the apartment, or studying. Activity recognition may be implemented, for example, by comparing a pattern or sequence of detected actions with predetermined patterns or sequences of actions corresponding to known activities. In an example implementation, the activities that are identified may include well-known ADLs (Activities of Daily Living). In another implementation, the activities that are identified may also include additional activities that are not included in a list of ADLs, but that occur on a frequent basis.
Activity prediction, i.e., using sensor data to predict future activity occurrence times, is valuable for providing activity-aware services such as energy-efficient home automation, prompting-based interventions, and anomaly detection. However, while various techniques exist to identify past and/or present activities based on sensor data, there are various challenges in predicting future activity times. For example, sensor data is typically noisy, activity labels provided by activity recognition algorithms are subject to error, and data describing recognized past and present activities contains spatial and temporal relationships that, if considered, may improve the accuracy of activity predictions.
This Detailed Description describes example techniques to analyze labeled sensor event data to generate predictions for future activity occurrence times. The techniques described herein include techniques to train an activity predictor and to use predicted activity occurrence times to generate activity prompts.

Example Environment

FIG. 1 illustrates an example implementation environment 100, which includes a smart environment 102. Example smart environment 102 includes various sensors such as, for example, motion sensors 104, light sensors 106, door sensors 108, and temperature sensors 110. Sensor event data is generated by the various sensors and transmitted to a computing device, such as activity prediction server 112, for example, over a network 114. Activity prediction server 112 may include, for example, sensor event data store 116, activity recognition training data 118, activity recognition module 120, activity prediction module 122, and facility automation module 124.
Example implementation environment 100 may also include a personal computing device 126, such as a mobile phone, which may also communicate via network 114. Example mobile phone 126 may include an activity prompting application 128.
Smart environment 102 is a single example of a smart environment, which includes motion sensors, light sensors, door sensors, and temperature sensors. However, in other examples, other combinations of these and other sensors may be used to implement a smart environment. Some other sensors that could be used to implement smart environments include, but are not limited to, for example, sound sensors, proximity sensors, or the like.
The network 114 may include any combination of wired and/or wireless networks. By way of example, the network 114 may include one or more personal area networks (PANs), home area networks (HANs), local area networks (LANs), and/or wide area networks (WANs).
In an example implementation, activity recognition module 120 is trained using activity recognition training data 118. Activity recognition training data 118 includes sensor data from smart environment 102 and/or sensor data from one or more other smart environments. Sensor events in the activity recognition training data 118 is labeled (e.g., by human annotators) to identify an activity that was occurring at the time the sensor event was recorded. In an example implementation, the labeled activities include bathe, bed-toilet transition, cook, eat, enter home, leave home, personal hygiene, relax, sleep, wash dishes, and work. Any combination of these or other activities may be reflected in the activity recognition training data 118. Various techniques for identifying and recognizing activities within a smart environment are described in additional detail in U.S. Pat. No. 8,417,481, filed Sep. 2, 2009 and issued Apr. 6, 2013, titled “Systems and Methods for Adaptive Smart Environment Automation,” the contents of which are incorporated herein by reference.
Once trained using activity recognition training data 118, activity recognition module 120 recognizes activities that are performed within smart environment 102 based on data sent from the sensors 104, 106, 108, and 110 to the sensor event data store 116. Activity recognition module 120 labels the received sensor data with the recognized activity class.
Activity prediction module 122 analyzes sensor event data that has been labeled by activity recognition module 120, and predicts next occurrence times for one or more activities within the smart environment 102.
Facility automation module 124 may be configured to automatically control one or more aspects of the smart environment 102 based, at least in part, on the predicted next activity occurrence time. For example, based on a predicted “enter home” activity, facility automation module 124 may cause one or more lights to be turned on and/or may cause the temperature within the smart environment to be adjusted to a comfortable living temperature. As another example, based on a predicted “bed-to-toilet transition” activity facility automation module 124 may case a light in the bathroom to be turned on. Any number of automated controls for the smart environment 102 may be implemented in response to predicting a future activity occurrence.

Activity Prediction

FIG. 2 illustrates an example data flow 200 for activity prediction as described herein. As described above, sensor data generated by the various sensors in the smart environment 102 is labeled by activity recognition module 120 and stored in the sensor event data store 116. At time t=t_e, sensor event features 202, x={x₁, x₂, . . . x_d}, are extracted from the sensor event data store 116 and sent as input to the activity prediction module 122. Activity prediction module 122 analyzes the received sensor event features 202 and generates output 204, which includes predictions of relative next occurrence times of one or more activities. In the illustrated example, output 204, ŷ={ŷ₁, ŷ₂, ŷ₃}, represents respective predicted next occurrence times of three distinct activities, a₁, a₂, and a₃.
In the illustrated example, activity a₁(e.g., eating) will actually occur at time t₁, activity a₂(e.g., taking medication) will actually occur at time t₂, and activity a₃(e.g., sleeping) will actually occur at time t₃. The output predictions 204 correspond to the actual activity times such that ŷ₁is the prediction corresponding to actual time t₁, ŷ₂is the prediction corresponding to actual time t₂, and ŷ₃is the prediction corresponding to actual time t₃. In an example implementation, each prediction, ŷ_i, may be expressed as a specific time (e.g., ŷ₁=t₁) or as a number of time units that will pass until the activity occurs again (e.g., ŷ₁=t₁−t_e).

Activity Prompting

FIG. 3 illustrates an example data flow 300 between an example personal computing device 126 and example activity prediction server 112 to support activity prompting. In the illustrated example, personal computing device 126 (shown implemented as a mobile phone) includes an activity prompting application 128. Activity prompting application 128 configures the personal computing device 126 to periodically (e.g., every 15 minutes) request 302 from the activity prediction server 112, activity occurrence predictions. For example, a user may access the activity prompting application 128 to configure preferences, which may include a list one or more activities for which the user would like to be prompted. Alternatively, the activity prompting application 128 may be configured to request predictions and provide activity prompts for any activities that are recognized and predicted by activity prediction server 112.
Upon receiving a request for activity occurrence predictions, activity prediction server 112 sends 304 the requested activity occurrence predictions to the personal computing device. The activity occurrence predictions that are sent may include, for example, any activity occurrence predictions that have not already been sent, activity occurrence predictions that are within a threshold time range, occurrence predictions for specifically requested activities, and so on.
When the personal computing device 126 receives the requested occurrence predictions, the activity prompting application 128 compares 306 the received activity occurrence predictions to the current time. Based on the comparison, activity prompting application 128 generates and presents one or more activity prompts 308. For example, activity prompting application 128 may generate and presents a prompt 308 for an activity when the current time is greater than or equal to a predicted occurrence time for the activity. Alternatively, activity prompting application 128 may generate and presents a prompt 308 for an activity when the current time is within a threshold time period before and/or after the predicted occurrence time for the activity.
Upon receiving a prompt 308, a user may provide feedback indicating any action the user may be taking in response to the prompt. Such feedback may be recorded and later analyzed, for example, to determine the effectiveness of the activity prompts for that particular user.

Activity Prediction Techniques

Any number of techniques may be used to predict activity occurrence times. An independent activity predictor and a recurrent activity predictor are described herein.

Independent Activity Predictor

The independent activity predictor described herein does not take into account relationships between activities or the temporal structure of the sensor data, making predictions using only recent sensor events at a given time. In an example implementation, the independent activity predictor is trained using sensor event data in sensor event data store 116 that has been labeled with an activity class, for example, by activity recognition module 120. For each set of sensor event data λ_iin a training sequence Λ, features, x_i=Φ(λ_i)ε
, are determined (i.e., input) and the ground-truth activity predictions, y_i*ε
, (i.e., output) are extracted from the labeled activity segments. The aggregate set of input-output pairs {x_i,y_i*}_i=1 ^N(i.e., training examples) is given to a multi-output regression learner to learn the activity predictor by minimizing the given loss function L.
A weakness of the independent activity predictor is that the local sensor event data may not provide sufficient information to make highly-accurate activity predictions.

Recurrent Activity Predictor

To improve upon the independent activity predictor described above, a recurrent activity predictor is trained to consider joint models by reasoning over the relationships between different activities and accounting for the temporal structure of activities. In this example, activity prediction can be viewed as a generalization of sequence labeling, where each output token is a vector of T real values corresponding to the next activity occurrence time of each activity, where T is the number of activities.
A natural solution would be to define a graphical model encoding the relationships between input and output variables at different time steps and to learn the parameters from the training data. However, such a graphical model may be very complex (e.g., high tree width) and can pose severe learning and inference challenges. The model may be simplified to allow for tractable learning and inference, but that can be detrimental to prediction accuracy.
An alternate solution is to employ a heuristic inference method (e.g., loopy belief propagation or variational inference) with the complex model. However, with these solutions, it is very difficult to characterize the solutions and to predict when they will work well for a new problem.
The recurrent activity predictor described herein employs both the local features and context features to make activity predictions. Local features are computed from a recent sensor event window, and context features capture the activity predictions from a small history window. An advantage of the recurrent activity predictor compared to the graphical model solution described above, is that it allows for arbitrary relationships between activities and the temporal structure between activities as context features and is highly efficient in terms of training and testing.

Example Activity Prediction Server

FIG. 4 illustrates example components of an activity prediction server 112 implemented to support activity prediction within a smart environment. Example activity prediction server 112 includes network interface(s) 402, processor(s) 404, and memory 406. Network interface(s) 402 enable activity prediction server 112 to receive and/or send data over a network, for example, as illustrated and described above with reference to FIG. 1. Processor(s) 404 are configured to execute computer-readable instructions to perform various operations. Computer-readable instructions that may be executed by the processor(s) 404 are maintained in memory 406, for example, as various software modules.
In an example implementation, memory 406 may maintain any combination or subset of components including, but not limited to, operating system 408, sensor event data store 116, activity recognition training data store 118, activity recognition module 120, activity prediction module 122, activity prediction history data store 410, and facility automation module 124.
Sensor event data store 116 may be implemented to store data that is received from one or more sensors implemented in one or more smart environments. As described above with reference to FIG. 1, activity recognition training data store 118 may be implemented to store labeled sensor data received from one or more smart environments, which can be used to train the activity recognition module 120.
Activity recognition module 120 is configured to receive sensor events from sensors in a smart environment, and to label the sensor events with corresponding activity class labels.
Activity prediction module 122 is configured to predict next occurrence times for one or more activities within a smart environment.
Facility automaton module 124 is configured to automatically control one or more aspects of smart environment 102 based, at least in part, on the predicted activity occurrence times.
Activity prediction module 122 includes local feature calculator 412, context feature calculator 414, loss function calculator 416, multi-output regression learner 418, and activity occurrence predictor 420.
In an example implementation, activity occurrence predictor 420 is a recurrent activity predictor that is trained based, at least in part, on imitation learning. Imitation learning is a training technique in which the goal of the learner is to learn to imitate the behavior of an expert performing a sequential decision making task (e.g., playing a video game) in a way that generalizes to similar tasks or situations. Typically this is done by collecting a set of trajectories of the expert's behavior (e.g., games played by the expert) on a set of training tasks. Then, supervised learning is applied to train a predictor that can replicate the decisions made on those trajectories. Often the supervised learning problem corresponds to learning a mapping from states to actions and any of a variety of classification tools can be used.
In an example implementation, activity prediction module 122 trains the activity occurrence predictor 420 according to an imitation learning technique such that the expert corresponds to the loss function, L, and the expert behavior corresponds to predicting the best output, y_i*ε
, at each time step, i. To make predictions, the activity predictor uses both local features, Ψ_local(i)=Φ(λ_i), and prediction context features, Ψ_context(i), including the previous activity predictions from a small history window. The context features may include, for example, the predicted occurrence times, ŷε
, for the T activities and for each history window. Given a history context of H previous windows, the context feature vector will be of size H·T.
Local feature calculator 412 determines local features from sensor event data store 116. Context feature calculator 414 determines context features from activity prediction history data store 410. Loss function calculator 416 calculates the loss function, L, based on training data that includes previous predictions and corresponding actual activity times. Multi-output regression learner 418 trains the activity occurrence predictor 420 using the local features, the context features, and the loss function.
Both the independent activity predictor and the recurrent activity predictor are trained using a multi-output regression learner. In various implementations, any of various multi-output regression learners may be used. In an example implementation, an independent regression function is learned for each output variable. That is, T regressors are learned, one for each of the T activities. In an example implementation, each regressor is implemented as a regression tree (e.g., a model tree), such that predictions are made by a learned linear function over all of the features at each leaf node.

Example Training and Prediction Operation

FIGS. 5 and 6 illustrate example processes for implementing data-driven activity prediction as described herein. These processes are illustrated as collections of blocks in logical flow graphs, which represent sequences of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions stored on one or more computer storage media that, when executed by one or more processors, cause the processors to perform the recited operations. Note that the order in which the processes are described is not intended to be construed as a limitation, and any number of the described process blocks can be combined in any order to implement the processes, or alternate processes. Additionally, individual blocks may be deleted from the processes without departing from the spirit and scope of the subject matter described herein. Furthermore, while these processes are described with reference to the computing device 112 described above with reference to FIG. 4, other computer architectures may implement one or more portions of these processes, in whole or in part.
FIG. 5 illustrates an example process 500 for performing data-driven activity prediction for a smart environment.
At block 502, labeled sensor data is received. For example, as described above with reference to FIG. 1, activity recognition training data store maintains sensor event data that was generated in an one or more smart environments, with each sensor event labeled with an activity class that corresponds to an activity that was occurring at the time the sensor event was recorded.
At block 504, an activity recognition module is trained based on the received labeled sensor data. For example, activity recognition module 120 is trained using the data in activity recognition training data store 118 to enable activity recognition based on newly received sensor event data from a particular smart environment 102.
At block 506, sensor data is received from a smart environment. For example, sensor event data is received over network 114 from smart environment 102.
At block 508, activity recognition module 120 labels the sensor event data that is received from the smart environment 102 and stores the labeled sensor data in sensor event data store 116.
At block 510, activity prediction module 122 trains an activity occurrence predictor 420 based, at least in part on the labeled sensor data in sensor event data store 116.
At block 512, future occurrence times are predicted for one or more activities. For example, activity occurrence predictor analyzes the labeled sensor event data in sensor event data store 116 and predicts future occurrence times for one or more activities within smart environment 102.
FIG. 6 illustrates an example process 510 for training an activity occurrence predictor.
At block 602, training data is received. For example, activity prediction module 122 receives labeled sensor event data from sensor event data store 116. In an example implementation, activity occurrence predictor 420 is trained using a sequence of raw sensor events, Λ=(λ₁, λ₂, . . . λ_N), where λ_icorresponds to sensor readings generated at time t_i. As described above, as sensor event data is received, activity recognition module 120 labels each sensor event with a corresponding activity class.
At block 604, a loss function is calculated. For example, loss function calculator 416 analyzes the labeled sensor event data and calculates a non-negative loss function, L, such that L(x,ŷ,y*)ε
is the loss associated with labeling a particular input xε
by output ŷε
when the true output is y*ε
. In an example implementation, the loss function is the root mean squared error (RMSE), which can be expressed as:
$L = RMSE = \sqrt{\frac{{Σ ({\hat{y}}_{i} - y_{i}^{*})}^{2}}{T}},$
where T is the number of activities. The goal is to train an activity predictor that generates predicted outputs that have low expected loss.
At block 606, a time step is initialized. For example, a first window is determined to define a time period for a first set of labeled sensor event data.
At block 608, local features are determined for the current time step. For example, local feature calculator 412 extracts data from sensor event data store 116 and employs a feature function, Φ, to determine local features, Ψ_local(i)=Φ(λ_i)ε
.
At block 610, context features are determined for the current time step. For example, context feature calculator 414 analyzes activity prediction history data store to determine prediction context features, Ψ_context(i), including the previous activity predictions from a small history window. The context features may include, for example, the predicted occurrence times, ŷε
, for the T activities and for each history window. Given a history context of H previous windows, the context feature vector will be of size H·T.
In an example implementation, for exact imitation training, context features consist of ground-truth labels from the previous window. In various implementations, a variety of context features may be used. Example context features may include any combination of one or more of the features listed and described in Table 1.

TABLE 1

ID	Feature	Description

1	LastSensorEventHours	Hour of day for current event
2	LastSensorEventSeconds	Seconds since the beginning of the
		day for the current event
3	WindowDuration	Window duration (seconds)
4	TimeSinceLastSensorEvent	Seconds since previous event
5	PrevDominantSensor1	Most frequent sensor in the previous
		window
6	PrevDominantSensor2	Most frequent sensor in the window
		before the previous window
7	LastSensorID	Current event sensor
8	LastLocation	Most recent location sensor
9	SensorCount	Number of events in the window for
		each sensor
10	SensorElTime	Time since each sensor fired
11	TimeStamp	Normalized time since beginning of
		the day
12	LaggedTimeStamp	Previous event TimeStamps
13	LaggedPredictions	Previous event predictions
14	MaximumValue	Maximum value of sensor
15	MinimumValue	Minimum value of sensor
16	Sum	Sum of sensor values
17	Mean	Mean of sensor values
18	MeanAbsoluteDeviation	Average difference from mean
19	MedianAbsoluteDeviation	Average difference from median
20	StandardDeviation	Value standard deviation
21	CoeffVariation	Coefficient of value variation
22	NumZeroCrossings	Number of median crossings
23	Percentiles	Number below which a percentage
		of values fall
24	SqSumPercentile	Square sum values < percentile
25	InterQuartileRange	Difference between 25^thand
		75^thpercentiles
26	BinCount	Values binned into 10 bins
27	Skewness	Symmetry of values
28	Kurtosis	Measure of value “peakedness”
29	SignalEnergy	Sum of squares of values
30	LogSignalEnergy	Sum of logs of squares
31	SignalPower	SignalEnergyAverage
32	PeakToPeak	Maximum-minimum
33	AvgTimeBetweenPeaks	Time between local maxima
34	NumPeaks	Number of Peaks

At block 612, joint features for the current time step are computed. For example, activity prediction module determines the joint features, which are expressed as Ψ_i=Ψ_local(i)⊕Ψ_context(i), where “⊕” refers to the vector concatenation operator.
At block 614, the best output for the current time step is determined, based, at least in part, on the loss function. For example, multi-output regression learner 418 determines the best activity predictions, which can be represented as y_i*ε
.
At block 616, the current regression example, (Ψ_i,y_i*) is added to a set of regression examples, D.
At block 618, activity prediction module 122 determines whether or not to increment the time step. For example, the processing described above with regard to blocks 608-616 is performed for each window represented by the training data. If all of the training data has not yet been processed, then at block 618, the time step is incremented and processing continues as described above with reference to block 608 (the “Yes” branch from block 618). On the other hand, if all of the training data has been processed, then the time step is not incremented, and processing continues at block 620 (the “No” branch from block 618).
At block 620, the aggregate set of input-output pairs (i.e., {x_i,y_i*}_i=1 ^N), which are the training examples, is given to multi-output regression learner 418 to learn the recurrent activity occurrence predictor 420 by minimizing the given loss function, L. A learned function,
, that is consistent with these imitation training examples will generalize and perform well on new instances.
One potential challenge with exact imitation training is error propagation. That is, errors in early time steps can propagate to downstream decisions and can lead to poor global performance. If the error propagation problem arises, more advanced imitation learning algorithms (e.g., DAGGER) can be used to learn more robust predictors. For example, DAGGER is an iterative algorithm, known to those skilled in the art, that can be viewed as generating a sequence of predictors (one per iteration), where the first iteration corresponds to exact imitation training. In each subsequent iteration, DAGGER makes decisions with the predictor from the previous iteration, and generates additional training examples to learn to recover from any errors. A new predictor is learned from the aggregate set of training examples. The final predictor is selected based on a validation set. DAGGER also has positive theoretical properties and can be seen as a no-regret online learning algorithm.
In an example implementation, the learned recurrent activity predictor is deployed in a real-life application and the predictor is then adapted online based on feedback from users, and the DAGGER algorithm is used to naturally facilitate a life-long learning scenario.

Example Facility Automation Operation

FIG. 7 illustrates an example process for implementing facility automation based on data-driven activity prompting as described herein. The process is illustrated as a collection of blocks in a logical flow graph, which represents a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions stored on one or more computer storage media that, when executed by one or more processors, cause the processors to perform the recited operations. Note that the order in which the process is described is not intended to be construed as a limitation, and any number of the described process blocks can be combined in any order to implement the process, or alternate processes. Additionally, individual blocks may be deleted from the process without departing from the spirit and scope of the subject matter described herein. Furthermore, while this process is described with reference to the computing device 112 described above with reference to FIG. 4, other computer architectures may implement one or more portions of these processes, in whole or in part.
At block 702, one or more next predicted activity occurrence time are determined. For example, activity prediction module 122 analyzes labeled sensor event data to determine predicted next activity occurrence times.
At block 704, the next predicted activity is determined. For example, facility automation module 124 analyzes the predicted next activity occurrence times to determine the next activity having the soonest future predicted activity occurrence time.
At block 706, it is determined whether or not the next predicted activity has an associated facility automation. For example, some predicted activities may have an associated facility automation (e.g., turning on lights or adjusting temperature for bed-to-toilet transition, enter home, leave home, relax, or sleep), while other predicted activities may not have an associated facility automation (e.g., eat, personal hygiene, wash dishes, or work may not have an associated facility automation).
If it is determined that the next predicted activity does not have an associated facility automation (the “No” branch from block 706), then processing continues as described above with reference to block 702.
On the other hand, if it is determined that the next predicted activity does have an associated facility automation (the “Yes” branch from block 706), then at block 708, a difference between the current time and the predicted next occurrence time of the determined next activity is compared to a threshold value. In an example implementation, different activities may have different threshold values.
If it is determined that the current time is not within a threshold time period of the predicted next activity occurrence (the “No” branch from block 708), then processing continues at block 708. On the other hand, when it is determined that the current time is within the threshold time period of the predicted next activity occurrence (the “Yes” branch from block 708), then at block 710, the facility automation associated with the next predicted activity is performed. For example, lights may be turned on or off or temperature may be adjusted in anticipation of the next predicted activity.

Example Personal Computing Device for Activity Prompting

FIG. 8 illustrates example components of a personal computing device 126 implemented to support activity prompting within a smart environment. Example personal computing device 126 may be implemented as a desktop computer, a laptop computer, a tablet computer, a mobile phone, or any other network-enabled personal computing device.
Example personal computing device 126 includes network interface(s) 802, processor(s) 804, and memory 806. Network interface(s) 802 enable personal computing device 126 to receive and/or send data over a network, for example, as illustrated and described above with reference to FIG. 1. Processor(s) 804 are configured to execute computer-readable instructions to perform various operations. Computer-readable instructions that may be executed by the processor(s) 804 are maintained in memory 806, for example, as various software modules.
In an example implementation, memory 806 may maintain any combination or subset of components including, but not limited to, operating system 808, activity prompting application 128, and other applications 810.
Activity prompting application 128 may include, for example, configuration user interface 812, activity prompt user interface 814, prompt generator 816, pending prompts 818, and user feedback 820.
In an example, configuration user interface 812 may be configured to enable a user to set one or more preferences. For example, a user may be allowed to specify specific activities for which they do or do not wish to receive prompts. As another example, a user may be allowed to specify a relative time at which they would like to receive a prompt. For example, a user may specify that they want to be prompted no more than five minutes before the predicted activity time. A user may also be able to specify a sound and/or visual indicator to be presented as part of the activity prompt.
Activity prompt user interface 814 enables presentation of an activity prompt. In an example, an activity prompt may include any combination of a visual prompt, an audio prompt, a tactile prompt (e.g. vibration of a mobile phone), and a user feedback mechanism.
Prompt generator 816 is configured to receive activity occurrence predictions from activity prediction server 112, and generate prompts to be presented to a user of the personal computing device 126. Prompt generator 816 generates a prompt and determines a time at which the prompt is to be presented. Prompts that are to be presented at a later time are stored in pending prompts store 818 until the time at which they are to be presented.
User feedback store 820 stores data received from a user in response to an activity prompt. For example, as illustrated in FIG. 3, a user may provide feedback indicating they have already done the activity, they are doing the activity now, they will do the activity later, or that they are choosing to ignore the activity prompt. User feedback in response to activity prompts can be used to modify prompt configuration settings and/or to improve the accuracy of future activity occurrence predictions.

Example Activity Prompting Operation

FIG. 9 illustrates an example process for implementing data-driven activity prompting as described herein. The process is illustrated as a collection of blocks in a logical flow graph, which represents a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions stored on one or more computer storage media that, when executed by one or more processors, cause the processors to perform the recited operations. Note that the order in which the process is described is not intended to be construed as a limitation, and any number of the described process blocks can be combined in any order to implement the process, or alternate processes. Additionally, individual blocks may be deleted from the process without departing from the spirit and scope of the subject matter described herein. Furthermore, while this process is described with reference to the computing device 112 and personal computing device 126 described above with reference to FIGS. 4 and 8, other computer architectures may implement one or more portions of these processes, in whole or in part.
At block 902, activity prompting application 128 sends to activity prediction server 112, a request for activity occurrence predictions. In an example implementation, activity prompting application 128 is configured to send activity prediction requests periodically (e.g., every 15 minutes or other, possibly configurable, time period).
At block 904, activity prediction server 112 receives the request from the personal computing device 126. For example, the request is received over the network 114.
At block 906, activity prediction server 112 sends the requested activity occurrence predictions to the personal computing device 126. For example, the activity occurrence predictions are sent over the network 114. In an example implementation, activity occurrence predictions may be sent for specifically requested activities, for all activities, for any activities for which the current occurrence prediction has not yet been sent, and so on.
At block 908, personal computing device 126 receives activity occurrence predictions from the activity prediction server 112, for example, over the network 114.
At block 910, the activity prompting application 128 compares the received predictions to the current time. For example, prompt generator 816 generates a prompt to be presented, and determines a time at which the prompt is to be presented. The time at which the prompt is to be presented may be based, for example, on a comparison of the current time and the predicted activity occurrence time.
At block 912, it is determined, for each pending prompt, whether or not the current time is greater than or equal to the prompt time. If the current time is not greater than or equal to the prompt time (the “No” branch from block 912), then processing continues as described above with reference to block 910. However, if the current time is greater than or equal to the prompt time (the “Yes” branch from block 912), then at block 914, the activity prompt is presented. For example, activity prompt user interface 814 is invoked to present one or more pending activity prompts.
At block 916, user feedback associated with the prompt may be received. For example, a user may indicate if they have already performed the activity associated with the prompt, a user may indicate that they are ignoring the prompt, a user may indicate that they do not want to be prompted for this particular activity, a user may indicate they do not want to be prompted at this particular time of day, and so on. Any of various types of user feedback may be enabled for a particular activity prompt.
User feedback may be used, for example, by the activity prompting application to configure user settings. For example, feedback indicating that the user is ignoring the prompt or does not wish to receive prompts at a particular time of day can be used to update a user-configurable setting that defines periods of time when the user does not want to be disturbed with activity prompts.
As another example, user feedback may be sent to the activity prediction server 112 and used to improve the training of the activity occurrence predictor 420. For example, if user feedback frequently indicates that the activity has already been performed, then the activity occurrence predictor 420 may be retrained to improve the accuracy of the activity predictions.

CONCLUSION

Data-driven activity occurrence prediction recognition within smart environments may be implemented based on data resulting from known activity recognition techniques. Predicting future occurrence times for activities with a smart environment also facilitates activity prompting which can be effective in encouraging consistent behaviors or even modifying behaviors of individuals within a smart environment.
Although the subject matter has been described in language specific to structural features and/or methodological operations, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or operations described. Rather, the specific features and acts are disclosed as example forms of implementing the claims.

Claims

What is claimed is:

1. A method comprising:

receiving a set of activity recognition training data, the activity recognition training data including a plurality of sensor events, wherein each sensor event is labeled with a corresponding activity class;

training an activity recognition module based on the activity recognition training data;

receiving sensor events from a smart environment;

using the trained activity recognition module to label each sensor event with an activity class to generate labeled sensor event data;

training an activity occurrence predictor based, at least in part, on the labeled sensor event data; and

using the activity occurrence predictor to predict a future occurrence time of one or more activities within the smart environment.

2. A method as recited in claim 1, wherein the future occurrence time is expressed as a date/time.

3. A method as recited in claim 1, wherein the future occurrence time is expressed as a number of time units until a next occurrence of a particular activity.

4. A method as recited in claim 3, wherein a time unit is a second.

5. A method as recited in claim 3, wherein a time unit is a minute.

6. A method as recited in claim 1, wherein training the activity occurrence predictor includes training a regressor function.

7. A method as recited in claim 6, wherein training the regressor function includes training a respective regressor function for each of a plurality of activities.

8. A method as recited in claim 1, wherein training the activity occurrence predictor includes:

determining local features of the labeled sensor event data;

determining context features associated with the labeled sensor event data;

determining a loss function associated with the labeled sensor event data;

using a multi-output regression learner to train the activity occurrence predictor based on the local features and the context features to minimize the loss function.

9. A method as recited in claim 8, wherein the local features include sensor event data labeled with recognized activity classes.

10. A method as recited in claim 8, wherein the context features include data based on previous activity occurrence predictions.

11. A method as recited in claim 8, wherein the loss function is expressed as a root mean squared error.

12. A method as recited in claim 1, further comprising, performing facility automation within the smart environment based, at least in part, on a predicted future occurrence time of a particular activity.

13. A method comprising:

determining an activity of interest;

querying an activity prediction server for a predicted future time associated with the activity of interest;

receiving, from the server, the predicted future time associated with the activity of interest;

comparing the predicted future time to a current time; and

when the current time is equal to or greater than the predicted future time, presenting an activity prompt associated with the activity of interest.

14. A method as recited in claim 13, wherein querying the activity prediction server includes periodically querying the activity prediction server.

15. A method as recited in claim 13, wherein determining the activity of interest includes one or more of:

determining an activity specified in association with user-configured settings;

determining an activity for which no activity prompts are currently pending; or

determining an activity for which an activity prompt is currently pending and is schedule to be presented within a threshold time period.

16. A personal computing device configured to perform the method as recited in claim 13.

17. A mobile phone configured to perform the method as recited in claim 13.

18. A personal computing device comprising:

a processor;

a memory communicatively coupled to the processor;

an activity prompting application stored in the memory and executed on the processor, to configure the personal computing device to perform the method as recited in claim 13.

19. An activity prediction server system comprising:

a processor;

a memory communicatively connected to the processor;

a sensor event data store stored in the memory;

an activity recognition module stored in the memory and executed on the processor, the activity recognition module configured to:

receive sensor event data from sensors within a smart environment;

label a received sensor event as being triggered during a recognized activity; and

store the labeled sensor event data in the sensor event data store; and

an activity prediction module stored in the memory and executed on the processor, the activity prediction module configured to analyze the labeled sensor event data in the sensor event data store to predict a future time of occurrence of a particular activity within the smart environment.