3DROV: A Planetary Rover System Design, Simulation and ...

3DROV: A Planetary Rover System Design, Simulation and Verification Tool
P. Poulakis (1) , L. Joudrier (1) , S. Wailliez (2) , K.Kapellos (2)
(1) European Space Agency, ESTEC/Automation & Robotics Section
{pantelis.poulakis , luc.joudrier}@esa.int
(2) Trasys Space
{sebastien.wailliez, konstantinos.kapellos}@trasys.be
Abstract
This paper presents the ongoing work on the
3DROV planetary rover system simulation
environment. 3DROV is designed for end-to-end
mission simulations. It includes models of the
planetary environment, the mechanical, electrical, and
thermal subsystems of the rover, generic onboard
controller, and a ground control station module.
Different levels of fidelity exist for the physical models
depending on the scope of the simulation and scientific
instrument models are included for simulating science
mission scenarios. 3DROV offers the ability to attach
onboard algorithms for testing. The simulation
framework relies on ESA’s SIMSAT 4.0 and the models
are designed to comply with the SMP 2.0 standard.
For modeling the rover’s physical subsystems the
novel port-based modeling approach was adopted.
1. Introduction
The operations of planetary robotic agents need to
be taken into account early in the system design phase,
due to the variety of tasks and conditions that may be
encountered. The difficulty of designing and testing a
planetary rover is to a big extent due to the lack of
knowledge and reproduction capabilities of the target
environment, which often ends up being the driving
factor of the design.
Rovers are key elements to European planetary
exploration missions, with ESA’s ExoMars due to
launch in 2013 and NEXT technology demonstration
mission to the Lunar South Pole in the conceptual
design phase. Thus there is a significant need for the
development of a simulation environment that supports
the system design process and provides a virtual
verification testbed. A similar effort has been ongoing
at JPL for several years, resulting in the ROAMS
Planetary Rover Simulation Environment [3],[4].
ROAMS has been used very successfully in NASA’s
Mars Exploration Rover (MER) mission, in both the
development and operations phases and is already
being used for the upcoming Mars Science Laboratory
(MSL) mission.
In this paper we describe the status of the newly
established 3DROV research activity which aims at the
development of a generic tool that supports the testing
and verification at system level of planetary robot
missions. The 3DROV activity has been initiated by
the Automation & Robotics Section of ESA with
Trasys Space, Belgium as the prime industrial
contractor.
As the work in 3DROV is ongoing, we present the
current status of the project and the future development
and validation plans. The structure of the paper is as
follows. Section 2 gives an overview of the design
philosophy and high-level architecture of 3DROV. In
section 3 the chosen simulation framework, SIMSAT,
is described. Section 4 is devoted to the rover physical
subsystem (s/s) models, while section 5 presents the
modeling of scientific instruments within 3DROV.
Subsequently the design of the Generic Controller is
described in section 6 and section 7 focuses on the
developments on the Environment model. Section 8 is
devoted to the Control Station and the Visualization
environment of 3DROV. The last two sections of the
paper present preliminary results of the system and
validation plans and offer a brief discussion
respectively.
2. 3DROV design
The first section of this paragraph describes in the
design philosophy and the goals that drive the
development of 3DROV. Subsequently the architecture
is presented at system level together with a functional
overview of the main elements.

