This repository has been archived on 2020-04-08. You can view files and clone it, but cannot push or open issues or pull requests.
Files
FtmPrologic/tex/chapters/8_experiments.tex
2020-03-04 09:15:15 +01:00

362 lines
22 KiB
TeX

\section{Experiments}
\subsection{Hardware Setup}
%\begin{itemize}
% \item Pixel 2XL Android P liefert RSSI und FTM
% \item 4 Intel NUCS mit selbstgebauten Antennen (Auf Ibrahim verweisen aber auch genau erläutern, eventl mit Bild)
% \item Gebäude erläutern. Bürogebäude in Industriegebiet. Holzhaus. Gebäude war Leer um eine optimale menschenleere Umgebung zu schaffen. Größe XxX. -> Bild mit AP Positionen (gerne von unten linken wo ergebnisse drauf sind, spart platz)
% \item FH Gebäude erläutern. -> Bild mit AP Positionen (gerne von unten linken wo ergebnisse drauf sind, spart platz)
% \item Zweites Gebäude weil: Verhält es sich in einem anderen Gebäude genauso? Also AP's ähnlich positionieren, aber andere umgebung (wände, räume usw.).
% \item Position wurde auf einem Stockwerk geschätzt, also nur 2D.
% \item Nuc steht auf einem Tisch
% \item die messungen kommen immer gleichzeitig von ftm und rssi. dadurch ist die sampelrate die gleiche und wir können besser vergleichen
%\end{itemize}
%
%
%Mapping zwischen AP-MAC und Position ist gegeben.
%In Android Q könnte man LCI am Ap hinterlegen um die AP-Pos dynamisch zu erfragen.
%Praktische Einschräkungen: Da Wifi Scans nur selten möglich sind, können neue FTM APs nicht leicht erkannt werden.
%AUßerdem muss per Reflection ScanResults für bereits bekannte APs MAC erzeugt werden.
%Für eine parktische Anwendung wäre es nochtwenig, dass neue APs automatisch on the fly erkannt werden können.
In all our experiments we used a Google Pixel 2 XL and Google Pixel 3a smartphone, both running Android~9.
Google introduced official ranging APIs based on FTM for supported devices with Android~9.
Also starting with Android~9, Google limited the number of network scans to four every two minutes.
This limitation renders the commonly used network scanning API virtually unusable for measuring RSSI values for localization purposes.
However, the new FTM ranging API has no rate limit.
Additionally, the new FTM API also provides RSSI values, thus with each measurement the signal strength and distance to one AP can be simultaneously obtained.
In our experiments every \SI{200}{ms} a FTM measurement to every known access point is queried.
This does not guarantee that distance measurements for every access point are available at that frequency.
Due to blocked sight or harsh environmental conditions the measurements can fail.
According to our observations Android issues eight FTM measurements for a single ranging request.
The API returns various values, \eg mean distance, standard deviation, RSSI, number of attempted measurements, and the number of successful measurements.
It is not documented how Android aggregates the eight measurements, but it is assumed that the arithmetic mean is calculated on the distance.
The list of access points is statically stored in the application and known beforehand.
With Android~10 it is possible to transfer the AP position dynamically using the location configuration information protocol.
This allows a more flexible applications as access point can be added or modified dynamically without updating the client application.
In some cases we noticed that Android did not provide FTM measurements for intervals about three up to five seconds for unknown reasons, although multiple APs were clearly in reach.
Due to the rarity of this problem we decided to repeat these faulty experiment runs.
% TODO welche Daten liefert Android. Wie die konkret gemessene Distanz entshtet ist nicht bekannt. Android teilt mit wieviele FTM Messungen erfolgreich waren z.b. 7/8. etc.
% TODO Linux kernel version; intel firmware version
The access points are Intel NUCs running a patched Linux to enable FTM support.
In total we're using eight APs based on Intel WiFi cards.
Four of them are based on Intel Dualband-Wireless-AC~8260 cards configured as described by \etal{Ibrahim} \cite{ibrahim2018verification}.
The remaining four are based on Intel Wireless-AC~9462 modules and run a recent Linux kernel where the iwlwifi driver and hostapd are already prepared to support FTM.
However, the driver still requires small manual changes, as a global boolean flag needs to be set to activate the FTM related code.
In addition, the firmware of the card returns that the chip is not calibrated for FTM.
As a consequence the driver disables FTM responder functionality.
Overriding this check, however, allows to use the chip as responder and FTM measurements can be performed reliable.
At this point it is not clear to us what the exact purpose of the flag is.
While it indicates that the card is not calibrated accuracy of the measurements are sufficient as shown in our experiments.
Due to regulatory limitations both wireless cards can only be configured as access points in the \SI{2.4}{GHz} frequency band.
To improve the signal quality and strength we connected two external consumer grade omni directional antennas to the wireless cards and attached them to the case of the Intel NUC.
The antennas have an antenna gain of \SI{2}{dBi} as specified by the manufacturer.
We used a \SI{10}{cm} coaxial cable to connect the antennas to the cards, which is practically the shortest cable possible to limit the additional signal propagation delay.
\subsection{Verification FTM Performance in LOS Scenario}
%\begin{itemize}
% \item AP position strategy
% \item DoP plot
% \item wieviel APs sichtbar sind, wie kommen die Ranges, welche Parameter machen was und bedeuten was
% \item Einfluss der Wände; warum starke Abschwächungen
% \item Welche Platzierung wäre besser; Warum nicht möglich?
% \item Daher Proabilistic Ansatz weil viele Messungen fehlen oder stark schwanken
% \item Mehr APs bringen was?
% \item Bildergrid und Video
%\end{itemize}
The first experiment evaluates the indoor precision of FTM distance measurements given different hardware configurations.
While \etal{Ibrahim} \cite{ibrahim2018verification} already verified the precision of the Intel~AC~8260 card in great detail, our setup differs from theirs and requires anew evaluation.
In contrast to \etal{Ibrahim} we use smartphones as receivers and two different cards with different firmware versions as senders.
Additionally, it is unclear how the external antennas affect the measurements.
For these reasons we did a static distance measurement experimental setup to confirm that the combination of Pixel devices and Intel cards provide reliable values.
Our test setup consist of 10 measurement points evenly spaced on a straight line with a distance of \SI{2}{m}.
The closest point to the AP is \SI{2}{m} away and the furthest \SI{20}{m}.
At every point each phone is placed on a stand.
Around 140 FTM measurements are recorded, which corresponds to a measure period of \SI{30}{s} per point.
The APs and the phones are placed on an empty cardboard box on a metal stand to allow some distance between the metal and the phone.
The phones laid flat on the box.
Both the APs and the phones are located at \SI{1.05}{m} above the floor.
While recording measurements for \SI{30}{s} at a single point is not realistic in a dynamic positioning system, it allows us to evaluate the statistical properties of the method.
The whole experiment was deployed in the hallway of our university.
Each distance measurement is performed with every hardware combination.
On the receiving side we used the Google Pixel 2 XL and Pixel 3a.
On the sending side we used the Intel AC 8260 and 9462 with internal and external \SI{2}{dBi} antennas.
The antenna geometry and properties of the internal antenna are unknown.
In total there are eight phone AP combinations.
% TODO Table mit mean dist err, median dist err und mean RSSI
% Erkenntnis 1: 9462 bessere schätzung, weniger Messungen die zu kurz sind; 8260 viele Messungen bei <16m sind zu kurz; Zusammenhang mit 15m wegen Sampling Rate?
% Erkenntnis 2: Unterschied der Antennen bei RSSI minimal langweilig;
% Erkenntnis 3: Antenne vs FTM: Keine Aussage möglich
% Erkenntnis 4: Unterschied zwischen Pixel 2 und 3 ist nicht erkennbar
\autoref{fig:DistMeasMeanNucPixel}~\subref{fig:DistMeasMeanNucPixel:a} shows the average measured distance per smartphone in respect to the ground truth distance.
Likewise, \autoref{fig:DistMeasMeanNucPixel}~\subref{fig:DistMeasMeanNucPixel:b} depicts the average measured distance per access point.
The corresponding values of these figures are shown in \autoref{tab:distvaluesPixels} and \autoref{tab:distvaluesNUCs}.
Interestingly, both the wireless cards and the Pixel devices exhibit some similar tendency regarding the measurement error.
As seen in \autoref{fig:DistMeasMeanNucPixel}~\subref{fig:DistMeasMeanNucPixel:a} the Pixel 3a tends to underestimate the distance.
Only at \SI{6}{m} and \SI{10}{m} the estimated distance is slightly larger compared to the true distance.
The overall error is mostly negative and the mean absolute error is $\SI{1}{m}$.
Contrarily, the Pixel 2 XL tends to overestimates the distance compared to the groundtruth distance.
Here the mean absolute error is $\SI{1.4}{m}$.
However, at the \SI{16}{m} mark the measured mean distance of the Pixel 2 XL significantly increases.
Computing the mean absolute error only in the interval of $[\SI{2}{m}, \SI{16}{m}]$ reduces the Pixel 2 XL error to $\SI{0.6986}{m}$, while the Pixel 3a error changes negligible.
At \SI{16}{m} the Pixel 3a stops to underestimate the distance and the measurements at \SI{18}{m} and \SI{20}{m} are quite close to the true distance.
In contrast, the Pixel 2 XL starts to increasingly overestimate the true distance which results in large error values ($\approx \SI{4}{m}$).
The same behavior is observable for the Intel AC 8260 and 9460 cards.
Again at \SI{16}{m} both cards start to overestimate the true distance.
For distances smaller than \SI{16}{m} the \intelOld also underestimates the distance with a mean absolute error of \SI{1.11}{m} in that range.
Like the \pixelOld the error increases for larger distances, however, somewhat smaller with $\approx \SI{2}{m}$.
In total the \intelNew card tends to provide an accurate distance estimate but has some outliers at \SI{6}{m} and \SI{10}{m} but never underestimates the true distance.
While the mean distance over many measurements is relevant for stationary measure points, in our scenario a pedestrian is moving with the smartphone.
Therefore, only one or a few measurements can be observed at a given position.
A more expressive visualization for this scenario is given with the CDF graph in \autoref{fig:DistMeasMeanNucPixel}~\subref{fig:DistMeasMeanNucPixel:c}.
\begin{figure}[ht]
\begin{minipage}{.5\textwidth}
\centering
\subfloat[]{\label{fig:DistMeasMeanNucPixel:a}\includegraphics[width=0.8\textwidth]{DistMeasMeanPerPixel.png}}
\end{minipage}%
\begin{minipage}{.5\textwidth}
\centering
\subfloat[]{\label{fig:DistMeasMeanNucPixel:b}\includegraphics[width=0.8\textwidth]{DistMeasMeanPerNuc.png}}
\end{minipage}\par\medskip
\centering
\subfloat[CDF of error]{\label{fig:DistMeasMeanNucPixel:c}\includegraphics[width=\textwidth]{DistMeasCDF.png}}
\caption{my fig}
\label{fig:DistMeasMeanNucPixel}
\end{figure}
% Pixel values
\begin{table}[ht]
\centering
\renewcommand{\arraystretch}{1.2}
\begin{tabular}{@{}RRRRcRRR@{}}
\toprule
\theadbf{GT dist in m} & \multicolumn{3}{c}{\bfseries Pixel 2 XL} & \phantom{a} & \multicolumn{3}{c}{\bfseries Pixel 3a} \\ \cmidrule{2-4} \cmidrule{6-8}
~ & \thead{$\bar{d}$} & \thead{$\sigma$} & \thead{error} && \thead{$\bar{d}$} & \thead{$\sigma$} & \thead{error} \\ \midrule
2 & 2.472 & 1.165 & 0.472 && 0.032 & 1.615 & -1.968 \\
4 & 3.976 & 1.755 & -0.024 && 2.645 & 1.834 & -1.355 \\
6 & 6.605 & 1.978 & 0.605 && 6.577 & 1.780 & 0.577 \\
8 & 8.780 & 1.510 & 0.780 && 6.861 & 1.506 & -1.139 \\
10 & 11.520 & 1.522 & 1.520 && 10.454 & 2.176 & 0.454 \\
12 & 12.096 & 1.582 & 0.096 && 10.342 & 1.875 & -1.658 \\
14 & 14.327 & 1.870 & 0.327 && 12.866 & 2.309 & -1.134 \\
16 & 17.765 & 1.488 & 1.765 && 15.992 & 0.879 & -0.008 \\
18 & 22.569 & 1.458 & 4.569 && 18.962 & 1.491 & 0.962 \\
20 & 24.058 & 1.820 & 4.058 && 20.742 & 1.318 & 0.742 \\
\bottomrule
\end{tabular}
\caption{TODO}
\label{tab:distvaluesPixels}
\end{table}
% NUC values
\begin{table}[ht]
\centering
\renewcommand{\arraystretch}{1.2}
\begin{tabular}{@{}RRRRcRRR@{}}
\toprule
\theadbf{GT dist in m} & \multicolumn{3}{c}{\bfseries Intel AC 8260} & \phantom{a} & \multicolumn{3}{c}{\bfseries Intel AC 9460} \\ \cmidrule{2-4} \cmidrule{6-8}
~ & \thead{$\bar{d}$} & \thead{$\sigma$} & \thead{error} && \thead{$\bar{d}$} & \thead{$\sigma$} & \thead{error} \\ \midrule
2 & 0.221 & 1.460 & -1.779 && 2.282 & 1.724 & 0.282 \\
4 & 2.175 & 0.541 & -1.825 && 4.446 & 1.973 & 0.446 \\
6 & 5.599 & 0.876 & -0.401 && 7.583 & 1.922 & 1.583 \\
8 & 7.041 & 1.562 & -0.959 && 8.601 & 1.715 & 0.601 \\
10 & 9.916 & 1.787 & -0.084 && 12.058 & 1.247 & 2.058 \\
12 & 10.055 & 1.478 & -1.945 && 12.384 & 1.506 & 0.384 \\
14 & 12.312 & 2.110 & -1.688 && 14.882 & 1.182 & 0.882 \\
16 & 16.223 & 1.005 & 0.223 && 17.534 & 1.710 & 1.534 \\
18 & 20.341 & 2.417 & 2.341 && 21.190 & 2.589 & 3.190 \\
20 & 22.001 & 2.920 & 2.001 && 22.799 & 1.853 & 2.799 \\
\bottomrule
\end{tabular}
\caption{TODO}
\label{tab:distvaluesNUCs}
\end{table}
% Smartphones und Intel cards in einer table
%\begin{table}[ht]
%\renewcommand{\arraystretch}{1.2}
%\begin{tabular}{@{}RRRRcRRRcRRRRcRRR@{}}
%\toprule
%\theadbf{GT} & \multicolumn{3}{c}{\bfseries Pixel 2 XL} & \phantom{a} & \multicolumn{3}{c}{\bfseries Pixel 3a} & \phantom{a} & \multicolumn{3}{c}{\bfseries AC 8260} & \phantom{a} & \multicolumn{3}{c}{\bfseries AC 9462} \\ \cmidrule{2-4} \cmidrule{6-8} \cmidrule{10-12} \cmidrule{14-16}
%~ & \thead{$\bar{d}$} & \thead{$\sigma$} & \thead{error} && \thead{$\bar{d}$} & \thead{$\sigma$} & \thead{error} && \thead{$\bar{d}$} & \thead{$\sigma$} & \thead{error} && \thead{$\bar{d}$} & \thead{$\sigma$} & \thead{error} \\ \midrule
%2 & 2.472 & 1.165 & 0.472 && 0.032 & 1.615 & -1.968 && 0.221 & 1.460 & -1.779 && 2.282 & 1.724 & 0.282 \\
%4 & 3.976 & 1.755 & -0.024 && 2.645 & 1.834 & -1.355 && 2.175 & 0.541 & -1.825 && 4.446 & 1.973 & 0.446 \\
%6 & 6.605 & 1.978 & 0.605 && 6.577 & 1.780 & 0.577 && 5.599 & 0.876 & -0.401 && 7.583 & 1.922 & 1.583 \\
%8 & 8.780 & 1.510 & 0.780 && 6.861 & 1.506 & -1.139 && 7.041 & 1.562 & -0.959 && 8.601 & 1.715 & 0.601 \\
%10 & 11.520 & 1.522 & 1.520 && 10.454 & 2.176 & 0.454 && 9.916 & 1.787 & -0.084 && 12.058 & 1.247 & 2.058 \\
%12 & 12.096 & 1.582 & 0.096 && 10.342 & 1.875 & -1.658 && 10.055 & 1.478 & -1.945 && 12.384 & 1.506 & 0.384 \\
%14 & 14.327 & 1.870 & 0.327 && 12.866 & 2.309 & -1.134 && 12.312 & 2.110 & -1.688 && 14.882 & 1.182 & 0.882 \\
%16 & 17.765 & 1.488 & 1.765 && 15.992 & 0.879 & -0.008 && 16.223 & 1.005 & 0.223 && 17.534 & 1.710 & 1.534 \\
%18 & 22.569 & 1.458 & 4.569 && 18.962 & 1.491 & 0.962 && 20.341 & 2.417 & 2.341 && 21.190 & 2.589 & 3.190 \\
%20 & 24.058 & 1.820 & 4.058 && 20.742 & 1.318 & 0.742 && 22.001 & 2.920 & 2.001 && 22.799 & 1.853 & 2.799 \\
%\bottomrule
%\end{tabular}
%\caption{TODO}
%\label{tab:distvalues}
%\end{table}
\subsection{Range Measurements in NLOS Scenario}
Während der posionierung ist an gewissen stellen eine systematische abweichung zum gt aufgefallen dies trat immer an zwei stellen auf, daraus folgender die hypthese das es irgendwie an dieser gegebenheit liegen muss. als folge daraus ist dann eben entstanden das wir die brandschutztüren gesehen haben und dann eine experiment aufgebaut haben um die hypthese zu messen, inwiefern sich die türen oder besser gesagt wie sich unterschiedliche wandmateriellien, insbesondere wenn diese so extrem wie hier sind, auf die FTM Messungen auswirken.
rssi grafik lassen wir weg (bst2rssi.png) und schreiben das nur im text. müssen ja nur den sprung von 7 auf 8 beschreiben. interessanter sind die FTM Plots mit der Streuung (bst2ftm.png)
\begin{figure}[ht]
\begin{minipage}{.5\textwidth}
\centering
\subfloat[]{\label{main:a}\includegraphics[width=\textwidth]{VersuchsaufbauBST1.png}}
\end{minipage}%
\begin{minipage}{.5\textwidth}
\centering
\subfloat[]{\label{main:b}\includegraphics[width=0.8\textwidth]{VersuchsaufbauBST2.png}}
\end{minipage}\par\medskip
\centering
\subfloat[CDF of error]{\label{main:c}\includegraphics[width=\textwidth]{bst1ftm.png}}
\par\medskip
\centering
\subfloat[CDF of error]{\label{main:c}\includegraphics[width=\textwidth]{bst2ftm.png}}
\caption{die einzelnen aufbauten können wir in die grafiken der ergebnisse embedden rechts oben ins eck}
\label{fig:main}
\end{figure}
\subsection{Positioning Environment}
\begin{itemize}
\item Beschreibe Gebäude - inkl HLS Räume!
\item beschreibe ground truth pfade
\item access point positionen mit DOP analyse
\item wie sind wir gelaufen / testbedingungen... wie wurde GT gemessen usw. app etc pp.
\end{itemize}
All experiments were done in our university building.
The before mentioned Intel NUCs were deployed, because the existing WiFi infrastructure does not support the FTM protocol.
While the positions of the access points where chosen with localization in mind, the actual positions mimic the placement of access points for network infrastructure.
In contrast to regular stationary access points which are usually mounted on walls or ceilings, our Intel NUCs were placed on tables for practical reasons.
\subsection{Results for Multilateration}
zunächst wird das einfachste und nahliegendste verfahren untersucht um die performance von ftm und rssi gegenüberzustellen.
Figure 3 rote Bereiche - Heizung Lüftung Sanitär (HLS) Räume schirmen Radio Signale komplett ab! Wenn man dahinter steht, bekommt man gar nichts mehr vom AP mit. Wenn man sich nun die AP positionen ansieht, welche wir gewählt haben, fällt auf das wir Idioten sind. Anhand eine Triangulation Loc + Fehler Plots erklären.
\begin{itemize}
\item Parameter einführen und erklären
\item Unterschied FTM und RSSI bei diesem Verfahren
\item Positioning Error
\item Wie sieht der geschätzte Pfad aus
\item FTM ist nicht wie erwartet mega viel besser als RSSI. die simple literation glättet einfach gar nichts, weswegen... (hier begründung einfügen)
\item DOP Grafik -> später vom particel filter referenzieren.
\end{itemize}
wir bekommen hier also das gefühl, das ftm irgendwie besser sein muss, aber können es noch nicht wirklich nutzen. weshalb nun der probabilistische approach angesehen wird.
\subsection{Results for Probabilistic Approach}
multilateration verfügt über keinerlei glättung, das einfach probablistische verfahren bietet das. verlgeicht man fig. x und fig. y kann man das schön sehen.
\begin{itemize}
\item Parameter einführen und erklären
\item Unterschied FTM und RSSI bei diesem Verfahren
\item Positioning Error
\item Wie sieht der geschätzte Pfad aus
\item FTM setzt sich langsam ab und wird ein gutes stück besser als Rssi
\end{itemize}
\subsection{Results for Particle Filtering}
der einsatz der probablistischen methode sieht weitaus besser azs als multilateration weil wir eine glättung der daten ermöglichen. es fehlt aber informationen über die vergangenheit. der particle filter bietet das.
\begin{itemize}
\item Parameter einführen und erklären
\subitem filter updated pro neuer messung. kann man natürlich auch anders machen. nachdem wir aber eine so simple transition haben, ist es egal.
\item Unterschied FTM und RSSI bei diesem Verfahren
\item Positioning Error
\item Wie sieht der geschätzte Pfad aus
\item Hier werden die Ergebnisse langsam richtig gut. Also FTM ist weitaus besser als RSSI. Warum ist das so? (Filter hat die Vergangenheit mit drin, FTM ist somit auf Dauer stabiler und streut deswegen nicht so stark wie RSSI).
\end{itemize}
\begin{figure}[ht]
\centering
\includegraphics[width=1\textwidth]{Path2_Walk0_FTM.png}
\caption{Path 2 FTM, Pixel 2 mean 4.94778 stdDev 2.49081 median 4.88544 count 249 }
\end{figure}
\begin{figure}[ht]
\centering
\includegraphics[width=1\textwidth]{Path2_Walk0_FTM_Error.png}
\caption{Path 2 Error FTM, Pixel 2 }
\end{figure}
\begin{figure}[ht]
\centering
\includegraphics[width=1\textwidth]{Path2_Walk0_RSSI.png}
\caption{Path 2 RSSI, Pixel 2 mean 5.33965 stdDev 2.68662 median 5.22802 count 249}
\end{figure}
\begin{figure}[ht]
\centering
\includegraphics[width=1\textwidth]{Path2_Walk0_RSSI_Error.png}
\caption{Path 2 Error RSSI, Pixel 2}
\end{figure}
\begin{figure}[ht]
\centering
\includegraphics[width=1\textwidth]{Path2_Walk0_FTM_RSSI_Error.png}
\caption{Path 2 Error FTM / RSSI, Pixel 2}
\end{figure}
Unterscuhen ob die Abweichung nach untne daher kommt weil die Brandschutztür stört
\begin{figure}[ht]
\centering
\includegraphics[width=1\textwidth]{VersuchsaufbauBST1.png}
\caption{}
\end{figure}
\begin{figure}[ht]
\centering
\includegraphics[width=1\textwidth]{VersuchsaufbauBST2.png}
\caption{}
\end{figure}
\subsection{Comparison and Discussion}
Hier vergleichen wie sich die einzelen Verfahren untereinander unterscheiden und welche Vor / Nachteile sie haben. Jeweils für RSSI und FTM. (Vorher haben wir RSSI und FTM gegenübergestellt innerhalb der Verfahren und jetzt stellen wir die einzelnen Verfahren gegenüber und diskutieren deren Unterschied in Bezug auf die WI-Fi methoden)
\begin{itemize}
\item multilateration ist an sich schon ein schlechtes verfahren, man kann aber sehen das ftm schon etwas besser wird. verfolgt man den gedanken über die weiteren verfahren, sieht man schnell wie sich FTM von der Leistung her absetzt und durch die besseren verfahren auch eine besser lokalisiierungsleistung bringt.
\item Tabelle, wo alle Ergebnisse nochmal zusammen sind.
\item Wichtige Erkenntnisse:
\subitem wenn man sehr nah dran ist, ist die messung nicht wirklich gut bei FTM.
\subitem FTM ist vom setup weitaus einfacher als rssi, weil es die dämpfung etc. pp nicht so wichtig nimmt.
\end{itemize}