fixed some missing macros
removed path from intro/related/filtering
This commit is contained in:
@@ -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} =
|
||||
|
||||
@@ -6,10 +6,10 @@
|
||||
Determining a position indoors is a challenging task.
|
||||
Besides the complex architecture of many buildings, high accuracy needs to be achieved, especially for buildings with many small separated areas like shopping malls or office blocks.
|
||||
In recent years, many different systems were presented to meet those requirements.
|
||||
Especially Wi-Fi positioning and pedestrian dead reckoning (PDR) are very popular solutions.
|
||||
Especially \docWIFI{} positioning and pedestrian dead reckoning (PDR) are very popular solutions.
|
||||
Approaches based on PDR try to estimate the current position given the previous position and thus require an initial state.
|
||||
However, this allows for cumulative errors and leads to an erroneous position estimation within a very short period.
|
||||
By incorporating the absolute position information of Wi-Fi this drift can be corrected.
|
||||
By incorporating the absolute position information of \docWIFI{} this drift can be corrected.
|
||||
Additional improvements can be achieved by using environmental information about walls and obstacles provided by a floor map.
|
||||
|
||||
In most cases, probabilistic methods are used to incorporate those highly different sensor types.
|
||||
@@ -37,7 +37,7 @@ For example, a barometer can be used to determine the probability of being on a
|
||||
|
||||
Despite the many advances made in the last years, nearly all systems suffer from more or less the same problems.
|
||||
Like mentioned before, PDR suffers from an accumulating bias,
|
||||
the signal of Wi-Fi gets attenuated by walls
|
||||
the signal of \docWIFI{} gets attenuated by walls
|
||||
%\commentByFrank{falls noch platz ist: noch mehr nachteile :P \docWIFI{} location estimation strongly depends on the quality of the signal-strength estimation model (oder fingerprinting) and the way the smartphone is held}
|
||||
and the barometric pressure is highly affected by weather patterns and humidity
|
||||
%\commentByFrank{spontane fenster/tuer oeffnung}
|
||||
@@ -52,7 +52,7 @@ This temporal delay worsens the estimate immensely.
|
||||
A solution to recover from such filter divergences faster, involves methods to re-initialize the filtering procedure \cite{Nurminen2014}.
|
||||
However, even this can not completely prevent delays.
|
||||
Another reason for possible time delays are slow sensor updates.
|
||||
For example, most mobile devices restrict the Wi-Fi module to update only every few seconds, to save on battery.
|
||||
For example, most mobile devices restrict the \docWIFI{} module to update only every few seconds, to save on battery.
|
||||
%
|
||||
\begin{figure}[t]
|
||||
\centering
|
||||
@@ -72,12 +72,14 @@ Due to inaccurate measurements and a PDR approach for evaluating the movement, t
|
||||
Therefore, the weighted average position is somewhere in-between.
|
||||
Only after the pedestrian turns right, the distribution is again unimodal, since moving through walls is impossible.
|
||||
As one can imagine, this can lead to serious problems in big indoor environments.
|
||||
Such a situation can be improved by incorporating future measurements (e.g. the right turn) or predictive information (e.g. the most likely path) to the filtering procedure \cite{Ebner-16}.
|
||||
Such a situation can be improved by incorporating future measurements (e.g. the right turn)
|
||||
%or predictive information (e.g. the most likely path)
|
||||
to the filtering procedure \cite{Ebner-16}.
|
||||
However, standard filtering methods are not able to use any future information and the possibilities to make a distant forecast are also limited \cite{robotics, Doucet11:ATO, chen2003bayesian}.
|
||||
|
||||
One very promising way to deal with these problems is smoothing.
|
||||
Smoothing methods are able to make use of future measurements for computing their estimation.
|
||||
By running backwards in time, they are also able to remove multimodalities and improve the overall localization result.
|
||||
By running backwards in time, they are also able to remove multimodalities and improve the overall localisation result.
|
||||
Since the problem of navigation, especially the representation of complex movement patterns, results in a non-linear and non-Gaussian state space, this work focuses mainly on smoothing techniques based on the broad class of MC methods.
|
||||
%Of course, this excludes linear procedures like Kalman filtering.
|
||||
Namely, forward-backward smoothing \cite{doucet2000} and backward simulation \cite{Godsill04:MCS}.
|
||||
|
||||
@@ -39,13 +39,13 @@ For example, in \cite{Platzer:2008} a particle smoother is used to reduce multim
|
||||
%smoothing im bezug auf indoor
|
||||
Nevertheless, there are some promising approaches for indoor localisation systems as well.
|
||||
For example \cite{Nurminen2014} deployed a fixed-interval forward-backward smoother to improve the position estimation for non-real-time applications.
|
||||
They combined Wi-Fi, step and turn detection, a simple line-of-sight model for floor plan restrictions and the barometric change within a particle filter.
|
||||
They combined \docWIFI{}, step and turn detection, a simple line-of-sight model for floor plan restrictions and the barometric change within a particle filter.
|
||||
The state transition samples a new state based on the heading change, altitude change and a fixed step length.
|
||||
The experiments of \cite{Nurminen2014} clearly emphasize the benefits of smoothing techniques. The estimation error could be decreased significantly.
|
||||
However, a fixed-lag smoother was discussed only in theory.
|
||||
|
||||
In the work of \cite{Paul2009} both fixed-interval and fixed-lag smoothing were presented.
|
||||
They implemented Wi-Fi, binary infrared motion sensors, binary foot-switches and a potential field for floor plan restrictions.
|
||||
They implemented \docWIFI{}, binary infrared motion sensors, binary foot-switches and a potential field for floor plan restrictions.
|
||||
Those sensors were incorporated using a sigma-point Kalman filter in combination with a forward-backward smoother.
|
||||
It was also proven by \cite{Paul2009}, that the fixed-lag smoother is slightly less accurate than the fixed-interval smoother, as one would expect from the theoretical foundation.
|
||||
Unfortunately, even a sigma-point Kalman filters is after all just a linearisation and therefore not as flexible and suited for the complex problem of indoor localisation as a non-linear estimator like a particle filter.
|
||||
@@ -54,7 +54,7 @@ Unfortunately, even a sigma-point Kalman filters is after all just a linearisati
|
||||
%\commentByToni{Ich bin mir nicht sicher ob das eine Behauptung ohne jeglichen Hintergrund ist. Meiner Meinung nach ist das ziemlich weitreichend bekannt. Finde den Satz persoenlich ganz gut, weil er uns deutlich von dieser Arbeit abgrenzt und das ist wichtig.}
|
||||
%\commentByFrank{hab zwar ka was das ist, aber vermutlich ist es auch normal-dist also unimodal? dann verweisen wir doch einfach auf fig1 mit dem zusatz: 'sowas geht garned erst'}.
|
||||
%\commentByToni{Sigma Point Kalman Filter können mit Multimodalitäten umgehen... auch wenn sie linearisieren. frag nicht wie das gehen soll.}
|
||||
Additionally, the Wi-Fi RSSI model requires known calibration points and is deployed using a remarkable number of access points for very small spaces.
|
||||
Additionally, the \docWIFI{} RSSI model requires known calibration points and is deployed using a remarkable number of access points for very small spaces.
|
||||
In our opinion this is not practical and does not suite real-world conditions.
|
||||
Since humans with a specific destination in mind do not tend to change their directions randomly, we would further recommend adding a PDR-based transition to draw samples in a more directed manner instead of scattering them randomly in every direction.
|
||||
|
||||
@@ -63,10 +63,10 @@ Since humans with a specific destination in mind do not tend to change their dir
|
||||
%\commentByFrank{man koennte die reihenfolge vlt umstellen, erst die ganzen filtering sachen beschreiben, map, activity, ... und on top of that two smoothing algorithms both implemented as fixed-interval and fixed-lag?}
|
||||
The here presented approach will use two different smoothing algorithm, both implemented as fixed-interval and fixed-lag versions.
|
||||
Further, our localisation system presented in \cite{Ebner-16} enables us to walk stairs and thus going into the third dimension.
|
||||
Therefore, a regularly tessellated graph is utilized to avoid walls, detecting doors and recognizing stairs.
|
||||
Within this work, this is additionally supported by a simple classification that detects the activities unknown, standing, walking and walking stairs.
|
||||
Finally, we incorporate prior navigation knowledge by using syntactically calculated realistic human walking paths \cite{Ebner-16}.
|
||||
This method makes use of the given destination and thereby provides a more targeted movement.
|
||||
Therefore, a regularly tessellated graph is utilised to avoid walls, detecting doors and recognizing stairs.
|
||||
Within this work, this is additionally supported by a simple classification that detects the activities unknown, standing, walking and walking stairs.
|
||||
%Finally, we incorporate prior navigation knowledge by using syntactically calculated realistic human walking paths \cite{Ebner-16}.
|
||||
%This method makes use of the given destination and thereby provides a more targeted movement.
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user