2.1 Design philosophy
The driving philosophy behind the project is to
build a tool for rover system design and simulation that
would provide ESA’s Automation & Robotics section
the means to effectively support the development of
European planetary exploration missions. More
specific design requirements of 3DROV include the
following:
Generic end-to-end simulation capabilities. For
assessing the design on a system or mission level, the
3DROV environment must be flexible and generic. It
must be able to simulate a mission scenario from the
early stage of its definition until its completion. Thus it
is essential to have the capability to incorporate models
of scientific instruments interacting with the virtual
environment to simulate the daily scientific outputs of
a given scenario. Finally, it is within the scope of
3DROV to represent and support different planetary
environments (Moon and Mars).
Utilize ESA simulation framework and standardized
model interfaces. In order to take advantage of the
technology and know-how developed within the
Agency on spacecraft simulations, it was decided to
adopt the SIMSAT 4.0 framework [1]. Developed at
the European Space Operation Center (ESOC) in
collaboration with European industry, SIMSAT is used
for spacecraft and ground segment simulations and
training. To be used within this framework, the models
under development for 3DROV must comply with the
Simulation Modeling Portability 2.0 standard (SMP
2.0). This standard was introduced by ESA to aid the
portability of simulation models developed within the
European Space Industry. The above choices also aim
at making the 3DROV infrastructure compatible with
other groups within ESA (e.g, Operations, the
Concurrent Design Facility, etc.).
Different levels of fidelity for multi-domain physical
system models. An important requirement is that
3DROV can provide high fidelity dynamic simulations
for the rover physical subsystems but also include the
option to use low fidelity models for fast, mission level
simulation runs. The rover physical models must
include the mechanical, power and thermal s/ss as
well, and also a dynamically consistent contact model.
The novel port-based methodology has been chosen
for the rover physics-based models, which provides an
intuitive energetic model structure both within and
between the different domains.
System testbench approach. As a tool, 3DROV is also
meant to be utilized as a testbench for onboard
controllers and ground station modules. It should
support hardware in the loop simulation allowing
further use with breadboards and engineering models.
Thus it is required that 3DROV has a modular
architecture with clear interfaces to ease closing the
loop with test modules.
2.2 System architecture
3DROV is designed for Linux and VxWorks
operating systems. Its main building blocks and a highlevel
interconnection can be visualized in
Figure 1. An overview of the functionality and role
of each block within the 3DROV architecture is given
below.
Figure 1. 3DROV building blocks
The Simulation Framework relies on ESA’s SIMSAT
and is responsible for the proper execution and
scheduling of the simulation run.
The Control Station serves as the virtual rover’s
ground control station. It provides the means to set-up
mission scenarios via a 3D graphical environment and
upload them to the rover while also assigned to display
the onboard telemetry. The robotic ground control
station A-DREAMS [2] has been chosen as the
baseline for 3DROV.
The Generic Controller assumes the role of the
onboard flight software, as a SIMSAT component, and
controls all the rover operations. Algorithms or
software modules can be attached on the Generic
Controller – or replace it completely – for testing in the
virtual environment.
Rover s/s block includes models of rover physical s/ss,
sensors and scientific instruments. Although developed
in different modeling environments they comprise

C/C++ code encapsulated in SMP-2.0-compliant
SIMSAT modules.
The Environment component is responsible for the
ephemeris and timekeeping of the system, for
generating terrain and atmospheric conditions, and for
tracking the rover location. Within the framework it
interfaces with most of the rover submodels (contact
model, thermal model, etc.) to provide them with the
necessary environmental information.
The Visualization Environment acts as the front-end of
3DROV, providing real-time visualization of the
simulation run and also visualization within the
Control Station to assist the preparation of Activities.
3. Simulation framework
One of the initial design choices of the 3DROV
project was to incorporate the ESA developed
SIMSAT simulation framework, version 4.0. SIMSAT
comprises of the following elements:
The SIMSAT Man-Machine Interface (MMI). This
provides the interface between the user and the
simulator. The MMI is used to build-up the simulator
as a set of interconnected components, to control the
evolution of the execution (start/stop, save states, etc.)
and to monitor its internal parameters.
The SIMSAT Kernel. The kernel is the ‘engine’ of the
simulator, thus taking care of the low level tasks such
as creating and running processes, storing and reading
data, etc. The kernel is also responsible for standard
simulation services such as message logging,
scheduling of events and time management.
Models. This element includes the models to be
executed within the framework. For 3DROV these
include the Generic Controller, the Rover models and
the Environment. SIMSAT integrates the models via
the SMP 2.0 interface standard.
4. Models of physical systems
For the goals of 3DROV considerable effort is put
in the development of consistent and modular models
for the physical systems of a rover. Using a port-based,
lumped-parameter approach we model the mechanical
subsystems (s/ss) and the wheel-terrain interaction as
well as the thermal and power s/ss of a rover. Two
levels of abstraction exist for the rover models within
3DROV: a) a detailed dynamic model of the whole
system where each domain can be plugged in or left
out of a simulation run and b) a purely kinematical one
for fast, operation-level simulations.
4.1 Modeling methodology
Physical systems interact via a bidirectional
interconnection comprised of generalized forces and
generalized velocities. The signal modeling approach
is not suitable to capture this structure intuitively, since
every interconnection carries only one signal. Using
the port-based approach, however, models of physical
systems interact via bidirectional ports which
simultaneously carry effort and flow variables, the
product of which represents the power exchange. This
approach offers a systematic as well as intuitive way of
modeling and results in a unified way to represent and
interconnect subsystems from different physical
domains such as mechanical, electrical, thermal, etc.
Rigid body motions are described using Screw
Theory [5], which gives the advantage of expressing
the velocities of bodies geometrically (i.e., coordinate
free) by their respective twists. Generalized forces
acting on the bodies are defined through wrenches.
The dynamics of the mechanical subsystems are
expressed in the port-Hamiltonian framework, where
positions and momenta are used as state variables. The
port-Hamiltonian representation gives an intuitive
representation of the energetic structure of a system
[6].
The commercial tool 20sim [7] is used as the
modeling environment for the rover’s physical
subsystems. It inherently supports both the signal and
the port-based modeling approach and thus offers the
possibility to build hybrid models from different
physical domains. 20sim exports the models in C-code
together with the integration method (see Figure 2).
The exported models are attached to the SIMSAT
simulation framework via the SMP-2.0-compliant
interface.
Figure 2. Rover s/s models

