Activity Recognition

[carissalow]

Originally posted by @Meng6

Unify activity recognition data for iOS client

According to the following algorithm, we transform iOS activity recognition raw data into Android's format:

if activities field is automotive, set activity_name = in_vehicle and activity_type = 0
if activities field is cycling, set activity_name = on_bicycle and activity_type = 1
if activities field is walking or running, set activity_name = on_foot and activity_type = 2
if activities field is stationary, set activity_name = still and activity_type = 3
if activities field is unknown, set activity_type = 4

In addition, iOS activity pairs formed by "stationary" and "automotive" labels (driving but stopped at a traffic light) are transformed to "automotive" only.
Calculate activity recognition episodes

We consider the consecutive rows as a single activity episode if (1) any two consecutive rows are logged within certain a threshold from each other (by default, this threshold is 5 minutes); (2) all rows have the same activity_type.
Extract activity recognition features based on activity recognition episodes

We divide episodes to match the beginning and end of day segments (daily, 30 minutes, etc), then extract features for different day segments (epochs) from activity recognition episodes:

"count": number of episodes.
"mostcommonactivity": the most common activity_type. If this feature is not unique the first activity_type of the set of most common activity_types is selected ordered by activity_type.
"countuniqueactivities": number of unique activity_type.
"durationstationary": total duration of episodes of still and tilting (phone) activities.
"durationmobile": total duration of episodes of on foot, running, and on bicycle activities.
"durationvehicle": total duration of episodes of on vehicle activity.

[carissalow]

Originally posted by @sefyas

To reformat iOS activity table in the same scheme as Android activity table we do the following

• if column walking is 1 assign 7 and walking to activity_type and activity_name respectively.
• if column running is 1 assign 8 and running to activity_type and activity_name respectively.
• if column cycling is 1 assign 1 and on_bicycle to activity_type and activity_name respectively.
• if column automotive is 1 assign 0 and in_vehicle to activity_type and activity_name respectively.
• if column stationary is 1 assign 3 and still to activity_type and activity_name respectively.
• if column unknown is 1 assign 4 and unknown to activity_type and activity_name respectively.

If more than one iOS column is 1 for any row we use the following order to decide the reformatting walking > running > cycling > automotive > stationary > unknown. For example, if both automative and stationary are 1, we reformat the row as automative (this is similar to handling both automative and stationary above).

[carissalow]

Originally posted by @sefyas

Our cleanup steps are:

• removing rows with null values under activities (iOS) or activity_type (Android)
• keeping one of multiple rows with the same timestamp (applied to both Android and iOS after being transformed to Android format). The logic to decide what row to keep is as follows: keep the row with highest confidence value. Under equal confidence, use the following priority over activity_type to decide which row to keep: walking > running > on_foot > in_vehicle > on_bicycle > still > tilting > unknown.

We did have multiple rows with the same timestamp and confidence (this is different from having a single row with multiple entries under activities). Instead of picking the first row, we used the logic above to decide which row to keep.

[carissalow]

Originally posted by @sefyas

We briefly discussed other logic for deciding which of the multiple rows to keep in the meeting today. For example, we might want to choose the row with the same activity_type as the previous or next timestamp instead of using a fixed priority list (i.e. walking > running > on_foot > in_vehicle > on_bicycle > still > tilting > unknown).

[carissalow]

Originally posted by @JulioV

We fixed the walking/running conversion to match UW/Ubicomp (types 7 and 8) in e10e030. Still pending is the deduplication based on activity priority

[carissalow]

Originally posted by @sefyas

We decided to implement the following logic to decide what row to keep when there are multiple rows with the same timestamp and confidence: look at previous and next samples if they are close enough (e.g. at most 5 minutes away).

• If they are the same, use their activity_type.
• If they are different, use the activity_type of the closer one
• If they are different and are equally distanced, use the priority list walking > running > on_foot > in_vehicle > on_bicycle > still > tilting > unknown (walking and running are more informative that on_foot and all labels are more informative that unknown).