toni/IPIN2016
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

added comments

Browse Source 
worked on eval and transition
This commit is contained in:
kazu
2016-05-03 13:01:02 +02:00
parent 5bde96df3a
commit ce1a1b4d99
5 changed files with 132 additions and 86 deletions
Download Patch File Download Diff File Expand all files Collapse all files

148
tex/chapters/filtering.tex
View File

@@ -1,23 +1,26 @@
\section{Filtering}
\label{sec:filtering}
\commentByToni{Bin mir nicht sicher ob wir diese Section überhaupt brauchen. Könnte man bestimmt auch einfach unter Section 3 packen. Aber dann können wir ungestört voneinander schreiben.}
%\section{Filtering}
%
% \label{sec:filtering}
%
% \commentByToni{Bin mir nicht sicher ob wir diese Section überhaupt brauchen. Könnte man bestimmt auch einfach unter Section 3 packen. Aber dann können wir ungestört voneinander schreiben.}
%
\section{Evaluation}
\commentByFrank{brauchen wir hier noch was (kurze einleitung) oder passt das so?}
\subsection{Barometer}
\label{sec:sensBaro}
%
The probability of currently residing on a given floor is evaluated using the smartphone's barometer.
Environmental influences are circumvented by using relative pressure readings instead of absolute ones.
To reduce the impact of noisy sensors, we calculate the average of several sensor reading, carried out
while the pedestrian chooses his destination. This $\overline{\mObsPressure}$ serves as relative base.
Likewise, we estimate the sensor's uncertainty $\sigma_\text{baro}$ for later use within the evaluation step.
The probability of currently residing on a floor is evaluated using the smartphone's barometer.
Environmental influences are circumvented by using relative pressure values instead of absolute ones.
To reduce the impact of noisy sensors, we calculate the average $\overline{\mObsPressure}$ of several
sensor readings, carried out while the pedestrian chooses his destination. This average serves as relative base
for all future measurements. Likewise, we estimate the sensor's uncertainty $\sigma_\text{baro}$ for later use
within the evaluation step.
In order to evaluate relative pressure readings, we need a prediction to compare them with. Therefore, each
In order to evaluate the relative pressure readings, we need a prediction to compare them with. Therefore, each
transition from $\mStateVec_{t-1}$ to $\mStateVec_t$ estimates the state's relative pressure prediction
$\mStatePressure$ by examining every height-change ($z$-axis):
$\mStatePressure$ by tracking every height-change ($z$-axis):
%
\begin{equation}
\mState_{t}^{\mStatePressure} = \mState_{t-1}^{\mStatePressure} + \Delta z \cdot b
@@ -30,8 +33,8 @@
\end{equation}
%
In \refeq{eq:baroTransition}, $b$ denotes the common pressure change in $\frac{\text{hPa}}{\text{m}}$.
The evaluation step compares the predicted relative pressure with the observed
one using a normal distribution with the previously estimated $\sigma_\text{baro}$:
The evaluation step for time $t$ compares every predicted relative pressure $\mState_t^{\mStatePressure}$ with the observed
one $\mObs_t^{\mObsPressure}$ using a normal distribution with the previously estimated $\sigma_\text{baro}$:
%
\begin{equation}
p(\mObsVec_t \mid \mStateVec_t)_\text{baro} = \mathcal{N}(\mObs_t^{\mObsPressure} \mid \mState_t^{\mStatePressure}, \sigma_\text{baro}^2) \enspace.
@@ -42,16 +45,28 @@
%
\subsection{Wi-Fi \& iBeacons}
%
The smartphone's \docWIFI{} and \docIBeacon{} component provides absolute location estimation by
The smartphone's \docWIFI{} and \docIBeacon{} component provides an absolute location estimation by
measuring the signal-strengths of nearby transmitters. The positions of detected \docAP{}s (\docAPshort{}) and \docIBeacon{}s
are known beforehand. This allows a comparison of each measurement with a corresponding estimation
using the wall-attenuation-factor signal strength prediction model \cite{Ebner-15}. This model uses the 3D distance $d$ and the
number of floors $\Delta f$ between transmitter and the state-in-question:
are known beforehand. Using the wall-attenuation-factor signal strength prediction model \cite{Ebner-15}, we are able to
compare each measurement with a corresponding estimation. To infer this estimation, the prediction model
uses the 3D distance $d$ and the number of floors $\Delta f$ between transmitter and the state-in-question $\mStateVec$:
%
\begin{equation}
P_r(d, \Delta f) = \mTXP - 10 \mPLE \log_{10}{\frac{\mMdlDist}{\mMdlDist_0}} + \Delta{f} \mWAF \enspace ,
\label{eq:waf}
\end{equation}
%
In \refeq{eq:waf}, there are three more parameters per \docAPshort{}. The signal-strength $\mTXP$ measurable at a distance
$\mMdlDist_0$ (usually \SI{1}{\meter}), a path-loss exponent $\mPLE$ describing the transmitter's environment and the attenuation
per floor $\mWAF$.
To reduce the system's setup time, we use the same three values for all \docAP{}s at the cost of accuracy.
All parameters are chosen empirically. Further details on how to determine this parameters exactly,
can be found in \cite{PathLossPredictionModelsForIndoor}.
The same holds for the \docIBeacon{} component, except $\mTXP$,
which is broadcasted by each beacon. However, as \docIBeacon{}s cover only a small area, $\mPLE$ is usually much smaller compared
to the one needed for \docWIFI{}.
As transmitters are assumed to be statistically independent, the overall probability to measure their predictions at a given location is:
%
\begin{equation}
@@ -59,67 +74,60 @@
\prod\limits_{i=1}^{n} \mathcal{N}(\mRssi_\text{wifi}^{i} \mid P_{r}(\mMdlDist_{i}, \Delta{f_{i}}), \sigma_{\text{wifi}}^2) \enspace .
\label{eq:wifiTotal}
\end{equation}
%
The prediction model itself needs three parameters per \docAPshort{}: $\mTXP$ measured at a distance
$\mMdlDist_0$ (usually \SI{1}{\meter}), the path-loss exponent $\mPLE$ describing the environment
and the attenuation per floor $\mWAF$.
\commentByFrank{aufs andere paper beziehen zum kuerzen?}
To reduce the system's setup time, we use the same values for all \docAP{}s at the cost of accuracy.
All parameters are chosen empirically. Further details on how to determine this parameters exactly,
can be found in \cite{PathLossPredictionModelsForIndoor}.
The same holds for the \docIBeacon{} component, except $\mTXP$, which is broadcasted by each beacon.
As \docIBeacon{}s cover only a small area, $\mPLE$ is usually much smaller compared to the one needed for \docWIFI{}.
%
\section{Transition}
\label{sec:transition}
The distribution $p(\mStateVec_{t} \mid \mStateVec_{t-1})$ is sampled via random walks on a graph
$G=(V,E)$, which is generated from the buildings floorplan \todo{FUSION2016}.
$p(\mStateVec_{t} \mid \mStateVec_{t-1})$ is determined by walking along adjacent edges $\mEdgeAB$ connecting
The transition-distribution $p(\mStateVec_{t} \mid \mStateVec_{t-1})$ is sampled via random walks on a graph
$G=(V,E)$, which is generated from the buildings floorplan \cite{Ebner-16}.
Each walk starts at $\mStateVec_{t-1}$ and uses adjacent edges $\mEdgeAB$ connecting
two vertices $\mVertexA, \mVertexB \in V$ until a certain distance $\gDist$ is reached.
Thus, the position of any $\mStateVec$ is represented by the position $\fPos{\mVertexA}$ of the corresponding vertex.
Hereby, the position of any $\mStateVec$ is represented by the position $\fPos{\mVertexA}$ of its corresponding vertex $\mVertexA$.
This approach draws only valid movements, as ambient conditions (walls, doors, stairs, etc.) are considered.
While sampling, to-be-walked edges are not chosen uniformly, but depending on a probability $p(\mEdgeAB)$.
The latter depends on several constraints and recent sensor-readings from the smartphone. Using sensors
The latter depends on several constraints and recent sensor-readings from the smartphone. Using those readings
directly within the transition step provides a more robust posterior distribution. Adding them to the evaluation
instead, would lead to sample impoverishment due to the used Monte Carlo methods.
instead, would lead to sample impoverishment due to the used Monte Carlo methods \cite{Isard98:CCD}.
\commentByFrank{ist das verstaendlich oder schon zu kurz?}
\subsection{Pedestrian's Destination}
We assume the pedestrian's desired destination to be known beforehand. This prior knowledge is incorporated
during the random walk using $p(\mEdgeAB)_\text{path}$, which is a simple heuristic, favouring movements (edges)
approaching the chosen destination with a ratio of $0.9:0.1$ over those, departing from the destination
\cite{FUSION2016}. The underlying shortest-path is based on a special distance metric, considering special
architectural facts:
approaching his chosen destination with a ratio of $0.9:0.1$ over those, departing from the destination
\cite{Ebner-16}. The underlying shortest-path uses Dijkstra's algorithm with special weight (distance) metric,
considering special architectural facts:
\subsection{Architectural Facts}
To ensure realistic path estimations, we include additional architectural knowledge.
Each vertex's distance from the nearest wall is used to prevent the shortest-path from clinging to walls.
Likewise, his distance from the nearest door (favour ).
Normally, the shortest-path calculated for a narrow grid would stick unnaturally close to obstacles like walls.
To ensure realistic (human like) path estimations, we include architectural knowledge within Dijkstra's edge-weight function \cite{Ebner-16}:
Each vertex's distance from the nearest wall is used to artificially increase the edge-weight and thus prevent the shortest-path
from clinging to walls. Obviously this has a negative effect on doors which are surrounded by walls. Therefore, doors are detected
and favoured by decreasing their edge-weight.
\subsection{Step- \& Turn-Detection}
Steps and turns are detected using the smartphone's IMU, implemented as described in \cite{Ebner-15}.
The number of steps detected since the last transition is used to estimate the to-be-walked distance $\gDist$
assuming a fixed step-size with some deviation:
by assuming a fixed step-size with some deviation:
%
\begin{equation}
\gDist = \mObs_{t-1}^{\mObsSteps} \cdot \mStepSize + \mathcal{N}(0, \sigma_{\gDist}^2)
\enspace .
\end{equation}
%
Turn-Detection supplies the magnitude of the detected heading change by integrating the gyroscope's change
Turn-Detection supplies the magnitude of the detected heading change by integrating over the gyroscope's change
since the last transition. Together with some deviation and the state's previous heading, the magnitude is
used to estimate the state's current heading:
used to estimate the current state's heading:
%
\begin{equation}
\gHead = \mState_{t}^{\mStateHeading} = \mState_{t-1}^{\mStateHeading} + \mObs_{t-1}^{\mObsHeading} + \mathcal{N}(0, \sigma_{\gHead}^2) \\
\end{equation}
%
During the random walk, edges should satisfy the heading:
During the random walk, edges should satisfy the current heading and are thus drawn according to their resemblance:
%
\begin{equation}
p(\mEdgeAB)_\text{head} = p(\mEdgeAB \mid \gHead) = \mathcal{N} (\angle \mEdgeAB \mid \gHead, \sigma_\text{head}^2)
@@ -129,49 +137,45 @@
%
While the distribution \refeq{eq:transHeading} does not integrate to $1.0$ due to circularity of angular
data, in our case, the normal distribution can be assumed as sufficient for small enough $\sigma^2$.
\subsection{Activity-Detection}
Additionally we perform a simple activity detection for the pedestrian, able to distinguish between
standing, walking, walking stairs upwards and downwards. Likewise, this knowledge
is evaluated when walking the grid: Edges $\mEdgeAB$ matching the currently detected
activity are favoured using $p(\mEdgeAB)_\text{act} = 0.8$ and $0.2$ otherwise.
Additionally we perform a simple activity detection for the pedestrian, able to distinguish between several actions
$\mObsActivity \in \{ \text{unknown}, \text{standing}, \text{walking}, \text{stairs\_up}, \text{stairs\_down} \}$.
Likewise, this knowledge is evaluated when walking the grid: Edges $\mEdgeAB$ matching the currently detected
activity are favoured using $p(\mEdgeAB)_\text{act} = 0.8$ and $0.2$ otherwise:
\begin{equation}
p(\mEdgeAB)_\text{act} =
\footnotesize{
\begin{cases}
0.8 & \text{stairs\_up}, \fPos{\mVertexB}_z > \fPos{\mVertexA}_z \\
0.2 & \text{stairs\_up}, \fPos{\mVertexB}_z \le \fPos{\mVertexA}_z \\
1.0 & \mObsActivity = \text{unknown} \\
0.8 & \mObsActivity = \text{stairs\_up} \land \fPos{\mVertexB}_z > \fPos{\mVertexA}_z \\
0.2 & \mObsActivity = \text{stairs\_up} \land \fPos{\mVertexB}_z \le \fPos{\mVertexA}_z \\
\cdots
\end{cases}
}\enskip .
\end{equation}
\commentByFrank{das switch ist wahrscheinlich unnoetig und der text reicht}
\commentByFrank{hier passen die sachen vom lukas. kurze beschreibung der beiden geschaetzten verteilungen etc}
% Activity Recognition
% Naives Bayes als Klassifikator
% Features -> 1: Variance of mean 2: Differenz zwischen Barometer
% Zeitintervall für das die Merkmale berechnet werden
\commentByFrank{weg mit diesem absatz? das hatte ich ja schon beschrieben}
The transition model includes a simple recognizer of different locomotion modes like normal walking or ascending/descending stairs. The reasoning behind this is to favour paths that correspond with the detected locomotion mode.
We use a Naives Bayes classifier with two features. For this, the sensor signals are split in sliding windows. Each window has a length of one second and overlaps 500 ms with its prior window.
The first feature is the variance of the accelerometer's magnitude during a window and the second feature is the difference between the last and first barometer measurement of the particular window.
Based on these features the classifier assigns an activity to each sliding window.
\todo{Was passiert wenn ein überlappendes Fenster zwei verschiedene Aktivitäten zugewiesen bekommt? Sliding windows evtl. weglassen?}
\commentByFrank{bei mir ueberlappt aktuell nix, muessten mal testen was besser ist. beim ueberlappen ist das delay halt kuerzer. denke das schon ok.}
\commentByFrank{satzreihenfolge war komisch -> angepasst}
For this, the sensor signals are split in sliding windows. Each window has a length of one second and overlaps 500 ms with its prior window.
\commentByFrank{navies: naive?}
We use a Naives Bayes classifier with two features. The first one is the variance of the accelerometer's magnitude within a window.
The second feature is the difference between the last and first barometer measurement of the particular window.
Based on these features the classifier assigns an activity to each of the sliding windows.
%\todo{Was passiert wenn ein überlappendes Fenster zwei verschiedene Aktivitäten zugewiesen bekommt? Sliding windows evtl. weglassen?}