4.2 Mechanical s/s models
In the current phase of the development of 3DROV
the rover mechanics are modeled within 20sim’s 3D
Editor Toolbox. The mechanical configuration is
defined graphically and CAD data is attached to it for
visualization. The rover’s kinematics and dynamics
equations are then exported as a 20sim code block,
with power-port interfaces for the actuated parts,
where it is combined with other s/s models. This
process is time consuming when rover mechanical
parameters need to be modified or other mobility
concepts need to be tested, and a more generic and
simplistic approach will be sought in the next phase of
the project.
One important feature of 20sim is that it offers
several methods to handle closed-loop mechanisms,
which makes it very generic for the types of mobility
configurations that we can model.
4.3 Power and Thermal s/s models
The core of the power s/s model is the solar panel
models and battery models. Applying the power-port
based approach, in the electrical domain, we can attach
models of different levels of fidelity for the power s/s,
depending on the simulation needs. Instruments are
modeled as loads on the electrical network, based on
their nominal consumption characteristics.
The thermal models used within 3DROV are
derived by simplifying large thermal analysis models
of specific rover configurations. The reference thermal
model under development for 3DROV aims at
reducing the complex thermal analysis model for the
current configuration of the ExoMars rover to a 30node
model. Expressed in the lumped-parameter
fashion, the nodes of the reduced model represent an
average thermal behavior of the components that the
node includes. The thermal model interfaces (powerports
with the rest of the physical model and signals
with 3DROV’s environment mode) are designed so
that the model can be exchanged with a more
sophisticated one.
4.4 Actuators – Sensors
A high fidelity actuator model within 3DROV
describes in a lumped-parameter way the dynamics of
the respective s/s. This extends to modeling the lowlevel
servo controller of the motor, the transmission
system, its electrical circuit and its thermal behavior.
3DROV models the functionality and signal
processing behavior of sensors neglecting their
physical characteristics (mass, power consumption)
since this would not improve significantly the fidelity
of the system. Thus sensors are modeled as signal
processing blocks that transduce the input magnitude
to a measurement magnitude, allowing the modeler to
include algorithms that induce errors to the outputs.
Sensors modeled within 3DROV include common
space robotic sensors such as encoders, potentiometers,
temperature sensors, inertial measurement units
(IMUs) and sun sensors.
4.5 Contact model
The first instance of the 3DROV contact model,
currently implemented, assumes the wheels and terrain
to be smooth surfaces with orthogonal
parameterizations f(θ,φ) and g(u,v). One pair of contact
points is assumed per wheel. Deriving the differential
geometry parameters, namely the metric M, the
curvature K, and the torsion T, for each surface patch
we can detect and track the wheel-terrain contact
points using contact kinematics equations, as described
in [8]. The ongoing work on the contact model aims at
making it more generic in the terrain surface utilization
by incorporating computational geometry algorithms
for collision detection.
The contact model is also responsible of inducing
forces in the normal direction and on the tangential
plane defined by each pair of wheel-terrain contact
points. During simulation the normal forces are
computed numerically using a physically-based
gradient method. In the normal direction of each pair
of contact points a 1 degree of freedom (DoF) Kelvin-
Voigt compliant system is attached (Eq. 1), where Fn is
the normal force, zG penetration depth, kn and dn the
spring-damper coefficients. This technique is causal
and very efficient for a multibody dynamic simulator,
at the expense of adding one more state per wheel to
the system.
F = k z + d z&
(1)
n
n
The forces on the tangential contact plane are
calculated in a similar manner, as shown in
Figure 3. Each compliant system has, as a saturation
threshold, the maximum shear capacity of the soil in
the longitudinal direction, given by the terramechanic
(Eq. 2). Above this threshold the wheel starts to slip.
Parameters c and φ are soil cohesion and friction angle
respectively, and A is the wheel-terrain contact area.
G
n
G

