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

Merge branch 'master' of https://git.frank-ebner.de/toni/IPIN2016

Browse Source
This commit is contained in:
toni
2016-05-05 10:36:11 +02:00
parent 2fbc10fbd3 9d3efd10c7
commit ba8066507c
1 changed files with 79 additions and 81 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
tex/chapters/filtering.tex
View File

@@ -1,14 +1,12 @@
%\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}
\section{Filtering}
\commentByFrank{eval und transition tauschen von der reihenfolge?}
\subsection{Evaluation}
\commentByFrank{brauchen wir hier noch was (kurze einleitung) oder passt das so?}
\subsection{Barometer}
\subsubsection{Barometer}
\label{sec:sensBaro}
%
The probability of currently residing on a floor is evaluated using the smartphone's barometer.
@@ -43,7 +41,7 @@
%
%
%
\subsection{Wi-Fi \& iBeacons}
\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
@@ -77,8 +75,8 @@
\section{Transition}
\label{sec:transition}
\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}.
@@ -94,14 +92,14 @@
\commentByFrank{ist das verstaendlich oder schon zu kurz?}
\subsection{Pedestrian's Destination}
\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:
\subsection{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
@@ -109,7 +107,7 @@
and favoured by decreasing their edge-weight.
\subsection{Step- \& Turn-Detection}
\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:
@@ -138,7 +136,7 @@
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}
\subsubsection{Activity-Detection}
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} \}$.