senf zu experimente abgegeben
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
\section{Conclusion}
|
||||
|
||||
\section{Future Work}
|
||||
|
||||
\commentByFrank{balance zwischen den einzelnen wahrscheinlichkeiten ist oft ein schmaler grad. wieviel turn erlauben, wieviel auf den pfad zwingen. das verbesern}
|
||||
\commentByFrank{position der APs wissen ist viel arbeit. vereinfachen durch test-walks auf vorgegebenen pfaden -> numerisch optimieren wo APs sind}
|
||||
\commentByToni{quadtress. stellen die groesse der zellen variable ein. je nach bedarf.}
|
||||
|
||||
@@ -6,46 +6,45 @@
|
||||
%
|
||||
We conducted 4 distinct walks, for testing short distances, long distances, critical sections
|
||||
and ignoring the shortest-path suggested by the system.
|
||||
Due to an inhouse exhibition during that time, many places were crowded and \docWIFI{} signals
|
||||
Due to an in-house exhibition during that time, many places were crowded and \docWIFI{} signals
|
||||
are attenuated more than usual.
|
||||
Each acquired path is backed by ground truth information to enable error calculation.
|
||||
This ground truth is measured by recording a timestamp at a marked spot on the walking route.
|
||||
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 conducted using a Google Nexus 6 and a Samsung Galaxy S5.
|
||||
error measurements. All walks were performed using a Google 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:
|
||||
\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 of the Nexus smartphone.
|
||||
the Galaxy does. This results in a much 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 algorithm with \SI{7500}{} particles as realization of the recursive density estimation \cite{todo}.
|
||||
the CONDENSATION particle filter with \SI{7500}{} particles as realization.
|
||||
The weighted arithmetic mean of the particles was used as state estimation.
|
||||
|
||||
As mentioned earlier, the position of all \docAP{}s (about 5 per floor) is known beforhand.
|
||||
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.
|
||||
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}{}$,
|
||||
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 localistation
|
||||
process to perform generally worse compared to fingerpring methods \todo{cite}. 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}.
|
||||
|
||||
As we start with a uniformation distribution for $\mStateVec_0$ (random position and heading), the first few estimations
|
||||
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 follwing few seconds is expected to be much higher than the error when starting with a well known initial
|
||||
position and heading.
|
||||
during the following few seconds is expected to be much higher than the error when starting with a well known initial
|
||||
position and heading.
|
||||
|
||||
The follwing evaluations will depict the improvements prior path knowledge is able to provide
|
||||
The following evaluations will depict the improvements that the prior path knowledge is able to provide,
|
||||
even when other system parameters are badly chosen.
|
||||
Just adding importance-factors described in \ref{sec:wallAvoidance} and \ref{sec:doorDetection}
|
||||
to the simple transition \refeq{eq:transSimple} addresses only minor local errors
|
||||
@@ -53,7 +52,7 @@
|
||||
and is therefore not further evaluated.
|
||||
To examine the contribution our approach is able to provided, we will have a closer look
|
||||
at a long walk with many stairs, intentionally leaving the shortest path several times,
|
||||
named path 4 (see \ref{fig:paths}).
|
||||
named path 4 (see fig. \ref{fig:paths}).
|
||||
%
|
||||
|
||||
|
||||
@@ -71,46 +70,7 @@
|
||||
\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}
|
||||
|
||||
\newcommand{\refSeg}[1]{$(#1)$}
|
||||
Fig. \ref{errorTimedNexus} shows the error for the individual segments of path 1 and path 4 recorded with the Google Nexus 6.
|
||||
Remember that we start with a uniform distribution instead of a well known pedestrian location. Therefor the first few estimations
|
||||
reside somewhere near the center of the building and result in a very high error contribution
|
||||
(see fig. \ref{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 (see \ref{sec:sensors}). Furthermore, as the pedestrian is not yet walking,
|
||||
our proposed method is not yet able to addres those error. This can be seen in both
|
||||
fig. \ref{fig:nexusPathDetails} \refSeg{1} (the red are in the upper left)
|
||||
and fig \ref{fig:errorTimedNexus} \refSeg{1}.
|
||||
%
|
||||
However, as soon as the pedestrian starts moving down the hallway \refSeg{2} the error is reduced dramatically.
|
||||
Adding prior knowledge centers the density in the middle of the floor, ensures 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 \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}.
|
||||
%
|
||||
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 draged 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 improvments.
|
||||
Thus, a constant error of approximately the floor's width remains (see \ref{fig:nexusPathDetails} \refSeg{6}).
|
||||
%
|
||||
Due to the excellent barometer installed within the Nexus 6, the stair provides were small estimation
|
||||
errors \refSeg{7}. Hereafter follows a critical area with high errors and multimodalities. Due to an
|
||||
inhouse 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 lead to the
|
||||
density being dragged into another stairwell (see \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.
|
||||
|
||||
|
||||
% 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
|
||||
@@ -120,7 +80,6 @@
|
||||
staircases just before the destination (9).}
|
||||
\label{fig:errorTimedNexus}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}
|
||||
\input{gfx/eval/path_nexus_detail}
|
||||
\caption{Detailed path analysis depicting the individual segments of path 4. Their corresponding error contribution can
|
||||
@@ -128,6 +87,47 @@
|
||||
times ($3'$ and $3''$) our approach is still able to improve the overall localisation error.}
|
||||
\label{fig:nexusPathDetails}
|
||||
\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?}
|
||||
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
|
||||
reside somewhere near the centre of the building and result in a very high error contribution
|
||||
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}.
|
||||
%
|
||||
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
|
||||
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}.
|
||||
%
|
||||
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 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}.
|
||||
%
|
||||
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).
|
||||
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.
|
||||
|
||||
|
||||
% overall error-distribution for nexus and galaxy
|
||||
\begin{figure}
|
||||
@@ -149,6 +149,8 @@
|
||||
% error values
|
||||
\begin{table}
|
||||
\centering
|
||||
\label{tbl:errNexus}
|
||||
\caption{Median error for walks conducted with the Nexus 6.}
|
||||
\begin{tabular}{|l|c|c|c|c|}
|
||||
\hline
|
||||
& Path1 & Path2 & Path3 & Path4 \\\hline
|
||||
@@ -156,12 +158,12 @@
|
||||
Shortest (\refeq{eq:transShortestPath}) & \SI{2.72}{\meter} & \SI{2.98}{\meter} & \SI{2.48}{\meter} & \SI{3.06}{\meter} \\\hline
|
||||
Multipath (\refeq{eq:transMultiPath}) & \SI{2.62}{\meter} & \SI{2.14}{\meter} & \SI{2.46}{\meter} & \SI{2.75}{\meter} \\\hline
|
||||
\end{tabular}
|
||||
\label{tbl:errNexus}
|
||||
\caption{Median error for walks conducted with the Nexus 6.}
|
||||
\end{table}
|
||||
|
||||
\begin{table}
|
||||
\centering
|
||||
\label{tbl:errGalaxy}
|
||||
\caption{Median error for walks conducted with the Galaxy S5.}
|
||||
\begin{tabular}{|l|c|c|c|c|}
|
||||
\hline
|
||||
& Path1 & Path2 & Path3 & Path4 \\\hline
|
||||
@@ -169,8 +171,6 @@
|
||||
Shortest (\refeq{eq:transShortestPath}) & \SI{ 5.86}{\meter} & \SI{4.14}{\meter} & \SI{5.14}{\meter} & \SI{5.20}{\meter} \\\hline
|
||||
Multipath (\refeq{eq:transMultiPath}) & \SI{ 6.35}{\meter} & \SI{4.21}{\meter} & \SI{5.03}{\meter} & \SI{6.79}{\meter} \\\hline
|
||||
\end{tabular}
|
||||
\label{tbl:errGalaxy}
|
||||
\caption{Median error for walks conducted with the Galaxy S5.}
|
||||
\end{table}
|
||||
|
||||
\begin{figure}
|
||||
@@ -187,16 +187,6 @@
|
||||
\label{fig:bergwerkPath3Galaxy}
|
||||
\end{figure}
|
||||
|
||||
|
||||
|
||||
\begin{itemize}
|
||||
\item Nochmal kurz auf die Probleme des letzten Systems eingehen (schon teil der introduction)
|
||||
\item Da letztes mal nur 1 Pfad, machen wir dieses mal mehrere!
|
||||
\item Stelle normale Lokalisation der Pfad Lokalisation gegenüber und überlege wo Probleme auftreten
|
||||
\item nutze den "natürlichen Pfad" und einen normalen dijkstra
|
||||
\item Analysiere Probleme ggf. mit schönen Grafiken.
|
||||
\item Vergleich zum Schluss das neue System mit dem Alten um eine schöne Conclusion der Verbesserungen einzuleiten.
|
||||
\end{itemize}
|
||||
\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}
|
||||
|
||||
@@ -11,38 +11,31 @@ Especially the hard problem of pedestrian localisation and navigation has lately
|
||||
|
||||
Most modern indoor localisation systems primarily use smartphones to determine the position of a pedestrian.
|
||||
Especially the phone's inertial measurement unit (IMU) as well as external information like Wi-Fi or Bluetooth
|
||||
are used to collect the necessary data. Additionally, environmental knowledge is often incorporated e.g. by using
|
||||
floor maps. This combination of highly different sensor types is also known as sensor fusion.
|
||||
are used to collect the necessary data.
|
||||
Additionally, environmental knowledge is often incorporated e.g. by using floormaps.
|
||||
This combination of highly different sensor types is also known as sensor fusion.
|
||||
|
||||
Here, probabilistic methods like particle- or Kalman filters are often used to approximate a probability
|
||||
distribution describing the pedestrian's possible whereabouts.
|
||||
Here, probabilistic methods like particle- or Kalman filters are often used to approximate a probability distribution describing the pedestrian's possible whereabouts.
|
||||
This procedure can be separated into two probabilistic models:
|
||||
The transition model, which represents the dynamics of the pedestrian
|
||||
and predicts his next accessible locations,
|
||||
and the evaluation model, which estimates the probability for the position also corresponding to
|
||||
The transition model, which represents the dynamics of the pedestrian and predicts his next accessible locations, and the evaluation model, which estimates the probability for the position also corresponding to
|
||||
recent sensor measurements.
|
||||
%Therefore, the most accurate position is represented by a peak of the probability distribution.
|
||||
In our previous work we were able to present such a localisation system based on all the sensors
|
||||
mentioned above, including the phone's barometer \cite{Ebner-15}.
|
||||
In our previous work we were able to present such a localisation system based on all the sensors mentioned above, including the phone's barometer \cite{Ebner-15}.
|
||||
|
||||
In pedestrian navigation, the human movement is subject to the characteristics of walking speed and -direction.
|
||||
Additionally, environmental restrictions need to be considered as well, for example,
|
||||
walking through walls is impossible.
|
||||
Additionally, environmental restrictions need to be considered as well, for example, walking through walls is impossible.
|
||||
Therefore, incorporating environmental knowledge is a necessary and gainful step.
|
||||
Like other systems, we are using a graph-based approach to sample only valid movements.
|
||||
The unique feature of our approach is the way how we model the human movement.
|
||||
This is done by using random walks on a graph, which are based on the heading of the
|
||||
pedestrian.
|
||||
Despite very good results, the system presented in \cite{Ebner-15} suffers from two drawbacks,
|
||||
we want to solve within this work.
|
||||
This is done by using random walks on a graph, which are based on the heading of the pedestrian.
|
||||
Despite very good results, the system presented in \cite{Ebner-15} suffers from two drawbacks, we want to solve within this work.
|
||||
|
||||
First, the transition model of our previous approach uses discrete floor-changes.
|
||||
Although the overall systems provides viable results, it does not resemble real-world floor changes.
|
||||
Especially the barometric sensor is affected due to its continuous pressure measurements.
|
||||
The discrete model prevents the barometer's full potential.
|
||||
It could further be shown that a correct estimation strongly depends on the quality of $z$-transitions.
|
||||
To address this problem we extended the graph by adding realistic stairs, allowing a step-wise transition
|
||||
in the $z$-direction.
|
||||
To address this problem we extended the graph by adding realistic stairs, allowing a step-wise transition in the $z$-direction.
|
||||
|
||||
Second, the heading for modelling the pedestrian's walking behaviour is calculated between two adjacent nodes.
|
||||
This restricts the transition to perform only discrete \SI{45}{\degree} turns. In most scenarios this assumption performs
|
||||
@@ -50,8 +43,7 @@ well, since the... However, walking sharp turns and ... is not
|
||||
\commentByToni{Ich denke hier kann Frank E. noch bissle was schreiben, oder?}
|
||||
\commentByFrank{ja das werde ich noch anpassen, dass es stimmt und die probleme beschreibt}
|
||||
|
||||
To improve the complex problem of localising a person indoors, prior knowledge given by a pedestrian navigation can be used.
|
||||
\commentByFrank{klingt etwas komisch. -- given by a navigation system -- oder sowas in der art?}
|
||||
To improve the complex problem of localising a person indoors, prior knowledge given by a navigation system can be used.
|
||||
Such applications are used to navigate a user to his desired destination.
|
||||
This limits the unpredictability of human movement to a certain degree.
|
||||
So, based on this assumption, the destination is known beforehand and the starting point is the pedestrian's currently estimated position.
|
||||
@@ -63,13 +55,11 @@ Therefore, we present a novel approach that detects walls using the inverted gra
|
||||
|
||||
In order to model areas near walls less likely to be chosen for walking, a probabilistic weight is assigned to every node of the graph.
|
||||
This allows a variety of options for integrating additional knowledge about the environment and enables us to address another problem:
|
||||
\commentByFrank{wie waers mit: entering or leaving rooms is very unlikely as only a few nodes (doors) allow doing so}
|
||||
Walking through a door has a lower probability than remaining on the corridor, since only a few nodes are representing it.
|
||||
Entering or leaving rooms is very unlikely as only a few nodes are representing doors and allow doing so.
|
||||
This can be tackled by making such areas more likely.
|
||||
Therefore, a novel approach for detecting doors using again the inverted graph and the principal component analysis (PCA) \cite{Hotelling1933} is presented within this work.
|
||||
\commentByFrank{auch hier vlt das inverted erstmal noch weg lassen wegen platz}
|
||||
|
||||
\commentByFrank{wenn dir das weighted graph immer noch nicht gefaellt: -- weights attached the nodes -- oder sowas?}
|
||||
Finally, it is now possible to calculate more natural and realistic paths using the weighted graph.
|
||||
We introduce two different methods which make use of the given destination and thereby provide a targeted movement.
|
||||
To the best of our knowledge, this approach is the first one that uses prior navigation knowledge to increase the localisation results.
|
||||
|
||||
Reference in New Issue
Block a user