See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/307530246

GEMMA: A GENERIC, EXTENSIBLE AND MODULAR MULTI-SENSOR

NAVIGATION ANALYSIS SYSTEM

Article in ISPRS Annals of the Photogrammetry Remote Sensing and Spatial Information Sciences · June 2016
DOI: 10.5194/isprsannals-III-3-433-2016

CITATION READS

1 147

3 authors:

José Navarro M.Eulàlia Parés Calaf

CTTC Catalan Telecommunications Technology Centre CTTC Catalan Telecommunications Technology Centre
49 PUBLICATIONS 263 CITATIONS 47 PUBLICATIONS 404 CITATIONS

SEE PROFILE SEE PROFILE

Ismael Colomina

114 PUBLICATIONS 3,512 CITATIONS

SEE PROFILE

All content following this page was uploaded by Ismael Colomina on 21 September 2018.

The user has requested enhancement of the downloaded file.

 ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume III-3, 2016
XXIII ISPRS Congress, 12–19 July 2016, Prague, Czech Republic

GEMMA: A GENERIC, EXTENSIBLE AND MODULAR MULTI-SENSOR NAVIGATION

ANALYSIS SYSTEM

J. A. Navarroa,∗, M. E. Parésa,* , I. Colominab

a
CTTC, Av. Carl Friedrich Gauss 7, 08860 Castelldefels, Spain - (jose.navarro, eulalia.pares)@cttc.es
b
GeoNumerics S.L., Av. Carl Friedrich Gauss 11, 08860 Castelldefels, Spain - [email protected]

ICWG III/I

KEY WORDS: Trajectory determination systems, Research toolset, Navigation, Sensor orientation

ABSTRACT:

This paper presents the concept of an architecture for a system that helps researchers in the field of Geomatics to speed up their
daily research on kinematic geodesy, navigation and positioning fields. The presented ideas correspond to an extensible and modular
software system aimed at the development of new navigation and positioning algorithms as well as at the evaluation of the performance
of sensors. The concept, already implemented in the CTTC’s system GEMMA is generic and extensible. This means that it is possible
to incorporate new navigation algorithms or sensors at no maintenance cost. Only the effort related to the development tasks required
to either create such algorithms or model sensors needs to be taken into account. As a consequence, change poses a much smaller
problem for CTTC’s research activities is this specific area. This system includes several standalone tools that may be combined in
different ways to accomplish various goals; that is, it may be used to perform a variety of tasks, as, for instance, (1) define positioning
and navigation scenarios, (2) simulate different kinds of sensors, (3) validate new navigation algorithms or (4) evaluate the quality of
an estimated navigation solution.

1. INTRODUCTION process constitutes a challenge (for instance, from the software

engineering standpoint) for the research activities in this area.
Nowadays, the research community is constantly developing new
Nowadays, researchers have at their hand a wide range of help-
positioning and navigation algorithms. These algorithms aim at
ful tools (either proprietary, free or open source). However, these
the determination of precise, accurate and robust trajectories. By
have been conceived to perform rather specific tasks and not as
trajectory we mean a path of an stochastic process; that is, it is one
components of a larger (tool) ecosystem. It is possible, for in-
of the many time series realizations of an stochastic process. In
stance, to find MATLAB R code to generate synthetic trajecto-
the context of this paper, a trajectory is a time series of positions,
ries (Ahmadzadeh, 2015), signal (IFEN, 2015) and measure-
velocities and attitudes of a moving object plus the calibration
ment (MathWorks, 2015) generators or reliable and widely known
parameters of the instruments used to determine these as well as
trajectory determination and analysis systems like the Applanix
the estimated covariances of all the aforementioned values.
or the Waypoint ones. Unfortunately, and in spite of (and be-
cause of) this availability of tools, researchers will have to cope
The navigation research community is currently dealing with two
with problems as data format incompatibilities or, in the worst
challenges: new technologies and their use in new applications.
case, develop a full trajectory determination system when new
New sensors, able to provide data suitable for geoapplications,
algorithms need to be implemented.
appear constantly in the market. As stated in (Groves et al.,
2014a, Groves et al., 2014b), technology has to deal with new This paper presents the concept of an architecture for a system
sensors—like plenoptic or photon-mixing cameras—, new per- whose target is to provide a reliable framework where research
formances—like the inertial sensors found in smartphones—and related to positioning, navigation and sensor modelling may take
new environments—like indoor or urban canyons. Furthermore, place. The goal of such system is to become the basic toolset for
there are still many issues to solve concerning the achievement of researchers in these areas, avoiding the need to start anew each
target precision, accuracy and reliability in the realm of position- time a new project begins or, thanks to some of the tools included
ing and navigation. The following are some examples: for mo- in this architecture, not having to organize and execute costly data
bile mapping purposes, GNSS accuracy is almost unachievable acquisition campaigns when (new or not) sensors need to be eval-
due to strong multipath in narrow urban environments (Xie and uated. Additionally, an implementation of the aforementioned
Petovello, 2015); completely autonomous or unattended driven concept and architecture, is presented here: GEMMA (Generic
systems (in aerial, marine or submarine environments) are still Extensible and Modular Multi-sensor navigation Analysis sys-
a wish for the surveying community due to the lack of reliabil- tem).
ity of navigation solutions (Velaga et al., 2012); kinematic air-
borne gravimetry is not able yet to reach the maximum preci- GEMMA is a portable, extensible and modular software system
sion because of the high level of noise present in INS/GNSS sys- aimed at the development of new navigation and positioning algo-
tems (Skaloud et al., 2015). rithms as well as at the evaluation of the performance of sensors.
It has been conceived as a research toolset useful in laboratory en-
The examples above define an scenario where continuous and in- vironments (as opposed to workshop or factory ones) (Navarro,
tense research in a steadily changing technological environment 1999).
is taking place. This constant, uninterrupted change and evolution
It is, however, worthy to say, that although GEMMA is not a com-
∗ Corresponding authors. mercial product, the team in charge of its design and implementa-

