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

worked on transition

Browse Source
This commit is contained in:
k-a-z-u
2018-10-16 14:10:28 +02:00
parent 533b6cfdf2
commit 40a0c8cbff
2 changed files with 85 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

93
tex_review/chapters/transition.tex
View File

@@ -31,46 +31,89 @@
\end{figure}
Within previous works, we used a graph of equidistant nodes (see \reffig{fig:museumMapGrid})
to model the buildings floorplan, representing the basis for the transition step \cite{Ebner-15, Ebner-16}.
to model the building's floorplan, representing the basis for the transition step \cite{Ebner-15, Ebner-16}.
\add{
It is created \emph{automatically}, based on the building's floorplan,
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
%
The graph equals a grid, where each node constitutes the center of a grid-cell.
Cells, usually around \SI{30} x \SI{30}{\centi\meter} in size,
are only placed in regions that are actually walkable and not intersected by any walls
or other obstacles. After placement, each cell is connected with their, up to 8, potential
neighbors in the plane, creating a walkable graph for each floor. The resulting graphs are
hereafter connected via stairs or elevators, to form the final data structure
for the whole building.
This allowes for (semi-)random walks along the graph, by assigning probabilities to each edge,
using prior knowledge provided by sensors, forming the transition probability
The resulting graph equals a grid, where each node constitutes the center of a grid-cell.
\add{
Each cell uses an empiric choice of \SI{30} x \SI{30}{\centi\meter} in size.
The algorithm thus places a new cell every \SI{30}{\centi\meter},
but only in regions that are actually walkable,
and where the cell's outline does not intersect any wall or other obstacles.
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
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,
more cells are needed in total, increasing memory requirements for the smartphone.
}
After placement, each cell is connected with their, up to 8, potential
neighbors in the plane \add{(left,right,top,bottom and diagonals)}.
\add{
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,
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{
By assigning probabilities to each edge, using prior knowledge \eg{} provided by sensors,
the random walk along those weighted edges denotes the transition probability
$p(\mStateVec_{t} \mid \mStateVec_{t-1}, \mObsVec_{t-1})$ \cite{Ebner-16}.
}
Due to the equidistant spacing, the resulting graph was rather rigid and
only well-suited for rectangular buildings. For more contorted buildings, like many
historic ones, the node-spacing needs to be small, to reliably reach every door, stair
and corner of the building. Within \reffig{fig:museumMapGrid} we used a
\SI{90}{\centi\meter} spacing, that is barely able to reach all places within
the lower floors of the building, and failing to connect the upper floors reliably.
Due to the equidistant spacing \add{every \SI{30}{\centi\meter}},
the resulting graph is rather rigid and only well-suited for rectangular buildings.
For more contorted buildings, like many historic ones,
the node-spacing needs to be small, to reliably reach every door, stair
and corner of the building.
\add{For demonstration, we used a \SI{90}{\centi\meter} spacing} within \reffig{fig:museumMapGrid}.
\add{As can be seen, the automatically generated grid} is barely able to reach all places within
the lower floors of the building, and fails to connect the upper floors reliably.
While using smaller spacings remedies the problem, it requires huge amounts of memory:
up to several hundred megabytes and millions of nodes and edges to model a single building.
\add{Up to hundred megabytes and millions of nodes and edges are realistic for larger buildings.}
% musuem aus figure: 90cm grid : ca 2000 nodes, ca 6500 edges
% museum aus figure: 30cm grid : ca 32k nodes und 120k edges
% museum ganz, 20cm grid : ca 75k nodes, 280k edges
Because of both, required memory amounts and inaccuracies of the graph-based
model, 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})$.
The new foundation is provided by well-known navigation meshes \cite{navMesh1}
where the walkable area is spanned by convex polygons, sharing
their outline edges. Each polygon knows its adjacent
neighbors, creating a walkable mesh.
Using variable shaped/sized elements instead of rigid grid-cells
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
more accurately.}
%
The new foundation is provided by well-known navigation meshes \cite{navMesh1},
where the walkable area is spanned by convex polygons.
\add{
As the polygons are neither axis-aligned nor fixed in shape and size,
they can accurately represent skewed architectures, where
the grid-based approach suffers from aforementioned flaws.
}
\add{
Another main idea behind navigation meshes
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
denote some sort of walkable surface.
Just as before, the navigation mesh can be \emph{automatically}
generated from the building's floorplan, based on
various algorithms \cite{navMeshAlg1}.
}
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
common operations used within the transition step, like checking whether
a point is contained within some region. This is much more costly for polygons
compared to grid-cells, which are axis-aligned rectangles.
\add{ compared to axis-aligned, rectangular grid-cells. }
% museum aus figure: 305 3-ecke
% museum ganz : 789 fuer alles
%

16
tex_review/egbib.bib
View File

@@ -2974,3 +2974,19 @@ address = {{Rothenburg, Germany}},
publisher={IEEE}
}
@INPROCEEDINGS{navMeshAlg1,
author={W. van Toll and A. F. Cook and R. Geraerts},
booktitle={2011 IEEE/RSJ International Conference on Intelligent Robots and Systems},
title={Navigation meshes for realistic multi-layered environments},
year={2011},
REM_volume={},
REM_number={},
pages={3526-3532},
REM_keywords={mesh generation;navigation;virtual reality;navigation meshes;realistic multilayered environments;virtual characters;path planning;airport;multistorey building;two-dimensional polygons;Navigation;Data structures;Complexity theory;Buildings;Airports;Path planning;Graphics},
REM_doi={10.1109/IROS.2011.6094790},
REM_ISSN={2153-0866},
REM_month={Sept},
}