This commit is contained in:
toni
2018-10-17 17:21:04 +02:00
8 changed files with 95 additions and 60 deletions

View File

@@ -1,7 +1,7 @@
\abstract{
Within this work we present an updated version of our \del{award-winning} indoor localization system for smartphones.
The \add{pedestrian's} position is given by means of recursive state estimation using a particle filter to incorporate different probabilistic sensor models.
Our \del{rapid computation} \add{recently presented approximation} scheme of the kernel density estimation allows to find an exact estimation of the current position\add{, instead of classical methods like weighted-average}.
Our \del{rapid computation} \add{recently presented approximation} scheme of the kernel density estimation allows to find an exact estimation of the current position\add{, compared to classical methods like weighted-average}.
%
Absolute positioning information is given by a comparison between recent \docWIFI{} measurements of nearby access points and signal strength predictions.
Instead of using time-consuming approaches like classic fingerprinting or measuring the exact positions of access points, we use an optimization scheme based on a few reference measurements to estimate a corresponding \docWIFI{} model.

View File

@@ -30,7 +30,7 @@ In the case of particle filters the MMSE estimate equals to the weighted-average
where $W_t=\sum_{i=1}^{N}w^i_t$ is the sum of all weights.
While producing an overall good result in many situations, it fails when the posterior is multimodal.
In these situations the weighted-average estimate will find the estimate somewhere between the modes.
Clearly, such a position between modes is extremely unlikely the position of the pedestrian.
\del{Clearly}\add{It is expected that}, such a position between modes is extremely unlikely the position of the pedestrian.
The real position is more likely to be found at the position of one of the modes, but virtually never somewhere between.
In the case of a multimodal posterior the system should estimate the position based on the highest mode.
@@ -39,7 +39,7 @@ A straightforward approach is to select the particle with the highest weight.
However, this is in fact not necessarily a valid MAP estimate, because only the weight of the particle is taken into account.
In order to compute the true MAP estimate the local density of the particles needs to be considered as well \cite{cappe2007overview}.
\del{It is obvious,} A computation of the probability density function of the posterior could solve the above, but finding such an analytical solution is clearly an intractable problem, which is the reason for applying a sample representation in the first place.
\del{It is obvious,} A computation of the probability density function of the posterior could solve the above, but finding such an analytical solution is \del{clearly} an intractable problem, which is the reason for applying a sample representation in the first place.
A feasible alternative is to estimate the parameters of a specific parametric model based on the sample set, assuming that the unknown distribution is approximately a parametric distribution or a mixture of parametric distributions, \eg{} Gaussian mixture distributions.
Given the estimated parameters the most probable state can be obtained from the parameterised density function.
%In the case of multi-modalities several parametric distributions can be combined into a mixture distribution.

View File

@@ -1,6 +1,8 @@
\section{Evaluation}
\label{sec:evaluation}
%\newcommand{\ourWifiModel}{log-distance + ceilings model}
The probability density of the state evaluation in \eqref{equ:bayesInt} is given by
%
\begin{equation}
@@ -46,9 +48,16 @@ The comparison between a single RSSI measurement $\mRssi_i$ and the reference is
\noindent where $\mu_{i,\mPosVec}$ denotes the (predicted) signal strength for the \docAPshort{} identified by $i$, regarding the location $\mPosVec$.
A certain noise is allowed by the corresponding standard deviation $\sigma_{\text{wifi}}$.
Within this work $\mu_{\mPosVec}$ is calculated by a modified version of the wall-attenuation-factor model as presented in \cite{Ebner-17}.
\add{We only consider floors and ceilings in order to avoid computation-intensive intersection-tests with every wall along the line-of-sight.
Especially for a building like the one discussed in this paper, this assumption is reasonable due to the complex and historically grown architecture as well as the many different wall materials to be determined.}
Within this work $\mu_{i,\mPosVec}$ is calculated by a compromise between the log-distance model and the
wall-attenuation factor model \cite{radar}, as presented in \cite{Ebner-17}.
\add{
The model only considers floors/ceilings, as including walls demands for costly intersection tests to determine all walls along the signal's line-of-sight.
While including walls within the model would increase the accuracy of the model's prediction \cite{PropagationModelling, radar},
for many use-cases it is sufficient to just consider floors/ceilings,
to reduce the performance impact when being used on smartphones.
%Especially for a building like the one discussed in this paper,
%this assumption is reasonable due to the complex and historically grown architecture as well as the many different wall materials to be determined.
}
Therefore, the prediction depends on the 3D distance $d$ between the \docAPshort{} in question and the location $\mPosVec$ as well as the number of floors $\Delta f$ between them:
\begin{equation}

View File

@@ -28,7 +28,7 @@ Many unknown quantities, like the walls definitive material or thickness, make i
Additionally, \del{most wireless} \add{many of these} approaches are based on a line-of-sight assumption.
Thus, the performance will be even more limited due to the irregularly shaped spatial structure of such buildings.
Our approach tries to avoid those problems using an optimization scheme for Wi-Fi based on a \del{few} \add{set of} reference measurements.
We distribute a \del{small number} \add{set} of \del{simple} \add{small (\SI{2.8}{\centi\meter} x \SI{3.5}{\centi\meter})} and cheap \add{($\approx \SI{10}{\$}$)} \docWIFI{} beacons over the whole building \add{to ensure a reasonable coverage} and instead of measuring their position \add{and necessary parameters, we use our optimization scheme, initially presented in \cite{Ebner-17}}.
We distribute a \del{small number} \add{set} of \del{simple} \add{small (\SI{2.8}{\centi\meter} x \SI{3.5}{\centi\meter})} and cheap \add{($\approx \$10$)} \docWIFI{} beacons over the whole building \add{to ensure a reasonable coverage} and instead of measuring their position \add{and necessary parameters, we use our optimization scheme, initially presented in \cite{Ebner-17}}.
\add{An optimization scheme is able to compensate for wrongly measured access point positions, inaccurate building plans or other knowledge necessary for the Wi-Fi component.
}
@@ -65,11 +65,11 @@ The goal of this work is to propose a fast to deploy \del{and low-cost} localiza
\add{However, many state-of-the-art solutions are evaluating their systems within office or faculty buildings, offering a modern environment and well described infrastructure.}
Consequently, we believe that by utilizing our localization approach to such a challenging scenario, it is possible to prove those characteristics.
\add{To initially set up the system we only require a blueprint to create the floorplan, some Wi-Fi infrastructure, without any further information about access point positions or parameters, and a smartphone carried by the pedestrian to be localized.
The existing Wi-Fi infrastructure can consist of the aforementioned Wi-Fi beacons and / or already existing access points.
The existing Wi-Fi infrastructure can consist of the aforementioned Wi-Fi beacons and/or already existing access points.
The combination of both technologies is feasible, depending on the scenario and building.
Nevertheless, the museum considered in this work has no Wi-Fi infrastructure at all, not even a single access point.
Thus, we distributed a set of \SI{42}{beacons} throughout the complete building by simply plugging them into available power outlets.
Despite evaluating the novel contributions and the overall performance of the system, we have carried out additional experiments to determine the performance of our Wi-Fi optimization in such a complex scenario as well as a detailed comparison between KDE-based and weighted-average position estimation.}
In addition to evaluating the novel contributions and the overall performance of the system, we have carried out further experiments to determine the performance of our Wi-Fi optimization in such a complex scenario as well as a detailed comparison between KDE-based and weighted-average position estimation.}
%novel experiments to previous methods due to the complex scenario blah und blub.}
%Finally, it should be mentioned that the here presented work is an highly updated version of the winner of the smartphone-based competition at IPIN 2016 \cite{Ebner-15}.

