toni/IPIN2016
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

fixed some missing macros

Browse Source 
removed path from intro/related/filtering
This commit is contained in:
kazu
2016-05-09 10:22:48 +02:00
parent 769d78d7f6
commit 2655ae73ac
3 changed files with 43 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
tex/chapters/filtering.tex
View File

@@ -89,19 +89,26 @@
%\commentByFrank{ist das verstaendlich oder schon zu kurz?}
%\subsubsection{Pedestrian's Destination}
We assume the pedestrian's desired destination to be known beforehand. This prior knowledge is incorporated
during the random walk using $p(\mEdgeAB)_\text{path}$, which is a simple heuristic, favouring movements (edges)
approaching his chosen destination with a ratio of $0.9:0.1$ over those, departing from the destination
\cite{Ebner-16}. The underlying shortest-path uses Dijkstra's algorithm with special weight (distance) metric,
considering special architectural facts:
% We assume the pedestrian's desired destination to be known beforehand. This prior knowledge is incorporated
% during the random walk using $p(\mEdgeAB)_\text{path}$, which is a simple heuristic, favouring movements (edges)
% approaching his chosen destination with a ratio of $0.9:0.1$ over those, departing from the destination
% \cite{Ebner-16}. The underlying shortest-path uses Dijkstra's algorithm with special weight (distance) metric,
% considering special architectural facts:
%\subsubsection{Architectural Facts}
Normally, the shortest-path calculated for a narrow grid would stick unnaturally close to obstacles like walls.
To ensure realistic (human like) path estimations, we include architectural knowledge within Dijkstra's edge-weight function \cite{Ebner-16}:
Each vertex's distance from the nearest wall is used to artificially increase the edge-weight and thus prevent the shortest-path
from clinging to walls. Obviously this has a negative effect on doors which are surrounded by walls. Therefore, doors are detected
and favoured by decreasing their edge-weight.
% Normally, the shortest-path calculated for a narrow grid would stick unnaturally close to obstacles like walls.
% To ensure realistic (human like) path estimations, we include architectural knowledge within Dijkstra's edge-weight function \cite{Ebner-16}:
% Each vertex's distance from the nearest wall is used to artificially increase the edge-weight and thus prevent the shortest-path
% from clinging to walls. Obviously this has a negative effect on doors which are surrounded by walls. Therefore, doors are detected
% and favoured by decreasing their edge-weight.
\commentByFrank{Architectural hab ich mal gelassen, aber so umgeschrieben, dass es keinen bezug mehr zum pfad hat}
Walking a grid of vertices without architectural knowledge, would evenly include vertices, a pedestrian
is unlikely to encounter: e.g. vertices that are (very) close to walls.
To ensure realistic (human like) movements, we include architectural knowledge to prioritise some of the grid's vertices \cite{Ebner-16}:
Each vertex's distance from the nearest wall is used to determine its likelihood and thus downvote nodes close to walls and
other obstacles. Obviously this has a negative effect on doors, which are surrounded by walls. Therefore, doors are detected
as well and favoured by increasing their likelihood.
%\subsubsection{Step- \& Turn-Detection}
Steps and turns are detected using the smartphone's IMU, implemented as described in \cite{Ebner-15}.
@@ -135,17 +142,17 @@
%\subsubsection{Activity-Detection}
Additionally we perform a simple activity detection for the pedestrian, able to distinguish between several actions
$\mObsActivity \in \{ \text{unknown}, \text{standing}, \text{walking}, \text{stairs\_up}, \text{stairs\_down} \}$.
%
%\commentByFrank{bei mir ueberlappt aktuell nix, muessten mal testen was besser ist. beim ueberlappen ist das delay halt kuerzer. denke das schon ok.}
%
For this, the sensor signals are split in sliding windows. Each window has a length of one second and overlaps 500 ms with its prior window.
We use a naive Bayes classifier with two features. The first one is the variance of the accelerometer's magnitude within a window.
The second feature is the difference between the last and first barometer measurement of the particular window.
Based on these features the classifier assigns an activity to each of the sliding windows.
%
Similarly to the above, this knowledge is then evaluated when walking the grid: Edges $\mEdgeAB$ matching the currently detected
%
%\commentByFrank{bei mir ueberlappt aktuell nix, muessten mal testen was besser ist. beim ueberlappen ist das delay halt kuerzer. denke das schon ok.}
%
For this, the sensor signals are split in sliding windows. Each window has a length of one second and overlaps 500 ms with its prior window.
We use a naive Bayes classifier with two features. The first one is the variance of the accelerometer's magnitude within a window.
The second feature is the difference between the last and first barometer measurement of the particular window.
Based on these features the classifier assigns an activity to each of the sliding windows.
%
Similarly to the above, this knowledge is then evaluated when walking the grid: Edges $\mEdgeAB$ matching the currently detected
activity are favoured using $p(\mEdgeAB)_\text{act} = 0.8$ and $0.2$ otherwise.
If no information of the current activitiy could be obtained, no influence is exerted on the edges.
If no information of the current activitiy could be obtained, no influence is exerted on the edges.
% \begin{equation}
% p(\mEdgeAB)_\text{act} =