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

Merge branch 'master' of https://git.frank-ebner.de/FHWS/IPIN2018

Browse Source
This commit is contained in:
toni
2018-10-21 13:14:55 +02:00
parent a0936823a5 1a69d14628
commit 7b7ce11331
3 changed files with 37 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
tex_review/chapters/conclusion.tex
View File

@@ -4,7 +4,7 @@
Within this work we provided an extensive overview of our smartphone-based indoor localization system, \add{providing both, previous advances and novel contributions.}
The thorough evaluation demonstrated the good performance under multiple scenarios within a complex environment.
The system is able to handle problems like sample impoverishment and multimodal densities, occurring through the use of a particle filtering scheme.
\add{Based on the good results in this challenging scenario, we believe that our solution can be adapted to many other public buildings and environments, resulting in a very generally usable solution for self-localization of pedestrians using smartphones.
\add{Based on the promising results achieved in this challenging scenario, we believe that our solution can be adapted to various public buildings and environments, resulting in a generally usable solution for self-localization of pedestrians using smartphones.
Previous versions of the system have already proven themselves in other, more modern buildings, which supports this claim to general use.}
%novel stuff

12
tex_review/chapters/eval.tex
View File

@@ -186,12 +186,12 @@ Defining a threshold $t_\text{acc}$ for acceleration (m/s$^2$) and $t_\text{baro
\node [activity, below=0.5cm of x3, xshift=3cm](x3r){walking up};
%
\path [*->, line] (start) -- (x0);
\path [line] (x0) -| (x2) node [pos=0.25] {no};
\path [line] (x0) -| (x1) node [above, pos=0.25] {yes};
\path [line] (x2) -| (x3) node [pos=0.25] {no};
\path [line] (x3) -| (x3l) node [above, pos=0.25] {yes};
\path [line] (x3) -| (x3r) node [pos=0.25] {no};
\path [line] (x2) -| (x4) node [above, pos=0.25] {yes};
\path [line] (x0) -| (x2) node [pos=0.25] {false};
\path [line] (x0) -| (x1) node [above, pos=0.25] {true};
\path [line] (x2) -| (x3) node [pos=0.25] {false};
\path [line] (x3) -| (x3l) node [above, pos=0.25] {true};
\path [line] (x3) -| (x3r) node [pos=0.25] {false};
\path [line] (x2) -| (x4) node [above, pos=0.25] {true};
\end{tikzpicture}
\end{center}
\caption{\add{Decision tree describing the threshold-based activity recognition using the smartphone’s

57
tex_review/chapters/experiments.tex
View File

@@ -42,7 +42,7 @@ As the optimization scheme does not require equally spaced reference points, doi
Furthermore, it is not easy to adopt the exact position to take the reference measurements in the building later on.
Of course, this could be achieved with appropriate hardware (e.g. laser-scanner), but again, this requires more time and care, which in our opinion does not justify a presumably increased accuracy of some decimeters.}
\add{Summing up the above, the following initial steps are required to utilize our localization system to a building:
\add{Summing up the above, the following initial steps are required to utilize our localization system in a building:
\begin{enumerate}
\item Acquiring a blueprint or architectural drawing of the building including at minimum the walls and stairs of the respective floors.
\item Based on this 2D drawing, the floor plan is created manually using our 3D map editor (cf. fig. \ref{fig:mapeditor}), comparable to software like Inkscape or FreeCAD.
@@ -57,16 +57,16 @@ Step 1 and 2 were conducted off-site.
The blueprint was initially provided by the director of the museum as digital photography.
Creating the floor plan including walls and stairs took us approximately \SI{40}{\minute} and is then stored onto the smartphone after creation.
Adding knowledge like semantic information such as room numbers would of course take additional time.
All other steps were performed on-site using our smartphone app for localization, which can be seen in fig. \ref{fig:yasmin}.
As the museum did not provide any Wi-Fi infrastructure, we installed the \SI{42}{} beacons as explained above.
Thanks to the great support of the museum's janitor, this step took only \SI{30}{\minute}, as he was well aware of all available power outlets and also helped plugging them in.
After that, each of the \SI{133}{} reference points was scanned 30 times ($\approx \SI{25}{\second}$ scan time) using a Motorola Nexus 6 at \SI{2.4}{GHz}.
All remaining steps were performed on-site using our smartphone app for localization, which can be seen in fig. \ref{fig:yasmin}.
As the museum did not provide any Wi-Fi infrastructure, we installed \SI{42}{} beacons as explained above.
With the help of the museum's janitor, this step took only \SI{30}{\minute}, as he was well aware of all available power outlets and also helped plugging them in.
After that, each of the \SI{133}{} reference points was scanned 30 times ($\approx \SI{25}{\second}$ scan time) using a Motorola Nexus 6 at the \SI{2.4}{GHz} Wi-Fi band.
This took \SI{85}{\minute}, as all measurements were conducted using the same smartphone.
The optimized Wi-Fi model and the mesh can be created automatically within a few seconds directly on the smartphone, which then enables the pedestrian to start the localization.
The optimized Wi-Fi model and the mesh can be created automatically within a negligible amount of time directly on the smartphone, which then enables the pedestrian to start the localization.
Of course, for the experiments conducted below several additional knowledge was obtained to evaluate the quality of the proposed methods and the overall localization error.
Thus the above provided times were measured for a pure localization installation, as for example a customer would order, while the experiments were performed in a 2-day period.
Nevertheless, we believe that an on-site setup-time of less then \SI{120}{\minute} is a big step for the practicability of localization systems.
In addition, the above steps do not require a high level of detail in their execution, which should also allow unbiased persons to set up the system.}
Nevertheless, we believe that an on-site setup-time of less than \SI{120}{\minute} is a big step for the practicability of localization systems. \commentByMarkus{big step is komisch}
In addition, the above steps do not require a high level of thoroughness in their execution or special knowledge about the details of the system, which should also allow unbiased persons to set up the system.}
\begin{figure}[t]
\centering
@@ -78,7 +78,7 @@ In addition, the above steps do not require a high level of detail in their exec
\hspace{1cm}
\begin{subfigure}{0.45\textwidth}
\includegraphics[width=\textwidth]{gfx/apps/simple.png}
\caption{Simple Recording App}
\caption{Recording App}
\label{fig:simple}
\end{subfigure}
@@ -88,12 +88,12 @@ In addition, the above steps do not require a high level of detail in their exec
\add{As mentioned, the here presented localization system was implemented as an Android App.
It was written in high performant C++ code, enabling to run completely on the smartphone and thus not requiring any connection to a server.
However, since the experiments required a lot of different information to evaluate the methods, a second, very simple application was developed to record them (see fig. \ref{fig:simple}).
It implements the standard Android sensor functionalities and provides a very simple user interface so that even non-technical users can use it.}
However, since the experiments required additional information to evaluate the methods, a second, simple application was developed to aid the recording of them (see fig. \ref{fig:simple}).
It implements the standard Android sensor functionalities and provides a minimalistic user interface so that even non-technical users can use it.}
As smartphones we used either a Samsung Note 2, Google Pixel One or Motorola Nexus 6.
The computation of the state estimation as well as the \docWIFI{} optimization are done offline using an Intel Core i7-4702HQ CPU with a frequency of \SI{2.2}{GHz} running \add{\SI{8}{threads} on \SI{4}{cores}} and \SI{16}{GB} main memory.
\add{An offline computation has practical advantages, such as easier evaluation of the results or shorter waiting times due to higher computing power.
Nevertheless, Android app and offline application are both based on the same C++ backend for localization.}
Nevertheless, Android app and offline application are both use the same C++ backend for localization.}
%However, similar to our \add{previously presented system}, the setup is able to run completely on commercial smartphones as it \add{is} written in high performant C++ code \cite{torres2017smartphone}.
@@ -102,7 +102,7 @@ Nevertheless, Android app and offline application are both based on the same C++
The experiments are separated into five sections:
At first, we discuss the performance of the novel transition model and compare it to a grid-based approach.
In section \ref{sec:exp:opti} we have a look at \docWIFI{} optimization and how the real \docAPshort{} positions differ from it.
Following, we conducted several test walks throughout the building to examine the estimation accuracy (in \SI{}{\meter}) of the localization system and discuss the here presented solutions for sample impoverishment.
Following, we conducted several test walks throughout the building to examine the estimation accuracy (in meter) of the localization system and discuss the here presented solutions for sample impoverishment.
\add{In section \ref{sec:eval:act} the threshold-based activity recognition is evaluated, providing a detection rate for the test walks utilized before.}
Finally, the respective estimation methods are discussed in section \ref{sec:eval:est}.
@@ -113,27 +113,27 @@ Finally, the respective estimation methods are discussed in section \ref{sec:eva
\begin{subfigure}{0.4\textwidth}
\def\svgwidth{\columnwidth}
\input{gfx/transEval/mesh_25_final.eps_tex}
\caption{Mesh after 25 steps}
\caption{Mesh approach after 25 steps}
\label{fig:transitionEval:a}
\end{subfigure}
\hspace{2cm}
\begin{subfigure}{0.4\textwidth}
\def\svgwidth{\columnwidth}
\input{gfx/transEval/grid_25_final.eps_tex}
\caption{Graph after 25 steps}
\caption{Graph approach after 25 steps}
\label{fig:transitionEval:b}
\end{subfigure}
\begin{subfigure}{0.4\textwidth}
\def\svgwidth{\columnwidth}
\input{gfx/transEval/mesh_180_final.eps_tex}
\caption{Mesh after 180 steps}
\caption{Mesh approach after 180 steps}
\label{fig:transitionEval:c}
\end{subfigure}
\hspace{2cm}
\begin{subfigure}{0.4\textwidth}
\def\svgwidth{\columnwidth}
\input{gfx/transEval/grid_180_final.eps_tex}
\caption{Graph after 180 steps}
\caption{Graph approach after 180 steps}
\label{fig:transitionEval:d}
\end{subfigure}
@@ -153,7 +153,7 @@ We chose a simple, yet effective strategy: whenever a destination is unreachable
Of course, the graph does not require for such a rule, since particles are only allowed to move on nodes and search for neighbours.
Fig. \ref{fig:transitionEval:a} and \ref{fig:transitionEval:b} illustrate the results after \SI{25}{steps} for each method.
The particles are colored according to their height and the walking path (green line) is estimated using weighted-average.
The particles are colored according to their z-coordinate and the walking path (green line) is estimated using weighted-average.
It can be seen that both methods provide similar results.
Due to the discrete grid structure, the purple particles on the graph scatter more strongly, while the mesh provides a truly continuous structure and thus a more compact representation.
It is important to note that outliers have already appeared in both scenarios (blue particles).
@@ -161,7 +161,7 @@ Due to the included sensor noise, they covered a too short distance for several
Going straightforward to \SI{180} steps, this phenomenon has multiplied for the graph (cf. fig. \ref{fig:transitionEval:d}), but not for the mesh (cf. fig. \ref{fig:transitionEval:c}).
This is due to the above-mentioned strategy for the mesh.
Compared to this approach, the graph is not able to remove any particles and thus they walk according to the recognized steps and heading changes, even if they theoretically hit a wall several times.
The resulting effects are obvious.
The resulting effects are obvious. \commentByMarkus{ausformulieren was hier obvious ist}
After walking up and down twice, several particle groups have formed, which no longer allows an accurate position estimation.
Of course, a similar strategy could be developed for a graph.
@@ -413,7 +413,7 @@ As the building does not have an elevator, this state is ignored in the followin
Whether a state needs to be changed was indicated by small symbols on the ground truth markers.
This experiment is based on the same measurement series as section \ref{sec:exp:loc}.}
%
\add{As the activity recognition uses moving averages, the detection suffers from a certain lag, depending on their size.
\add{As the activity recognition uses moving averages, the detection suffers from a certain lag, determined by the window size.
Thus, comparing each activity that is newly calculated with incoming barometer measurements to the ground truth at the current timestamp, would result in a rather low detection rate for the respective activities.
In addition, only a fraction of a test path consists of the change of an activity, since the testers were walking most of the time.
This would bias an overall detection rate.}
@@ -444,24 +444,27 @@ This does not allow a perfect, but at least fair examination of the detection ra
The lag is given as the (absolute) difference between the timestamp, the activity swaps in ground truth (e.g. from standing to walking), and the first timestamp of an interval, given by the size of $\vec{\omega}_\text{s}$, holding the same activity, given by our recognition method.
This provides in an average lag of \SI{2.96}{\second} and a standard deviation of \SI{1.09}{\second} over all walks.
The resulting detection rates can be seen in table \ref{table:activity}.
They are calculated by dividing the number of correctly detected activities with the number of activities given by the ground truth.
They were calculated by dividing the number of correctly detected activities with the number of activities given by the ground truth.
The first thing to notice is the bad recognition rate of standing, especially in comparison to the others.
A major impact on this, is the fact, that we encourage the testers to behave as natural as possible, i.e. like a normal visitor of the museum.
As a result, they often turned around or a took a few small steps within the standing sequences, to look at the exhibits.
This behavior is not mapped by the ground truth.
In addition, using only acceleration for detecting might be a bad choice in the first place, as moving the phone, e.g. by putting it in the trouser pocket, will exceed the threshold.
As a result, they often turned around or a took a few small steps within the standing sequences, to look at the exhibits.}
\add{This behavior is not mapped by the ground truth.
In addition, using only acceleration for detection might be a bad choice in the first place, as moving the phone, e.g. by putting it in the trouser pocket, will exceed the threshold.
At the end, this leads to the general question, on how to define standing.
Is it a complete standstill or should it allow for a certain degree of freedom?
The answer is always the same, it depends.
As for this museum scenario, the results for detecting the standing activity are not satisfying and a more advanced approach should be considered.}
\commentByMarkus{Letzten zwei Sätze wissenschaftlicher machen}
\add{In contrast, the detection rates for walking up or down are certainly better.
\add{In contrast, the detection rates for walking up or down are clearly better.
With only a single exception in walk 3 (cf. chapter \ref{sec:exp:loc}), the approach makes it possible to direct particles smoothly over stairs.
Due to the lag, however, there is a noticeable delay of the estimation when entering the staircase.
During this short period of time, the particles gather in front of the staircase, as they only receive a corresponding weighting when the activity changes.
In buildings with many successive stairs, this could lead to further problems, as it affects the PDR-based movement of the particles.
Nevertheless, in a scenario such as the present, the absolute positioning of Wi-Fi should compensate for this.
As a final notice on this approch, it is not possible to derive the smartphone or the user from the detection rates, which recommends a general use of the approach.}
Nevertheless, in a scenario such as the present, the absolute positioning of Wi-Fi should compensate this.
Finally, the detection rates did not allow to derive the concrete smartphone or the user, which indicates the generality of the approach.}