\section{Indoor Positioning System}
\label{sec:system}

	Our smartphone-based indoor localization system estimates a pedestrian's current location and heading
	using recursive density estimation \changed{\cite{particleFilter,robotics}}
	seen in \refeq{eq:recursiveDensity}.
	
		\begin{equation}
		%\arraycolsep=1.2pt
		%\begin{array}{ll}
			p(\mStateVec_{t} \mid \mObsVec_{1:t}) \propto\\ 
				\underbrace{p(\mObsVec_{t} \mid \mStateVec_{t})}_{\text{evaluation}}
				\int \underbrace{p(\mStateVec_{t} \mid \mStateVec_{t-1}, \mObsVec_{t-1})}_{\text{transition}}
				\underbrace{p(\mStateVec_{t-1} \mid \mObsVec_{1:t-1})d\vec{q}_{t-1}}_{\text{recursion}} \enspace,
		%\end{array}
		\label{eq:recursiveDensity}
	\end{equation}
	
	The pedestrian's hidden state $\mStateVec$ is given by
	\begin{equation}
		\mStateVec = (x, y, z, \mStateHeading),\enskip
		x, y, z, \mStateHeading \in \R \enspace,
	\end{equation}
	%
	where $x, y, z$ represent its position in 3D space and $\mStateHeading$ his current (absolute) heading.
	
	The corresponding observation vector, given by the smartphone's sensors, is defined as
	%
	\begin{equation}
		\mObsVec = (\mRssiVecWiFi{}, \mObsSteps, \mObsHeadingRel, \mObsHeadingAbs, \mPressure, \mObsGPSVec) \enspace.
	\end{equation}
	%
	$\mRssiVecWiFi$ contains the signal strength measurements of all \docAP{}s (\docAPshort{}s) currently visible to the phone,
	$\mObsSteps$ describes the number of steps detected since the last filter-step,
	$\mObsHeadingRel$ the (relative) angular change since the last filter-step,
	$\mObsHeadingAbs$ the vague absolute heading as provided by the magnetometer,
	$\mPressure$ the ambient pressure in hPa and
	$\mObsGPSVec = ( \mObsGPSlat, \mObsGPSlon, \mObsGPSaccuracy)$ the current location given by the GPS.
	If the latter is currently not available, this is indicated by a special value combination, which
	is checked within the evaluation.
	
	
	Assuming statistical independence, the state-evaluation density from \refeq{eq:recursiveDensity} can be written as 
	%
	\begin{equation}
		p(\vec{o}_t \mid \vec{q}_t) = 
		p(\vec{o}_t \mid \vec{q}_t)_\text{wifi}\enskip
		p(\vec{o}_t \mid \vec{q}_t)_\text{gps}\enskip
		p(\vec{o}_t \mid \vec{q}_t)_\text{abshead}\enskip
		p(\vec{o}_t \mid \vec{q}_t)_\text{activity}\enskip
		\enspace.
		\label{eq:evalDensity}
	\end{equation}
	%
	
	Besides the evaluation, a movement model, based on random walks on a graph, samples only those transitions
	(= pedestrian movements), that are allowed by the building's floorplan.
	%$p(\mStateVec_{t} \mid \mStateVec_{t-1}, \mObsVec_{t-1})$
	The smartphone's accelerometer, gyroscope, magnetometer, GPS- and \docWIFI{}-module provide
	the observations for both, the transition and the following evaluation step to infer the hidden state,
	namely the pedestrian's location and heading
	\cite{Ebner2016OPN, Fetzer2016OMC}.
	

	Absolute location information is provided by $p(\vec{o}_t \mid \vec{q}_t)_\text{wifi}$ and 
	$p(\vec{o}_t \mid \vec{q}_t)_\text{gps}$, if available. Otherwise, their probability
	is uniformly distributed (same likelihood for any location).
	The vague absolute heading provided by
	the smartphone's magnetometer is included using a simple heuristic for 
	$p(\vec{o}_t \mid \vec{q}_t)_\text{abshead}$. Finally, the barometer is used
	to distinguish between normal walking and climbing stairs within
	$p(\vec{o}_t \mid \vec{q}_t)_\text{activity}$
	\changed{%
		by comparing relative pressure changes. This makes the barometer invariant to long-term pressure fluctuations 
		due to temperature and humidity.		
	}%
	
	Furthermore, the smartphone's IMU is used to infer the number of steps
	and the relative turn angle the pedestrian has taken since the last filter-update.
	While those values could be used within the evaluation \refeq{eq:evalDensity}
	we apply them within the transition model (see \cite{Koeping14-PSA, Ebner2016OPN})
	to estimate the pedestrian's potential
	movement $p(\mStateVec_{t} \mid \mStateVec_{t-1}, \mObsVec_{t-1})$ within the building.
	Using real values to perform this movement-update instead of just scattering randomly 
	along the floorplan followed by downvoting within the evaluation \refeq{eq:evalDensity}
	provides a more stable result.
	
	As this work focuses on \docWIFI{} optimization, not all parts of the localization system were discussed in detail.
	For missing explanations and further details on aforementioned practices,
	please refer to \cite{Ebner2016OPN}.
	%
	Compared to this reference, absolute heading and GPS have been added as additional sensors
	to further enhance the localization.
	\changed{%
		Within \refeq{eq:evalAbsHead}, we favour movements (model transitions \refeq{eq:recursiveDensity})
		with a heading $\pm\SI{120}{\degree}$ around the heading $\mObs_t^{\mObsHeadingAbs}$
		indicated by the smartphone's compass.
		As this sensor is usually inaccurate, we use $\pm\SI{120}{\degree}$ to just prevent walks in the opposite direction.
		The result is normalized using $\xi$.
		A normal distribution in \refeq{eq:evalGPS} is used to model GPS' uncertainty.
	}%
	The difference between the GPS' estimation and potential state $\mStateVec$ is given by the
	Euclidean 2D $\text{distance}(\dots)$ in \refeq{eq:evalGPS}.
	
	
	\begin{equation}
		p(\vec{o}_t \mid \vec{q}_t)_\text{abshead}
		= \xi
		\begin{cases}
			0.7 & 	| \mObs_t^{\mObsHeadingAbs} - \mState_t^{\mStateHeading} | < \SI{120}{\degree}	\\
			0.3	&	\text{else}
		\end{cases}
		,\enskip
		\xi = \text{const}
		\label{eq:evalAbsHead}
	\end{equation}
	
	\begin{equation}
		p(\vec{o}_t \mid \vec{q}_t)_\text{gps} = 
			\mathcal{N}(
				d
				\mid
				0,
				\sigma^2
			), \enskip
			d = \text{distance}(
					(\mObsGPS_\text{lat}, \mObsGPS_\text{lon}),
					(\mState_t^x, \mState_t^y)
				), \enskip
			\sigma = \mObsGPS_\text{accuracy}
		\label{eq:evalGPS}
	\end{equation}
	
	%\todo{neues resampling? je nach dem was sich noch in der eval zeigt}
	
	The GPS sensor should enhance scenarios where multiple, unconnected buildings are involved
	and the pedestrian is required to move outdoors to enter the next facility.
	Indoors the GPS will usually not provide viable location estimations and the system has to
	solely rely on the smartphone's \docWIFI{} observations.
	Therefore its crucial for the \docWIFI{} component to supply location
	estimations that are as accurate as possible,
	while the component itself must be easy to set-up and maintain.

	%\todo{ueberleitung besser?}
