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

transition

Browse Source
This commit is contained in:
k-a-z-u
2018-10-16 16:56:25 +02:00
parent 40a0c8cbff
commit 334c237bcf
4 changed files with 59 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files

72
tex_review/chapters/transition.tex
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,26 +153,43 @@
\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.

7
tex_review/review/01_review.txt
View File

@@ -14,11 +14,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...

7
tex_review/review/02_review.txt
View File

@@ -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?

9
tex_review/review/03_review.txt
View File

@@ -59,15 +59,12 @@ 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?