This contribution has been peer-reviewed. The double-blind peer-review was conducted on the basis of the full paper.
doi:10.5194/isprsannals-III-3-433-2016 433
 ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume III-3, 2016
XXIII ISPRS Congress, 12–19 July 2016, Prague, Czech Republic

tion decided to incorporate some characteristics present in prod- scenario being tackled (see section 3. for some examples), only
ucts that are, indeed, commercial ones. For instance, GEMMA a subset of these tools and data flows will be used. For instance,
intends to be a complete toolset or suite, providing an integrated when not working in a real-time environment, the trajectory es-
environment where research tasks and work flows are facilitated; timation tool will not be connected to an acquisition system but
a data abstraction and their corresponding interface has been de- will use logged (pre-recorded) data (measurements), information
vised as well, to avoid impedances between the tools integrating coming from one or more of the available signal generators, or
this suite, since the need of file converters is noticeably reduced; both.
a batch interface exists, making possible the automation of repet-
itive tasks, while a—still very immature— graphic interface has
been included to ease the interaction with end-users (researchers).
In short, the essential traits (as scientific rigour) that are a must in
a software toolset targeted at research have been complemented
with other characteristics usually present in commercial systems.

Section 2. describes the architecture (and components) of GEM-

MA from the conceptual and implementation standpoints (show-
ing how the GEMMA system materializes the concept). Sec-
tion 3. details how this system may be used in different scenarios
(use-cases or work flows).

2. CONCEPT AND ARCHITECTURE

The architecture (and components) of a framework willing to pro-

vide with a useful set of tools and procedures to facilitate the re-
search tasks related to a specific set of disciplines may obviously
vary depending on the actual experience of the people involved
first in its inception and, later on, in its design and implementa- Figure 1: GEMMA components and work flow
tion stages. This paper presents, therefore, the view of its authors,
view that has been heavily influenced by their participation in a
series of projects where the framework discussed here played a The following sections describe briefly the different components
key role. Nonetheless, after several years of being put to the test, of the architecture and show how GEMMA implemented these.
the implementation of the architecture discussed below has been
2.1 Trajectory Generation
able to cope with all the challenges faced up to the moment.
The ultimate goal of the trajectory generator tool is to create ref-
The components included in a positioning and navigation research
erence trajectories to compare with when these do not exist or it
framework should be able to offer, at least, the following set of
is too expensive to obtain them—for instance, flying a real plane.
features:
Strictly speaking, this tool is not about fully trajectory genera-
tion but about trajectory densification. Given a set of way points
• Generation (densification) of realistic trajectories for any
(time-tagged positions, and eventually attitudes) an infinite num-
kind of platform: from spacecrafts, to aerial, terrestrial or
ber of trajectories can be derived. The tool should be able to
marine vehicles, or even alive organisms;
produce a dense realistic trajectory including not only the previ-
• simulation of signals (measurements) for several types of
ous way points but a much more extensive list of them as well as
sensors, as, for instance, IMUs or GNSS receivers,
related velocities and orientations. Figure 2 depicts a densified
• sequencing of sensor measurements,
trajectory using a few way points.
• trajectory estimation and
• (trajectory) quality assessment.

Each of the features (and related tools) in the list above is impor-
tant by itself. For instance, the ability to generate and densify tra-
jectories avoids having to obtain such trajectories by other meth-
ods; when signal (measurement) generators are available, there
is no need to organize data collection campaigns. In short, these
tools help to save time and reduce costs, thus facilitating the work
of researchers. However, it is the combination of different sub-
sets of these features (tools) what reveals the versatility of the
concept, and how it responds to different research use cases (see
section 3.).

