FHWS/Fusion2016
Archived
3
0
Fork 0
Code Issues 1 Pull Requests Releases Wiki Activity

latest TeX: grid, experiments, conclusion. some gfx changed

Browse Source
This commit is contained in:
FrankE
2016-02-14 18:35:33 +01:00
parent 53ff0dd29e
commit 0acccf9fdc
10 changed files with 9144 additions and 3251 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
tex/bare_conf.tex
View File

@@ -113,7 +113,7 @@
% gfx include folder
\graphicspath{ {gfx/baro/},{gfx/graph/},{gfx/paths/},{gfx/eval/},{gfx/}}
\graphicspath{ {gfx/baro/},{gfx/graph/},{gfx/paths/},{gfx/eval/},{gfx/},{gfx/grid/}}
% correct bad hyphenation here

15
tex/chapters/conclusion.tex
View File

@@ -1,17 +1,20 @@
\section{Conclusion}
We presented a novel approach for integrating prior navigation knowledge by using realistic human walking paths.
Based on a weighted graph, two different models for walking in a more targeted and natural manner were introduced.
It could be shown that adding this additional knowledge causes an overall improvement of the localisation results, while maintaining flexible for uncertain behaviour.
Furthermore, our approach is able to provide accurate and robust position estimations, even when (normally) necessary calibration processes are ignored.
It could be shown that adding this additional knowledge causes an overall improvement of the localisation results, while maintaining flexibility for unexpected behaviour.
Furthermore, our approach is able to provide accurate and robust position estimations, even when (usually) necessary calibration processes are omitted.
However, providing this calibration knowledge can further improve the results.
In order to reduce the effort of locating the \docAP{}s and calibrating them, a numerical optimization based on predefined walks could be considered.
Additionally, the graph allows for storing pre-computed signal strengths and thus enables more complex prediction models incorporating floor and wall information into the signal strength estimation.
In order to reduce the effort of locating and calibrating \docAP{}s, a numerical optimization based on
measurements during predefined walks could be considered.
Additionally, the graph allows for storing pre-computed signal strengths and thus enables more complex
prediction models e.g. incorporating wall information.
As seen, multimodal distributions lead to faulty position estimations and therefore a rising error.
As seen, multimodal distributions lead to faulty position estimations and therefore rising errors.
One possible method to resolve this issue would be a more suiting location estimation technique.
Another promising way is smoothing.
By deploying a fixed-lag smoother the system would still be perceived as real-time application, but is able to calculate the (delayed) estimation using future measurements up to the latest timestep.
By deploying a fixed-lag smoother the system would still be perceived as real-time application,
but is able to calculate the (delayed) estimation using future measurements up to the latest timestep.

95
tex/chapters/experiments.tex
View File

