Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Results updated. Bulk commit

  • Loading branch information...
commit 4c5b1a6be9315789fad3e27ed576368bd71ad4f4 1 parent 18b2371
@divyekapoor authored
View
BIN  results/figures/android_back.jpg
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN  results/figures/android_front.JPG
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN  results/figures/android_front2.jpg
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN  results/figures/android_front3.jpg
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN  results/figures/paths.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN  results/figures/ravindra_map.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
1  results/figures/step_variation.png
View
BIN  results/figures/test_path_1_and_2.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN  results/figures/test_path_4_and_5.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN  results/figures/test_paths.jpg
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
BIN  results/figures/test_paths.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
View
2  results/groundwork.tex
@@ -151,7 +151,7 @@ \subsection{Accuracy}
\end{figure}
-TODO: Insert values for Standard deviation here.
+\todo[inline]{Insert values for Standard deviation here}
These values are required to determine choice of parameters for the particle
filter that will be introduced later.
View
263 results/lyx/#Dynamical Equations.lyx#
@@ -0,0 +1,263 @@
+#LyX 2.0 created this file. For more info see http://www.lyx.org/
+\lyxformat 413
+\begin_document
+\begin_header
+\textclass article
+\use_default_options true
+\maintain_unincluded_children false
+\language english
+\language_package default
+\inputencoding auto
+\fontencoding global
+\font_roman default
+\font_sans default
+\font_typewriter default
+\font_default_family default
+\use_non_tex_fonts false
+\font_sc false
+\font_osf false
+\font_sf_scale 100
+\font_tt_scale 100
+
+\graphics default
+\default_output_format default
+\output_sync 0
+\bibtex_command default
+\index_command default
+\paperfontsize default
+\use_hyperref false
+\papersize default
+\use_geometry false
+\use_amsmath 1
+\use_esint 1
+\use_mhchem 1
+\use_mathdots 1
+\cite_engine basic
+\use_bibtopic false
+\use_indices false
+\paperorientation portrait
+\suppress_date false
+\use_refstyle 1
+\index Index
+\shortcut idx
+\color #008000
+\end_index
+\secnumdepth 3
+\tocdepth 3
+\paragraph_separation indent
+\paragraph_indentation default
+\quotes_language english
+\papercolumns 1
+\papersides 1
+\paperpagestyle default
+\tracking_changes false
+\output_changes false
+\html_math_output 0
+\html_css_as_file 0
+\html_be_strict false
+\end_header
+
+\begin_body
+
+\begin_layout Standard
+\begin_inset Formula $\begin{bmatrix}x_{i+1}\\
+y_{i+1}
+\end{bmatrix}$
+\end_inset
+
+=
+\begin_inset Formula $\begin{bmatrix}x_{i}\\
+y_{i}
+\end{bmatrix}$
+\end_inset
+
+ +
+\begin_inset Formula $d{}_{i}$
+\end_inset
+
+
+\begin_inset Formula $\begin{bmatrix}-cos(\theta_{i})\\
+sin(\theta_{i})
+\end{bmatrix}$
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+For the case where the coordinate system for the map is
+\begin_inset Formula $x$
+\end_inset
+
+ positive towards right and
+\begin_inset Formula $y$
+\end_inset
+
+ positive downwards with
+\begin_inset Formula $TrueNorth$
+\end_inset
+
+ of the map pointing upwards.
+\end_layout
+
+\begin_layout Standard
+This dynamical representation is overtly simplistic because it doesn't take
+ into account real world issues as seen in the groundwork section.
+ The most important issue is the issue of sensor drift.
+ The magnetometer is a rather inaccurate sensor and is rated to an accuracy
+ of 5 degrees in static circumstances.
+ There is also a recommendation to re-calibrate before use.
+ This is required because this sensor suffers from a lot of sensor noise
+ and drift.
+
+\end_layout
+
+\begin_layout Standard
+Recalibration of the magnetometer involves moving it around in a pattern
+ of 8.
+ Effectively, that randomizes internal magnetic elements enough for magnetic
+ saturation effects to be neutralized.
+ Unfortunately, for a continuous use scenario like ours, recalibration of
+ this sensor is not an option.
+ Hence, we modify our dynamical equation to take this error into account.
+\end_layout
+
+\begin_layout Standard
+\begin_inset Formula $\begin{bmatrix}x_{i+1}\\
+y_{i+1}
+\end{bmatrix}$
+\end_inset
+
+=
+\begin_inset Formula $\begin{bmatrix}x_{i}\\
+y_{i}
+\end{bmatrix}$
+\end_inset
+
+ +
+\begin_inset Formula $d{}_{i}$
+\end_inset
+
+
+\begin_inset Formula $\begin{bmatrix}-cos(\theta_{i}+\phi_{mag})\\
+sin(\theta_{i}+\phi_{mag})
+\end{bmatrix}$
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+In this dynamical equation, we have added an additional parameter
+\begin_inset Formula $\phi_{mag}$
+\end_inset
+
+which is a random variable that represents random white noise in the reading
+ from the true value of the magnetometer.
+\end_layout
+
+\begin_layout Standard
+Besides the sensor noise that creeps into the values of the magnetometer,
+ there are 2 other issues that need to be taken care of in our dynamical
+ modelling of the dead reckoning system.
+\end_layout
+
+\begin_layout Standard
+The first issue is an issue of bias in the angle readings from the magnetometer.
+ This bias can creep in due to 2 different reasons - the first being specific,
+ environmental magnetic fields which distort the actual detection of
+\begin_inset Formula $TrueNorth$
+\end_inset
+
+ in the system and the second being a bias that creeps in due to the way
+ the user holds the smartphone in the palm of his hand and the offset thus
+ produced.
+ To take into account such offsets, we modify the dynamical equations as
+ follows:
+\end_layout
+
+\begin_layout Standard
+\begin_inset Formula $\begin{bmatrix}x_{i+1}\\
+y_{i+1}
+\end{bmatrix}$
+\end_inset
+
+=
+\begin_inset Formula $\begin{bmatrix}x_{i}\\
+y_{i}
+\end{bmatrix}$
+\end_inset
+
+ +
+\begin_inset Formula $d{}_{i}$
+\end_inset
+
+
+\begin_inset Formula $\begin{bmatrix}-cos(\theta_{i}+\theta_{b}+\vartheta+\phi_{mag})\\
+sin(\theta_{i}+\theta_{b}+\phi_{mag})
+\end{bmatrix}$
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+In this modified version of the dynamical equations, we have added a slowly
+ varying term
+\begin_inset Formula $\theta_{b}$
+\end_inset
+
+that represents an explicit bias in the readings from the magnetometer.
+\end_layout
+
+\begin_layout Standard
+The second issue at hand is step size variation and the issue of missing
+ or extra step detection.
+ To map accelerometer readings to step sizes, we have used the empirical
+ equation provided by [ref].
+ However, this empirical equation doesn't take into account changes in step
+ sizes due to changes in footwear or floor material.
+ To account for this bias in step size detection, we introduce an additional
+ parameter
+\begin_inset Formula $d_{b}$
+\end_inset
+
+in the dynamical system.
+ The new equations for the dynamical system are:
+\end_layout
+
+\begin_layout Standard
+\begin_inset Formula $\begin{bmatrix}x_{i+1}\\
+y_{i+1}
+\end{bmatrix}$
+\end_inset
+
+=
+\begin_inset Formula $\begin{bmatrix}x_{i}\\
+y_{i}
+\end{bmatrix}$
+\end_inset
+
+ +
+\begin_inset Formula $(d{}_{i}+d_{b})$
+\end_inset
+
+
+\begin_inset Formula $\begin{bmatrix}-cos(\theta_{i}+\theta_{b}+\phi_{mag})\\
+sin(\theta_{i}+\theta_{b}+\phi_{mag})
+\end{bmatrix}$
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+In this representation,
+\begin_inset Formula $d_{b}$
+\end_inset
+
+is a slowly varying bias variable on the step size.
+\end_layout
+
+\end_body
+\end_document
View
262 results/lyx/Dynamical Equations.lyx
@@ -0,0 +1,262 @@
+#LyX 2.0 created this file. For more info see http://www.lyx.org/
+\lyxformat 413
+\begin_document
+\begin_header
+\textclass article
+\use_default_options true
+\maintain_unincluded_children false
+\language english
+\language_package default
+\inputencoding auto
+\fontencoding global
+\font_roman default
+\font_sans default
+\font_typewriter default
+\font_default_family default
+\use_non_tex_fonts false
+\font_sc false
+\font_osf false
+\font_sf_scale 100
+\font_tt_scale 100
+
+\graphics default
+\default_output_format default
+\output_sync 0
+\bibtex_command default
+\index_command default
+\paperfontsize default
+\use_hyperref false
+\papersize default
+\use_geometry false
+\use_amsmath 1
+\use_esint 1
+\use_mhchem 1
+\use_mathdots 1
+\cite_engine basic
+\use_bibtopic false
+\use_indices false
+\paperorientation portrait
+\suppress_date false
+\use_refstyle 1
+\index Index
+\shortcut idx
+\color #008000
+\end_index
+\secnumdepth 3
+\tocdepth 3
+\paragraph_separation indent
+\paragraph_indentation default
+\quotes_language english
+\papercolumns 1
+\papersides 1
+\paperpagestyle default
+\tracking_changes false
+\output_changes false
+\html_math_output 0
+\html_css_as_file 0
+\html_be_strict false
+\end_header
+
+\begin_body
+
+\begin_layout Standard
+\begin_inset Formula $\begin{bmatrix}x_{i+1}\\
+y_{i+1}
+\end{bmatrix}$
+\end_inset
+
+=
+\begin_inset Formula $\begin{bmatrix}x_{i}\\
+y_{i}
+\end{bmatrix}$
+\end_inset
+
+ +
+\begin_inset Formula $d{}_{i}$
+\end_inset
+
+
+\begin_inset Formula $\begin{bmatrix}-cos(\theta_{i})\\
+sin(\theta_{i})
+\end{bmatrix}$
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+For the case where the coordinate system for the map is
+\begin_inset Formula $x$
+\end_inset
+
+ positive towards right and
+\begin_inset Formula $y$
+\end_inset
+
+ positive downwards with
+\begin_inset Formula $TrueNorth$
+\end_inset
+
+ of the map pointing upwards.
+\end_layout
+
+\begin_layout Standard
+This dynamical representation is overtly simplistic because it doesn't take
+ into account real world issues as seen in the groundwork section.
+ The most important issue is the issue of sensor drift.
+ The magnetometer is a rather inaccurate sensor and is rated to an accuracy
+ of 5 degrees in static circumstances.
+ There is also a recommendation to re-calibrate before use.
+ This is required because this sensor suffers from a lot of sensor noise
+ and drift.
+
+\end_layout
+
+\begin_layout Standard
+Recalibration of the magnetometer involves moving it around in a pattern
+ of 8.
+ Effectively, that randomizes internal magnetic elements enough for magnetic
+ saturation effects to be neutralized.
+ Unfortunately, for a continuous use scenario like ours, recalibration of
+ this sensor is not an option.
+ Hence, we modify our dynamical equation to take this error into account.
+\end_layout
+
+\begin_layout Standard
+\begin_inset Formula $\begin{bmatrix}x_{i+1}\\
+y_{i+1}
+\end{bmatrix}$
+\end_inset
+
+=
+\begin_inset Formula $\begin{bmatrix}x_{i}\\
+y_{i}
+\end{bmatrix}$
+\end_inset
+
+ +
+\begin_inset Formula $d{}_{i}$
+\end_inset
+
+
+\begin_inset Formula $\begin{bmatrix}-cos(\theta_{i}+\phi_{mag})\\
+sin(\theta_{i}+\phi_{mag})
+\end{bmatrix}$
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+In this dynamical equation, we have added an additional parameter
+\begin_inset Formula $\phi_{mag}$
+\end_inset
+
+which is a random variable that represents random white noise in the reading
+ from the true value of the magnetometer.
+\end_layout
+
+\begin_layout Standard
+Besides the sensor noise that creeps into the values of the magnetometer,
+ there are 2 other issues that need to be taken care of in our dynamical
+ modelling of the dead reckoning system.
+\end_layout
+
+\begin_layout Standard
+The first issue is an issue of bias in the angle readings from the magnetometer.
+ This bias can creep in due to 2 different reasons - the first being specific,
+ environmental magnetic fields which distort the actual detection of
+\begin_inset Formula $TrueNorth$
+\end_inset
+
+ in the system and the second being a bias that creeps in due to the way
+ the user holds the smartphone in the palm of his hand and the offset thus
+ produced.
+ To take into account such offsets, we modify the dynamical equations as
+ follows:
+\end_layout
+
+\begin_layout Standard
+\begin_inset Formula $\begin{bmatrix}x_{i+1}\\
+y_{i+1}
+\end{bmatrix}$
+\end_inset
+
+=
+\begin_inset Formula $\begin{bmatrix}x_{i}\\
+y_{i}
+\end{bmatrix}$
+\end_inset
+
+ +
+\begin_inset Formula $d{}_{i}$
+\end_inset
+
+
+\begin_inset Formula $\begin{bmatrix}-cos(\theta_{i}+\theta_{b}+\phi_{mag})\\
+sin(\theta_{i}+\theta_{b}+\phi_{mag})
+\end{bmatrix}$
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+In this modified version of the dynamical equations, we have added a slowly
+ varying term
+\begin_inset Formula $\theta_{b}$
+\end_inset
+
+that represents an explicit bias in the readings from the magnetometer.
+\end_layout
+
+\begin_layout Standard
+The second issue at hand is step size variation.
+ To map accelerometer readings to step sizes, we have used the empirical
+ equation provided by [ref].
+ However, this empirical equation doesn't take into account changes in step
+ sizes due to changes in footwear or floor material.
+ To account for this bias in step size detection, we introduce an additional
+ parameter
+\begin_inset Formula $d_{b}$
+\end_inset
+
+in the dynamical system.
+ The new equations for the dynamical system are:
+\end_layout
+
+\begin_layout Standard
+\begin_inset Formula $\begin{bmatrix}x_{i+1}\\
+y_{i+1}
+\end{bmatrix}$
+\end_inset
+
+=
+\begin_inset Formula $\begin{bmatrix}x_{i}\\
+y_{i}
+\end{bmatrix}$
+\end_inset
+
+ +
+\begin_inset Formula $(d{}_{i}+d_{b})$
+\end_inset
+
+
+\begin_inset Formula $\begin{bmatrix}-cos(\theta_{i}+\theta_{b}+\phi_{mag})\\
+sin(\theta_{i}+\theta_{b}+\phi_{mag})
+\end{bmatrix}$
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+In this representation,
+\begin_inset Formula $d_{b}$
+\end_inset
+
+is a slowly varying bias variable on the step size.
+\end_layout
+
+\end_body
+\end_document
View
248 results/proposed_method.tex
@@ -1,9 +1,61 @@
-\chapter{Proposed Method\label{chap:proposed_method}}
-The particle filter approach described in [ped. Nav.] is adapted to and
-implemented on the Android smartphone. The onboard accelerometer and
-magnetometer of the Nexus S are used as inertial navigation sensors.
-Improvements are made to the algorithm. The performance of the particle filter
-is analyzed with different parameters and approaches:
+\chapter[Proposed Work]{Particle filter Based Map and Sensor Fusion technique for Indoor Tracking
+using an Android Smartphone \label{chap:proposed_method}}
+
+As described in Chapter \ref{chap:literature_review} (Literature Review),
+the step detection method for pedestrian navigation shows the most promise
+for accurate tracking of subjects in indoor tracking scenarios.
+Hence, our proposed method will be building upon the same. However, specific
+modifications are proposed and implemented to take into account the fact
+that our implementation system is an Android smartphone with a number of
+sensors and limited processing capabilities.
+
+The device for implementation is the Samsung Nexus S. The onboard accelerometer
+and magnetometer of the Nexus S are used as inertial navigation sensors.
+Improvements are made to the algorithm keeping in mind the capabilities and
+shortcomings of the mobile platform as well as the behaviour of sensors during
+real world tests. The algorithm is then analyzed with
+different parameters and approaches and is compared and contrasted with other
+tracking approaches.
+
+\section{Inputs}
+
+Given the choice of hardware, we are constrained to use only specific
+data sources for our algorithm. The sections below detail the data
+sources used by the algorithm.
+
+\subsection{Accelerometer}
+
+\todo[inline]{Show how Accelerometer can be sensor fused}
+
+\subsection{Orientation}
+
+\todo[inline]{Show how Orientation can be sensor fused}
+
+\subsection{Camera info\label{sec:QRCodes}}
+QRCodes are a kind of 2 dimensional bar code
+that can be read off from a camera. They can contain a variety of content -
+from URLs to Contact information. They can also contain plain text. The
+plain text information mode of QRCodes is leveraged to provide encoding
+of a human-readable text representation of map points. We can leverage
+the on-board camera of smartphones to provide information about the map
+of the floor, the current location and any additional information that is
+required by the tracking algorithm. Such factors might include the scaling
+factor of the map, Wifi AP information, navigation information etc.
+
+\subsubsection{QRCode information format}
+
+\todo[inline]{Add information about the message format for embedding data inside the QRCode}
+
+
+\subsection{Map Information}
+\todo[inline]{Show how Map Information can be sensor fused}
+
+
+\subsection{Wifi Information}
+
+\todo[inline]{Show how wifi information can be sensor fused}
+\todo[inline]{Which cases is such sensor fusion useful?}
+
\section{Dead reckoning with step counts}
@@ -13,60 +65,80 @@ \section{Dead reckoning with step counts}
and lie buried in sensor noise. They are virtually indetectible using the MEMS
accelerometer supplied with the android device - Nexus S.
-To overcome this difficulty, the step count method of [ped. Nav.] is adopted.
+To overcome this difficulty, the step count method of \todo{Provide reference}[ped. Nav.] is adopted.
Under the assumption that step size varies very little over the course of
-motion of the subject, an inertial navigation system may be created.
+motion of the subject, an inertial navigation system may be created. An
+empirical formula is used to correlate acceleration values from
+the
\subsection{Step counting method}
The step counting method is described in [ped. Nav.]. However, we take a
-slightly modified approach.
+slightly modified approach.
+
+\todo[inline]{Write a short recap on the step counting approach}
\subsection{Noise clamping\label{sec:NoiseClamping}}
-The MEMS accelerometer sensor on the smartphone has sensor noise present close
-to zero. The noise level for the accelerometer was determined to be always less
-than $0.6 m/s^2$. To allow for a reasonable noise margin and provide sufficient
-cushion for additional noise introduced due to the dynamic nature of walking, we
-choose a threshold of $1.3 m/s^2$. If the absolute value of the Z-axis
-acceleration sample is less than this threshold, then the sample will be clamped
-to zero.
+It is well known that while measuring real world information, sensors of all
+kinds pick up noise from the environment that affects the readings of the
+sensed variables. The MEMS accelerometer present on a typical smartphone is
+no different. Figure \ref{fig:accel_static} graphs the sensor noise of
+the accelerometer sensor for our device under test.
-As has been determined experimentally, steps taken by a human usually produce
-a pair of spikes - one positive and one negative with magnitude around $2 m/s^2$.
-By choosing this threshold value, we give maximal noise margin for step detection.
+The noise level for the accelerometer was determined to be always less
+than $0.6 m/s^2$. The acceleration peaks corresponding to actual steps usually
+lie around $2.0 m/s^2$. To allow for a reasonable noise margin and provide
+sufficient cushion for additional noise introduced due to the dynamic nature of
+walking, we choose a threshold of $1.3 m/s^2$ which is the mean value of the two
+peak values. If the absolute value of the Z-axis acceleration sample is less
+than this threshold, then the sample will be clamped to zero. For a smartphone
+with a similar accelerometer sensor but with different noise characteristics,
+the values of the threshold can be varied accordingly.
-See figure [...] for a comparative estimation of step values versus sensor noise.
+Figure \ref{fig:accel_raw} graphs how the filtering process works by
+supressing sensor noise close to zero while allowing sensor values to
+pass unaltered when they correspond to a step being taken.
-\subsection{Step size detection procedure}
+\subsection{Step detection procedure}
\subsubsection{Zero Crossings}
To detect actual steps taken by the subject holding the device, [ped. Nav.]
suggests using zero crossings. However, in the sensor data collected, a number
-of spurious zero crossings exist (primarily due to sensor noise). However,
-even after sensor noise is clamped as per section \ref{sec:NoiseClamping},
-spurious zero crossings often arise due to variable motion of the subject.
+of spurious peaks and valleys exist (primarily due to sensor noise). However,
+even after sensor noise is clamped as per Section \ref{sec:NoiseClamping},
+spurious peaks and valleys that arise due to variable motion of the subject
+are not completely eliminated.
\subsubsection{Peak and Valley hunting}
-Peak and Valley hunting procedure (better than zero crossings) for step detection.
-Robust to unexpected values.
-To have robust detection of steps, a state machine is maintained. The state
-machine detects a peak and then waits for a trough. Subsequent
+Peak and Valley hunting procedure is an alternate method for step detection.
+In this method a 2-state machine is constructed according to Table
+\ref{tbl:peak_valley_state_table}. This method outputs a detected step at
+the first positive peak in the accelerometer sensor data that corresponds to
+the beginning of the next step. This is contrast to the zero-crossing method
+that outputs the detection of a step at every negative to positive zero
+crossing.
+
An internal state machine is used. The state machine has 2 states and a comparison
is made between $A_{max}$ or $A_{min}$ and the sample value that forms the peak/trough
whenever state transitions occur.
+\todo{Improve this area}
\begin{table}[h]\centering
- \caption{State table of the step detection state machine}
+ \caption{State table of the step detection state machine\label{tbl:peak_valley_state_table}}
\begin{tabular}{cccc} \hline
State & Accelerometer Value & New State & Action\\ \hline
- $q_0$ & Positive Peak Detected & $q_1$ & Update $A_{max}$ if peak is of larger magnitude \\
+ $q_0$ & Positive Peak Detected & $q_1$ & Update $A_{max}$ if peak value \\
+ & & & is positive and of \\
+ & & & a larger magnitude than \\
+ & & & current $A_{max}$ \\
& Other values & $q_0$ & Ignore \\ \hline
- $q_1$ & Negative Trough Detected & $q_0$ & Update $A_{min}$ if trough is negative \\
- & & & and of larger magnitude than $A_{min}$ \\
+ $q_1$ & Negative Trough Detected & $q_0$ & Update $A_{min}$ if trough \\
+ & & & is negative and of larger \\
+ & & & magnitude than $A_{min}$ \\
& Other values & $q_1$ & Ignore \\ \hline
\end{tabular}
\end{table}
@@ -83,39 +155,117 @@ \subsection{Step Size Estimation}
to scale the step-values to real world distances.
\section{Determining the Training Constant}
-A simple procedure was followed to determine the training constant for a user.
-The user was asked to locate himself using a QRCode before starting out along
-a straight line along a corridoor
-\section{Sensor fusion using Particle Filters}
+An experimental method was used to determine the training constant for each
+user.
-A background on particle filters has already been given.
\subsection{Dynamical equations for system}
-The dynamical equations that govern the system are:
+Effectively, we can state that the basic system is being modelled by the
+following set of equations:
+
+\begin{equation}\label{eq:dr_eq}
+\begin{bmatrix}x_{i+1}\\
+y_{i+1}
+\end{bmatrix} = \begin{bmatrix}x_{i}\\
+y_{i}
+\end{bmatrix} + d{}_{i} \begin{bmatrix}-cos(\theta_{i})\\
+sin(\theta_{i})
+\end{bmatrix}
+\end{equation}
+For the case where the coordinate system for the map is $x$ positive towards right and $y$ positive downwards with TrueNorth of the map pointing upwards.
+This dynamical representation is overtly simplistic because it doesn't take into account real world issues as seen in the groundwork section. The most important issue is the issue of sensor drift. The magnetometer is a rather inaccurate sensor and is rated to an accuracy of 5 degrees in static circumstances. There is also a recommendation to re-calibrate before use. This is required because this sensor suffers from a lot of sensor noise and drift.
-\subsection{Accelerometer}
+Recalibration of the magnetometer involves moving it around in a pattern of 8. Effectively, that randomizes internal magnetic elements enough for magnetic saturation effects to be neutralized. Unfortunately, for a continuous use scenario like ours, recalibration of this sensor is not an option. Hence, we modify our dynamical equation to take this error into account.
+\begin{equation}
+\begin{bmatrix}x_{i+1}\\
+y_{i+1}
+\end{bmatrix} = \begin{bmatrix}x_{i}\\
+y_{i}
+\end{bmatrix} + d{}_{i} \begin{bmatrix}-cos(\theta_{i}+\vartheta)\\
+sin(\theta_{i}+\vartheta)
+\end{bmatrix}
+\end{equation}
-\subsection{Orientation}
+In this dynamical equation, we have added an additional parameter $\vartheta$ which is a random variable that represents random white noise in the reading from the true value of the magnetometer.
-\subsection{Camera info}
-For first fix, we use QR codes. They are used whenever subject changes floors too.
-The QR codes provide information about the map of the floor, the current location
-and any additional information that is required by the tracking algorithm.
+Besides the sensor noise that creeps into the values of the magnetometer, there are 2 other issues that need to be taken care of in our dynamical modelling of the dead reckoning system.
-\subsection{Map Information}
+\subsection{Accounting for orientation bias and noise}
+The first issue is an issue of bias in the angle readings from the magnetometer. This bias can creep in due to 2 different reasons - the first being specific, environmental magnetic fields which distort the actual detection of $TrueNorth$ in the system and the second being a bias that creeps in due to the way the user holds the smartphone in the palm of his hand and the offset thus produced. To take into account such offsets, we modify the dynamical equations as follows:
+\begin{equation}
+\begin{bmatrix}x_{i+1}\\
+y_{i+1}
+\end{bmatrix} = \begin{bmatrix}x_{i}\\
+y_{i}
+\end{bmatrix} + d{}_{i} \begin{bmatrix}-cos(\theta_{i}+\theta_{b}+\vartheta)\\
+sin(\theta_{i}+\theta_{b}+\vartheta)
+\end{bmatrix}
+\end{equation}
-\subsection{Wifi Information}
+In this modified version of the dynamical equations, we have added a slowly
+varying term $\theta_{b}$ that represents an explicit bias in the readings from
+the magnetometer.
+
+\subsection{Accounting for varying step sizes}
+
+The second issue at hand is step size variation and missing steps. To map
+accelerometer readings to step sizes, we have used the empirical equation
+provided by [ref]. However, this empirical equation doesn't take into account
+changes in step sizes due to changes in footwear or floor material. To account
+for this bias in step size detection, we introduce an additional parameter
+$d_{b}$ in the dynamical system. The new equations for the dynamical system are:
+
+\begin{equation}
+\begin{bmatrix}x_{i+1}\\
+y_{i+1}
+\end{bmatrix} = \begin{bmatrix}x_{i}\\
+y_{i}
+\end{bmatrix} + (d{}_{i}+d_{b}) \begin{bmatrix}-cos(\theta_{i}+\theta_{b}+\vartheta)\\
+sin(\theta_{i}+\theta_{b}+\vartheta)
+\end{bmatrix}
+\end{equation}
+
+In this representation, $d_{b}$ is a slowly varying bias variable on the step size.
+
+\section{Particle Filter Implementation of the Dynamical Equations}
+
+There are a number of ways in which you can transform these dynamical
+equations to practice. An HMM based approach might be taken if a discrete
+output space is preferred. A particle filter approach is taken when the
+output state space is continuous. Since we intend to keep the output space
+continuous, we choose the Particle filter implementation of the dynamical
+equations over the HMM implementation.
+
+\subsection{Algorithm for updates}
+
+\todo[inline]{Expand this section}
+
+\section{Fusing Map Information}
+
+\todo[inline]{Explain how map information can act as an error correcting
+ tool for the system.}
+
+\section{Inherent limitations of the Particle filter approach}
+
+\begin{enumerate}
+\item Computational complexity
+\item Possibility of running out of valid successor states (effectively getting lost)
+\item Degeneracy of states
+\end{enumerate}
-\section{Accounting for orientation bias and noise}
+\section{Additional heuristics to combat these limitations}
-\section{Accounting for varying step sizes}
+The following heuristics are used to combat some of the limitations
+described above.
-\section{Barometer Information}
+\section{Future enhancements}
+\subsection{Fusing Barometer Information}
+\todo[inline]{Propose sensor fusion for barometric sensors as and when they become available}
View
240 results/results.tex
@@ -31,9 +31,16 @@ \section{Hardware}
is a composite sensor that fuses Gravity information derived from the
3 axis Accelerometer and the magnetic field information derived from the
3 axis Magnetic field sensor to orient the device in the 3 Dimensional World
-Coordinate space. The actual method used to do so is described in the API
-documentation [reference to API documentation] and further discussion is out of
-scope for this thesis.
+Coordinate space. The actual method used to do so is described in the API
+documentation \todo{Provide Reference}[reference to API documentation] and
+further discussion is out of scope for this thesis.
+
+\begin{figure}
+\centering
+ \includegraphics[height=3in]{figures/android_front}
+ \includegraphics[height=3in]{figures/android_back}
+\caption{Google Nexus S manufactured by Samsung}
+\end{figure}
\section{Location Under Test}
@@ -63,15 +70,8 @@ \section{Location Under Test}
\end{figure}
-\section{Simple Dead Reckoning}
-As discussed in the Literature Review (Chapter \ref{chap:literature_review}) and
-in the Proposed Work (Chapter \ref{chap:proposed_method}), it is impossible to
-directly obtain displacement information by double integration of the
-accelerometer data. Hence, the step detection method was employed for tracking
-the motion of the device as held by a walking human.
-
-\subsection{Step detection procedure}
+\section{Step detection procedure}
Step detection for dead reckoning was done using accelerometer sensor data.
Two different methods were employed and the simple zero crossing method on
@@ -132,7 +132,7 @@ \subsection{Step detection procedure}
\end{figure}
-\subsection{First Fix}
+\section{First Fix}
For any dead reckoning algorithm, it is important to provide a good starting
point. Low error in the starting location contributes to better
@@ -149,6 +149,19 @@ \subsection{First Fix}
in the area under test.
\end{enumerate}
+\missingfigure{QRCodes pasted on the wall}
+
+\subsection{Experimental setup}
+
+All the experments were performed with the same Android device (the Samsung
+Nexus S) and with the same application software. Users were familiar with
+touch screen phones and were well aware of the layout of the building. None of
+the users had had any prior exposure to the map of the building and did not
+know the direction of True North. Details of the experiments performed
+are specified in Sections \ref{sec:direct_selection} and \ref{sec:qrcode_selection}
+
+\subsection{Direct Selection of Location on a Map\label{sec:direct_selection}}
+
Five test subjects were asked to mark out their current position on a
map by simply touching the corresponding location on the map shown on the
touchscreen of the device. The map was shown at a fixed resolution to all
@@ -156,15 +169,177 @@ \subsection{First Fix}
The test were also allowed to retry locating themselves on the map in case they
were not satisfied with their initial results. All their location attempts were
-logged for later analysis. The results are summarized in
+logged for later analysis.The following facts were observed during the process of
+selection:
+
+\begin{enumerate}
+\item Users had an initial difficulty in orienting themselves with regard to
+ the map supplied.
+\item As the map contained blocks of rooms that were similar looking, users
+ made initial errors in orienting themselves. However, they attempted to
+ correct their errors when the mistake was realized.
+\item Some users felt extremely frustrated by the direct selection procedure
+ primarily because they could not mark out their locations precisely due
+ to the large surface area of contact of their fingers with the touch
+ screen. The variability of selection of the contact point while using
+ the touchscreen contributed to an increase in the number of attempts
+ required to correctly mark their positions on the map.
+\end{enumerate}
+
+\todo[inline]{Ask 5 people to select locations on a map and log data}
+\missingfigure{Table of error from true location}
+\missingfigure{Table of number of times attempted for satisfactory positioning}
+
+\subsection{Camera based QRCode Method \label{sec:qrcode_selection}}
-\subsubsection{Direct Location on a Map}
+To evaluate the efficiency of determining first fix via QRCodes in comparison
+to the direct location selection method, an experiment was set up.
+The experiment was performed in conjunction with the experment of
+Section \ref{sec:direct_selection}, users were asked to locate themselves
+by snapping a QRCode pasted on the wall instead of marking their starting
+location on a map.
-\subsubsection{Camera based QRCode Method}
-QRCode acquisition was successful at distances ranging from 30 cm to 1 m using
-the Android phone.
+The users were then positioned at various distances from the QRCode and
+asked whether they would make the effort to go to the QRCode to snap their
+starting location while using the application or whether they would prefer
+the manual method.
-\subsection{Determining the Training Constant}
+The following observations were made regarding the QRCode method for first
+fix:
+
+\begin{enumerate}
+\item QRCode selection via the camera was a fast process, usually not requiring
+ more than 10 seconds on behalf of the user.
+\item Users were consistently located at distances less than 1 meter from
+ the QRCode. In most cases, the users were at a distance of around 30 cm
+ from the QRCode pasted on the wall.
+\item There was an instance where poor lighting delayed the capture of the
+ QRCode and the QRCode could be successfully captured only after a
+ fluorescent tubelight was switched on to provide adequate lighting.
+\end{enumerate}
+
+\missingfigure{Image of a person snapping the QRCode with the camera}
+
+\subsection{Comparison between the two methods}
+
+After processing the results of the experiments, it was determined that
+users overwhelmingly preferred the QRCode method for first fix acquisition.
+They were willing to walk up to $5 m$ to the nearest QRCoded location in
+order to take advantage of the facility.
+
+\todo[inline]{Insert survey results}
+
+\subsection{User Feedback}
+
+Users in their comments indicated that potential improvements to the
+application were possible. For example, if the application could determine
+roughly their current location and then provide just that subset of the map
+in which the user was located, the speed of providing the first fix location
+by a manual method could be improved.
+
+\section{Determining the Training Constant}
+
+In a separate experiment, three test subjects were asked to walk between
+2 QRCoded locations. The first fix was taken using the QRCode method and
+the training constant was thus estimated based on the number of steps
+detected and the known distance between the 2 QRCoded locations.
+
+The locations used for this test were along a corridoor and were about $30 m$
+apart. The tests were repeated thrice for each subject. The resulting
+step constants are summarized in the table below.
+
+\todo[inline]{Determining training constant}
+\missingfigure{Table of training constant values}
+
+\section{Step variation analysis}
+
+To see the performance of the algorithm to step variations, an experiment
+was performed wherein a test subject walked at three distinct speeds
+along a straight corridoor. The subject paused for a short while between
+the three distinct segments to maintain separation of speeds.
+
+The three segments of the walk had the following
+characteristics:
+
+\begin{enumerate}
+\item The test subject walked with very light steps, almost shuffling along.
+\item The test subject walked with regular steps along the corridoor.
+\item The test subject walked with large steps along the corridoor in a motion
+ that approximated running.
+\end{enumerate}
+
+The accelerometer graphs and the consequent step detections for this
+experiment are shown in Figure \ref{fig:step_variation}. The tabulated
+results of the step detection process are shown in
+Table \ref{tbl:step_variation}. Note that the poor performance for
+shuffling steps is due to acceleration peaks not being sufficiently
+distinguishable from sensor noise and for the fast heavy steps is
+due to generation of spurious peaks while coming to an abrupt halt.
+A smooth motion doesn't generate such issues and thus the step
+detection procedure is very accurate for that range.
+
+\begin{table}[tbph]
+ \centering
+ \begin{tabular}{|l|c|c|}
+ \hline
+ \hline
+ Step Segment & Actual Number of Steps & Steps Detected \\
+ \hline
+ Light Steps (Shuffle) & 10 & 5 \\
+ Regular steps & 10 & 10 \\
+ Fast (Heavy) steps & 15 & 18 \\
+ \hline
+ \hline
+ \end{tabular}
+ \caption{Step detections under step variations\label{tbl:step_variation}}
+\end{table}
+
+\begin{figure}
+ \centering
+ \includegraphics{figures/step_variation.png}
+ \caption{Difference in step sizes and the corresponding variations in
+ step detection and step estimates\label{fig:step_variation}}
+\end{figure}
+
+\section{Test Paths}
+
+Five different test paths were used to test the performance of the system.
+The features of these paths are described below. The paths themselves
+are marked out in Figure \ref{fig:test_paths}.
+
+\begin{enumerate}
+\item Straight walk down a corridoor (A to B)
+\item Straight walk down a corridoor, a U turn followed by a straight walk
+ to the starting point. (A to B and then B to A)
+\item Zig-Zag walk down a corridoor (A to B).
+\item A U shaped walk along all three corridoors. (A-B-C-D)
+\item A U shaped walk along all three corridoors followed by a U turn and a
+ walk back to the starting location. (A-B-C-D-C-B-A)
+\end{enumerate}
+
+\begin{figure}
+ \centering
+ \includegraphics[width=5in]{figures/test_paths.jpg}
+ \caption{Test paths for algorithm\label{fig:test_paths}}
+\end{figure}
+
+
+\section{Simple Dead Reckoning}
+
+As discussed in the Literature Review (Chapter \ref{chap:literature_review}) and
+in the Proposed Work (Chapter \ref{chap:proposed_method}), it is impossible to
+directly obtain displacement information by double integration of the
+accelerometer data. Hence, the step detection method was employed for tracking
+the motion of the device as held by a walking human. The steps are integrated
+with orientation information received from the magnetometer to create a
+simple dead reckoning system in accordance with the dynamical equation
+\eqref{eq:dr_eq}. The initial position for dead reckoning was obtained via
+QRCodes in accordance with the description in Section \ref{sec:QRCodes}.
+
+
+\subsection{Simple Dead Reckoning Results}
+\todo[inline]{Describe actual path and dead reckoning path}
+\missingfigure{Dead Reckoning path}
\section{Plain Wifi Based Positioning}
\subsection{Case 1: Dead reckoning with NN wifi positioning}
@@ -183,24 +358,31 @@ \subsection{Case 7: Simple post processing of output.??}
\subsection{Case 8: Simple heuristics to deal with impoverished samples}
(retry, retry with greater inaccuracy)
-\section{Particle filter + Wifi data}
-TODO
-
-\subsection{Case 1: Use of Wifi data for accounting for drift errors}
-\subsection{Case 2: Use of Oriented Wifi data for accounting for drift errors}
-\subsection{Case 3: Use of clamped wifi data for accounting for drift errors}
-\subsection{Case 4: Use of area Restricted Wifi data for accounting for drift errors}
-
\section{Signal Strength Map}
TODO if time permits
Wifi signal strength map developed using crowdsourced data for use in systems such as RedPin.
+\section{Summary of Results}
+\todo[inline]{Which algorithms to pick based on the results, advantages and disadvantages}
+
\section{Issues faced}
-Incorrect step sizes yielded states in which no further progress was possible using data from the inertial sensors. Hence we had to resort to wifi data to get out of the blind spot.
+Incorrect step sizes yielded states in which no further progress was possible
+using data from the inertial sensors. Hence we had to resort to wifi data to get
+out of the blind spot.
-Limited processing power and near-realtime time constraints of operation constrain computational
-complexity of the solution.
+Limited processing power and near-realtime time constraints of operation
+constrain computational complexity of the solution.
Surveying is the biggest issue in this system.
+Computational complexity and scaling issues.
+
+
+\section{Future Work: Particle filter + Wifi data}
+
+\subsection{Case 1: Use of Wifi data for accounting for drift errors}
+\subsection{Case 2: Use of Oriented Wifi data for accounting for drift errors}
+\subsection{Case 3: Use of clamped wifi data for accounting for drift errors}
+\subsection{Case 4: Use of area Restricted Wifi data for accounting for drift errors}
+
View
26 results/thesis.tdo
@@ -0,0 +1,26 @@
+\contentsline {todo}{{Insert values for Standard deviation here}}{11}
+\contentsline {todo}{{Show how Accelerometer can be sensor fused}}{18}
+\contentsline {todo}{{Show how Orientation can be sensor fused}}{18}
+\contentsline {todo}{{Add information about the message format for embedding data inside the QRCode}}{18}
+\contentsline {todo}{{Show how Map Information can be sensor fused}}{18}
+\contentsline {todo}{{Show how wifi information can be sensor fused}}{18}
+\contentsline {todo}{{Which cases is such sensor fusion useful?}}{18}
+\contentsline {todo}{{Provide reference}}{19}
+\contentsline {todo}{{Write a short recap on the step counting approach}}{19}
+\contentsline {todo}{{Improve this area}}{20}
+\contentsline {todo}{{Expand this section}}{23}
+\contentsline {todo}{{Explain how map information can act as an error correcting tool for the system.}}{23}
+\contentsline {todo}{{Propose sensor fusion for barometric sensors as and when they become available}}{23}
+\contentsline {todo}{{Provide Reference}}{26}
+\contentsline {todo}{Figure: {QRCodes pasted on the wall}}{30}
+\contentsline {todo}{{Ask 5 people to select locations on a map and log data}}{31}
+\contentsline {todo}{Figure: {Table of error from true location}}{31}
+\contentsline {todo}{Figure: {Table of number of times attempted for satisfactory positioning}}{31}
+\contentsline {todo}{Figure: {Image of a person snapping the QRCode with the camera}}{32}
+\contentsline {todo}{{Insert survey results}}{33}
+\contentsline {todo}{{Determining training constant}}{33}
+\contentsline {todo}{Figure: {Table of training constant values}}{33}
+\contentsline {todo}{{Describe actual path and dead reckoning path}}{36}
+\contentsline {todo}{Figure: {Dead Reckoning path}}{36}
+\contentsline {todo}{{Which algorithms to pick based on the results, advantages and disadvantages}}{38}
+\contentsline {todo}{{Put bibliography and appendices}}{41}
View
15 results/thesis.tex
@@ -1,6 +1,10 @@
-\documentclass[12pt,a4paper,oneside]{book}
-\usepackage{fullpage}
+\documentclass[12pt,a4paper,twoside]{book}
+%\usepackage{fullpage}
+%\usepackage[twoside,bindingoffset=0.75in??,left=1.75in,right=0.9in]{geometry}
+\usepackage{todonotes}
\usepackage[avantgarde]{quotchap}
+\usepackage{amsmath}
+\usepackage{setspace}
\usepackage{graphicx}
\pdfimageresolution 300
@@ -27,8 +31,13 @@ \chapter{Abstract}
\listoftables
+\clearpage
+\listoftodos
+
\mainmatter
+%\onehalfspacing
+
\input{introduction.tex}
\input{literature_review.tex}
@@ -45,7 +54,7 @@ \chapter{Abstract}
\backmatter
-% TODO: Put bibliography and appendices
+\todo[inline]{Put bibliography and appendices}
\end{document}
Please sign in to comment.
Something went wrong with that request. Please try again.