GEMMA implements these features, providing a tool for each of Figure 2: Example of a densified trajectory
them. In particular, it includes four signal generators, for IMUs,
magnetometers, odometers and GNSS receivers.
In order these trajectories to be as realistic as possible they should
Figure 1 depicts all the features just discussed (implemented as a be continuous and infinitely derivable. Moreover, since not all
set of tools in the GEMMA system). Additionally, all the possi- the vehicles (platforms) follow the same dynamic equations, the
ble data flows between these are shown. Depending on the actual tool should be designed in such a way that the densification of

This contribution has been peer-reviewed. The double-blind peer-review was conducted on the basis of the full paper.
doi:10.5194/isprsannals-III-3-433-2016 434
 ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume III-3, 2016
XXIII ISPRS Congress, 12–19 July 2016, Prague, Czech Republic

the way points and the related orientation definition adhere to the
specific dynamics of the selected platform. This translates into an
extensible software component where the densification process is
independent of the selected vehicle dynamics.

For versatility (and flexibility) reasons, the generator must be able

to accept way points generated by different sources, as for in-
stance, KML files or trajectories output by (realistic) flight simu-
lators—file format converters may be needed to do so. The pa-
rameters controlling the behaviour of the tool (as the output fre-
quency) must be also configurable by the user.

GEMMA includes a trajectory generation tool complying with Figure 3: Example of output of an IMU signal generation tool
the functional requirements discussed above. Specifically, it is
able to achieve the infinitely derivable position and orientation
At the moment of writing this paper, GEMMA includes four
by convolving with a C ∞ function and later on interpolating the
types of signal generators fully compliant with the functional de-
resulting trajectory at the rate selected by the user; the realistic
scription above, namely odometers, magnetometers, GNSS re-
orientation for different platforms is obtained from the dynamics
ceivers and IMUs (Parés et al., 2015). Others may be included in
formulas of those vehicles (Rajamani, 2011, Roskam, 1995).
the future when needed. A hardware GNSS simulator, the IFEN
2.2 Signal Generators NavX-NCS PROFESSIONAL GNSS simulator (IFEN, 2015), is
also part of the system.
A (software) signal1 generator simulates the observations that
It is important to highlight that there exist nowadays many signal
would have been delivered by a sensor if it would have actually
generators in the market for a variety of sensors—see (Ebinuma,
been used in a real campaign.
2015) and (Nievinski and Larson, 2014) for two examples of
Signal generators take as input a reference trajectory—however available GNSS simulators or (Yang et al., 2007) and (Yan et
obtained—and use the models defining the behaviour of the sen- al., 2015) for IMU ones. In spite of this availability, the team
sor these mimic to deliver the simulated observations. Note that in charge of the development of GEMMA decided to implement
these models must include the errors affecting the sensors, so its own signal generators.
output data mirrors this defective behaviour.
The extra cost of developing tools that already exist in the market
Errors may correspond to various stochastic processes (as random is justified by several reasons that were deemed strategic. First,
walks, white noise or Gauss-Markov ones). Additionally, errors an in-house development allows for a higher degree of freedom
may be originated by different sources, as the instrument itself, when implementing a sensor simulator; additionally, it is possi-
the environment (temperature, magnetic fields, humidity among ble to incorporate any kind of error models that other tools might
many others) or the platform the instrument is mounted on (ve- have not considered; moreover, the data formats used by in-house
hicles, human or animal carriers). These kinds and sources of developments may be GEMMA’s own, reducing the data con-
errors must be taken into account by a signal generator so reality version steps needed to make data suitable for other tools in the
is properly mirrored. toolset; last, but not least, it is possible to design these generators
in such a way that these may be integrated in batch production en-
Signal generators may be either software or hardware compo- vironments (to avoid the unnecessary repetition of routine tasks)
nents and the presented architecture makes no distinctions be- and, at the same time, include a user-friendly graphic interface fa-
tween these. Software components, apparently, are less prone to cilitating the interaction between the researcher and the tool when
obsolescence since it is possible to include new features just by required.
maintaining the code.
2.3 Sequencer
There are different situations where the use of such generators
prove to be useful. These are some, among others: The goal of the sequencer is to sort a series of heterogeneous ob-
servations in ascending time order. In this context, heterogeneous
stands for originating in different kinds of sensors. The need to
• To check how the quality of an estimated trajectory is im- sort input data is motivated by the fact that the estimation of the
proved by incorporating a sensor that is not available—but successive values of the states integrating a trajectory is based on
correctly modelled. the use of observations that are close in time.
• To select the appropriate quality of a sensor according to the
requisites that the estimated navigation solution must meet. A sequencer takes as input a series of files or TCP/IP (Trans-
For instance, a tactical grade GNSS receiver may not be nec- mission Control Protocol / Internet Protocol) socket connections
essary in all situations. containing or transmitting time-tagged observations measured by
different sensors and outputs a single stream of data including
these same observations conveniently sorted. This output stream
For instance, Figure 3 shows the behaviour of two different IMUs
may be either written to a file (for local, batch processing) or sent
travelling along the same reference trajectory. Purple data cor-
through a TCP/IP socket connection (remote, batch processing).
responds to a low-cost IMU unit while the green bar represents
how a navigation-grade IMU behaves. The different responses of When processing data received through TCP/IP socket connec-
these two sensors are easily identifiable. tions, the signal generator must be able to discard data whose
1 The words signal, measurement and observation are incorrectly used time tag is prior to the current time being processed. A time tol-
as synonyms here for the sake of simplicity. For instance, in some situa- erance parameter to decide if such data is accepted in spite of
tions, additional processing may be needed to obtain a measurement out being too old is a very convenient feature to have; normally, read-
of a signal, but such distinction is not made in this paper. ing data through network connections imply real-time processing

This contribution has been peer-reviewed. The double-blind peer-review was conducted on the basis of the full paper.
doi:10.5194/isprsannals-III-3-433-2016 435
 ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume III-3, 2016
XXIII ISPRS Congress, 12–19 July 2016, Prague, Czech Republic

and, in this situation, some delays or shifts related to time stamps of vehicle used (airplane, helicopter, terrestrial vehicle, to
are to be expected. Therefore, such a tolerance parameter may mention some) imposes a very different set of constraints
be used to alleviate these discordances. Obviously, the trajectory on what kind of trajectories are possible. For instance, sud-
estimation tool (see section 2.4) must be able to cope with such den changes in the direction of movement are possible when
non-perfectly time-sorted stream of data for this feature to be of equipment is carried by people, while airplanes are not able
any use at all. to do so. A trajectory determination system should be aware
of these limitations that depend on the context, either be-
GEMMA includes a sequencer tool implementing almost all the cause it has been informed by the user or being able to deter-
features described above. The only limitation is that it is only able mine these by itself when no information is available. This
to accept input data stored in files (network input is not yet ac- is the task of the computational strategy object. This compo-
cepted), so the discussion related to time tolerances do not apply nent must be able to determine—depending on the context it
here. The ability of the sequencer to send its output through a net- is working in—whether there is enough information to com-
work connection opens the way to distributed research, which has pute a solution and what to do when the answer is negative—
been put into practice in several projects, as ATENEA (Fernández as for instance, deliver a partial solution or just warning
et al., 2011): observation data is obtained in one place, sequenced about its inability to proceed. The computational strategy
there, and sent via sockets to a second place, where it is pro- object must be independent from the estimation (“number
cessed. crunching”) engine; this approach allows for the combina-
2.4 Trajectory Estimation tion of different sensor models and environments (contexts)
at no (source code) maintenance cost.
The goal of this tool is to estimate trajectories (navigation solu-
tion) out of a series of time-sorted, heterogeneous sensor obser- The channels used for input (observations) and output (trajecto-
vations. ries) data must be selectable freely; that is, any combination of
New sensors—the source of observations—appear constantly in file or TCP/IP sockets data channels for input or output must be
the market and old ones are improved or modified. To cope with possible. In this way, it is possible to use the trajectory estimation
constant change and innovation, a trajectory estimator should be tool in a wide variety of scenarios. For instance, it may work as a
designed to be a generic and extensible tool, so the heavy toll real time (navigation) data logger using sockets on input and files
that should be paid in terms of software maintenance due to such on output; if both input and output channels are TCP/IP sockets,
evolution may be avoided. To do so, the following principles then the tool works as a real-time navigation system. Using files
should be the cornerstones on which a tool like this should rely: in both channels transforms the trajectory estimator into a batch
tool.
• Separation of estimation and modelling. The tool must sepa- NAVEGA (Parés and Colomina, 2015) is the trajectory estima-
rate the estimation—“number crunching”—engine from the tion component included in GEMMA. It has been designed ac-
data being used and its relations. This allows a quick ex- cording to the principles described above. In short, the most im-
tension of the software when new sensors appear. When portant features of NAVEGA are:
the tool starts, it must load the components related to the
intervening sensors as well as some mission-related states.
These components, whatever they are, must not affect how • Robust trajectory estimation,
the computational kernel (the estimation engine) behaves. • using a geodetic approach, that is able to
In this way, the inclusion of new sensors imply the devel- • perform multi-sensor navigation,
opment of only relatively small fragments of code that are • detecting and isolating faults,
materialized as the aforementioned loadable components. • running either in real-time or batch environments, and that
• Rigorous data modelling. Data must be modelled to repre- • is available for the most common operating systems.
sent the essential traits defining the four entities identified as
key players in the positioning and navigation realm: (input) Currently, the number crunching engine of NAVEGA includes a
measurements, (input) auxiliary instrument constant values, family of Kalman filter algorithms and provides with Gaussian
(output) states and (equation) models relating all those ele- states, this is, the output are expected values and covariance ma-
ments. The abstraction must therefore be generic and able trices. Furthermore, it also provides the user with expected resid-
to manage, at the same time, the variety of available sen- uals and standard deviation values, suitable for a posteriori tra-
sors. Relying in a rigorous data model implies that the im- jectory analysis (see section 2.5).
plementation or maintenance of sensor models may bene-
fit of code reuse and object-orientation techniques—and its The extensibility of NAVEGA has been proven processing data
encapsulation, inheritance and polymorphism mechanisms. provided by several types of sensor like IMUs (Molina et al.,
This leads to a substantial simplification of the system and 2012b), GNSS (Silva et al., 2011), redundant IMUs (Molina et
much shorter times to implement new sensors, measurement al., 2012b), LIDAR (Montaño et al., 2015), camera images (An-
and state models in the software. gelats et al., 2014) and odometers (Angelats et al., 2011). NA-
• Generic and adaptable interface. The input / output inter- VEGA is validated using indirect methods—because not all the
face of the trajectory estimator must mirror the data abstrac- sensor models implemented are available in commercial systems.
tion process just stated, so the inclusion of new sensors im- When NAVEGA is used as a position provider (remote sensing
plies no changes in the way data are handled. To enable platforms, as photogrammetric systems for instance), its output
either batch or real-time processing, at least two data in- is compared with topographic measurements, which, up to now,
terfaces should be defined: file and network—this last one have served to show the success of this software component; that
based on TCP/IP sockets. is, the actual and predicted state errors match, or, in short, the ex-
• Computational strategy object. Sensors (equipment) are not pected quality is achieved. NAVEGA has also been successfully
the only factor affecting the quality of a navigation solu- used for processing data collected in a wide range of environ-
tion. Environmental conditions must also be taken into ac- ments: airplanes, helicopters (Molina et al., 2012b) and terrestrial
count (Groves et al., 2014a, Groves et al., 2014b); the kind vehicles, either outdoors and indoors (Angelats et al., 2011).