F = cA + F tanφ
(2)
Y max n
The reason for decoupling the two directions is to
be able to tune the system parameters separately for
tests. This simplified hybrid contact model performs
well in a multibody simulator, nevertheless it is part of
the ongoing work in 3DROV to incorporate more
terramechanics effects.
Figure 3. Tangential contact model
5. Scientific instrument models
The instrument models provide a virtual presence of
the rover payloads with respect to data acquisition,
sensor system response properties, and payload data
generation including onboard processing.
The 3DROV infrastructure allows instantiation of
virtual instruments and provides the needed structures
and real-time mechanisms to integrate and execute data
acquisition and data product generation algorithms. It
also provides access to the global state of the simulator
and in particular the rover state, information needed
for data registration of the scientific measurement. The
instances of the virtual instrument execute commands
issued by the Generic Controller and their states are
sampled in discrete time steps. Thus the operation
behavior of the instrument is monitored and can be
acquired by the other subsystems of the simulator.
6. Generic controller
The role of the Generic Controller is to substitute
the rover on-board flight software in the simulator
environment. It receives and executes the Activity
Plans as prepared and uploaded by the Ground Control
Station and transmits back housekeeping and science
data. To this end, it interfaces with:
• The rover s/s models for the simulation of the
Activities related to the locomotion, the
communication, the power and the thermal s/ss
management.
• The Instrument models for the simulation of
science related Activities.
The Generic Controller functions as an SMP-2.0compliant
module within SIMSAT. It implements a
three-layer Rover control architecture ([9],[10],[11])
with the hybrid nature of combining both continuous
and discrete event aspects, as shown in
Figure 4.
3DROV’s controller module captures these aspects
considering two main entities: the Actions and the
Tasks which are elements of the Functional and the
Executive level respectively.
The Action represents an elementary robotic activity
and encapsulates a control law into a logical behaviour
that determines the instants of its activation, its end or
the occurrence of exceptions.
The Task is a logical and temporal composition of
actions or tasks, to achieve an objective in a context
dependent and reliable way. Therefore, the Task can be
considered as a discrete-event controller which
rhythms the sequencing of actions (through their
respective local event-based controllers) following a
user-defined scheme. The event-based behaviour
constitutes the interface of an Action to a Task.
Figure 4. Generic controller architecture
The Actions of the Generic Controller are in
principle fixed, but take all necessary dispositions to
allow the operator to fine tune parameters of the
involved algorithms as well as introduce new
algorithms. Consequently, algorithms developed for
rover flight controllers can be integrated to the
3DROV Generic Controller for testing.

7. Environment model
This 3DROV model introduces the environmental
conditions in which a planetary rover operates with
respect to locomotion, energy, communications, and
science activities. It supports other 3DROV models by
providing them with environmental data.
The model is designed to be generic and
configurable so that a wide range of rover missions
with various scientific payloads can be supported. The
components which comprise 3DROV’s Environment
model are presented in the following subsections.
7.1 Geographical Information System (GIS)
component
The GIS component concentrates geographic and
spatial data in a repository of so-called “locations”.
Locations contain geometrically co-registered datasets:
Digital Elevation Models (DEMs), terramechanical
maps, orbital images and other types of terrain
overlays. As such, the 3DROV GIS mainly serves as a
back-end to the Terrain component (see 7.2) as well as
an imagery server that supports camera and scientific
imager models.
The component design relies on the open source
GRASS GIS [12], where the locations are created or
edited offline. With GRASS we can synthesize DEMs
and also import and interpolate planetary DEMs (e.g.
MOLA) or synthetic DEMs (e.g. from PANGU [13]).
7.2 Terrain component
This 3DROV component answers queries from
other simulation modules for information about the
relief and terramechanical properties of the planetary
terrain. The wheel-terrain contact model is a prime
example of this. Relief is extracted from a DEM, while
mechanical properties are derived from a databaselinked
terramechanical map. In this latter map, patches
of terrain have been assigned soft or hard soil types (
Figure 5) and various rock coverage, all of which
are mechanically parameterized.
The Terrain component is also designed to provide
scientific telemetry –raw or processed– for the
simulation of the relevant rover payloads. It is
developed upon the PostgreSQL database and its
PostGIS spatial extension [14].
7.3 Orbital and Timekeeping component
The Orbital and Timekeeping module keeps track of
solar, planetary and orbiter ephemerides, line of sight
conditions, and solar time. It is typically used by the
solar panel model, to retrieve solar angles, by the
onboard radio communication software to retrieve
rover-orbiter or orbiter-Earth viewing geometry and
communication lags. The component is based on the
NASA/NAIF Spice Toolkit [12].
Figure 5. Terramechanical map in GRASS
7.4 Atmosphere component
This environment component provides data on the
planetary atmospheric conditions: wind speed,
atmospheric dust, solar flux, ambient temperature,
surface temperature, etc. These magnitudes are
essential for other 3DROV modules such as the
instruments, the thermal s/s models, and the solar panel
models. Due to the fact that planetary atmospheres are
unique this component is the least generic of the four
that make up the 3DROV Environment Model. The
Martian atmosphere is supported by the Mars Climate
Database [15], which is dynamic and scenario-driven.
A simplified atmospheric model describes the Moon
conditions.
8. Control station & Visualization
environment
The 3DROV Control Station simulates the basic
functionalities of a mission Ground Control Station. It
is based on the ESA A-DREAMS Robotic Ground
Control Station [2] (see Figure 6), with the following
functionalities:
Telemetry (TM) acquisition and processing: Receiving
TM packets from the Generic Controller (or batch
downloaded data) and processing them to the
appropriate level to generate products for further
analysis.

