Merge branch 'master' of https://git.frank-ebner.de/FHWS/IPIN2018
This commit is contained in:
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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}
|
||||
|
||||
@@ -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}.
|
||||
|
||||
@@ -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*}
|
||||
}
|
||||
|
||||
\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 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
|
||||
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 user’s 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}.
|
||||
|
||||
@@ -15,11 +15,8 @@ The paper presents a smartphone-based localization system using a particle filte
|
||||
-> Thank you very much for pointing this out. Your concerns are valid. This was a misformulation within the introduction of the paper. We have improved the relevant section of the text and made the basic statement clearer. Please refer to line xxx and xxx.
|
||||
|
||||
5. The author mention that "Such buildings are often full of nooks and crannies, what makes it hard for dynamical models using any kind of pedestrian dead reckoning (PDR)","the error accumulates not only over time, but also with the number of turns and steps made". So "Thus, this paper presents a robust but realistic movement model using a three-dimensional navigation mesh based on triangles". However, Why does the three-dimensional navigation mesh can deal with the turns and steps error? The author should give the more detail description. The navigation graph uses 30*30 grid-cell, the navigation mesh uses triangles. But I don't find very clear that how does the triangles plan? More triangles can improve the accuracy or not? Why the the ground floor need 320 triangles? This the minimum?
|
||||
@Frank besser beschreiben?
|
||||
alles wird mit so wenigen 3-ecken wie möglich abgedeckt. hängt von der architektur ab
|
||||
leerer raum = 2 3-ecke. je nach hindernissen wird es mehr
|
||||
die anzahl der 3-ecke ist NICHT variabel sondern wird vom algorithmus bestimmt
|
||||
320 kam halt bei raus
|
||||
-> We completely changed the transition part, describing how both, graph and nav-mesh are generated automatically, based on the building's floorplan. The number of required triangles strongly depends on the building's layout. 320 were required for the building presented within the picture.
|
||||
|
||||
|
||||
6. The authors emphasize that "The goal of this work is to propose a fast to deploy and low-cost localization solution, that provides reasonable results in a high variety of situations". But for the 2500m2 building they used 42 WiFi beacon. I don't think the number is few. Is the whole 42 beacon necessary? The author should discuss the impact of the number of WiFi beacon. How many are the reference poits? What's the impact of the density of the reference points? If the authors want to emphasizen the fast deploy and low-cost, they should give more detail discussion, also the "high variety".
|
||||
-> 2500m2 sind nur die bereiche in denen gelaufen werden kann. ohne den innenhof. die zahl ist also etwas verwirrend...
|
||||
|
||||
@@ -14,10 +14,9 @@ Using a MCL you do not need to mix observations and actions in the same concept
|
||||
From my point of view formulation of transition model T should be tackled using actions (steps) and observations (s_wifi) should be used like an observation model V (described like "Evaluation" in section 5).
|
||||
|
||||
line 226: What is z_t? Is an observation o_t? nomenclature should be unified through the whole paper
|
||||
@Frank z_t position genauer beschreiben
|
||||
das nav-mesh geht erstmal nur 2D und das z interpolieren wir
|
||||
das z (höhe) wird ja wirklich vom stockwerk vorgegeben.
|
||||
x,y,z sind alle 3 teil vom state!
|
||||
-> we completely changed the formulation here. z_t is the z-component at time t, which belongs to the state q_t.
|
||||
it is given be the nav-mesh triangles, which denote the buildings floor.
|
||||
z_t stays constant, as long as the floor is flat. it only changes when stairs are involved.
|
||||
|
||||
line 319: Are these thresholds able for all of pedestrians? have you tried with different actors and behaviors?
|
||||
|
||||
|
||||
@@ -59,27 +59,21 @@ Ln 160 “are based on the nature of particle filter.” -> “are based on the
|
||||
-> Fixed in line 180.
|
||||
|
||||
Ln 215: "Using variable shaped/sized elements instead of rigid grid-cells provide both higher accuracy for reaching every corner, and ..." Is accuracy the right word here?
|
||||
-> TODO: @Frank
|
||||
hervorheben, dass das grid integer based ist. und deshalb die grid-punkte fallen wie sie fallen
|
||||
hervorheben, dass grid und nav-mesh auto-generiert werden
|
||||
anzahl der 3-ecke hängt einfach von der architektur ab. je mehr hindernisse und türen, desto mehr 3-ecke werden es
|
||||
für einfache recheckige räumen reichen sonst 2 dreiecke. aber die seiten der 3-ecke müssen ja zusammenhänge
|
||||
-> We completely changed the transition part, describing how both, graph and nav-mesh are generated automatically, based on the building's floorplan.
|
||||
We hope the new description points out why navigation meshes allow for a better (and more exact/accurate) representation of the building's floorplan compared to the grid-based approach.
|
||||
|
||||
|
||||
Ln 228: "If the destination is unreachable, e.g. due to the walls or other obstacles." This phrase is incorrect, the authors should reformulate it.
|
||||
@Frak umschreiben
|
||||
-> Thank you for noticing! We adjusted the sentence accordingly.
|
||||
|
||||
Ln 237: "...the average acceleration..." This includes both linear acceleration and gravity, use "linear acceleration".
|
||||
-> TODO: @Frank?
|
||||
hier gehts um die gravity. wir müssen die lage des phones erkennen. hervorheben.
|
||||
die >>linear<< acceleration interessiert hier nicht.
|
||||
das ganze wird sehr oft aktualisiert um die richtige lage zu haben
|
||||
-> we rephrased the complete paragraph. It should now be clear how the current gravity readings are used to
|
||||
determined the phone's current orientation, to undo the rotation, present within the gyroscope's readings.
|
||||
|
||||
Ln 258 - This equation needs revision. Should it be "p(s_i|p) ~ N(u_i,p , std²_wifi)" ? Also the wall-attenuation-factor-model only takes into account attenuation by floors, not walls.
|
||||
-> TODO: Eigentlich passt das mit der NV, für Ihn tdz ändern? Und das model nimmt keine wände, weil wir keine wände nehmen :D.
|
||||
@Frank hervorheben dass wir nicht WAF sondern log-dist-ceiling benutzen
|
||||
walls wären problemlos möglich, allerdings kostet das dann viel zu viel zeit die schnittpunkte zu analysieren
|
||||
|
||||
-> No, the equation is correct. Its the actual >result< of the normal distribution when questioned for the received s_i, given the model prediction was u_i,p with uncertainty \sigma^2_wifi
|
||||
-> We now made clear that our model is something in between the log-distance and the wall-attenuation factor model. To reduce computation time on the smartphone, only floors/ceilings are considered
|
||||
as this can be achieved without costly intersection tests. We also pointed out, that including walls would be more accurate, but is costly during runtime (intersection-tests).
|
||||
|
||||
Ln 271-272: The authors mention that their WiFi fingerprinting approximation process is faster than classical fingerprinting, but they fail to provide a reference for an example of the latter or significant metrics such as the average time per square meter for fingerprinting a whole building. Furthermore, the authors should also take into account that while there are approaches where reference measurements are recorded on small grids between 1 to 2m, there are also approaches able to record reference measurements using faster methods. One example is walking by the building while registering ground truth points and using dead reckoning techniques (see Guimarães, V. et al. A motion tracking solution for indoor localization using smartphones. In Proceedings of the 2016 International Conference on Indoor Positioning and Indoor Navigation (IPIN)).
|
||||
-> TODO: vielleicht den satz hier entfernen und im related work darauf hinweisen, dass es auch andere schnelle ansätze gibt? Wobei wir im related work schon [20] gecited haben, der genau das macht! vielleicht erwähnen wir seinen noch, damit er zufrieden ist? Oder wir zeigen das kleine fingerprints schneller ist als laufen? was vermutlich nicht der fall ist.
|
||||
|
||||
Reference in New Issue
Block a user