This contribution has been peer-reviewed. The double-blind peer-review was conducted on the basis of the full paper.
doi:10.5194/isprsannals-III-3-433-2016 436
 ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume III-3, 2016
XXIII ISPRS Congress, 12–19 July 2016, Prague, Czech Republic

Regarding robustness issues, NAVEGA’s implemented analysis

tools are able to deal with odometers and camera outliers. When
working with GNSS modelling, the system is able to detect out-
liers when these affect just one satellite. At this moment, more
than one outlier cannot be properly detected.

Integrability is also a fact. It has been used in the framework

of several projects as a location provider of different services,
like mobile mapping systems (Fernández et al., 2011) or a GNSS
receiver with tight coupling capabilities (Silva et al., 2006).

The use of NAVEGA in the aforementioned examples served to

verify that this component is not only available for a wide range
of platforms but also that its performance suits the needs of these.
For instance, NAVEGA is able to process INS/GNSS solutions at
5000 Hz in real time when running on an Odroid-XU3 (HardKer-
nel, 2015) with a negligible latency.

Finally, but no less important, the dual interface of the system Figure 4: Quality plot from the analyser tool
(file and GUI) makes NAVEGA suitable for both Kalman filter
experts and inexperienced users as well.
• Technology selection or validation.
2.5 Analyser • Algorithm verification and validation.
• Navigation and positioning in real-life environments.
The last tool in the system is the trajectory analyser. As its name
indicates, the aim of this tool is to perform several quality analysis The following sections describe these use cases and the role that
over an estimated trajectory. The main features it should include play the different components of the toolset in each of these sit-
are: uations. All the presented use cases have been successfully ad-
dressed with GEMMA.
• Given a reference trajectory, which is considered as the ab- 3.1 Use Case: Technology Selection or Validation
solute truth, the system should be able to “translate” one
trajectory to the other one and to compare them. By “trans- This use case takes into account two possible situations:
lation” we mean to apply the user’s requested offset and
boresight matrix. The analyser should be able to compute
statistics (like, mean, standard deviation and RMSE) fully • It is necessary to select a sensor among a family of these
describing the difference between these, which is the cor- whose quality is good enough—but not necessarily better—
nerstone to assess the quality of the estimated trajectory. to estimate output trajectories that must match some preci-
sion and accuracy requirements. For instance, not all appli-
• Given a reference trajectory, the system should be able not cations need a navigation-grade IMU, but it may be costly
only to compare estimated and reference trajectory as pre- enough to determine what is the actual quality level that will
viously stated but also to check its coherence with the pre- guarantee the required output.
dicted error, and to determine if those last values are under- • Assessment of the quality of a single sensor, that is, deter-
or overestimated. mining whether it is appropriate for the requisites affecting
the estimated trajectory.
Given the residuals or the innovations of an estimated trajectory
the system should be able to determine the stochastic process be- The advantage of using GEMMA in this case is that it is possi-
neath them, and to check if it is coherent with the expected one ble to simulate the signals produced by these sensors and then
(typically white noise). estimate and evaluate, for each candidate, the respective output
trajectories. Needless to say, proper modelling of the behaviour
GEMMA’s trajectory analyser implements all the aforementioned of the intervening sensors is required.
features. Additionally, it is able to produce a series of plots de-
picting some of the statistics discussed above to help to better The components of GEMMA involved in this use case are shown
understand them. in Figure 5. There, those GEMMA components that do not inter-
vene in the use case are shown in pale grey.
Figure 4 is an example of one of these plots: there, the actual
error of an estimated trajectory (comparison between estimated The following would be the typical work flow to follow:
and reference trajectories—in red) and the standard deviation of
the estimator predicted error (in green) are shown. It may be
observed how the estimated and actual errors do not match; thus, • First of all, a reference trajectory is needed to compare it
the trajectory determination system is being optimistic. with the output estimated ones. It may be either syntheti-
cally generated by means of the trajectory generator compo-
nent or taken from any field campaign.
3. USE CASES • The signal generator(s) corresponding to the sensor(s) to
evaluate would then be used to simulate the signals (mea-
A toolset such the one presented in this paper may be used in a surements, observations) that would have been produced if
variety of research use cases, just combining, in different ways, the sensor would have actually travelled along the reference
the components that integrate it. The most usual use cases are: trajectory.

