184 lines
11 KiB
TeX
184 lines
11 KiB
TeX
%\section{Filtering}
|
|
\subsection{Evaluation}
|
|
\label{sec:eval}
|
|
|
|
%\subsubsection{Barometer}
|
|
%\label{sec:sensBaro}
|
|
|
|
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 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 tracking 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 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.
|
|
\label{eq:baroEval}
|
|
\end{equation}
|
|
%
|
|
%
|
|
%
|
|
%\subsubsection{Wi-Fi \& iBeacons}
|
|
|
|
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. 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 the 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 these 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}
|
|
\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}
|
|
|
|
|
|
|
|
\subsection{Transition}
|
|
\label{sec:transition}
|
|
|
|
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.
|
|
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 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 MC methods \cite{Isard98:CCD}.
|
|
|
|
%\commentByFrank{ist das verstaendlich oder schon zu kurz?}
|
|
|
|
%\subsubsection{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 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:
|
|
|
|
%\subsubsection{Architectural Facts}
|
|
% 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.
|
|
|
|
%\commentByFrank{Architectural hab ich mal gelassen, aber so umgeschrieben, dass es keinen bezug mehr zum pfad hat}
|
|
% Walking a grid of vertices without architectural knowledge, would evenly include vertices, a pedestrian
|
|
% is unlikely to encounter: e.g. vertices that are (very) close to walls.
|
|
% To ensure realistic (human like) movements, we include architectural knowledge to prioritise some of the grid's vertices \cite{Ebner-16}:
|
|
% Each vertex's distance from the nearest wall is used to determine its likelihood and thus downvote nodes close to walls and
|
|
% other obstacles. Obviously this has a negative effect on doors, which are surrounded by walls. Therefore, doors are detected
|
|
% as well and favoured by increasing their likelihood.
|
|
|
|
%\subsubsection{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$
|
|
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 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 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 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)
|
|
\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$.
|
|
|
|
%\subsubsection{Activity-Detection}
|
|
Additionally we perform a simple activity detection for the pedestrian, able to distinguish between several actions
|
|
$\mObsActivity \in \{ \tt{unknown}, \tt{standing}, \tt{walking}, \tt{stairs\_up}, \tt{stairs\_down} \}$.
|
|
%
|
|
%\commentByFrank{bei mir ueberlappt aktuell nix, muessten mal testen was besser ist. beim ueberlappen ist das delay halt kuerzer. denke das schon ok.}
|
|
%
|
|
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.
|
|
We use a naive 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.
|
|
%
|
|
Similarly to the above, this knowledge is then 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.
|
|
If no information of the current activitiy could be obtained, no influence is exerted on the edges.
|
|
|
|
% \begin{equation}
|
|
% p(\mEdgeAB)_\text{act} =
|
|
% \footnotesize{
|
|
% \begin{cases}
|
|
% 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}
|
|
|
|
|
|
% 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.
|
|
|
|
|
|
|
|
%\todo{Was passiert wenn ein überlappendes Fenster zwei verschiedene Aktivitäten zugewiesen bekommt? Sliding windows evtl. weglassen?}
|
|
|
|
|