Software Implementation

5.2. Target Tracking

n k

= 1 k!

k

X

i=0

(−1)ⁱ k

i

(k−i)ⁿ (5.3)

For an unspecified number of targets, the number of possible hypotheses followsBell’s Num-ber [9]:

B_n=

n

X

k=0

nn k

o

(5.4) For the evaluation, we tested window sizes between 10 and 20; higher values proved too time consuming to test out. For a window size of 20, the number of possible hypotheses exceeds 474 trillion>4.74×10¹³. Since it is not possible to retain all hypotheses in memory, we apply a number of filters to remove the least likely ones and remove unnecessary ones (for example, hypotheses for which a more likely hypothesis with a higher signal-to-noise ratio exists) to reduce the overall number of hypotheses. There are various metrics by which we can eliminate a large number of hypotheses before or after they are evaluated. The filters implemented for our evaluation are described in Section 5.2.2.3. The thresholds were chosen based on personal observations, but some general suggestions can be made. For example, the less powerful the hardware on which the algorithm runs, the stricter should the filters be. If the hardware allows, the filters can be disabled altogether.

Figure 5.7 shows – on a logarithmic scale – an example for the number of hypotheses for eleven events and how different filters affect the number of hypotheses retained. As we can see, the gating does not have a significant effect, though its impact varies with the size of the gate. Confidence and similarity filters lower the number of hypotheses by several magnitudes.

The filters are:

Gating Removes hypotheses where the the previous event is far away from the current event.

Confidence Removes hypotheses that are below a fixed or relative (to the most likely hypoth-esis) probability threshold.

Similarity A hypothesis is removed if a similar hypothesis with a higher probability exists. The similarity of two hypotheses is defined by the sum of the Levenshtein distance [49] of their tracks.

Combined A combination of all of the above.

Figure 5.7.: Number of hypotheses across window size with various filters

Overview The core logic of the algorithm is implemented in the MHTFilter class. To set up the tracking, anMHTFilter must be instantiated. The constructor requires a Directed-WeightedPseudograph, an implementation of a graph that allows multiple weighted edges between nodes, provided byJGraphT.

New sensor events are added to the tracking by calling the MHTFilter’s update method.

At each update, multiple new PathHypotheses are created based on the pool of currently maintained hypotheses.

For each path, aPathHypothesismaintains aFilterand aMovementPath. The former stores all data necessary for calculating the location probability of a target, such as the prior and posterior probability for recursive Bayesian filtering and a sensor model (hit andmiss prob-abilities for correct and incorrect sensor activations). The latter serves mainly as a data store for the raw sensor events and provides metrics such as a similarity measure and a count of the number of sensor events classified as noise.

The BayesianGraphFilteris the primary Bayes’ filter implementation used for the first evaluations. We will later extend the filter concept by overriding the activity model, which will be used later to evaluate whether body-worn sensors help improving the tracking precision.

All classes are implemented as a Maven⁵package in Java using OpenJDK 11⁶.

MHTFilter The MHTFilter is the core of the tracking system: it is the place for data prepro-cessing, such as filtering sensor events or manipulating them for faster processing; it provides an updatemethod which generates new hypotheses out of a pool of previous ones; it imple-ments the evaluation function for hypotheses, it maintains the pool of hypotheses, and therefore all targets and paths.

The creation of new hypotheses is parallelized in a private class calledHypoRunner. For each hypothesis from the hypothesis pool, a newHypoRunner is instantiated that will create at least three copies of this hypothesis for each of the events in the update:

1. a copy for each of the tracks being associated with the new event,

5https://maven.apache.org/

6https://openjdk.java.net/

5.2. Target Tracking 2. a copy where the new event constitutes the beginning of a new track and

3. a copy where the new event is discarded as noise.

After collecting all children hypotheses from theHypoRunnerinstances, they are subjected to a number of filters designed to minimize the size of the hypothesis pool. The following list shows the filters implemented as well as the values set for our evaluation (probability and similarity values are given as percentage values). It should be noted, however, that neither the type of filter nor its parameters are in any way fixed other than by the specifications of the hardware the algorithm runs on.

• Discard all hypotheses that do not reach a global minimum probability threshold (10),

• Discard all hypotheses that have a probability smaller than the probability of the most likely hypothesis divided by a factor (3),

• Discard all hypotheses where the new event is outside of the “gate”,

• Discard all hypotheses that have a probability lower than the probability of the most likely hypothesis minus a subtrahend (70),

• Discard all hypotheses that aresimilar to a more likely hypothesis and contain more noise (similarityScore> 95).

If exactly one hypothesis remains, it is accepted. That means, the track data in it is stored and the window sizereset. If more than one hypothesis remains, the checkForConsensus method will compare the track data in all remaining hypotheses chronologically and mark all events as accepted that are associated to the same path in all hypotheses.

There are various parameters through which an MHTFilter can be customized that affect the tracking behavior:

gating_max_jumps The size of the gating window, given by the maximally allowed distance on the sensor graph between the current sensor event and the last.

max_hypotheses The maximum number of hypotheses to maintain in order to avoid errors due to lack of memory.

min_diff_to_accept If a hypothesis “dominates”, i.e. it is significantly more likely than any other hypothesis, it can be accepted if its probability is this much larger than the next likely hypothesis’.

min_global_confidence Discard all hypotheses that have a confidence below this value.

similarity_threshold If two hypotheses score this much or higher on a similarity score, discard one if it is less likely and contains more noise.

PathHypothesis A PathHypothesis maintains all data necessary to maintain, evaluate and update a hypothesis. This mainly refers toArrayLists ofFilters andMovementPaths, but also a reference to the underlying sensor graph to calculate distances. Note that the use of ArrayListallows for quickly adding and removing of targets. Each PathHypothesis contains a reference to the hypothesis it was derived from, and its ID will be generated from its “parent hypothesis”, so that it is easy to retrace how the hypothesis was formed.

MovementPath The MovementPath class is a data store for sensor events that are com-bined into a “track”. It also provides utility functions and metrics, such as the amount of noise in the track or calculating theLevenshtein distance⁷between two tracks.

BayesianGraphFilter The core functionality of aFilteris to calculate and store the location probabilities for a target. The target states are derived from the sensor graph introduced via theMHTFilter. TheBayesianGraphFiltercalculates location probabilities using Bayes’

theorem,

P(x|y) = P(y|x)P(x)

P(y) (5.5)

whereP(x|y)is the the probability of the target being at locationxgiven an event at sensory (referred to as theposterior probability),P(y|x)is the probability of a sensorybeing triggered given the target locationx(referred to as thesensor model),P(x)theprior location probability and P(y) the probability of sensor y triggering regardless of target location (referred to as evidence). Commonly, the priors are uniformly distributed at initialization.

In theBayesianGraphFilter, the sensor model is defined by ahitandmissprobability, which define the probability of the sensor reporting an event given a target has entered its sensing area and the probability of the sensornotreporting an event given a target has entered its sensing area. For the evaluation, these values are set to static values of 0.96 and 0.02 based on experience with the hardware used.

An overview of the main components and their interactions is depicted in Figure 5.8.