Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
G
gps-modeling
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container registry
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
GitLab community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Martina Maggio
gps-modeling
Commits
32121d74
Commit
32121d74
authored
Sep 25, 2018
by
Martina Maggio
Browse files
Options
Downloads
Patches
Plain Diff
result section sketch
parent
d8e28470
No related branches found
No related tags found
No related merge requests found
Pipeline
#650
failed
Sep 25, 2018
Stage: build
Stage: test
Changes
1
Pipelines
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
paper/sections/06-results.tex
+51
-0
51 additions, 0 deletions
paper/sections/06-results.tex
with
51 additions
and
0 deletions
paper/sections/06-results.tex
0 → 100644
+
51
−
0
View file @
32121d74
\subsection
{
GPS sensor dynamics
}
\label
{
sec:res:gps
}
First-principle analysis of GPS dynamics:
\emph
{
time to first
fix
}
. Comparison with empirical analysis from the state of the art
(check that numbers match the python-nokia implementation or whatever
else is available). Implementation issues with existing solutions
(there are some unjustified delays -- probably introduced by the
software and software bugs -- that could be eliminated).
Additionally, decribe
\emph
{
phenomena
}
like loss of ephemeris and
randing data and what are the delays introduced because of that. Say
that losing the ephemeris data means basically having the GPS receiver
turned off for ``too long'' and losing the ranging data is mostly
equivalent to a worst case in losing visibility of the satellites. If
you want to distinguish, you can have a finite state machine for each
satellite.
\subsection
{
Power Consumption Accuracy Trade Off
}
\label
{
sec:res:tradeoff
}
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.
Figures (both bike and car) with the accuracy ``areas''.
\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.
\subsection
{
Simulation Results
}
\label
{
sec:res:sim
}
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}
\ No newline at end of file
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment