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

Changes

Browse Source
This commit is contained in:
MBulli
2018-10-20 18:51:07 +02:00
parent 837963b4e8
commit 5cfe410869
6 changed files with 58 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
tex_review/chapters/transition.tex
View File

@@ -6,7 +6,7 @@
\begin{subfigure}{0.325\textwidth}
\centering
\includegraphics[width=5.1cm]{gfx/transition/museumMap.pdf}
\caption{3D Floorplan}
\caption{3D Floor plan}
\label{fig:museumMap}
\end{subfigure}
\begin{subfigure}{0.325\textwidth}
@@ -22,7 +22,7 @@
\label{fig:museumMapMesh}
\end{subfigure}
\caption{
Floorplan and automatically generated transition data structures for the ground floor of the historic building (\SI{71}{\meter}~x~\SI{53}{\meter}).
Floor plan 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.
@@ -33,9 +33,9 @@
\end{figure}
Within previous works, we used a graph of equidistant nodes (see \reffig{fig:museumMapGrid})
to model the building's floorplan, representing the basis for the transition step \cite{Ebner-15, Ebner-16}.
to model the building's floor plan, representing the basis for the transition step \cite{Ebner-15, Ebner-16}.
\add{
It is created \emph{automatically}, based on the building's floorplan,
It is created \emph{automatically}, based on the building's floor plan,
which, in turn, results from \emph{manually} tracing available blueprint pictures within our editing software.
}
% in 15 und 16 haben wir stueckweise den graph eingefuhert
@@ -49,9 +49,9 @@
As cells are equidistant and axis aligned for performance reasons,
the algorithm works reasonably well for rectangular buildings,
matching the graph's coordinate system.
For skewed floorplans, however, many periphery cells will intersect
For skewed floor plans, however, many periphery cells will intersect
with walls and are thus omitted, reducing the quality of the representation.
While smaller cells thus allow for a more accurate representation of the building,
While smaller cells allow for a more accurate representation of the building,
more cells are needed in total, increasing memory requirements for the smartphone.
}
After placement, each cell is connected with their, up to 8, potential
@@ -60,8 +60,8 @@
Those connections are only added, if the neighbor is actually available,
and the connection itself does not intersect any obstacles.
}
Doing so creates a walkable graph \add{of nodes and edges} for each floor.
The graphs for each floor are hereafter connected via stairs or elevators,
Doing so creates a walkable graph \add{consisting of nodes and edges} for each floor.
These graphs are hereafter connected via stairs or elevators,
to form the final, walkable data structure for the whole building.
This allows for (semi-)random walks along the graph, \add{modeling potential pedestrian movements}.
\add{
@@ -88,7 +88,7 @@
model \add{depending on the spacing},
we developed a new basis for the transition step, that is still able to answer
$p(\mStateVec_{t} \mid \mStateVec_{t-1}, \mObsVec_{t-1})$,
\add{but has a much smaller memory footprint while representing the real floorplan
\add{but has a much smaller memory footprint while representing the real floor plan
more accurately.}
%
The new foundation is provided by well-known navigation meshes \cite{navMesh1},
@@ -103,10 +103,10 @@
is presented by shared outline edges between adjacent polygons.
It thus is always possible to walk from one polygon into another,
if they are adjacent.
Similar to the graph-based approach, adjacent polygons thus
Similar to the graph-based approach, adjacent polygons
denote some sort of walkable surface.
Just as before, the navigation mesh can be \emph{automatically}
generated from the building's floorplan, based on
generated from the building's floor plan, based on
various algorithms \cite{navMeshAlg1}.
}
Using variably shaped/sized elements instead of rigid grid-cells
@@ -182,7 +182,7 @@
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.
within a 2D projection of the triangle which 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{