This contribution has been peer-reviewed. The double-blind peer-review was conducted on the basis of the full paper.
doi:10.5194/isprsannals-III-3-433-2016 437
 ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume III-3, 2016
XXIII ISPRS Congress, 12–19 July 2016, Prague, Czech Republic

Figure 5: The technology selection use case. Figure 6: Algorithm verification and validation use case.

• Then the sequencer would time-sort all the observations pro- data collection campaign involving not only a set of trusted sen-
duced by the signal generators. sors—that is, already correctly modelled—but also the new one
• The trajectory estimator component (NAVEGA) would be must take place.
used to estimate the output trajectory, and, finally,
• the quality of the aforementioned trajectory would be as- The reference trajectory must be estimated using only trusted sen-
sessed by the analyser component. sors, so it is a reliable one to compare with (note that Figure 7
describes this procedure). Data coming from the new sensor is
just logged, and will be later used to verify and validate the new
When comparing several sensor candidates to select the most ap- model being developed.
propriate one, the process above should be repeated for every sen-
sor being evaluated. If the goal is just to determine whether a Once the reference trajectory and the new sensor data are avail-
sensor is good enough to fulfil the stated goal (trajectory quality) able, the procedure to follow is:
then a single run should suffice.

A real project where this use case was put to the test was GINSEC 1. Using the sequencer tool, data coming from all the sen-
(Navarro et al., 2015). sors involved in the data collection campaign must be time-
sorted.
3.2 Use Case: Algorithm Verification and Validation 2. The mathematical equations modelling the new sensor must
be written. This, essentially, means filling the gaps in a tem-
It has been stated several times in this paper that GEMMA is plate provided in GEMMA’s developer kit; such template
generic and extensible. This means that new sensors may be in- adheres to the API (Application Programming Interface) de-
cluded into the system—or, those that have been modified, easily fined by the system. In this way, developers need to have
adapted—at almost no cost. no prior knowledge about the internals of GEMMA; their
knowledge may be just limited to sensor modelling
Including a new sensor means writing the mathematical equations 3. A dynamically loadable library is then created and included
modelling its behaviour and generating a loadable library includ- in the GEMMA system.
ing the new model. There is no need to change already existing 4. NAVEGA is used to estimate a new trajectory.
software to make the new model available to GEMMA; that is, 5. The trajectory analyser is then used to compare the reference
when adding new sensors there is no need to maintain, change or trajectory with the newly estimated one, thus assessing its
adapt the existing code base. The new model will be loaded dy- quality.
namically upon request—that is, when data related to such model
is processed.
Steps 2 to 5 may have to be repeated several times until the quality
As it happens to any kind of algorithm, it is necessary to verify of the mathematical model is satisfactory.
and validate new models in order to guarantee their correctness
(that is, the new code contains no bugs) and performance (the new Several projects that took place in the past were clear examples of
sensor is correctly modelled). This is the algorithm verification this use case: GAL (Skaloud et al., 2015), ENCORE (Colomina
and validation use case. et al., 2012) and ATENEA (Fernández et al., 2011).

Figure 6 shows the components in the GEMMA system playing 3.3 Use Case: Navigation and Positioning in Real-life Envi-
a role in this situation (note that, in this figure, those components ronments
not intervening in the process are shown in pale grey).
This is the use case where less components of GEMMA are in-
The sequence of steps to take when verifying and validating a new volved: NAVEGA is used as a standalone tool (see Figure 7). In
algorithm is defined below. A reliable reference trajectory, how- this situation, NAVEGA is used as a real-time trajectory estima-
ever, must be generated beforehand. To create such trajectory, a tor.

This contribution has been peer-reviewed. The double-blind peer-review was conducted on the basis of the full paper.
doi:10.5194/isprsannals-III-3-433-2016 438
 ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume III-3, 2016
XXIII ISPRS Congress, 12–19 July 2016, Prague, Czech Republic

ACKNOWLEDGEMENTS

The research reported in this paper started around eight years

