From b528cadbf1f3336f1624bfcc424dc62ef7f35cb9 Mon Sep 17 00:00:00 2001
From: Claudio Mandrioli <claudio.mandrioli@control.lth.se>
Date: Tue, 16 Oct 2018 23:27:48 +0200
Subject: [PATCH] final review
---
matlab/GPSaidedINS_cycling.m | 9 +++++----
matlab/gps_randomized.m | 2 +-
matlab/main.m | 2 ++
paper/main.tex | 4 ++--
paper/sections/01-intro.tex | 7 +++----
paper/sections/02-related-work.tex | 7 +++----
paper/sections/03-model.tex | 9 ++++-----
paper/sections/04-fusion.tex | 2 +-
paper/sections/05-control.tex | 6 +++---
paper/sections/06-results.tex | 10 +++++-----
10 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/matlab/GPSaidedINS_cycling.m b/matlab/GPSaidedINS_cycling.m
index 57cf789..48a7cee 100644
--- a/matlab/GPSaidedINS_cycling.m
+++ b/matlab/GPSaidedINS_cycling.m
@@ -178,15 +178,16 @@ end
%% output for simulation of energy-accuracy tradeoff
out_data.energy=energy;
-xest = out_data.x_h(2,:);%start_sim:start_sim+length_sim);
-yest = out_data.x_h(1,:);%start_sim:start_sim+length_sim);
-xgps = interp1(in_data.GNSS.t,in_data.GNSS.pos_ned(2,:),in_data.IMU.t,'linear','extrap')';
-ygps = interp1(in_data.GNSS.t,in_data.GNSS.pos_ned(1,:),in_data.IMU.t,'linear','extrap')';
+xest = out_data.x_h(2,start_sim:start_sim+length_sim);%2,:);
+yest = out_data.x_h(1,start_sim:start_sim+length_sim);%1,:);
+xgps = interp1(in_data.GNSS.t,in_data.GNSS.pos_ned(2,:),in_data.IMU.t(start_sim:start_sim+length_sim),'linear','extrap')';
+ygps = interp1(in_data.GNSS.t,in_data.GNSS.pos_ned(1,:),in_data.IMU.t(start_sim:start_sim+length_sim),'linear','extrap')';
xerr = xest - xgps;
yerr = yest - ygps;
out_data.error = sqrt(mean(xerr.^2+yerr.^2));
out_data.P_store=P_store;
out_data.turn=turn_store;
+
end
diff --git a/matlab/gps_randomized.m b/matlab/gps_randomized.m
index 60078a2..4349e72 100644
--- a/matlab/gps_randomized.m
+++ b/matlab/gps_randomized.m
@@ -31,7 +31,7 @@ required_sv= 4;
ephDuration=1800.0;
%bounds for time required for fetching freq and phase
fp_lower=0.2;
-fp_upper=1.2;%500.5;
+fp_upper=500.5;
%% initialize output
sensor = sensor_in;
diff --git a/matlab/main.m b/matlab/main.m
index 6fed46e..9cbfca7 100644
--- a/matlab/main.m
+++ b/matlab/main.m
@@ -21,6 +21,8 @@ out_data=GPSaidedINS_cycling(in_data,settings);
%% Plot the data
disp('Plot data')
+%overall error
+out_data.error
%plot_data(in_data,out_data,'True');drawnow
h=zeros(1,2);
figure(2)
diff --git a/paper/main.tex b/paper/main.tex
index 497e2e5..f0053b7 100644
--- a/paper/main.tex
+++ b/paper/main.tex
@@ -69,7 +69,7 @@
\begin{document}
-\title{PAN: Power-Aware Navigation with Sensor Fusion}
+\title{Cyber-Physical Modeling of GPS Receivers for Power Efficient Localization Systems.}
\author{Claudio Mandrioli}
\affiliation{%
\institution{Department of Automatic Control,\\Lund University}
@@ -125,7 +125,7 @@ Politecnico di Milano, Italy}
\ccsdesc[500]{Computer systems organization~Embedded systems}
-\keywords{Power-aware computing -- cyber-physical modeling -- localization systems.}
+\keywords{GPS Receiver, Power-Aware Computing, Cyber-Physical Modeling, Localization Systems.}
\maketitle
diff --git a/paper/sections/01-intro.tex b/paper/sections/01-intro.tex
index f867c05..fce35c7 100644
--- a/paper/sections/01-intro.tex
+++ b/paper/sections/01-intro.tex
@@ -48,7 +48,7 @@ influence what can be achieved with any GPS sensor, as they introduce
basic limitations and characteristics of the technology. In this
specific context, we highlight how a dynamical model is necessary to
capture the involved \emph{phenomena}. In fact, GPS sensors that
-receive the same input data can behave differently, depending on the
+receive the same \textcolor{red}{\emph{stimula}} can behave differently, depending on the
sensor's internal state.
\item \textbf{Design:} It identifies opportunities for battery
savings. Specifically, modeling the GPS-related \emph{phenomena}
@@ -56,9 +56,8 @@ allows us to devise a sampling strategy that exploits the technology
characteristics.
\item \textbf{Integration:} It integrates the GPS with an ecosystem of
inertial measurement sensors. While this is not a new idea, thanks to
-our model we are able to capture the trade-offs between the different
-sensor types programmatically and to exploit the characteristics of
-each sensor.
+our model we are able to capture the trade-offs \textcolor{red}{of the different merging algorithms programmatically and to expose the characteristics of
+each solution}.
\end{itemize}
%
This paper is organized as follows. As much research has been done on
diff --git a/paper/sections/02-related-work.tex b/paper/sections/02-related-work.tex
index 4ef0cc7..d02b30c 100644
--- a/paper/sections/02-related-work.tex
+++ b/paper/sections/02-related-work.tex
@@ -3,15 +3,14 @@ devices. This is well testified by the number and variety of works
that try to mitigate it. Previous work mainly apply to smartphones and
can be categorized in two classes, depending on the type of approach
that is used for battery optimization: (i) work on the GPS stack --
-i.e., work optimizing the behavior of the sensor, (ii) work that try
-to reduce the usage of the GPS sensor -- i.e., work that tries to
+i.e., work optimizing the behavior of the sensor, (ii) work that reduce the usage of the GPS sensor -- i.e., work that tries to
sample less frequently or only when needed.
The first class includes results like~\cite{7528057,
bib:computation-offloading, bib:selective-tracking,
bib:microsoft-leap, bib:sparse-fourier}. The authors of
\cite{bib:computation-offloading} aim at outsourcing the device
-computation (once the data has been received) to some server, using a
+computation (once the data has been \textcolor{red}{retrieved}) to some server, using a
network connection. \cite{bib:selective-tracking} improves the GPS
receiver power-efficiency selecting only a subset of visible
satellites to be tracked. Other works aim at improving the speed of
@@ -28,7 +27,7 @@ trade-off controller, that trades accuracy for energy consumption. In
the same class we can include works that exploit other sensors. When
the adaptation layer detects that the user state does not need high
accuracy, it minimizes the GPS receiver usage by turning it off and
-enabling it again only on demand~\cite{bib:feasibility-duty-cycling,
+enabling it again only on demand \textcolor{red}{or eventually switching to other positioning techniques}~\cite{bib:feasibility-duty-cycling,
bib:traffic-delay, bib:entracked-datadriven-modeling, bib:senseLess,
bib:framework-for-energy-efficiency}. Among the works on this
additional adaptation
diff --git a/paper/sections/03-model.tex b/paper/sections/03-model.tex
index b873a31..aa4ce12 100644
--- a/paper/sections/03-model.tex
+++ b/paper/sections/03-model.tex
@@ -98,8 +98,7 @@ are frequently updated. The transmission of the ephemeris data has a
duration of 30 seconds, and the satellites continuously broadcast new
data. In order to ensure the correct acquisition of one data point, the
receiver then has to fetch and decode the signal for a time that is in
-the interval $[30,60)$ seconds (in the worst case, the receiver is
-turned on right after the start of a new message transmission).
+the interval $[30,60)$ seconds (in the worst case, the receiver \textcolor{red}{starts reading the message} right after the start of a new message transmission).
All the satellites transmit on the same frequency and then the
different signals are multiplexed using the Code Division Multiple
@@ -277,7 +276,7 @@ represent the events that alter the information availability or the
antenna state changes. As described in Section~\ref{sec:gps:phy}, the
ephemeris data become available when the receiver listens
consecutively to the satellites' signal for long enough (transition
-\texttt{get\_ephemeris}). The loss of availability happens either at
+\texttt{get\_ephemeris}). Their loss of availability happens either at
the expiration of the ephemeris data, or when the tracked satellites
disappear from the visible sky. In theory, the second event does not
necessarily force an update of the ephemeris data. For instance, a
@@ -286,8 +285,8 @@ before its ephemeris data expiration. For simplicity (and without
loss of information with respect to our model usage) we do not include
the specific tracking of different satellites in the model and,
consequently, we do not distinguish between these two cases. The
-transition \texttt{ephemeris\_expire} implements both. The ranging
-data become available as soon as the satellites' signals are
+transition \texttt{ephemeris\_expire} implements both. The ranging
+data \textcolor{red}{instead} become available as soon as the satellites' signals are
fetched. We refer to this transition as
\texttt{fetch\_freq\&phase}. The loss of ranging data can have two
causes: (i) the antenna is turned off (transition \texttt{turn\_off}),
diff --git a/paper/sections/04-fusion.tex b/paper/sections/04-fusion.tex
index 567c870..8001dc7 100644
--- a/paper/sections/04-fusion.tex
+++ b/paper/sections/04-fusion.tex
@@ -97,7 +97,7 @@ Finally, $\Omega$ is defined as
Equation~\eqref{eq:integration} can also be seen in the form of a
discrete-time dynamical system $x(k) = f(x(k-1), u(k))$. This
representation highlights that $x(k) = [p(k), v(k), q(k)]'$ is the
-system state (and output), i.e., the position estimation, and
+system state and output, i.e., the position estimation, and
$u(k) = [s(k),\omega(k)]'$ is the system input, i.e., the data read by
the IMU. The corresponding block diagram is shown in
Figure~\ref{fig:sensorfusionscheme}.
diff --git a/paper/sections/05-control.tex b/paper/sections/05-control.tex
index 8c3043e..ce91f3e 100644
--- a/paper/sections/05-control.tex
+++ b/paper/sections/05-control.tex
@@ -68,8 +68,8 @@ Another important consequence of the sampling policy is the
observability of the event \texttt{lost\_visibility}. The occurrence
event is in fact detectable only when the antenna is turned on and the
sensor is listening to the visible satellites. When a satellite
-disappears, the device is not aware of the even if the antenna is
-turned off. At the next sampling, the receiver needs then to acquire
+disappears, if the antenna is
+turned off, the device cannot detect it. At the next sampling, the receiver needs then to acquire
new ephemeris data before being capable to provide positioning
information.
@@ -86,5 +86,5 @@ in the state machine shown in Figure~\ref{fig:controller}.
The logical controller sends a \textcolor{red}{\texttt{turn\_on}} signal when the system is starting, to collect the ephemeris data (State \textcircled{\scriptsize 2} in Figure~\ref{fig:controller}). Then, once the ephemeris data are available (which is defined by the very same transition of the sensor model), it starts cycling between states \textcircled{\scriptsize 3} and \textcircled{\scriptsize 4}, alternatively triggering the \textcolor{red}{\texttt{turn\_off}} and \textcolor{red}{\texttt{turn\_on}} signals. For readability, and consistently with the sensor model shown in Figure~\ref{fig:cyberDynamics}, the states in which the antenna is turned on are filled in green.
-When the ephemeris data are about to expire (intuitively defined as $time>expiry\_time\_ephemeris-60$), or the sensor loses visibility of the tracked satellites, the controller goes back to State \textcircled{\scriptsize 2} and keeps the antenna on, to refresh the ephemeris data. If the ephemeris data are valid (and about to expire) the sensor can actually still be sampled, represented by taking the transition \texttt{sensor in position\_avaialable}.
+When the ephemeris data are about to expire (intuitively defined as $time>expiry\_time\_ephemeris-60$), or the sensor loses visibility of the tracked satellites, the controller goes back to State \textcircled{\scriptsize 2} and keeps the antenna on, to refresh the ephemeris data. If the former ephemeris data are valid the sensor can actually still be sampled, represented by taking the self-loop transition \texttt{sensor in position\_avaialable}.
diff --git a/paper/sections/06-results.tex b/paper/sections/06-results.tex
index 55f085a..5773155 100644
--- a/paper/sections/06-results.tex
+++ b/paper/sections/06-results.tex
@@ -195,7 +195,7 @@ increase the complexity of the model and decrease it usability. An
extension of the model to include also this phenomenon would not be
very difficult to obtain. It is enough to have parallel state machines
similar to the one shown in Figure~\ref{fig:cyberDynamics}, that
-independently capture the tracking of individual satellites.
+independently capture the tracking of individual satellites \textcolor{red}{but are synchronized in the antenna's state}.
\subsection{Positioning Accuracy}
\label{sec:res:accuracy}
@@ -370,7 +370,7 @@ then use simulations to further analyze the trade-off between power
accuracy).
Figures~\ref{fig:cycling-trace} and~\ref{fig:car-trace} respectively
-shows traces for the tracking of the bike and the car. In each
+show traces for the tracking of the bike and the car. In each
figure, the GPS trace is represented using solid blue lines, while
two different executions of the sensor fusion algorithm (with
different values of the threshold $th$) are shown in red dotted lines
@@ -413,8 +413,8 @@ step in the simulation, there is a probability of increasing or
decreasing the number of visible satellites (in a realistic bound
between 3 and 6). The overall error of a trace is defined as the
root-mean-square of the distance between the trace and the pure GPS
-signal. We also normalize (removing the minimum number encountered in
-the simulations), to highlight the trade-off.
+signal. \textcolor{red}{We also normalize (removing the minimum number encountered in
+the simulations), to highlight the trade-off.(NO MORE)}
\begin{figure*}
\centering
@@ -534,5 +534,5 @@ This is reasonable, since the loss of visibility will negatively
affect both the accuracy (as the GPS data wont be available until a
sufficient number of satellites become visible again) and the energy
consumption (as the sensor will have to be turned on for relatively
-long time to reacquire the ephemeris data).
+long time to reacquire the ephemeris data). \textcolor{red}{Still, if we look only at the simulations where no visiblity-loss happens, the same behavior is exposed.}
--
GitLab