\section{Filtering}

	\commentByFrank{eval und transition tauschen von der reihenfolge?}

	\subsection{Evaluation}

		\commentByFrank{brauchen wir hier noch was (kurze einleitung) oder passt das so?}

		\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 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}
				\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 Monte Carlo 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.
				
				
		\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 \{ \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}
					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. 
			
			
			\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?}