@@ -13,13 +13,13 @@
During the walk, the pedestrian had to click a button on the smartphone application
when passing a marker. Between two consecutive points, a constant movement speed is assumed.
Thus, the ground truth might not be \SI{100}{\percent} accurate, but fair enough to conduct
error measurements. All walks were performed using a Google Nexus 6 and a Samsung Galaxy S5.
error measurements. All walks were performed using a Motorola Nexus 6 and a Samsung Galaxy S5.
As the Samsung Galaxy S5's \docWIFI{} can not be limited to the \SI{2.4}{\giga\hertz} band only,
its scans take much longer than those of the Google Nexus 6:
its scans take much longer than those of the Motorola Nexus 6:
\SI{3500}{\milli\second} vs. \SI{600}{\milli\second}.
Also, the Nexus' barometer sensor provides readings both more frequent and far more accurate than
the Galaxy does. This results in a much better localisation using the Nexus smartphone.
the Galaxy does. This results in a better localisation using the Nexus smartphone.
Despite being fast enough to run in realtime on the smartphone itself, computation was done offline using
the CONDENSATION particle filter with \SI{7500}{} particles as realization.
@@ -28,21 +28,24 @@
As mentioned earlier, the position of all \docAP{}s (about 5 per floor) is known beforehand.
Due to legal terms, we are not allowed to depict their positions and therefore omit this information within the figures.
Additionally, we used three \docIBeacon{}s for slight enhancements in some areas.
The empirically chosen values for \docWIFI{} were $P_{0_{\text{wifi}}} = \SI{-46}{\dBm}, \mPLE_{\text{wifi}} = \SI{2.7}{}$,
The empirically chosen values for \docWIFI{} were
$P_{0_{\text{wifi}}} = \SI{-46}{\dBm}, \mPLE_{\text{wifi}} = \SI{2.7}{}, \mWAF_{\text{wifi}} = \SI{8}{\dB}$,
and $\mPLE_{\text{ib}} = \SI{1.5}{}$ for the \docIBeacon{}s, respectively.
%
Due to omitting a time-consuming calibration process for those values we expect the localisation process to perform generally worse compared to standard fingerprinting methods \cite{Ville09}.
However, incorporating prior knowledge will often compensate for those poorly chosen system parameters.
Due to omitting a time-consuming calibration process for those values we expect the localisation process to
perform generally worse compared to standard fingerprinting methods \cite{Ville09}. However, incorporating
prior knowledge will often compensate for those poorly chosen system parameters.
As uncertainties we used $\sigma_\text{wifi} = \sigma_\text{ib} = 8.0$, both growing with each measurement's age.
While the pressure change was assumed to be \SI{0.105}{$\frac{\text{\hpa}}{\text{\meter}}$}, all other barometer-parameters
are determined automatically (see \ref{sec:sensBaro}). The step size for the transition was configured to be \SI{70}{\centimeter}
with an allowed derivation of \SI{10}{\percent}. The heading deviation in \refeq{eq:transSimple} was \SI{25}{\degree}.
with an allowed derivation of \SI{10}{\percent}. The heading deviation in
\refeq{eq:transSimple}, \refeq{eq:transShortestPath} and \refeq{eq:transMultiPath} was \SI{25}{\degree}.
As we start with a discrete uniform distribution for $\mStateVec_0$ (random position and heading), the first few estimations
are omitted from the error calculation to allow the system to somewhat settle its initial state. Even though, the error
during the following few seconds is expected to be much higher than the error when starting with a well known initial
position and heading.
position and heading.
The following evaluations will depict the improvements that the prior path knowledge is able to provide,
even when other system parameters are badly chosen.
@@ -65,21 +68,19 @@ position and heading.
\label{fig:paths}
\end{figure}
\commentByFrank{verlassen vom shortest path fuehrt zu weniger verbesserung, aber es wird nach wie vor besser als ohne!}
\commentByFrank{in den ersten paar sec ist die pfad-info teils hinderlich, da die genaue position noch sehr unklar ist und sich erst einstellen muss.
deshalb geht der fehler hier oft leicht hoch}
% error development over time while walking along a path
% error development over time while walking along a path
\begin{figure}
\input{gfx/eval/error_timed_nexus}
\caption{Development of the error while walking along
%path 1 (upper) and
path 4 (lower) using the Google Nexus 6.
path 4 (lower) using the Motorola Nexus 6.
Path 4 shows increasing errors for our methods when leaving the shortest path (3) and when facing multimodalities between two
staircases just before the destination (9).}
\label{fig:errorTimedNexus}
\end{figure}
% detailed analysis of path 4
\begin{figure}
\input{gfx/eval/path_nexus_detail}
\caption{Detailed path analysis depicting the individual segments of path 4. Their corresponding error contribution can
@@ -89,8 +90,7 @@ position and heading.
\end{figure}
%
\newcommand{\refSeg}[1]{$(#1)$}
Fig. \ref{fig:errorTimedNexus} shows the error for path 4 recorded with the Google Nexus 6.
\commentByToni{heisst das teil nicht motorola nexus 6?}
Fig. \ref{fig:errorTimedNexus} depicts the error for path 4 recorded with the Motorola Nexus 6.
For a better understanding of the following discussion, the path was divided into $10$ individual segments.
Remember that we start with a uniform distribution instead of a well known pedestrian location.
Therefore, the first few estimations
@@ -98,33 +98,36 @@ position and heading.
as illustrated in fig. \ref{fig:nexusPathDetails} \refSeg{1}.
%
Even when removing those initial estimations from the error calculation, the next few seconds are still erroneous
due to (intentionally) bad system parameters introduced in section \ref{sec:sensors}. Furthermore, as the pedestrian is not yet walking,
our proposed method is also not yet able to address those errors. This can be seen
at the red area in the upper left corner of fig. \ref{fig:nexusPathDetails} \refSeg{1} and within segment \refSeg{1} of fig. \ref{fig:errorTimedNexus}.
due to (intentionally) bad system parameters introduced in section \ref{sec:sensors}.
Furthermore, as the pedestrian is not yet walking, our proposed method is also not yet able to address those errors.
This can be seen at the red area in the upper left corner of fig. \ref{fig:nexusPathDetails} \refSeg{1} and within
segment \refSeg{1} of fig. \ref{fig:errorTimedNexus}.
%
However, as soon as the pedestrian starts moving down the hallway \refSeg{2} the error is reduced dramatically.
Adding prior knowledge centres the density in the middle of the floor, ensures the heading is directed towards
Adding prior knowledge centres the density in the middle of the floor, ensures that the heading is directed towards
the shortest path and thus produces even better localisation results.
%
Directly hereafter, we ignore the shortest path \refSeg{3'} determined by the system and walk along \refSeg{3}
instead. Of course, this leads to a temporally increasing error, as the system needs to detect this path change
and takes some time to recover (see fig. \ref{fig:errorDistNexus} \refSeg{3}). The new path to the desired destination
is \refSeg{3''} which is also ignored. Instead, we took a much longer route down the stairwell \refSeg{4}.
After this change is detected by the system, prior knowledge is able to reduce the error for segment \refSeg{5}.
After this change is detected by the system, prior knowledge is again able to reduce the error for segment \refSeg{5}.
%
Immediately hereafter follows a long, straight walk down the hallway. While the \docWIFI{} component pulls
the pedestrian into the rooms on the right side, the actual walking route was located on the left side
of the wall (see ground truth in fig. \ref{fig:nexusPathDetails} \refSeg{6}). While prior knowledge prevents
the density being dragged into the office-rooms, the estimated path is still located on the wrong side
of the floor (see ground truth in fig. \ref{fig:nexusPathDetails} \refSeg{6}). While prior knowledge prevents
the density from being dragged into the office-rooms, the estimated path is still located on the wrong side
of the hallway. As both sides of the floor result in a route with almost the same length,
just knowing the pedestrian's destination is not able to provide further improvements.
Thus, a constant error of approximately the floor's width remains. This is clearly visible in fig. \ref{fig:nexusPathDetails} \refSeg{6}.
Thus, a constant error of approximately the floor's width remains.
This is clearly visible in fig. \ref{fig:nexusPathDetails} \refSeg{6}.
%
Due to the excellent barometer installed within the Nexus 6, changing the floor provides only small estimation errors in segment \refSeg{7}.
Due to the excellent barometer installed within the Nexus 6, changing the floor provides only small estimation
errors in segment \refSeg{7}.
It follows a critical area with high errors and multimodalities.
Due to an in-house exhibition during the time of recording, we had to leave the ground truth by a few meters.
Furthermore, the overcrowded areas lead to attenuated \docWIFI{} signals. Both reasons cause the
density being dragged into another stairwell (see fig. \ref{fig:nexusPathDetails}, red lines in the lower right).
Furthermore, the overcrowded areas lead to attenuated \docWIFI{} signals. Both reasons move the
density into another stairwell (see fig. \ref{fig:nexusPathDetails}, red lines in the lower right).
The resulting multimodality (two staircases possible at the same time) leads to a rising error
\refSeg{8}, \refSeg{9}. At the end of the walk \refSeg{10} the system is able to recover, again.
@@ -132,7 +135,7 @@ position and heading.
% overall error-distribution for nexus and galaxy
\begin{figure}
\input{gfx/eval/error_dist_nexus}
\caption{Error distribution for all walks conducted with the Google Nexus 6. Our proposed methods
\caption{Error distribution for all walks conducted with the Motorola Nexus 6. Our proposed methods
clearly provide an enhancement for the overall localization process.}
\label{fig:errorDistNexus}
\end{figure}
@@ -141,7 +144,7 @@ position and heading.
% \caption{Nicht so markant beim galaxy, denke aber der platz reicht eh nicht, also einfach kurz erwaehnen}
%\end{figure}
The error values for all other paths and the other smartphone are listed in table
The median error values for all other paths and the other smartphone are listed in table
\ref{tbl:errGalaxy} and \ref{tbl:errNexus}. As can be seen, adding prior knowledge
is able to improve the localisation for all examined situations, even when
leaving the suggested path or when facing bad/slow sensor readings.
@@ -173,20 +176,20 @@ position and heading.
\end{tabular}
\end{table}
\begin{figure}
\includegraphics{gfx/eval/bergwerk_path1_galaxy}
\caption{Path 1 recorded with the Galaxy S5. Using prior knowledge improves the staircase (left) and the target area (right) where
both the barometer and \docWIFI{} provided bad readings.}
\label{fig:bergwerkPath1Galaxy}
\end{figure}
\begin{figure}
\includegraphics{gfx/eval/bergwerk_path3_galaxy}
\caption{Path 3 recorded with the Galaxy S5. Even though both paths look similar, the version with prior knowledge ended
much closer to the real destination due to reduced delays.}
\label{fig:bergwerkPath3Galaxy}
\end{figure}
%\begin{figure}
% \includegraphics{gfx/eval/bergwerk_path1_galaxy}
% \caption{Path 1 recorded with the Galaxy S5. Using prior knowledge improves the staircase (left) and the target area (right) where
% both the barometer and \docWIFI{} provided bad readings.}
% \label{fig:bergwerkPath1Galaxy}
%\end{figure}
%
%\begin{figure}
% \includegraphics{gfx/eval/bergwerk_path3_galaxy}
% \caption{Path 3 recorded with the Galaxy S5. Even though both paths look similar, the version with prior knowledge ended
% much closer to the real destination due to reduced delays.}
% \label{fig:bergwerkPath3Galaxy}
%\end{figure}
\commentByFrank{sensorausfall simulieren, z.b. in der mitte, oder auf einer treppe}
\commentByFrank{zwischendrin mal stehenbleiben und schauen ob auch das klappt}
\commentByFrank{zu grosser einfluss vom pfad ist also kein allheilmittel.. kann, wie beim treppenhaus, auch nach hinten los gehen}
%\commentByFrank{sensorausfall simulieren, z.b. in der mitte, oder auf einer treppe}
%\commentByFrank{zwischendrin mal stehenbleiben und schauen ob auch das klappt}
%\commentByFrank{zu grosser einfluss vom pfad ist also kein allheilmittel.. kann, wie beim treppenhaus, auch nach hinten los gehen}

139
tex/chapters/grid.tex
View File

@@ -1,54 +1,61 @@
\section{Transition Model}
\label{sec:trans}
\newcommand{\spoint}{l}
\newcommand{\gHead}{\theta}
\newcommand{\gDist}{d}
To sample only transitions that are actually feasible
within the environment, we utilize a \SI{20}{\centimeter}-gridded graph
$G = (V,E)$, $v_{x,y,z} \in V$, $e_{v_{x,y,z}}^{v_{x',y',z'}} \in E$
derived from the buildings floorplan as described in section \ref{sec:relatedWork}.
However, we add improved $z$-transitions by also modelling realistic
stairwells using nodes and edges as can be seen in fig. \ref{fig:gridStairs}.
stairwells using nodes and edges, depicted in fig. \ref{fig:gridStairs}.
\begin{figure}
\centering
\includegraphics[trim=0 0 0 0]{grid/grid}
\caption{Besides the nodes and edges defined by the distinct floors, we add realistic stairs to interconnect them.}
\input{gfx/grid/grid}
\caption{
Besides the nodes and edges defined by the distinct floors, we add realistic stairs to interconnect them.
Stairs are given by three points $\vec{\spoint}_1, \vec{\spoint}_2, \vec{\spoint}_3$, defining the
starting-edge and the direction.
}
\label{fig:gridStairs}
\end{figure}
\newcommand{\spoint}{l}
Stairs are defined using three points $\vec{\spoint}_1, \vec{\spoint}_2, \vec{\spoint}_3 \in \R^3$ whereby the segment
$[ \vec{\spoint}_1 \vec{\spoint}_2 ]$ describes the starting-edge, and $[ \vec{\spoint}_2 \vec{\spoint}_3 ]$ the stair's direction.
The corresponding vertices are determined using intersections of the segments with the bounding-box
for each vertex.
\commentByToni{Der Teil wird mir gar nicht klar irgendwie. Kann mir vor allem den letzten Satz nicht vorstellen.}
\commentByFrank{mention?: clean z-transitions, remove x/y nodes by adding bounding boxes}
Stairs are defined using three points $\vec{\spoint}_1, \vec{\spoint}_2, \vec{\spoint}_3 \in \R^3$ whereby the segment
$[ \vec{\spoint}_1 \vec{\spoint}_2 ]$ describes the starting-edge, and $[ \vec{\spoint}_2 \vec{\spoint}_3 ]$ the stair's direction
(see fig. \ref{fig:gridStairs}). The corresponding grid-vertices are determined using an intersection of
those segments with the bounding-box for each vertex.
To reduce the system's memory footprint, we search for the largest connected region within the graph and
remove all nodes and edges that are not connected to this region.
\newcommand{\gHead}{\theta}
\newcommand{\gDist}{d}
Walking the grid is now possible by moving along adjacent nodes into a given walking-direction
until a desired distance $\gDist$ is reached \cite{Ebner-15}.
In order to use meaningful headings $\gHead$ and distances $\gDist$
(matching the pedestrian's real heading and walking speed) for each transition,
we use the current sensor-readings $\mObsVec_{t}$ for hinted instead of truly random adjustments.
we use the current sensor-readings $\mObsVec_{t}$ for hinted instead of truly random adjustments:
%
\begin{align}
\begin{align}
\mStateVec_{t}^{\mStateHeading} = \gHead &= \mStateVec_{t-1}^{\mStateHeading} + \mObsVec_t^{\mObsHeading} + \mathcal{N}(0, \sigma_{\gHead}^2) \\
\gDist &= \mObsVec_t^{\mObsSteps} \cdot \SI{0.7}{\meter} + \mathcal{N}(0, \sigma_{\gDist}^2)
.
\end{align}
%
During a walk, each edge has an assigned probability $p(e)$ which depends on a chosen implementation.
Usually, this probability describes aspects like a comparison of the edge's angle $\angle e$ with the
current heading $\gHead$. However, it is also possible to incorporate additional prior knowledge to favor
some vertices/edges.
This probability describes aspects such as the likelihood for walking into the edge's direction $\angle e$
given the current heading heading $\gHead$. Furthermore, we will incorporate additional prior knowledge to
favour some vertices/edges. For each single step on the graph, we calculate $p(e)$ for all available edges,
and, hereafter, randomly draw the to-be-walked edge depending on those probabilities. The random walk ends,
as soon as the distance $d$ is reached. The latter depends on the number of detected steps
$\mObsSteps$ and assumes an average step-size of \SI{0.7}{\meter}.
For comparison purpose we define a simple weighting method that assigns a probability to each edge
based on the deviation from the currently estimated heading $\gHead$:
just based on the deviation from the currently estimated heading $\gHead$:
\commentByFrank{das erste $=$ ist komisch. bessere option?}
\commentByFrank{das erste $=$ ist komisch. ideen?}
\commentByToni{Find ich jetzt nicht tragisch. Eher notwendig fuers Verstaendnis.}
\begin{equation}
p(e) = p(e \mid \gHead) = N(\angle e \mid \gHead, \sigma_\text{dev}^2).
@@ -59,24 +66,28 @@
\section{Navigation Knowledge}
\section{Navigational Knowledge}
Assuming navigation, the pedestrian wants to reach a well-known destination and represents additional
prior knowledge. Most probably, the pedestrian will stick to the path presented by
Considering navigation, a pedestrian wants to reach a well-known destination which represents additional
prior knowledge. Most probably, the user will stick to the path presented by
a navigation system. However, some deviations like chatting to someone or taking another route
cannot be strictly ruled out. We will therefore describe a system that is able to deal with such variants
as well as present an algorithm to calculate realistic routes based on the aforementioned grid.
cannot be strictly ruled out. We will therefore describe a system that is able to deal with such
variations as well as present an algorithm to calculate realistic routes based on the aforementioned grid.
\subsection{Wall Avoidance}
\label{sec:wallAvoidance}
As discussed in section \ref{sec:relatedWork}, simply running a shortest-path algorithm as Dijkstra or A* using the previously created graph would obviously lead to non-realistic paths sticking to the walls and walking many diagonals.
Pedestrian's however, walk either somewhere near (but not close to) a wall or, for larger open spaces, somewhere far from the walls.
In order to calculate paths the resemble pedestrian walking behavior, an importance factor is derived for each vertex within the graph.
As discussed in section \ref{sec:relatedWork}, simply applying a shortest-path algorithm such as Dijkstra or
A* using the previously created graph would obviously lead to non-realistic paths sticking to the walls and
walking many diagonals. Pedestrian's however, walk either somewhere near (but not close to) a wall or, for
larger open spaces, somewhere far from the walls. In order to calculate paths that resemble such a walking
behaviour, an importance factor is derived for each vertex within the graph. Those will be used to
adjust weight between two vertices, needed by the shortest-path algorithm.
To get the distance of each vertex from the nearest wall, an inverted version $G' = (V', E')$ of the graph $G$
is built. A nearest-neighbor search $\mNN(v_{x,y,z}, G')$ will then provide the nearest wall-vertex
$v'_{x,y,z} \in V'$ from the inverted graph \cite{Cover1967}. The wall avoidance is calculated as follows:
To downvote vertices near walls, we need to get the distance of each vertex from its nearest wall.
We therefore build an inverted version $G' = (V', E')$ of the graph $G$, just containing walls and other obstacles.
A nearest-neighbour search $\mNN(v_{x,y,z}, G')$ will then provide the nearest wall-vertex
$v'_{x,y,z} \in V'$ from the inverted graph \cite{Cover1967}. The wall avoidance can now be calculated as follows:
%
\begin{equation}
d_{v, v'} = d(v_{x,y,z}, v'_{x,y,z}), \enskip 0.0 < d_{v, v'} < 2.2 \\
@@ -93,7 +104,7 @@ Pedestrian's however, walk either somewhere near (but not close to) a wall or, f
The parameters of the normal distribution and the scaling-factors were chosen empirically.
While this approach provides good results for most areas, doors are downvoted by
\refeq{eq:wallAvoidance}, as they have only vertices that are close to walls.
Door detection thus is the next conducted step.
Door detection and upvoting thus is the next conducted step.
@@ -101,40 +112,36 @@ Pedestrian's however, walk either somewhere near (but not close to) a wall or, f
\subsection{Door Detection}
\label{sec:doorDetection}
Doors are usually anchored between two (thin) walls and have a normed width. Examining only a limited region
around the door, its surrounding walls describe a flat ellipse with the same center as the door itself. It is thus
possible to detect doors within the floorplan using a PCA.
Doors are usually anchored between two walls and have a normed width. Examining only a limited region
around the door, its surrounding walls describe a flat ellipse with the same center as the door itself.
It is thus possible to detect doors within the floorplan using a PCA.
To decide whether a vertex $v_{x,y,z}$ within the (non-inverted) grid $G$ belongs to a door, we use $k$-NN to fetch its
$k$ nearest neighbors $N'$ within the inverted grid $G'$. For this neighborhood the centroid $\vec{c} \in \R^3$ is calculated.
If the distance $\| \vec{c} - v_{x,y,z} \|$ between the centroid and the vertex-in-question is above certain threshold,
$k$ nearest neighbours $N'$ within the inverted grid $G'$. For this neighbourhood the centroid $\vec{c} \in \R^3$ is calculated.
If the distance $\| \vec{c} - v_{x,y,z} \|$ between the centroid and the vertex-in-question is above a certain threshold,
the node does not belong to a door.
\todo{diese distanzformel oder dist(a,b)?}
\commentByToni{dist gibt es doch net, oder? In der Graphentheorie schreibt man einfach d(v, v) (ist im prinzip shortest path). ansonsten müssten wir dist(..) irgendwo einführen als euklidische distanz oder so, find ich aber irgendwie doof. musst du wissen, was dir beser gefällt}
%ugly...
%\begin{equation}
% \vec{c} = \frac{ \sum_{v_{x,y,z} \in N'} v_{x,y,z} }{k}
%\end{equation}
\todo{Distanzformel centroid/vertex. ideen? $\|v1 - v2\|$ oder $d(v1, v2)$?}
Assuming the distance was fine, we compare the two eigenvalues $\{\lambda_1, \lambda_2 \mid \lambda_1 > \lambda_2\}$, determined by the PCA.
If their ratio $\frac{\lambda_1}{\lambda_2}$ is above a certain threshold (flat ellipse)
Assuming the distance is fine, we compare the two eigenvalues $\{\lambda_1, \lambda_2 \mid \lambda_1 > \lambda_2\}$,
determined by the PCA. If their ratio $\frac{\lambda_1}{\lambda_2}$ is above a certain threshold (flat ellipse)
the node-in-question belongs to a door or some kind of narrow passage.
\begin{figure}
\includegraphics[width=\columnwidth]{door_pca}
\caption{Detect doors within the floorplan using $k$-NN and PCA. While the white nodes are walkable, the black ones represent walls. The gray node is the one in question.}
\caption{Detect doors within the floorplan using $k$-NN and PCA.
While the white nodes are walkable, the black ones represent walls. The grey node is the one in question.}
\label{fig:doorPCA}
\end{figure}
Fig. \ref{fig:doorPCA} depicts all three cases where
(left) the node is part of a door,
(middle) the distance between node and k-NN centroid is above the threshold and
(right) the ration between $e_1$ and $e_2$ is below the threshold.
\commentByToni{was ist $e_1$ und $e_2$?}
(right) the ration between $\lambda_1$ and $\lambda_2$ is below the threshold.
Like before, we apply a distribution based on the distance from the nearest door to determine
an importance-factor for each node:
%
\commentByFrank{distanzrechnung: formel}
\begin{equation}
\text{dd}_{x,y,z} = 0.8 \cdot \mathcal{N}( \| \vec{c} - v_{x,y,z} \| \mid 0.0, 1.0 )
\end{equation}
@@ -148,14 +155,14 @@ Pedestrian's however, walk either somewhere near (but not close to) a wall or, f
Based on aforementioned assumptions, the final importance for each node is given by
%
\begin{equation}
\text{imp}_{x,y,z} = 1.0 + \text{wa}_{x,y,z} + \text{dd}_{x,y,z} \enspace ,
\text{imp}_{x,y,z} = 1.0 + \text{wa}_{x,y,z} + \text{dd}_{x,y,z} \enspace .
\end{equation}
%
A good visualization of the importance factors can be seen in fig. \ref{fig:importance}.
A good visualization of the resulting importance-factors can be seen in fig. \ref{fig:importance}.
\begin{figure}
\includegraphics[angle=-90, width=\columnwidth, trim=20 19 17 9, clip]{floorplan_importance}
\caption{The calculated importance factor for each vertex. While the black elements denote an importance-factor
\caption{The calculated importance-factor for each vertex. While the black elements denote an importance-factor
of about \SI{0.8}{}, the yellow door-regions denote a high importance of about \SI{1.2}{}.}
\label{fig:importance}
\end{figure}
@@ -193,12 +200,13 @@ Pedestrian's however, walk either somewhere near (but not close to) a wall or, f
\subsection{Guidance}
Based on the previous calculations, we propose two approaches to incorporate the prior
knowledge into the transiton model.
Based on the previous calculations, we propose two approaches to utilize the prior
knowledge within the transition model.
\subsubsection{Shortest Path}
Before every transition, the centroid $\vec{c}$ of the current sample-set $\Upsilon_{t-1}$, representing the posterior distribution at time $t-1$, is calculated:
Before every transition, the centroid $\vec{c}$ of the current sample-set $\Upsilon_{t-1}$,
representing the posterior distribution at time $t-1$, is calculated:
%
\begin{equation}
\vec{c} = \frac
@@ -225,20 +233,20 @@ Pedestrian's however, walk either somewhere near (but not close to) a wall or, f
\end{equation}
\newcommand{\pathRef}{v_{\hat{x},\hat{y},\hat{z}}}
\todo{summe laesst sich so nicht schreiben. ideen?}
\commentByFrank{avg-state vom sample-set. frank d. meinte ja hier muessen wir aufpassen. bin noch unschluessig wie.}
\commentByToni{Das ist gar nicht so einfach... wir haben nie ein Sample Set eingefuehrt. Nicht mal einen Sample. Wir haben immer nur diesen State... Man könnte natuerlich einfach sagen das $\Upsilon_t$ an set of random samples representing the posterior distribution ist oder einfach nur ein set von partikeln. habs mal eingefuegt wie ich denke}
This center is used as starting-point for the shortest path. As it is not necessarily part of
the grid, its nearest-grid-neighbor is determined and used instead.
The resulting vertex already knows its way to the pedestrian's destination, but is located somewhere
within the sample-set. We thus calculate the standard deviation for the distance
of all states from the center. After advancing the starting-vertex by three times the deviation
we get a new point outside of the sample-set and closer to the desired destination.
\commentByToni{Worauf liegt der Punkt? Sollte man dazu schreiben. }
of all samples from the centre. After advancing the starting-vertex by three times this deviation
we get a new point that is: part of the shortest path, outside of the sample-set and closer to the
desired destination.
This new reference node $\pathRef$ serves as a comparison base:
\commentByToni{Allgemein mal zur Schreibweise der Vertices. Irgendwie finde ich dieses $v_{x,y,z}$ nicht so gut. Ich denke jeder sieht das wir 3D haben und deswegen könntem man doch schlicht $v$, $v'$, $\hat{v}$ ... nutzen, oder was denkst du?}
\commentByFrank{war der vorschlag von frank d. letztes mal, weil man an vertices nicht einfach attribute (x,y,z) anhaengen kann wie wir es bei $\mObsVec$, $\mStateVec$ haben.}
\todo{bessere ideen fuer die schreibweise?}
\begin{equation}
\begin{split}
p(v_{x',y',z'} \mid v_{x,y,z})
@@ -261,9 +269,8 @@ Pedestrian's however, walk either somewhere near (but not close to) a wall or, f
\subsubsection{Multipath}
The Dijkstra calculation mentioned in \ref{sec:pathEstimation} already calculated the
cumulative distance $\text{cdst}_{x,y,z}$ to the pedestrian's target for each vertex.
\commentByToni{falls wir dist() nutzen sollten wir hier auch cdist machen. }
We thus apply the same assumption as above and downvote steps not decreasing
cumulative distance $\text{cdist}_{x,y,z}$ to the pedestrian's target for each vertex.
We thus apply the same assumption as above and downvote grid-steps not decreasing
the distance to the destination:
\begin{equation}
@@ -272,7 +279,7 @@ Pedestrian's however, walk either somewhere near (but not close to) a wall or, f
= N(\angle [ v_{x,y,z} v_{x',y',z'} ] \mid \gHead, \sigma_\text{dev}^2) \cdot \alpha \\
\alpha =
\begin{cases}
1.0 & \text{cdst}_{x',y',z'} < \text{cdst}_{x,y,z} \\
1.0 & \text{cdist}_{x',y',z'} < \text{cdist}_{x,y,z} \\
0.1 & \text{else}
\end{cases}
\end{split}
@@ -290,9 +297,3 @@ Pedestrian's however, walk either somewhere near (but not close to) a wall or, f
\label{fig:multiHeatMap}
\end{figure}
\commentByFrank{angular-change probability as polar-plot}
\commentByFrank{describe the multi-path version}

87
tex/chapters/sensors.tex
View File

@@ -4,33 +4,40 @@
\subsection{Barometer}
\label{sec:sensBaro}
As stated by \cite{Muralidharan14-BPS}, ambient pressure readings are highly influenced by environmental conditions like the weather, time-of-day and others.
Thus, relative pressure readings are preferred over absolute ones.
However, due to noisy sensors, one single reading is not enough as a relative base.
Harnessing the usual setup time of a navigation-system (route calculation, user checking the route) we use the average of all barometer readings during this timeframe as relative base $\overline{\mObsPressure}$.
However, it is often necessary to omit the first few sensors readings, as the sensor needs some time to settle.
Otherwise the estimated base would be far off the real values as shown in fig. \ref{fig:baroSetupError}.
Besides, we use the system's setup time to estimate the sensors uncertainty $\sigma_\text{baro}$ for later use within the evaluation.
%
As stated by \cite{Muralidharan14-BPS}, ambient pressure readings are highly influenced by environmental conditions
like the weather, time-of-day and others. Thus, relative pressure readings are preferred over absolute ones.
However, due to noisy sensors, more than one reading is required to estimate the relative base.
Harnessing the usual setup time of a navigation-system (route calculation, user checking the route, etc.)
we use the average of all barometer readings during this timeframe as estimated base $\overline{\mObsPressure}$.
Moreover, it is often necessary to omit some initial sensors readings, as the smartphone's sensor needs some time
to settle. Besides, we use the setup timeframe to estimate the sensors uncertainty $\sigma_\text{baro}$ for later
use within the evaluation. Fig. \ref{fig:baroSetupError} depicts actual sensor-readings including aforementioned
error conditions.
%
\begin{figure}
\include{gfx/baro/baro_setup_issue}
\caption{Sometimes the barometer provides erroneous \SI{}{\hpa} readings during the first seconds. Those
need to be omitted before $\sigma_\text{baro}$ and $\overline{\mObsPressure}$ are estimated.}
\label{fig:baroSetupError}
\end{figure}
%
During each transition from $\mStateVec_{t-1}$ to $\mStateVec_t$, we need a corresponding, relative pressure prediction $\mStatePressure$ which is adjusted according to the resulting $z$-change, if any:
%
%
During each transition from $\mStateVec_{t-1}$ to $\mStateVec_t$, we need a corresponding, relative
pressure prediction $\mStatePressure$ which is adjusted according to the resulting $z$-change:
%
\begin{equation}
\mState_{t}^{\mStatePressure} = \mState_{t-1}^{\mStatePressure} + \Delta z \cdot \SI{0.105}{\hpa}
\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
.
\label{eq:baroTransition}
\end{equation}
%
The evaluation following the transition then compares the predicted relative pressure with the observed one using a normal distribution with the previously estimated $\sigma_\text{baro}$:
%
In \refeq{eq:baroTransition}, $b$ denotes the usual pressure change in $\frac{\text{hPa}}{\text{m}}$.
The evaluation, following the transition, compares the predicted relative pressure with the observed
one using a normal distribution utilizing 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}).
\label{eq:baroEval}
@@ -39,45 +46,51 @@ The evaluation following the transition then compares the predicted relative pre
\subsection{Wi-Fi \& iBeacons}
For additional absolute location hints, we use the smartphones Wi-Fi and iBeacon sensor to measure the signal-strengths
of nearby transmitters. As the positions of both \docAP{}s and \docIBeacon{}s are known beforehand, we compare
each measurement with its corresponding signal strength prediction which is defined by the 3D distance $d$
and the number of floors $\Delta f$ between the \docAPshort{} and the particle
%
Additional absolute location hints, are provided by the smartphone's \docWIFI{} and \docIBeacon{} component,
measuring the signal-strengths of nearby transmitters. As the positions of both \docAP{}s and \docIBeacon{}s
are known beforehand, we compare each measurement with its corresponding signal strength prediction using
the wall-attenuation-factor model \cite{Ebner-15}. This prediction depends on the 3D distance $d$ from the
\docAPshort{} and the number of floors $\Delta f$ between the \docAPshort{} and the state-in-question:
%
\begin{equation}
P_r(d, \Delta f) = \mTXP - 10 \mPLE \log_{10}{\frac{\mMdlDist}{\mMdlDist_0}} + \Delta{f} \mWAF,
\end{equation}
%
and calculate the resulting probability as described in \cite{Ebner-15}:
%
%
The probability to measure this prediction given a 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).
\label{eq:wifiTotal}
\end{equation}
For the \docWIFI{} component we thus need two parameters per \docAPshort{}: $\mTXP$ measured at a distance
$\mMdlDist_0$ (usually \SI{1}{\meter}) and the path-loss exponent $\mPLE$ describing the environment.
For the \docWIFI{} component we thus need three parameters per \docAPshort{}: $\mTXP$ measured at a distance
$\mMdlDist_0$ (usually \SI{1}{\meter}), the path-loss exponent $\mPLE$ describing the environment
and $\mWAF$ denoting the attenuation per floor.
To reduce complexity and system setup time, we use the same values for all \docAP{}s at the cost of accuracy.
While, $\mTXP$ is best determined using averaged measurements at a single location,
a good estimation of $\mPLE$ requires several measurements and numerical optimization \cite{PathLossPredictionModelsForIndoor}.
$\mPLE$ is thus chosen empirically.
a good estimation of $\mPLE$ and $\mWAF$ requires several measurements and numerical optimization
\cite{PathLossPredictionModelsForIndoor}. $\mPLE$ and $\mWAF$ are thus chosen empirically.
For the \docIBeacon{} component we also use \refeq{eq:wifiTotal} but $\mTXP$ is transmitted by each beacon.
Due to the short-range coverage the model parameters require less consideration of the senders ambient conditions (e.g. walls).
Therefore, a smaller $\mPLE$ can be chosen to model the signal strength prediction for \docIBeacon{}s.
Due to the short-range coverage the model parameters require less consideration of the senders ambient conditions
(e.g. walls). Therefore, a smaller $\mPLE$ can be chosen to model the signal strength prediction for \docIBeacon{}s.
\subsection{Step- \& Turn-Detection}
\subsection{Step- \& Turn-Detection}
A big disadvantage of using the state transition as proposal distribution is the high possibility of sample impoverishment due to a small measurement noise.
This happens since accurate observations result in high peaks of the evaluation density and therefore the proposal density is not able to sample outside that peak \cite{Isard98:CCD}.
Additionally, erroneous or delayed measurements from absolute positioning sensors like \docWIFI{} may lead to misplaced turns.
This causes a downvoting of particles with increased heading deviation.
Therefore, we incorporate the turn-detection, as well as the related step-detection, directly into the state transition $p(\mStateVec_{t} \mid \mStateVec_{t-1}, \mObsVec_{t-1})$. This leads to a more directed sampling instead of a truly random one.
Step- and turn-detection uses the smartphone's IMU and is implemented as described in \cite{Ebner-15}.
%
However, a big disadvantage of using the state transition as proposal distribution is the high possibility of sample
impoverishment due to a small measurement noise. This happens since accurate observations result in high peaks
of the evaluation density and therefore the proposal density is not able to sample outside that peak \cite{Isard98:CCD}.
Additionally, erroneous or delayed measurements from absolute positioning sensors like \docWIFI{} may lead to misplaced turns.
This causes a downvoting of particles with increased heading deviation.
Therefore, we incorporate the turn-detection, as well as the related step-detection, directly into the state transition
$p(\mStateVec_{t} \mid \mStateVec_{t-1}, \mObsVec_{t-1})$, which leads to a more directed sampling instead of a truly random one.

11943
tex/gfx/grid/grid.eps
View File

File diff suppressed because it is too large Load Diff

12
tex/gfx/grid/grid.gp
View File

@@ -1,5 +1,5 @@
set terminal eps size 3.0,2.0
set output "grid.eps"
set terminal epslatex size 3.0,2.0
set output "grid.tex"
set ticslevel 0
set view 60, 286
@@ -23,6 +23,12 @@ set hidden3d front
set object 1 polygon from 1680,1158,720 to 1810,1158,720 to 1810,878,560 to 1680,878,560 fs solid fc rgb "#aaaaff" behind
set object 2 polygon from 1680,1158,400 to 1810,1158,400 to 1810,878,200 to 1680,878,200 fs solid fc rgb "#aaaaff" behind
set arrow 101 from 1810,878,560 to 1680,878,560 nohead lc rgb "#000000" lw 3 front
set arrow 102 from 1810,1158,720 to 1810,878,560 nohead lc rgb "#000000" lw 3
set label 101 "$\\vec{l}_1$" at 1680,878+40,560-2 center
set label 102 "$\\vec{l}_2$" at 1810,878-10,590 center
set label 103 "$\\vec{l}_3$" at 1810,1158,720+30 center
# inner
set object 4 polygon from 1510,1158,400 to 1650,1158,400 to 1650,878,560 to 1510,878,560 fs solid fc rgb "#ffaaaa" behind
set object 5 polygon from 1510,1158,720 to 1650,1158,720 to 1650,1100,760 to 1510,1100,760 fs solid fc rgb "#ffaaaa" behind
@@ -37,7 +43,7 @@ set object 11 polygon from 1280,1188,400 to 1470,1188,400 to 1510,1158,400 to 18
set object 12 polygon from 1280,1188,720 to 1470,1188,720 to 1510,1158,720 to 1810,1158,720 to 1810,1290,720 to 1280,1290,720 fs solid fc rgb "#888888" behind
splot '-' with lines lw 1 lc rgb '#555555' title '', '-' with lines lw 1 lc rgb '#555555' title '', '-' with points palette pt 7 ps 0.1 title ''
splot '-' with lines lw 1 lc rgb '#555555' title '', '-' with lines lw 1 lc rgb '#555555' title '', '-' with points palette pt 7 ps 0.3 title ''
1320 1200 400
1280 1200 400

95
tex/gfx/grid/grid.tex Normal file
View File

@@ -0,0 +1,95 @@
% GNUPLOT: LaTeX picture with Postscript
\begingroup
\makeatletter
\providecommand\color[2][]{%
\GenericError{(gnuplot) \space\space\space\@spaces}{%
Package color not loaded in conjunction with
terminal option `colourtext'%
}{See the gnuplot documentation for explanation.%
}{Either use 'blacktext' in gnuplot or load the package
color.sty in LaTeX.}%
\renewcommand\color[2][]{}%
}%
\providecommand\includegraphics[2][]{%
\GenericError{(gnuplot) \space\space\space\@spaces}{%
Package graphicx or graphics not loaded%
}{See the gnuplot documentation for explanation.%
}{The gnuplot epslatex terminal needs graphicx.sty or graphics.sty.}%
\renewcommand\includegraphics[2][]{}%
}%
\providecommand\rotatebox[2]{#2}%
\@ifundefined{ifGPcolor}{%
\newif\ifGPcolor
\GPcolorfalse
}{}%
\@ifundefined{ifGPblacktext}{%
\newif\ifGPblacktext
\GPblacktexttrue
}{}%
% define a \g@addto@macro without @ in the name:
\let\gplgaddtomacro\g@addto@macro
% define empty templates for all commands taking text:
\gdef\gplbacktext{}%
\gdef\gplfronttext{}%
\makeatother
\ifGPblacktext
% no textcolor at all
\def\colorrgb#1{}%
\def\colorgray#1{}%
\else
% gray or color?
\ifGPcolor
\def\colorrgb#1{\color[rgb]{#1}}%
\def\colorgray#1{\color[gray]{#1}}%
\expandafter\def\csname LTw\endcsname{\color{white}}%
\expandafter\def\csname LTb\endcsname{\color{black}}%
\expandafter\def\csname LTa\endcsname{\color{black}}%
\expandafter\def\csname LT0\endcsname{\color[rgb]{1,0,0}}%
\expandafter\def\csname LT1\endcsname{\color[rgb]{0,1,0}}%
\expandafter\def\csname LT2\endcsname{\color[rgb]{0,0,1}}%
\expandafter\def\csname LT3\endcsname{\color[rgb]{1,0,1}}%
\expandafter\def\csname LT4\endcsname{\color[rgb]{0,1,1}}%
\expandafter\def\csname LT5\endcsname{\color[rgb]{1,1,0}}%
\expandafter\def\csname LT6\endcsname{\color[rgb]{0,0,0}}%
\expandafter\def\csname LT7\endcsname{\color[rgb]{1,0.3,0}}%
\expandafter\def\csname LT8\endcsname{\color[rgb]{0.5,0.5,0.5}}%
\else
% gray
\def\colorrgb#1{\color{black}}%
\def\colorgray#1{\color[gray]{#1}}%
\expandafter\def\csname LTw\endcsname{\color{white}}%
\expandafter\def\csname LTb\endcsname{\color{black}}%
\expandafter\def\csname LTa\endcsname{\color{black}}%
\expandafter\def\csname LT0\endcsname{\color{black}}%
\expandafter\def\csname LT1\endcsname{\color{black}}%
\expandafter\def\csname LT2\endcsname{\color{black}}%
\expandafter\def\csname LT3\endcsname{\color{black}}%
\expandafter\def\csname LT4\endcsname{\color{black}}%
\expandafter\def\csname LT5\endcsname{\color{black}}%
\expandafter\def\csname LT6\endcsname{\color{black}}%
\expandafter\def\csname LT7\endcsname{\color{black}}%
\expandafter\def\csname LT8\endcsname{\color{black}}%
\fi
\fi
\setlength{\unitlength}{0.0500bp}%
\ifx\gptboxheight\undefined%
\newlength{\gptboxheight}%
\newlength{\gptboxwidth}%
\newsavebox{\gptboxtext}%
\fi%
\setlength{\fboxrule}{0.5pt}%
\setlength{\fboxsep}{1pt}%
\begin{picture}(4320.00,2880.00)%
\gplgaddtomacro\gplbacktext{%
\csname LTb\endcsname%
\put(2671,1807){\makebox(0,0){\strut{}$\vec{l}_1$}}%
\put(3114,2090){\makebox(0,0){\strut{}$\vec{l}_2$}}%
\put(1602,2789){\makebox(0,0){\strut{}$\vec{l}_3$}}%
}%
\gplgaddtomacro\gplfronttext{%
}%
\gplbacktext
\put(0,0){\includegraphics{grid}}%
\gplfronttext
\end{picture}%
\endgroup

2
tex/make.sh
View File

@@ -1,5 +1,7 @@
PATH=$PATH:/mnt/data/texlive/bin/x86_64-linux/
latex bare_conf.tex
bibtex bare_conf
latex bare_conf.tex
latex bare_conf.tex

5
tex/misc/functions.tex
View File

@@ -58,6 +58,9 @@
}%
}
%\newcommand{\commentByFrank}[1]{}
%\newcommand{\commentByToni}[1]{}
%comments
\newcommand{\commentByFrank}[1]{%
\noindent%
@@ -102,7 +105,7 @@
\newcommand{\mPLE}{\ensuremath{\gamma}} % path-loss exponent
\newcommand{\mTXP}{\ensuremath{P_0}} % tx-power
\newcommand{\mWAF}{\ensuremath{\lambda}} % wall attenuation factor
\newcommand{\mWAF}{\ensuremath{\beta}} % wall attenuation factor
\newcommand{\mMdlDist}{\ensuremath{d}} % distance used within propagation models