178 lines
8.9 KiB
TeX
178 lines
8.9 KiB
TeX
\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}
|
|
|
|
\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.
|
|
|
|
In order to evaluate 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):
|
|
%
|
|
\begin{equation}
|
|
\mState_{t}^{\mStatePressure} = \mState_{t-1}^{\mStatePressure} + \Delta z \cdot b
|
|
,\enskip
|
|
\Delta z = \mState_{t-1}^{z} - \mState_{t}^z
|
|
,\enskip
|
|
b \in \R
|
|
\enspace .
|
|
\label{eq:baroTransition}
|
|
\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}$:
|
|
%
|
|
\begin{equation}
|
|
p(\mObsVec_t \mid \mStateVec_t)_\text{baro} = \mathcal{N}(\mObs_t^{\mObsPressure} \mid \mState_t^{\mStatePressure}, \sigma_\text{baro}^2) \enspace.
|
|
\label{eq:baroEval}
|
|
\end{equation}
|
|
%
|
|
%
|
|
%
|
|
\subsection{Wi-Fi \& iBeacons}
|
|
%
|
|
The smartphone's \docWIFI{} and \docIBeacon{} component provides 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:
|
|
%
|
|
\begin{equation}
|
|
P_r(d, \Delta f) = \mTXP - 10 \mPLE \log_{10}{\frac{\mMdlDist}{\mMdlDist_0}} + \Delta{f} \mWAF \enspace ,
|
|
\end{equation}
|
|
%
|
|
As transmitters are assumed to be statistically independent, the overall probability to measure their predictions at a given location is:
|
|
%
|
|
\begin{equation}
|
|
\mProb(\mObsVec_t \mid \mStateVec_t)_\text{wifi} =
|
|
\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
|
|
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.
|
|
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
|
|
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.
|
|
|
|
\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:
|
|
|
|
\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 ).
|
|
|
|
|
|
\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:
|
|
%
|
|
\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
|
|
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:
|
|
%
|
|
\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:
|
|
%
|
|
\begin{equation}
|
|
p(\mEdgeAB)_\text{head} = p(\mEdgeAB \mid \gHead) = \mathcal{N} (\angle \mEdgeAB \mid \gHead, \sigma_\text{head}^2)
|
|
\enspace .
|
|
\label{eq:transHeading}
|
|
\end{equation}
|
|
%
|
|
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.
|
|
|
|
\begin{equation}
|
|
p(\mEdgeAB)_\text{act} =
|
|
\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 \\
|
|
\cdots
|
|
\end{cases}
|
|
\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
|
|
|
|
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?}
|
|
|
|
|