View File

@@ -22,10 +22,12 @@
\label{fig:museumMapMesh}
\end{subfigure}
\caption{
Floorplan and transition data structures for the ground floor of the building (\SI{71}{\meter}~x~\SI{53}{\meter}).
To reach every nook and cranny, the graph based approach (b) requires many nodes and edges.
The depicted version uses a coarse node-spacing of \SI{90}{\centi\meter} (1700 nodes) and barely reaches all doors and stairs.
A navigation mesh (c) requires only 320 triangles to tightly reach every corner within the building.
Floorplan and automatically generated transition data structures for the ground floor of the historic building (\SI{71}{\meter}~x~\SI{53}{\meter}).
\add{
To reach every nook and cranny, the generated graph (b) requires many nodes and edges.
The depicted version uses a coarse node-spacing of \SI{90}{\centi\meter} (1700 nodes) but barely reaches all doors and stairs.
A navigation mesh generated for the same building required only 320 triangles (c) and reaches every corner within the building.
}
}
\label{fig:transition}
\end{figure}
@@ -110,18 +112,29 @@
Using variably shaped/sized elements instead of rigid grid-cells
provides both, higher accuracy for reaching every corner, and a reduced
memory footprint as a single polygon is able to cover arbitrarily
large regions. However, polygons impose several drawbacks on
large regions.
\add{
For a rectangular room, the number of elements needed for the graph-based approach depends
on the room's size and the chosen spacing. The navigation mesh, however, only needs
a single, four-sided polygon, to fully cover the rectangular shape of the room, independent of its size.
}
However, polygons impose several drawbacks on
common operations used within the transition step, like checking whether
a point is contained within some region. This is much more costly for polygons
\add{ compared to axis-aligned, rectangular grid-cells. }
\add{ compared to axis-aligned, rectangular grid-cells.}
% museum aus figure: 305 3-ecke
% museum ganz : 789 fuer alles
%
Such issues can be mitigated by using triangles instead of polygons, depicted within \reffig{fig:museumMapMesh}.
Doing so, each element within the mesh has exactly three edges and a maximum of three neighbors.
While this usually requires some additional memory, as more triangles are need compared to polygons,
operations, such as aforementioned contains-check, can now easily be performed,
\eg{} by using barycentric coordinates.
\add{
This usually requires some additional memory, as more triangles are need compared to polygons.
For the example of the rectangular room, two adjacent triangles are required to form
a rectangular shape.
However, using triangles, operations such as aforementioned contains-check, can now easily be performed,
\eg{} by using barycentric coordinates, yielding noticeable speedups compared to polygons.
}
\newcommand{\turnNoise}{\mathcal{T}}
\newcommand{\stepSize}{\mathcal{S}}
@@ -129,8 +142,8 @@
The most simple approach uses an average pedestrian step size together with the
number of detected steps $\mObsSteps$ and change in heading $\mObsHeading$
gathered from sensor observations $\mObsVec_{t-1}$.
Combined with previously estimated position $(x,y)^T$ and heading $\mStateHeading$
%from $\mStateVec_{t-1}$
Combined with previously estimated position $(x,y,z)^T$ and heading $\mStateHeading$
from $\mStateVec_{t-1}$
, including uncertainties for step-size $\stepSize$
and turn-angle $\turnNoise$,
this directly defines new potential whereabouts
@@ -140,38 +153,61 @@
\begin{aligned}
x_t &=& \overbrace{x_{t-1}}^{\text{old pos.}}& & &+& \overbrace{\mObsSteps \cdot \stepSize}^{\text{distance}}& & &\cdot& \overbrace{\cos(\mStateHeading_{t})}^{\text{direction}}& & ,\enskip \turnNoise &\sim \mathcal{N}(\mObsHeading, \sigma_\text{turn}^2) \\
y_t &=& y_{t-1}\phantom{.}& & &+& \mObsSteps \cdot \stepSize& & &\cdot& \sin(\mStateHeading_{t})& & ,\enskip \stepSize &\sim \mathcal{N}(\SI{70}{\centi\meter}, \sigma_\text{step}^2) \\
z_t &=& \text{interpolated} \\
\mStateHeading_{t} &=& \mStateHeading_{t-1} + \turnNoise\\
\end{aligned}
\label{eq:navMeshTrans}
\end{equation}
\noindent{}with
%
\add{
\begin{equation*}
\mObsSteps,\mObsHeading \in \mObsVec_{t-1}
\enskip\enskip\enskip
\quad
\text{,}
\quad
x_{t-1},y_{t-1},z_{t-1},\mStateHeading_{t-1} \in \mStateVec_{t-1}
\quad
\text{and}
\enskip\enskip\enskip
x_{t-1},y_{t-1},\mStateHeading_{t-1} \in \mStateVec_{t-1}
\quad
x_{t},y_{t},z_{t},\mStateHeading_{t} \in \mStateVec_{t}
\enskip.
\end{equation*}
}
Whether the newly obtained destination $(x_t, y_t)^T$ is actually reachable from the start $(x_{t-1}, y_{t-1})^T$ can be determined
by checking if their corresponding triangles are connected with each other.
If so, the corresponding $z_t$ can be interpolated using the barycentric coordinates of $(x_t, y_t)^T$
within a 2D projection of the triangle the position belongs to and applying them to the original 3D triangle.
If the destination is unreachable,
\eg{} due to walls or other obstacles. Those occurrences demand for different handling strategies. Simply trying again might
\add{
The walk's starting triangle is the triangle that contains $(x_{t-1}, y_{t-1}, z_{t-1})^T$.
The $z$-component is hereafter ignored, as it is defined by the mesh's triangles, which denote the walkable floor.
Hereafter, \refeq{eq:navMeshTrans} is used to determine the walk's destination in $x$ and $y$ only.
Whether the newly obtained destination $(x_t, y_t)^T$ is actually reachable from the start $(x_{t-1}, y_{t-1})^T$ can be determined
by checking if there is a way from the starting triangle towards some other, nearby triangle that contains these coordinates.
If so, the discarded $z$-component $z_t$ is determined using the barycentric coordinates of $(x_t, y_t)^T$
within a 2D projection of the triangle the position belongs to, and applying them to the original 3D triangle.
This can be though of walking along a 2D floor, and determining the floor's altitude for the 2D destination.
}
\add{
If this destination is unreachable,
\eg{} due to walls or other obstacles, different handling strategies are required.
}
Simply trying again might
be a viable solution, as uncertainty induced by $\turnNoise$ and $\stepSize$ will yield a slightly different destination
that might be reachable. Increasing $\sigma_\text{step}$ and $\sigma_\text{turn}$ for those cases might also be a viable choice.
Likewise, just using some random position, omitting heading/steps might be viable as well.
The detected steps $\mObsSteps$ and the heading change $\mObsHeading$ are obtained using the smartphone's IMU.
To provide a robust heading change, we first need to rotate the gyroscope onto the east-north-up frame using a suitable transformation matrix.
After the rotation, integrating over the gyros $z$-axis for a predefined time interval provides the users heading change (yaw) \cite{Ebner-15}.
To obtain the matrix in the first place, we assume that the acceleration during walking is cyclic and thus the average acceleration over several cycles has to be almost zero.
This enables to measure the direction of gravity and use it to construct the transformation matrix.
It should be noted, that especially for cheap IMUs, as they can be found in most smartphones, the matrix has to be updated at very short intervals of one or two seconds to preserve good results \cite{davidson2017survey}.
The detected steps $\mObsSteps$ and the heading change $\mObsHeading$ \add{used within above transition} are obtained by the smartphone's IMU.
For the change in heading, we first need to rotate the gyroscope's readings onto the east-north-up frame using a suitable rotation matrix,
\add{
to determined, what the readings would look like, if the smartphone was placed parallel to the ground.
The matrix is thus used to undo the rotation introduced by the pedestrian holding the phone.
This rotation matrix is given by the matrix that rotates the current gravity readings from the accelerometer to
the $(0,0,\SI{9.81}{\meter\per\square\second})^T$ vector.
After applying the matrix to the gyroscope's readings,
the pedestrian's change in heading (yaw) is given by integrating over the gyroscope's $z$-axis \cite{Ebner-15}.
}
It should be noted, that especially for cheap IMUs, as they can be found in most smartphones,
the matrix has to be updated at very short intervals of one or two seconds to preserve good results \cite{davidson2017survey}.
To receive the number of steps, we use a very simple step detection based on the accelerometer magnitude.
To receive the number of steps, we use a very simple step detection based on the accelerometer's magnitude.
For this, we calculated the difference between the average magnitude over the last \SI{200}{\milli\second} and the gravity vector.
If this difference is above a certain threshold ($> \SI{0.32}{\m\per\square\s}$), a step is detected.
To prevent multiple detections within an unrealistic short interval, we block the complete process for \SI{250}{\milli\second} \cite{Koeping14}.