ago at the former Institute of Geomatics and has been funded by
means of several European projects. We would like to highlight
IADIRA, ATENEA, ENCORE, CLOSE-SEARCH, GAL and GIN-
SEC.

REFERENCES

Ahmadzadeh, R., 2015. Trajectory gener-

ation (3rd & 5th orders). http://www.
mathworks.com/matlabcentral/fileexchange/
40278-trajectory-generation--3rd---5th-orders-.
Accessed: 24 November 2015.

Angelats, E., Molina, P., Parés, M. E. and Colomina, I., 2014. A

parallax based robust image matching for improving multisensor
navigation in GNSS-denied environments. In: Proceedings of the
Figure 7: Real-time environments use case. 27th International Technical Meeting of The Satellite Division of
the Institute of Navigation (ION GNSS+ 2014), Tampa, USA,
pp. 2132–2138.
Loaded with the appropriate set of models (those characterizing
the sensors integrating an external acquisition system) NAVEGA Angelats, E., Parés, M. E. and Colomina, I., 2011. Methods,
might be used as a real-time server providing successive position algorithms and tools for precise terrestrial navigation.
and attitude values to some other subsystem(s). For instance, an
autopilot system might decide to delegate the task of positioning Colomina, I., Miranda, C. and Parés, M. E., 2012. Galileo’s sur-
the aircraft to NAVEGA, feeding this component with data com- veying potential. GPS World.
ing from the different sensors on board, instead of performing
this process itself. The GINSEC project (Navarro et al., 2015) is Ebinuma, T., 2015. GPS-SDR-SIM. https://github.com/
an example of this approach, where an implementation of a posi- osqzss/gps-sdr-sim. Accessed: 21 March 2015.
tioning server inspired by NAVEGA was installed on a low-end
board. Of course, other subsystems in need of georeferencing in Fernández, A., Diez, J., de Castro, D., Dovis, F., Silva, P., Friess,
real-time may benefit from such positioning server concept. P., Wis, M., Colomina, I., Lindenberger, J. and Fernández, I.,
2011. ATENEA: Advanced techniques for deeply integrated
A variation of the example above would compute position and at- GNSS/INS/LiDAR navigation. In: Proceedings of the 24th Inter-
national Technical Meeting of The Satellite Division of the Insti-
titude in real-time but log these data to permanent storage instead.
tute of Navigation (ION GNSS), Portland, OR, USA, pp. 2395–
This situation is typical in post-processing environments, when
2405.
higher accuracy and precision are required. Processing the data
collected with NAVEGA by means of techniques as PPP (Point Groves, P. D., Wang, L., Martin, H. and Voutsis, K., 2014a. To-
Precise Positioning) would improve the quality of the estimated ward a unified PNT - Part 1, complexity and context: Key chal-
trajectory to the level required by professional applications (as lenges of multisensor positioning. GPS World 25(10), pp. 18–49.
network bundle adjustment, for instance).
Groves, P. D., Wang, L., Martin, H. and Voutsis, K., 2014b. To-
The project CLOSE-SEARCH (Molina et al., 2012a) is a typical ward a unified PNT - Part 2, ambiguity and environmental data:
example of this use case. Two further key challenges of multisensor positioning. GPS
World 25(11), pp. 18–35.
4. CONCLUSIONS HardKernel, 2015. Odroid XU3 — Hardkernel.
http://www.hardkernel.com/main/products/prdt_
GEMMA is not only a concept but also a real, seasoned, research- info.php?g_code=G140448267127. Accessed: 22 March
oriented system, that has made possible a significant number of 2015.
research projects in the past, covering a wide spectrum of situa-
tions within the realm of kinematic geodesy, positioning, naviga- IFEN, 2015. NavX-NCS Professional GNSS
tion, and related disciplines and applications. This has been pos- Simulator. http://www.ifen.com/products/
sible thanks to the principles supporting its architecture, mainly navx-ncs-professional-gnss-simulator.html. Ac-
genericity and extensibilty, as well as a powerful set of data and cessed: 6 October 2015.
interface abstractions. These principles were crucial to cope with
MathWorks, 2015. Three-Axis Inertial Measurement
change and innovation from the very beginning, and still are. Unit. http://es.mathworks.com/help/aeroblks/
threeaxisinertialmeasurementunit.html. Accessed:
GEMMA is composed of a variety of tools whose combination
25 November 2015.
opens the path to its exploitation (as a research tool) in the most
usual scenarios where navigation is involved, as the evaluation / Molina, P., Colomina, I., Vitoria, T., Silva, P. F., Skaloud, J., Ko-
modelling of new sensors or real-time navigation. At least one rnus, W., Prades, R. and Aguilera, C., 2012a. Searching lost peo-
of these tools, the IMU signal simulator, as well as the definition ple with UAVs: the system and results of the CLOSE-SEARCH
of the generic and extensible data interface, are candidates to be project. In: International Archives of the Photogrammetry, Re-
put into the public domain (for more details, contact any of the mote Sensing and Spatial Information Sciences, Vol. XXXIX-B1,
corresponding authors). Melbourne, Australia, pp. 299–306.

