At the end of the activity recognition pipeline, we want to make sure that the classifications are not too volatile, that is, we don't want activities to change every millisecond. A basic approach is to design a filter that ignores quick changes in the activity sequence.

We build a filter that remembers the last window activities and returns the most frequent one. If there are multiple activities with the same score, it returns the most recent one.

First, we create a new SpuriousActivityRemoval class that will hold a list of activities and the window parameter:

class SpuriousActivityRemoval{
  
  List<Object> last;
  int window;
  
  public SpuriousActivityRemoval(int window){
    this.last = new ArrayList<Object>();
    this.window = window;
  }

Next, we create the Object filter(Object) method that will take an activity and return a filtered activity. The method first checks whether we have enough observations. If not, it simply stores the observation and returns the same value, as shown in the following code:

  public Object filter(Object obj){
    if(last.size() < window){
      last.add(obj);
      return obj;
  }

If we already collected window observations, we simply return the most frequent observation, remove the oldest observation, and insert the new observation:

    Object o = getMostFrequentElement(last);
    last.add(obj);
    last.remove(0);
    return o;
  }

What is missing here is a function that returns the most frequent element from a list of objects. We implement this with a hash map, as follows:

  private Object getMostFrequentElement(List<Object> list){
    
    HashMap<String, Integer> objectCounts = new HashMap<String, Integer>();
    Integer frequntCount = 0;
    Object frequentObject = null;

Now, we iterate over all the elements in the list, insert each unique element into a hash map, or update its counter if it is already in the hash map. At the end of the loop, we store the most frequent element that we found so far, as follows:

    for(Object obj : list){
      String key = obj.toString();
      Integer count = objectCounts.get(key);
      if(count == null){
        count = 0;
      }
      objectCounts.put(key, ++count);
      
      if(count >= frequntCount){
        frequntCount = count;
        frequentObject = obj;
      }
    }
    
    return frequentObject;
  }
  
}

Let's run a simple example:

String[] activities = new String[]{"Walk", "Walk", "Walk", "Run", "Walk", "Run", "Run", "Sit", "Sit", "Sit"};
SpuriousActivityRemoval dlpFilter = new SpuriousActivityRemoval(3);
for(String str : activities){
  System.out.println(str +" -> "+ dlpFilter.filter(str));
}

The example outputs the following activities:

Walk -> Walk
Walk -> Walk
Walk -> Walk
Run -> Walk
Walk -> Walk
Run -> Walk
Run -> Run
Sit -> Run
Sit -> Run
Sit -> Sit

The result is a continuous sequence of activities, that is, we do not have quick changes. This adds some delay, but unless this is absolutely critical for the application, it is acceptable.

Activity recognition may be enhanced by appending n previous activities as recognized by the classifier to the feature vector. The danger of appending previous activities is that the machine learning algorithm may learn that the current activity is always the same as the previous one, as this will often be the case. The problem may be solved by having two classifiers, A and B: the classifier B's attribute vector contains n previous activities as recognized by the classifier A. The classifier A's attribute vector does not contain any previous activities. This way, even if B gives a lot of weight to the previous activities, the previous activities as recognized by A will change as A is not burdened with B's inertia.

All that remains to do is to embed the classifier and filter into our mobile application.

There are two ways to incorporate a classifier into a mobile application. The first one involves exporting a model in the Weka format, using the Weka library as a dependency in our mobile application, loading the model, and so on. The procedure is identical to the example we saw in Chapter 3, Basic Algorithms – Classification, Regression, and Clustering. The second approach is more lightweight; we export the model as a source code, for example, we create a class implementing the decision tree classifier. Then we can simply copy and paste the source code into our mobile app, without event importing any Weka dependencies.

Fortunately, some Weka models can be easily exported to source code by the toSource(String) function:

// Output source code implementing the decision tree
System.out.println("Source code:
" + 
  model.toSource("ActivityRecognitionEngine"));

This outputs an ActivityRecognitionEngine class that corresponds to our model. Now, let's take a closer look at the outputted code:

class ActivityRecognitionEngine {

  public static double classify(Object[] i)
    throws Exception {

    double p = Double.NaN;
    p = ActivityRecognitionEngine.N17a7cec20(i);
    return p;
  }
  static double N17a7cec20(Object []i) {
    double p = Double.NaN;
    if (i[64] == null) {
      p = 1;
    } else if (((Double) i[64]).doubleValue() <= 10.353474) {
    p = ActivityRecognitionEngine.N65b3120a1(i);
    } else if (((Double) i[64]).doubleValue() > 10.353474) {
      p = 2;
    } 
    return p;
  }
...

The outputted ActivityRecognitionEngine class implements the decision tree that we discussed earlier. The machine-generated function names, such as N17a7cec20(Object []), correspond to decision tree nodes. The classifier can be called by the classify(Object[]) method, where we should pass a feature vector obtained by the same procedure as we discussed in the previous sections. As usual, it returns a double, indicating a class label index.