diff --git a/matlab/GPSaidedINS_cycling.m b/matlab/GPSaidedINS_cycling.m index 57cf78907f1ea2d89908da30c5537595e28c420f..48a7ceee554fc88bcdcff5bf55a918df3897d184 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 60078a215d3d087ae9f327fe6927df48636b29c9..4349e72641d2a6e512cc7f75c2305698edad980d 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 6fed46e76f91b60ad40148c5b9ce1da1befd7e9c..9cbfca75b7b8bdfad26fbe7d1cb6255a91566203 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 497e2e52e8b65d3298fb501519d979623f9a2e47..f0053b76704ef8cc2d7f3f801d2d96208e11386d 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 f867c05b93529c14864def7fa20f90c14f2c3ce8..fce35c73d7f8ed2a95beee1e9441a49569a7b7d0 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 4ef0cc785ddbaea1726a2c1b868b4f84683cefa5..d02b30c07f60dd3ab59a3a10ede74754a7f2762a 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 b873a3184093d72cc3743a7f1c4a1067ed1c182f..aa4ce129cffe35111f6d08b7f8e2407b7487f7e7 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 567c870bd1ed5ff7a9fdeb65b58f5ec10b0ae402..8001dc7c468dd942ecd4e07cbb36f83e8f19d1f6 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 8c3043e75518e96a453088fc2714aebc3aa4be4a..ce91f3ebf4663cb90d2a4a3e6cd239ce4f70039f 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 55f085ad138eae98794d691bd4f8e9f341f739f3..57731554df390c7757fe454446c8332e8f6d14be 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.}