Rover housekeeping data monitoring and assessment,
for monitoring the rover s/ss behavior during
simulation and post-analysis.
Science data monitoring and assessment, for science
products analysis. The operator can analyze selected
imagery and instruments products on dedicated MMIs,
in order to identify potential scientific targets to be
used in the following Activity Plan.
Activity preparation, validation and telecommand
(TC), for the specification and formal verification of
the Activity Plans to be uploaded to the Generic
Controller. Activity Plans are defined as timelines of
Tasks.
The visualization environment is used both for
visualizing independently in 3D the evolution of the
simulation and as an integrated component of the
Control Station.
3DROV’s visualization environment renders in a
photorealistic virtual scene the simulated rover and its
surrounding environment in the form of meshes. It
visualizes additional items such as ‘targets’, Activity
glyphs and image overlays and generates the animation
of all modeled mechanisms based on the rover state
values issued by the SIMSAT framework. Shadows
cast by the illumination sources are displayed and
ambient conditions are tuned to adjust direct sunlight
intensity and direction, ambient light and surface
reflexivity characteristics according to conditions
published by the Environment model.
The main technologies and tools used for the 3D
Visualization environment include material and
composition scripting, advanced scene managing,
meshes support, resources manager, and XML loaders.
Figure 6. The A-DREAMS control station
9. Preliminary results and applications
3DROV is a newly established research activity
within the Automation & Robotics section of ESA. Up
to now significant work has been conducted on the
development of individual 3DROV components with
the focus moving to integration. Preliminary results of
the project include the following.
A consistent and validated modeling approach has
been taken for the modeling of the rover physical s/ss.
Extensive modeling work has been performed on rover
locomotion s/ss –as preliminary work on 3DROV–
with application to the candidate chassis configurations
for the ExoMars mission. These models were
simulated for chassis performance evaluations and
focused on static stability issues. Results are well
documented in [8].
The 3DROV concept of hardware in the loop was
demonstrated during the ASTRA 2006 workshop at
ESTEC. The Generic Controller, specified in section 6,
was installed onboard the ExoMars Demonstration
Rover (ExoMaDer) of the Automation & Robotics Lab
(ARL). The CNES Rover Autonomous Navigation
Software [16] was attached to the Controller and
mission targets were defined from the Control Station.
The experiment was conducted towards the functional
verification of the individual components to be used in
3DROV and the validation of hardware-in-the-loop
system interfaces.
In addition to this work, the effort of building a
scientific instrument library, for the simulation needs
of 3DROV, is in progress. Up to date the library
contains models for: the Mars Infrared Mapper
(MIMA), the WISDOM Ground Penetrating Radar, the
Close-Up Imager (CLUPI) and the Miniaturized
Moessbauer Spectrometer (MIMOS II).
10. Ongoing development
The development of the 3DROV is ongoing
towards a complete and extendable simulation and
verification environment.
One of the main areas of focus of the ongoing work
is the development of a generic contact model. While
the current contact model is dynamically consistent
and efficient, the implemented contact tracking method
restricts us to using smooth, parameterized terrain
surfaces. Currently a new contact model is designed
with the goal to be generic in the types of surfaces it
can handle and also provide contact dynamics
consistency in the simulation.
In parallel to the development of 3DROV a
complete rover system testbench is being set up at the