This contribution has been peer-reviewed. The double-blind peer-review was conducted on the basis of the full paper.
doi:10.5194/isprsannals-III-3-433-2016 439
 ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume III-3, 2016
XXIII ISPRS Congress, 12–19 July 2016, Prague, Czech Republic

Molina, P., Parés, M. E., Colomina, I., Victoria, T., Silva, P., Yan, G., Wang, J. and Zhou, X., 2015. High-precision simula-
Skaloud, J., Kornus, W., Prades, R. and Aguilera, C., 2012b. tor for strapdown inertial navigation systems based on real di-
Drones to the rescue! Inside GNSS July/August, pp. 36–47. namics from GNSS and IMU integration. In: Proceedings of
the China satellite navigation conference (CSNC), Vol. 3, Xi’an,
Montaño, J., Wis, M., Pulido, J. A., Latorre, A., Molina, P., China, pp. 789–799.
Fernández, E., Angelats, E. and Colomina, I., 2015. Validation
of inertial and imaging navigation techniques for space applica- Yang, Y., El-Sheimi, N., Goodall, C. and Xiaoji, N., 2007. IMU
tions with UAVs. In: Proceedings of Data Systems in Aerospace, signal software simulator. In: Proceedings of the 2007 National
Barcelona, Spain. Technical Meeting of The Institute of Navigation, San Diego,
USA, pp. 532–538.
Navarro, J. A., 1999. Object-oriented technologies and beyond
for software generation and integration in Geomatics. PhD thesis,
Universitat de les Illes Balears.

Navarro, J. A., Parés, M. E., Colomina, I., Bianchi, G., Pluchino,

S., Baddour, R., Consoli, A., Ayadi, J., Gameiro, A., Sekkas, O.,
Tsetsos, V., Gatsos, T. and Navoni, R., 2015. A redundant GNSS-
INS low-cost UAV navigation solution for professional applica-
tions. In: International Archives of the Photogrammetry, Re-
mote Sensing and Spatial Information Sciences, Vol. XL-3/W3,
La Grande Motte, France, pp. 299–306.

Nievinski, F. and Larson, K., 2014. An open source GPS multi-

path simulator in Matlab/Octave. GPS solutions 18(3), pp. 473–
481.

Parés, M. E. and Colomina, I., 2015. On software architecture

concepts for an unified, generic and extensible trajectory deter-
mination system. In: Proceedings of the ION GNSS+, Tampa,
USA, pp. 2518–2526.

Parés, M. E., Navarro, J. A. and Colomina, I., 2015. On the

generation of realistic simulated inertial measurements. In: Pro-
ceedings of the ISS Gyro Symposium, Karlsruhe, Germany.

Rajamani, R., 2011. Vehicle dynamics and control. Springer

Science & Business Media.

Roskam, J., 1995. Airplane flight dynamics and automatic flight

controls. DAR corporation.

Silva, P., Silva, J., Caramagno, A., Wis, M., Parés, M. E., Colom-
ina, I., Fernández, J., Diez, J. and Gabaglio, V., 2006. IADIRA:
Inertial aided deeply integrated receiver architecture. In: Pro-
ceedings of the 19th International Technical Meeting of the Satel-
lite Division of The Institute of Navigation (ION GNSS 2006,
Fort Worth, USA, pp. 2686–2694.

Silva, P., Silva, J., Peres, T., Colomina, I., Miranda, C., Parés,
M. E., Andreotti, M., Hill, C., Galera, J., Camargo, P., Diez,
J., Palomo, J. M., Barbin, S., Moreira, J., Streiff, G., Grane-
mann, E. and Aguilera, C., 2011. ENCORE: Enhanced Galileo
code receiver for surveying applications. In: Proceedings of the
24th International Technical Meeting of The Satellite Division of
the Institute of Navigation (ION GNSS 2011), Portland, USA,
pp. 3679–3689.

Skaloud, J., Colomina, I., Parés, M. E., Blázquez, M., Silva, J.

and Chersich, M., 2015. Progress in airborne gravimetry by com-
bining strapdown inertial and new satellite observations via dy-
namic networks. In: Proceedings of the IUGG 2015 conference,
Prague, Czech Republic.

Velaga, N. R., Quddus, M., Bristow, A. L., Zheng, Y. et al., 2012.

Map-aided integrity monitoring of a land vehicle navigation sys-
tem. IEEE Transactions on Intelligent Transportation Systems
13(2), pp. 848–858.

Xie, P. and Petovello, M. G., 2015. Measuring GNSS multipath

distributions in urban canyon environments. IEEE Transactions
on Instrumentation and Measurement 64(2), pp. 366–377.

This contribution has been peer-reviewed. The double-blind peer-review was conducted on the basis of the full paper.
doi:10.5194/isprsannals-III-3-433-2016 440

View publication stats