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

TeX and helper code

Browse Source
This commit is contained in:
FrankE
2017-04-25 14:48:04 +02:00
parent 8a3de63075
commit fe9c25cde5
3 changed files with 136 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
tex/chapters/work.tex
View File

@@ -62,7 +62,7 @@
Depending on the use case, this value describes the number and type of walls, ceilings, floors etc. between both positions.
For obstacles, this requires an intersection-test of each obstacle with the line-of-sight, which is costly
for larger buildings. For real-time use on a smartphone, a (discretized) model pre-computation might thus be necessary
\todo{cite competition}. Furthermore this requires a detailed floorplan, that includes material information
\cite{competition}. Furthermore this requires a detailed floorplan, that includes material information
for walls, doors, floors and ceilings.
Throughout this work, we thus use a tradeoff between both models, where walls are ignored and only floors/ceilings are considered.
@@ -171,23 +171,33 @@
As the used model tradeoff does not consider walls, it is expected to provide erroneous values
for regions that are heavily shrouded by e.g. steel-enforced concrete or metallised glass.
Instead of using only one optimized model per \docAP{}, we use several instances with different
parameters that are limited to some region within the building:
{\bf \optPerFloor{}} will use one model for each story, that is optimized using
only the fingerprints that belong to the corresponding floor. During evaluation,
the $z$-value from $\mPosVec{}$ in \refeq{eq:wifiProb} is used to select the model
for this location's signal strength estimation.
{\bf \optPerRegion{}} works similar, except that the model is limited to a predefined,
axis-aligned bounding box. This approach allows a distinction between in- and outdoor-regions
or locations that are expected to highly differ from their surroundings.
\subsection{\docWIFI{} quality factor}
Past evaluations showed, that there are many situations where the \docWIFI{} location estimation
Evaluations within previous works showed, that there are many situations where the \docWIFI{} location estimation
is highly erroneous. Either when the signal strength prediction model does not match real world
conditions or the received measurements are ambiguous and there is more than one location
within the building that matches those readings. Both cases can occur e.g. in areas surrounded by
concrete walls where the model does not match the real world conditions as those walls are not considered,
and the smartphone barely receives some \docAPshort{}s due to the high attenuation.
and the smartphone barely receives \docAPshort{}s due to the high attenuation.
If such a sensor error occurs only for a short time period, the recursive density estimation
\refeq{eq:recursiveDensity} is able to compensate those errors using other sensors and the movement
model. However, if the error persists for a longer time period, the error will slowly distort
\refeq{eq:recursiveDensity} is able to compensate those errors using other observations and the transition
model. However, if the sensor-fault persists for a longer time period, such an error will slowly distort
the posterior distribution. As our movement model depends on the actual floorplan, the density
might get trapped e.g. within a room if the other sensors are not able to compensate for
might get trapped e.g. within a room if the other sensors are unable to compensate for
the \docWIFI{} error.
Thus, we try to determine the quality of received \docWIFI{} measurements, which allows for
@@ -196,8 +206,7 @@
In \refeq{eq:wifiQuality} we use the average signal strength of all \docAP{}s seen within one measurement
and scale this value to match a region of $[0, 1]$ depending on an upper- and lower bound.
If the returned quality falls below a certain threshold, \docWIFI{} is ignored within
the evaluation.
If the returned quality is below a certain threshold, \docWIFI{} is ignored within the evaluation.
\begin{equation}
\newcommand{\leMin}{l_\text{min}}
@@ -219,7 +228,7 @@
\subsection {VAP grouping}
\label{sec:vap}
Assuming normal conditions, the received signal strength at one location will also (strongly) vary
Assuming normal conditions, the received signal strength at one location will also (strongly) vary over time
due to environmental conditions like temperature, humidity, open/closed doors and RF interference.
Fast variations can be addressed by averaging several consecutive measurements at the expense
of a delay in time.
@@ -227,24 +236,17 @@
where one physical hardware \docAP{} provides more than one virtual network to connect to.
They can usually be identified, as only the last digit of the MAC-address is altered among the virtual networks.
%
As those virtual networks normally share the same frequency, they are unable to transmit at the same time.
As those virtual networks normally share the same frequency, they are unable to transmit at the same instant in time.
When scanning for \docAPshort{}s one will thus receive several responses from the same hardware, all with
a very small delay in time (micro- to milliseconds). Such measurements may be grouped using some aggregate
a very small delay (micro- to milliseconds). Such measurements may be grouped using some aggregate
function like average, median or maximum.
wie wird optimiert
a) bekannte pos + empirische params
b) bekannte pos + opt params (fur alle APs gleich) [simplex]
c) bekannte pos + opt params (eigene je AP) [simplex]
d) alles opt: pos und params (je ap) [range-random]
optimierung ist tricky. auch wegen dem WAF der ja sprunghaft dazu kommt, sobald messung und AP in zwei unterschiedlichen
stockwerken liegen.. und das selbst wenn hier vlt sichtkontakt möglich wäre, da der test 2D ist und nicht 3D
\todo{???
aps sind (statistisch) unaebhaengig. d.h., jeder AP kann fuer sich optimiert werden.
optimierung des gesamtsystems ist nicht notwendig.
pro AP also 6 params. pos x/y/z, txp, exp, waf
}