FHWS/OTHER2017
Archived
3
0
Fork 0
Code Issues 4 Pull Requests Releases Wiki Activity

current TeX and code

Browse Source
This commit is contained in:
FrankE
2017-05-08 14:38:14 +02:00
parent ea887af537
commit 7021034e6d
8 changed files with 107 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
tex/chapters/system.tex
View File

@@ -26,7 +26,7 @@
The corresponding observation vector, given by the smartphone's sensors, is defined as
%
\begin{equation}
\mObsVec = (\mRssiVecWiFi{}, \mObsSteps, \mObsHeadingRel, \mObsHeadingAbs, \mPressure, \mObsGPS) \enspace.
\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,
@@ -34,7 +34,9 @@
$\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
$\mObsGPS = ( \mObsGPSlat, \mObsGPSlon, \mObsGPSaccuracy)$ the current location (if available) given by the GPS.
$\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
@@ -60,7 +62,8 @@
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.
$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
@@ -70,7 +73,8 @@
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 to estimate the pedestrian's potential
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}
@@ -82,15 +86,20 @@
%
Compared to this reference, absolute heading and GPS have been added as additional sensors
to further enhance the localization. As can be seen in \refeq{eq:evalAbsHead} and \refeq{eq:evalGPS},
their values are incorporated using a simple distribution that models each sensor's uncertainty.
their values are incorporated using a distribution (normalized by $\xi$) that matches each sensor's 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 & | \mObsVec_{\mObsHeadingAbs} - \mStateVec_{\mStateHeading} | < \SI{120}{\degree} \\
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}
@@ -104,7 +113,7 @@
), \enskip
d = \text{distance}(
(\mObsGPS_\text{lat}, \mObsGPS_\text{lon}),
(\mStateVec_x, \mStateVec_y)
(\mState_t^x, \mState_t^y)
), \enskip
\sigma = \mObsGPS_\text{accuracy}
\label{eq:evalGPS}
@@ -116,8 +125,8 @@
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 this component to supply location
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?}
%\todo{ueberleitung besser?}