ARL. It is comprised of the indoors planetary terrain
surface (aprox. 81m 2 ), a Vicon global motion tracking
system [17] and several rover prototype designs.
Moreover, a Single Wheel Testbed (SWT), built by
DLR, has been installed in the lab for the performance
measurements of rover wheel designs. Among other
utilization, the above systems will aid our upcoming
verification efforts for the 3DROV components. It is
planned to use the SWT for the verification of and fine
tuning of the new contact model under development.
11. Conclusions
This paper presents an overview of the current
status of the recently initiated 3DROV activity. Upon
completion it will provide the necessary infrastructure
to evaluate robotic systems for planetary exploration
missions and generate design feedback.
Currently the work focuses on the completion of
individual components within the environment as well
as their integration. Significant effort is also put in
planning system validation methods.
3DROV aims at providing a valuable tool to the
Automation & Robotics section of ESA towards
support activities to future European planetary
exploration missions, with specific view on the
ExoMars mission.
12. References
[1] “Introduction to Simsat.”,
URL: http://www.egos.esa.int/portal/egosweb/products/Simulators/SIMSAT/,
Dec 2007.
[2] F. Didot, K. Kapellos, A. Schielle, “A-DREAMS: An
Advanced Ground Control Station for Teleoperation and
Telemanipulation”, in 8 th ESA Workshop on Advanced Space
Technologies for Robotics and Automation (ASTRA’04),
Noordwijk, The Netherlands, 2004.
[3] A. Jain et.al. “ROAMS: Planetary surface rover
simulation environment”, in 7 th Int. Symposium on Artificial
Intelligence and Automation in Space (iSAIRAS 2003), Nara,
Japan, May 19-23, 2003.
[4] A. Jain et.al. “Recent developments in the ROAMS
planetary rover simulation environment”, in IEEE Aerospace
Conference, Big Sky, Montana, USA, Mar. 6-13, 2004.
[5] S. Stramigioli, H. Bruyninckx, “Geometry and screw
theory for robotics”, Tutorial from International Conference
for Robotics and Automation (ICRA), IEEE/RSJ, Seoul,
Korea, 2001.
[6] Shaft, A.v.d., L 2-Gain and passivity techniques in nonlinear
control, ser. Communication and Control
Engineering, Springer-Verlag, 2001.
[7] “20sim Modeling and Simulation Tool.”, URL:
http://www.20sim.com., Dec 2007.
[8] P. Poulakis, L. Joudrier, S. Stramigioli, “Port-based
modelling and simulation of planetary rover locomotion on
rough terrain”, in 9 th ESA Workshop on Advanced Space
Technologies for Robotics and Automation (ASTRA’06),
Noordwijk, The Netherlands, 2006.
[9] D. Simon et.al., “Computer-aided design of a generic
robot controller”, Transactions on Control Systems
Technology, IEEE, Vol.1, Issue: 4, Dec. 1993.
[10] K. Kapellos et.al., “Task Level Specification and
Formal Verification of Robotics Control Systems”,
International Journal of Systems Science, Taylor & Francis
Vol.30, Num.11, Nov. 1999.
[11] K. Kapellos et.al. “The Orccad Robot Control
Architecture and Tools in Space Applications”, in 9 th ESA
Workshop on Advanced Space Technologies for Robotics and
Automation (ASTRA’06), Noordwijk, The Netherlands, 2006.
[12] Neteler, M., Mitasova, H., Open Source GIS: A
GRASS GIS Approach, Springer, New York, November
2007. URL: http://grass.itc.it/.
[13] S. M. Parkes et.al. “Planet surface simulation with
PANGU”, in 8 th International Conference on Space
Operations (SpaceOps 2004), Montreal, Canada, May 17-21,
2004.
[14] “PostgreSQL Database and its PostGIS spatial
extension”, URL: http://www.postgresql.org,
http://postgis.refractions.net, Dec 2007.
[15] S. J. Bingham et.al., “The Mars Climate Database”,
Proceedings of the 1 st International Workshop on Mars
Atmosphere Modelling and Observations, Granada, Spain,
13-15 Jan 2003.
[16] M. Maurette, “Mars Rover Autonomous Navigation”,
Journal of Autonomous Robots, Springer Netherlands,
Vol.14, Numbers 2-3, pp. 199-208, Nov 01, 2004.
[17] “Vicon Motion Tracking Systems.”, URL:
http://www.vicon.com., Dec 2007.