219 lines
12 KiB
TeX
219 lines
12 KiB
TeX
\section{Transition}
|
|
\label{sec:transition}
|
|
|
|
\begin{figure}[t]
|
|
\centering
|
|
\begin{subfigure}{0.325\textwidth}
|
|
\centering
|
|
\includegraphics[width=5.1cm]{gfx/transition/museumMap.pdf}
|
|
\caption{3D Floorplan}
|
|
\label{fig:museumMap}
|
|
\end{subfigure}
|
|
\begin{subfigure}{0.325\textwidth}
|
|
\centering
|
|
\includegraphics[width=5.1cm]{gfx/transition/museumMapGrid.pdf}
|
|
\caption{Navigation graph}
|
|
\label{fig:museumMapGrid}
|
|
\end{subfigure}
|
|
\begin{subfigure}{0.325\textwidth}
|
|
\centering
|
|
\includegraphics[width=5.1cm]{gfx/transition/museumMapMesh.pdf}
|
|
\caption{Navigation mesh}
|
|
\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}).
|
|
\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}
|
|
|
|
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}.
|
|
\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 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 \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:
|
|
\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 \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.
|
|
\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.}
|
|
% 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.
|
|
\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}}
|
|
This data structure yields room for various strategies to be applied within the transition step.
|
|
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,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
|
|
$p(\mStateVec_{t} \mid \mStateVec_{t-1}, \mObsVec_{t-1})$:
|
|
|
|
\begin{equation}
|
|
\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}
|
|
\quad
|
|
\text{,}
|
|
\quad
|
|
x_{t-1},y_{t-1},z_{t-1},\mStateHeading_{t-1} \in \mStateVec_{t-1}
|
|
\quad
|
|
\text{and}
|
|
\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 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$ \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'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}.
|
|
Of course, there are much more advanced methods as surveyed in \cite{davidson2017survey}, however this simple method has served us very well in the past.
|
|
|
|
%\commentByFrank{es gaebe noch ganz andere ansaetze etc. aber wir haben wohl nicht mehr genug platz :P}
|
|
%\commentByToni{ich denke aber auch, es langt.}
|
|
|