From 5d4da515910d6dfc68a48b1b53a03f92a1538010 Mon Sep 17 00:00:00 2001
From: Claudio <claudio.mandrioli@control.lth.se>
Date: Thu, 11 Oct 2018 17:03:27 +0200
Subject: [PATCH] sezione 6 v1
---
matlab/GPSaidedINS.m | 8 +--
matlab/GPSaidedINS_cycling.m | 21 +++---
matlab/get_settings.m | 4 +-
matlab/get_settings_cycling.m | 50 ++++++++++++++
matlab/gps.m | 10 +--
matlab/gps_randomized.m | 18 +----
matlab/main.m | 26 ++++---
matlab/run_many_car.m | 48 +++++++++++++
matlab/run_many_cycling.m | 71 +++++++++----------
paper/sections/06-results.tex | 126 ++++++++++++++++++++++++++--------
10 files changed, 261 insertions(+), 121 deletions(-)
create mode 100644 matlab/get_settings_cycling.m
create mode 100644 matlab/run_many_car.m
diff --git a/matlab/GPSaidedINS.m b/matlab/GPSaidedINS.m
index 75c96af..655499e 100644
--- a/matlab/GPSaidedINS.m
+++ b/matlab/GPSaidedINS.m
@@ -305,12 +305,12 @@ end
function sv=random_satellites(sv_old)
coin=random('uniform',0,1);
sv=sv_old;
-if sv_old==6 %simulate satellite loss of visibility
+if sv_old==6
if coin<0.005
sv=5;
end
end
-if sv_old==5 %simulate satellite loss of visibility
+if sv_old==5
if coin>0.99
sv=6;
end
@@ -318,7 +318,7 @@ if sv_old==5 %simulate satellite loss of visibility
sv=4;
end
end
-if sv_old==4 %simulate satellite loss of visibility
+if sv_old==4
if coin>0.99
sv=5;
end
@@ -326,7 +326,7 @@ if sv_old==4 %simulate satellite loss of visibility
sv=3;
end
end
-if sv_old==3 %simulate satellite loss of visibility
+if sv_old==3
if coin>0.95
sv=4;
end
diff --git a/matlab/GPSaidedINS_cycling.m b/matlab/GPSaidedINS_cycling.m
index 9461e86..c784438 100644
--- a/matlab/GPSaidedINS_cycling.m
+++ b/matlab/GPSaidedINS_cycling.m
@@ -35,9 +35,15 @@ function out_data=GPSaidedINS(in_data,settings)
u=[in_data.IMU.acc;in_data.IMU.gyro];
t=in_data.IMU.t;
+%% Information fusion
+start_sim=822799; %start index of time vector of IMU
+[is, where]=ismember(in_data.IMU.t(start_sim),in_data.GNSS.t); %find same start on GPS time vector
+ctr_gnss_data=where;
+GPS_position=true;
+
%% Initialization
% Initialize the navigation state
-x_h=init_navigation_state(u,settings,in_data);
+x_h=init_navigation_state(u,settings,in_data,where);
% Initialize the sensor bias estimate
delta_u_h=zeros(6,1);
@@ -45,7 +51,6 @@ delta_u_h=zeros(6,1);
% Initialize the Kalman filter
[P,Q1,Q2,~,~]=init_filter(settings);
-
% Allocate memory for the output data
N=size(u,2);
out_data.x_h=zeros(10,N);
@@ -55,15 +60,11 @@ out_data.diag_P(:,1)=diag(P);
out_data.delta_u_h=zeros(6,N);
turn_store=true;
-%% Information fusion
-ctr_gnss_data=1838;
-GPS_position=true;
-
%% Initialize GPS sensor
sensor.state='warm_start_available';
sensor.fetchfp=1.0;
sensor.geteph=Inf;
-sensor.ephExp=1800.0;
+sensor.ephExp=in_data.IMU.t(start_sim)+180000.0;
sensor.fp=0;
sensor.eph=5;
sv=5; %initialize the number of visible satellites
@@ -77,7 +78,7 @@ P_store=0; %store summed valued of the trace of P in time
sv_store=sv; %store number of visible satellites in time
%for k=2:N
-for k=200000:209000
+for k=start_sim:start_sim+20000
% Sampling period
Ts=0.01;%t(k)-t(k-1);
@@ -231,7 +232,7 @@ end
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Init navigation state %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-function x_h=init_navigation_state(u,settings,in_data)
+function x_h=init_navigation_state(u,settings,in_data,where)
% Calculate the roll and pitch
@@ -246,7 +247,7 @@ Rb2t=Rt2b([roll pitch settings.init_heading])';
q=dcm2q(Rb2t);
% Initial navigation state vector
-x_h=[in_data.GNSS.pos_ned(:,1838);zeros(3,1); q];
+x_h=[in_data.GNSS.pos_ned(:,where);zeros(3,1); q];
%x_h=[zeros(6,1); q];
end
diff --git a/matlab/get_settings.m b/matlab/get_settings.m
index 193930b..f4946dd 100644
--- a/matlab/get_settings.m
+++ b/matlab/get_settings.m
@@ -25,8 +25,8 @@ settings.init_heading = 320*pi/180;
% Process noise covariance (Q)
% Standard deviations, need to be squared
-settings.sigma_acc = 0.50;%0.05; % [m/s^2]
-settings.sigma_gyro = 1.0*pi/180;%0.1*pi/180; % [rad/s]
+settings.sigma_acc = 0.05; % [m/s^2]
+settings.sigma_gyro = 0.1*pi/180; % [rad/s]
settings.sigma_acc_bias = 0.0001; % [m/s^2.5]
settings.sigma_gyro_bias = 0.01*pi/180; % [rad/s^1.5]
diff --git a/matlab/get_settings_cycling.m b/matlab/get_settings_cycling.m
new file mode 100644
index 0000000..e4991dc
--- /dev/null
+++ b/matlab/get_settings_cycling.m
@@ -0,0 +1,50 @@
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%
+% Function that outputs a struct "settings" with the settings used in the
+% GNSS-aided INS
+%
+% Edit: Isaac Skog (skog@kth.se), 2016-09-01
+% Revised: Bo Bernhardsson 2018-01-01
+%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+function settings=get_settings()
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%% GENERAL PARAMETERS %%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%settings.non_holonomic = 'off';
+%settings.speed_aiding = 'off';
+
+settings.init_heading = 320*pi/180;
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%% FILTER PARAMETERS %%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+% Process noise covariance (Q)
+% Standard deviations, need to be squared
+settings.sigma_acc = 0.50;%0.05; % [m/s^2]
+settings.sigma_gyro = 1.0*pi/180;%0.1*pi/180; % [rad/s]
+settings.sigma_acc_bias = 0.0001; % [m/s^2.5]
+settings.sigma_gyro_bias = 0.01*pi/180; % [rad/s^1.5]
+
+
+% GNSS position measurement noise covariance (R)
+% Standard deviations, need to be squared
+settings.sigma_gps = 1/sqrt(3);%3/sqrt(3); %[m]
+
+% Initial Kalman filter uncertainties (standard deviations)
+settings.factp(1) = 10; % Position [m]
+settings.factp(2) = 5; % Velocity [m/s]
+settings.factp(3:5) = (pi/180*[1 1 20]'); % Attitude (roll,pitch,yaw) [rad]
+settings.factp(6) = 0.02; % Accelerometer biases [m/s^2]
+settings.factp(7) = (0.05*pi/180); % Gyro biases [rad/s]
+
+
+end
+
+
+
+
diff --git a/matlab/gps.m b/matlab/gps.m
index 1a4600d..55f0ab9 100644
--- a/matlab/gps.m
+++ b/matlab/gps.m
@@ -43,7 +43,7 @@ sensor.eph=min(sensor_in.eph,sv);
%% events
ephemeris_expired=(time>sensor.ephExp)||(sensor.eph<required_sv); %ephemeris data are expired
-lost_visibility=(sensor_in.fp~=sensor.fp)&&(sensor.fp<required_sv);
+lost_visibility=(sensor.fp<required_sv);
fetch_fp=(time-sensor_in.howLong)>=ttfs;
get_ephemeris=(time-sensor_in.howLong)>ttge;
@@ -108,10 +108,6 @@ if strcmp(sensor_in.state,'read_ephemeris')
end
end
if strcmp(sensor_in.state,'warm_start')
- if(lost_visibility)
- sensor.state='warm_start';
- sensor.howLong=time;
- end
if(fetch_fp)
sensor.state='position_available';
sensor.howLong=time;
@@ -134,10 +130,6 @@ if strcmp(sensor_in.state,'cold_start')
sensor.howLong=time;
sensor.fp=sv;
end
- if(lost_visibility)
- sensor.state='cold_start';
- sensor.howLong=time;
- end
if(~turn)
sensor.state='no_info';
sensor.howLong=time;
diff --git a/matlab/gps_randomized.m b/matlab/gps_randomized.m
index cd274e7..3321ca1 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=500.5;
+fp_upper=1.5;
%% initialize output
sensor = sensor_in;
@@ -43,7 +43,7 @@ sensor.eph=min(sensor_in.eph,sv);
%% events
ephemeris_expired=(time>sensor.ephExp)||(sensor.eph<required_sv); %ephemeris data are expired
-lost_visibility=(sensor_in.fp~=sensor.fp)&&(sensor.fp<required_sv);
+lost_visibility=(sensor.fp<required_sv);
fetched_fp=(time>sensor.fetchfp);
get_ephemeris=(time>sensor.geteph);
@@ -106,16 +106,6 @@ if strcmp(sensor_in.state,'read_ephemeris')
end
end
if strcmp(sensor_in.state,'warm_start')
-% if(lost_visibility)
-% sensor.state='warm_start';
-% sensor.fetchfp=time+random('uniform',fp_lower,fp_upper);
-% %might have to go on to cold_start
-% if(ephemeris_expired)
-% sensor.state='cold_start';
-% sensor.fetchfp=time+random('uniform',fp_lower,fp_upper);
-% sensor.eph=0;
-% end
-% end
if(fetched_fp)
sensor.state='position_available';
sensor.geteph=time+random('uniform',30,60);
@@ -137,10 +127,6 @@ if strcmp(sensor_in.state,'cold_start')
sensor.geteph=time+random('uniform',30,60);
sensor.fp=sv;
end
-% if(lost_visibility)
-% sensor.state='cold_start';
-% sensor.fetchfp=time+random('uniform',fp_lower,fp_upper);
-% end
if(~turn)
sensor.state='no_info';
sensor.howLong=time;
diff --git a/matlab/main.m b/matlab/main.m
index cac6874..9c79e59 100644
--- a/matlab/main.m
+++ b/matlab/main.m
@@ -5,37 +5,43 @@
%% Load data
disp('Loads data')
-%load('GNSSaidedINS_data.mat');
-load('cycling_input_data');
+load('GNSSaidedINS_data.mat');
+%load('cycling_input_data');
%% Load filter settings
disp('Loads settings')
settings=get_settings();
+%settings=get_settings_cycling();
settings.P_treshold=6.1;
%% Run the GNSS-aided INS
disp('Runs the GNSS-aided INS')
-%out_data=GPSaidedINS(in_data,settings);
-out_data=GPSaidedINS_cycling(in_data,settings);
+out_data=GPSaidedINS(in_data,settings);
+%out_data=GPSaidedINS_cycling(in_data,settings);
%% Plot the data
disp('Plot data')
%plot_data(in_data,out_data,'True');drawnow
-h=zeros(1,3);
+h=zeros(1,2);
figure(2)
plot(in_data.GNSS.pos_ned(2,:),in_data.GNSS.pos_ned(1,:),'b-');
+%plot(out_data.x_h(2,:),out_data.x_h(1,:),'r-');
hold on
h(1)=plot(in_data.GNSS.pos_ned(2,:),in_data.GNSS.pos_ned(1,:),'b.');
-h(2)=plot(out_data.x_h(2,:),out_data.x_h(1,:),'r');
-h(3)=plot(in_data.GNSS.pos_ned(2,1),in_data.GNSS.pos_ned(1,1),'ks');
+h(2)=plot(out_data.x_h(2,:),out_data.x_h(1,:),'-');
+%h(3)=plot(in_data.GNSS.pos_ned(2,1),in_data.GNSS.pos_ned(1,1),'ks');
title('Trajectory')
ylabel('North [m]')
xlabel('East [m]')
-legend(h,'GNSS position estimate','GNSS aided INS trajectory','Start point')
+legend(h,'GNSS position estimate','GNSS aided INS trajectory')%,'Start point')
axis equal
grid on
+%plot control signal P and control action turn
+h=zeros(1,2);
figure(3)
hold on
-plot(out_data.P)
-plot(out_data.turn)
\ No newline at end of file
+h(1)=plot(out_data.P_store);
+h(2)=plot(out_data.turn);
+legend(h,'sum of the trace of P','antenna turned ON')
+grid on
\ No newline at end of file
diff --git a/matlab/run_many_car.m b/matlab/run_many_car.m
new file mode 100644
index 0000000..8542958
--- /dev/null
+++ b/matlab/run_many_car.m
@@ -0,0 +1,48 @@
+%"monteCarlo" example
+
+%% Load data
+disp('Loads data')
+load('GNSSaidedINS_data.mat');
+
+%% Load filter settings
+disp('Loads settings')
+settings=get_settings();
+
+%vector of RGB colors for plotting for the different P references
+color=[[0.7,0.0,0.0];[0.0,0.7,0.0];[0.7,0.0,0.7];[0.0,0.0,0.7];[0.0,0.7,0.7];[0.7,0.7,0.0]];
+%vector of refrences for P
+P_treshold=[4.0,5.0,6.0,8.0,10.0,12.0];
+%nubmer of runs per each P
+n_run=30;
+%allocate memory for output
+energy=zeros(n_run,length(P_treshold));
+error=zeros(n_run,length(P_treshold));
+
+for j=1:length(P_treshold)
+ %set P reference
+ settings.P_treshold=P_treshold(j);
+ %run simulations
+ for k=1:n_run
+ %% Run the GNSS-aided INS
+ disp('Running the GNSS-aided INS')
+ P_treshold(j)
+ k
+ out_data=GPSaidedINS(in_data,settings);
+ energy(k,j)=out_data.energy;
+ error(k,j)=out_data.error;
+ end
+end
+
+
+%plot data
+disp('Plotting data:')
+figure
+hold on
+xlabel('energy')
+ylabel('error')
+title('cycling energy accuracy tracking trade-off')
+grid
+
+for j=1:length(P_treshold)
+ scatter(energy(:,j), error(:,j),20,color(j,:),'o','filled')
+end
\ No newline at end of file
diff --git a/matlab/run_many_cycling.m b/matlab/run_many_cycling.m
index 2ebf28d..7dd04ce 100644
--- a/matlab/run_many_cycling.m
+++ b/matlab/run_many_cycling.m
@@ -6,51 +6,42 @@ load('cycling_input_data');
%% Load filter settings
disp('Loads settings')
-settings=get_settings();
+settings=get_settings_cycling();
+%vector of RGB colors for plotting for the different P references
+color=[[0.7,0.0,0.0];[0.0,0.7,0.0];[0.7,0.0,0.7];[0.0,0.0,0.7];[0.0,0.7,0.7];[0.7,0.7,0.0]];
+%vector of refrences for P
+P_treshold=[4.0,5.0,6.0,8.0,10.0,12.0];
+%nubmer of runs per each P
+n_run=3;
+%allocate memory for output
+energy=zeros(n_run,length(P_treshold));
+error=zeros(n_run,length(P_treshold));
-settings.P_treshold=0.1;
-% %run first simulation
-% out_data=GPSaidedINS(in_data,settings);
-% energy=out_data.energy;
-% error=out_data.error;
-
-
-figure(5)
-hold on
-grid
-color=[[0.7,0.0,0.0];[0.0,0.7,0.0];[0.7,0.0,0.7];[0.0,0.0,0.7]];
-j=1;
-for P_treshold=[5.0,7.0,9.0,11.0]%[2.3,2.8,3.3,3.8,4.3,4.8,5.3,5.8,6.3,6.8,7.3]
- clear energy error
- settings.P_treshold=P_treshold;
- %run first simulation
- out_data=GPSaidedINS_cycling(in_data,settings);
- energy=out_data.energy;
- error=out_data.error;
-% energy=[energy,out_data.energy];
-% error=[error,out_data.error];
- %run more simulations
- for k=1:10
+for j=1:length(P_treshold)
+ %set P reference
+ settings.P_treshold=P_treshold(j);
+ %run simulations
+ for k=1:n_run
%% Run the GNSS-aided INS
disp('Running the GNSS-aided INS')
- P_treshold
+ P_treshold(j)
k
out_data=GPSaidedINS_cycling(in_data,settings);
- energy=[energy,out_data.energy];
- error=[error,out_data.error];
+ energy(k,j)=out_data.energy;
+ error(k,j)=out_data.error;
end
- %plot data
- scatter(energy, error,40,color(j,:),'o','filled')
- xlabel('energy')
- ylabel('error')
- %title(['P treshold = ', num2str(P_treshold)])
-
- j=j+1;
end
-% %plot data
-% figure(2)
-% scatter(energy, error)
-% xlabel('energy')
-% ylabel('error')
-% grid
+
+
+%plot data
+figure
+hold on
+xlabel('energy')
+ylabel('error')
+title('cycling energy accuracy tracking trade-off')
+grid
+
+for j=1:length(P_treshold)
+ scatter(energy(:,j), error(:,j),20,color(j,:),'o','filled')
+end
\ No newline at end of file
diff --git a/paper/sections/06-results.tex b/paper/sections/06-results.tex
index 97a6cc2..3370930 100644
--- a/paper/sections/06-results.tex
+++ b/paper/sections/06-results.tex
@@ -84,47 +84,113 @@ Last simulation of this part of the section shows how the model captures the los
\end{figure}
This last simulation points out also one limitation of the proposed model. In fact theoretically if the satellite that appears again after the loss of visibility was one of the two that previously disappeared the device would not need to re-acquire the ephemeris data, having still in memory the ones acquired at the start up and being those still valid. But to capture this we would have to describe separately the acquisition of the signal and ephemeris data of the different satellites, together with their visibiliy. This apparently would increase the complexity of the model and decrease it usability\footnote{An extension of the model to include also this phenomenon would't be very difficult. It would be sufficient to have parallel state machines similar to the one shown in figure~\ref{fig:cyberdynamics} that independently capture the tracking of the different satellites. Some more adjustments would of course be needede but the basic idea would still hold.}.
-------------------------------------------------
-\subsection{Power Consumption Accuracy Trade Off}
+
+\subsection{Tracking Performance and Power Consumption Accuracy Trade Off}
\label{sec:res:tradeoff}
+In this section, we use real traces recorded from an IMU sensor (accelerometer and gyroscope) and a GPS receiver in two different conditions: when moving by car and by bicycle. Traces with continuous sampling of GPS have been recorded and then different GPS sensor dynamics have been simulated in order to compare different sampling policies and GPS dynamics. We show the tracking performed by the sampled sensor fusion algorithm compared to the continuous sampling of the GPS. We then use simulations to expose the trade off between power consumption and accuracy in both cases.
+
+\begin{figure}[h]
+ \begin{center}
+ \includegraphics[height=0.70\columnwidth, width=0.90\columnwidth]{images/cycling_trace.png}
+ \caption{Tracked trace when cycling. The sampled sensor fusion algorithm is compared to the one using all the avaiable GPS measurements.
+ \label{fig:cycling-trace}
+ }
+ \end{center}
+\end{figure}
+
+\begin{figure}[h]
+ \begin{center}
+ \includegraphics[height=0.70\columnwidth, width=0.90\columnwidth]{images/car_trace.png}
+ \caption{Tracked trace when driving a car. The sampled sensor fusion algorithm is compared to the one using all the avaiable GPS measurements.
+ \label{fig:car-trace}
+ }
+ \end{center}
+\end{figure}
+
+Figures~\ref{fig:car-trace} and~\ref{fig:cycling-trace} show part of the traces generates respectively for the tracking of the car and the bike. In general the cycling trace exposes more complex dynamics that are tracked with more difficulty by the sensor fusion algorithm. Specifically we can see how the lower sampling of the GPS can still guarantee some form of tracking, whether this is acceptable or not it will be dependant on the specific application\footnote{This is also a basic implementation of a sensor fusion algorithm, better performances in terms of tracking could be achieved with more advanced versions of it and better quality IMU sensors. In any case this is not part of the discussion here.}.
+%\footnote{The reader might argue that the sensor fusion algorithm for the cycling data is even less performing than the pure GPS track. This is due to the fact that the algorithm here implemented is quite simple and for instance doesn't bound in any way the possible movements of the bike. We chosed instead this implementation since it provides more expressive figures, the same considerations would hold.}
+From the same simulations we show also plots of the signal used for the triggering of the GPS (i.e. the sum of the trace of $P$) toghether with the state of the GPS antenna. Those are shown in figure~\ref{fig:cycling-control} for the cycling trace and~\ref{fig:car-control} for the car trace. Those figures show how the sampling is able to keep bounded the variance of the estimation while reducing the time that the antenna spends being turned on.
-\textcolor{red}{In order to compare different sampling policies and GPS dynamics, traces with continuous sampling of GPS have been recorded and then different GPS sensor dynamics have been simulated.}
+\begin{figure}[h]
+ \begin{center}
+ \includegraphics[height=0.70\columnwidth, width=0.90\columnwidth]{images/cycling_control.png}
+ \caption{Control signal and control action for the triggering of the GPS sensor in the cycling trace.
+ \label{fig:cycling-control}
+ }
+ \end{center}
+\end{figure}
-In this section, we use real traces from an IMU sensor and a GPS
-receiver in two different conditions: car, and bicycle. In both cases,
-we recorded measurements for the entire duration of the trace with
-both devices. We show the accuracy of the IMU, compared to the GPS
-trace (which the sensor fusion algorithm considers to be the ground
-truth). We expose the trade off between power consumption due to the
-GPS antenna being turned on and accuracy in both cases. Expectation:
-in the bike trace, the IMU sensor trace is more noisy.
+\begin{figure}[h]
+ \begin{center}
+ \includegraphics[height=0.70\columnwidth, width=0.90\columnwidth]{images/car_control.png}
+ \caption{Control signal and control action for the triggering of the GPS sensor in the car trace.
+ \label{fig:car-control}
+ }
+ \end{center}
+\end{figure}
-Figures (both bike and car) with the accuracy ``areas''.
+%\subsection{Simulation of Ranging Data Loss}
+%\label{sec:res:vis}
-\subsection{Simulation of Ranging Data Loss}
-\label{sec:res:vis}
+%Simulation of what happens if ``lose visibility'' transition is taken
+%from time to time on one of the two traces above.
-Simulation of what happens if ``lose visibility'' transition is taken
-from time to time on one of the two traces above.
+%\subsection{Simulation Results}
+%\label{sec:res:sim}
+
+Finally we run a large number \todo{specify} of simulations with different triggering thresholds of $P$ \todo{specify}. The idea is that higher values of P will guarantee less power consumption at the price of lareger errors in the estimation and vice versa. In the simulations the acquisition time of the satellites signals is modeled as a random variable uniformly distributed. Moreover, while in the simulations with the cycling data the number of visible satellites is constant, in the ones with the car data it randomly changes\footnote{Specifically when the number of visible satellites is a given number there is some probability at every time step that t increases or decreases by one, always bounded betwen 3 and 6 in any case.}. The overall error of a tracking trace is here defined as the root-mean-square of the distance between the trace and the pure GPS signal.
+
+\begin{figure}[h]
+ \begin{center}
+ \includegraphics[height=0.60\columnwidth, width=0.80\columnwidth]{images/cycling_trade_off.png}
+ \caption{Power-tracking error trade off with the cycling data.\todo{fix error}
+ \label{fig:cycling-trade-off}
+ }
+ \end{center}
+\end{figure}
+
+Figure~\ref{fig:cycling-trade-off} shows the simulation results for the cycing tracking. The different colors of the points correspond to the different values for the triggering threshold of the sensor fusion algorithm. We can see that the trade-off is present and well controlled through the choice of the threshold. Furthermore two other interesting phenomena are pointed out by this simulation.
+
+For low triggering values (red, green and purple points) there is less variance in terms of error since we are converging to the situation of the antenna being always turned on and therefore saturating the achievable tracking precision. Instead the variance in terms of energy consumption increases due to the sensor being more frequently turned on and off and threfore being affected by the random time required to fetch the satellites' signals.
+
+Looking at higher triggering values instead (blue, light blue and yelow points) opposite behavior is experienced. There is smaller variance in terms of power consumption since the antenna is turned on less frequently and there will be less uncertainty on how much time is overall spent while fetching the signal. Insterad the error becomes both lager and with higher variance due to the necessity of using more the IMU data that are less reliable.
+
+\begin{figure}[h]
+ \begin{center}
+ \includegraphics[height=0.60\columnwidth, width=0.80\columnwidth]{images/car_trade_off_zoomout.png}
+ \caption{Power and tracking-error trade off with the car data.
+ \label{fig:car-trade-off}
+ }
+ \end{center}
+\end{figure}
+
+Finally figure~\ref{fig:car-trade-off} shows the simulations performed using the car data. Given the introduction of a varying number of visible satellites and therefore the possibility of losing GPS availability the possible behaviors of the system become much more various. Specifically they seem to spread radially away from the origin. 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 re-aquire the ephemeris data. If, as shown in figure~\ref{fig:car-trade-off-zoom}, we zoom in the lower part of the plot we can see that the same behavior as the one described for the cycling data is evidenced.
+
+\begin{figure}[h]
+ \begin{center}
+ \includegraphics[height=0.60\columnwidth, width=0.80\columnwidth]{images/car_trade_off_zoomin.png}
+ \caption{Zoom on the lower part of the power and tracking-error trade off with the car data.
+ \label{fig:car-trade-off-zoom}
+ }
+ \end{center}
+\end{figure}
-\subsection{Simulation Results}
-\label{sec:res:sim}
-Power-accuracy trade-off: Montecarlo simulations. Characteristics:
-\begin{itemize}
-\item We generate 10000 traces, 60 minutes long.
-\item For each point in each trace, we randomly extract from
- probability distributions the visibility of satellites. We also
- randomize the time to fetch signals.
-\item Figure comparing clouds of points with only GPS and GPS+IMU in
- the axis \emph{accuracy} (sum of distances from the ideal GPS trace)
- and \emph{power consumption} (due to antenna).
-\end{itemize}
+%Power-accuracy trade-off: Montecarlo simulations. Characteristics:
+%\begin{itemize}
+%\item We generate 10000 traces, 60 minutes long.
+%\item For each point in each trace, we randomly extract from
+% probability distributions the visibility of satellites. We also
+% randomize the time to fetch signals.
+%\item Figure comparing clouds of points with only GPS and GPS+IMU in
+% the axis \emph{accuracy} (sum of distances from the ideal GPS trace)
+% and \emph{power consumption} (due to antenna).
+%\end{itemize}
-To show how the proposed model joined with the sensor fusion algorithm allows to capture the trade-off betwen accuracy and power consumption we run simulations for different treshold values for triggering the sampling of the GPS. Coherently with the intuition, we can see that higher values for the treshold allow to save power at the cost of lower precision in the positioning. The accuracy is measured as the distance from the positioning that uses the GPS continuously.
+%To show how the proposed model joined with the sensor fusion algorithm allows to capture the trade-off betwen accuracy and power consumption we run simulations for different threshold values for triggering the sampling of the GPS. Coherently with the intuition, we can see that higher values for the threshold allow to save power at the cost of lower precision in the positioning. The accuracy is measured as the distance from the positioning that uses the GPS continuously.
-In these simulations the GPS model exposes a random acquisition time for the fetching of the ephemeris data, drawed for a uniform distribution between \textcolor{red}{2 and 12 milliseconds}. Also the number of satellites is randomized as in the previous simulations.
+%In these simulations the GPS model exposes a random acquisition time for the fetching of the ephemeris data, drawed for a uniform distribution between \textcolor{red}{2 and 12 milliseconds}. Also the number of satellites is randomized as in the previous simulations.
--
GitLab