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

net/publication/256198563

Modular Robots for On-Orbit Satellite Servicing

Conference Paper · December 2012

DOI: 10.1109/ROBIO.2012.6491265

CITATIONS READS
42 867

5 authors, including:

Michael Goeller Jan Oberländer

Lake Erie College of Osteopathic Medicine FZI Forschungszentrum Informatik
17 PUBLICATIONS   96 CITATIONS    25 PUBLICATIONS   244 CITATIONS   

SEE PROFILE SEE PROFILE

Klaus Uhl Arne Roennau

Intel FZI Forschungszentrum Informatik
18 PUBLICATIONS   109 CITATIONS    143 PUBLICATIONS   1,174 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Cogniron View project

Cognitive CAE Automation View project

All content following this page was uploaded by Arne Roennau on 08 January 2016.

The user has requested enhancement of the downloaded file.

©2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media,
including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to
servers or lists, or reuse of any copyrighted component of this work in other works. DOI: 10.1109/ROBIO.2012.6491265
Robotics and Biomimetics (ROBIO), 2012 IEEE International Conference on , vol., no., pp.2018-2023, 11-14 Dec. 2012.

Modular Robots for On-Orbit Satellite Servicing

Michael Goeller, Jan Oberlaender, Klaus Uhl, Arne Roennau, and Rüdiger Dillmann
FZI - Research Center for Information Technology
76131 Karlsruhe, Germany
[goeller, oberlaender, pfotzer, roennau, dillmann]@fzi.de

Abstract— Today satellites are mostly monolithic systems and

offer hardly any facilities to facilitate servicing or maintenance.
Consequently, no servicer satellites are present as well. In this
work, supported by the German Space Agency, we propose a
modular concept for satellites based on standardized building
blocks. These can be replaced in orbit requiring significantly
less manipulation skills than ordinary repair missions would
need. The building blocks could be replaced using robot
satellites instead of sending astronauts on maintenance missions
as has been performed few times in the past. The possible
benefits are numerous: the concept enables cheaper and faster
development of satellites, it enables repair missions extending
the life expectancy of satellites by replacing damaged blocks or
those run out of fuel, and finally old satellites can be refitted for
new missions, reducing space debris and the cost of launching
new systems. Developing our concept, we faced the same
challenges known from modular robots on earth: interfaces had
to be developed for connecting blocks, a distributed software
architectures was needed, and algorithms were necessary which
calculate suitable configurations of blocks according to given
constraints. In this paper we will present solutions from which a
concept of a modular satellite system emerges which is strongly
inspired by earthbound heterogeneous robotic systems. We will
complete the paper with thoughts on the servicing itself and on
setting up maintenance infrastructures in the earth orbit.
I. I NTRODUCTION
Today satellites are each unique and highly integrated
designs. To reduce volume and mass they have compact
shapes. As every moveable component poses a risk of
failure in space, the mechanical complexity of the systems is
reduced to an absolute minimum meaning that there are no
hatches which could be opened for maintenance. All in all,
this means catastrophic conditions thinking about repairing
satellites in orbit, letting alone changing a satellite’s. The
orbits around earth are already cluttered with space debris
- the point of triggering a snowball effect where collisions
between pieces of debris generate even more debris cluttering
the orbit completely is not far off. Hence the satellites have
to move out of their orbit (into the GEO graveyard or the
atmosphere for the LEO) before their fuel is depleted. These
satellites are often fully operational but have to be removed
anyway. Other satellites are almost operational, but small
errors render them completely useless. All these cases have
in common that satellites with 90 percent or more operational
subsystems are discarded - or even worse - clutter the orbit
as large pieces of debris.
Concluding we have two major challenges in commercial
space-flight: removing the debris which is already there as
well as extending the life expectancy of satellites to reduce
Fig. 1. Modular client and servicer satellite as envisioned by iBOSS.
costs and the amount of new debris by servicing satellites.
In the field of satellite servicing there are again two main
fields of interest: servicing current satellites and designing
new satellites which are easier to maintain. We want to tackle
the latter one in this paper.
A. Modular and re-configurable satellites as solution
Observing biological motivated robotics, one possible path
to solve the mentioned challenges is apparent: building
satellites based on a modular design as depicted in Fig. 1.
A large number of groups develop several kinds of modular
robots and robot swarms for a multitude of applications.
Modular robots can be classified by two dimensions: First
they can be homogenous or heterogeneous: All modules
are identical or the system incorporates a multitude of
specialized modules. And second the shape of the organism:
There are lattice-typ, chain-type and swarm-type systems.
Examples for homogenous systems (Fig. 2) are CONRO
[3] (chain-type), Pebbles [5] and EM-Cubes [1] (lattice-
type), examples for heterogeneous robots (Fig. 3) are the
inspection robot KAIRO [9] (chain-type) and Symbrion [13]
(latice-type) - robots utilizing highly specialized modules for
dedicated tasks such as computing, sensing or propulsion.
Constructing satellites in a modular manner out of a
construction kit offers the following benefits: The presence
of interfaces on the sides of the blocks would enable the
satellite to dock or un-dock individual modules, enabling
the replacement of modules if damaged or even new up-to-
date modules could be attached to replace deprecated ones,
outfitting the satellite for future tasks. Besides maintaining
satellites in orbit, the design of satellites on earth could be
sped up significantly. Providing a kit of predefined, highly

Fig. 2. Homogeneous robot: EM- Fig. 3. Heterogeneous robots: Top:
Cubes ([1]) Kairo [9], Bottom: Symbrion ([13])
integrated and qualified building blocks would enable the
engineers to concentrate on the demands of the missions, not
on the demands of the subsystems. They could just select
the needed blocks out of the kit and focus on developing
the few unique blocks needed for their individual mission
instead. We imagine that qualifying a system consisting of
independent and already qualified components should be
much easier and faster than qualifying a completely new
one. The process of selecting an arranging the blocks could
even be software assisted, as will be described in Chapter
IV. But these benefits come at the costs of more overhead
in volume and mass because each building block provides
its own structural integrity. Here a balance between large
blocks containing many subsystems with less overhead and
small blocks containing few - or one - subsystems providing
more flexibility has to be found.
B. iBOSS concept: Heterogeneous modular robotic system
The project ”Intelligent Building-Blocks for On-Orbit
Satellite Servicing” (iBOSS) is a cooperation of the three
partners Research Center for Information Technology (FZI)
from Karlsruhe, the institute for aeronautics ilr of the TU
Berlin and the institute for light weight construction ilb
of the RWTH Aachen and supported by the German space
agency DLR. iBOSS envisions a concept of modular satellites
based on cube-shaped building blocks with an edge length
of 40cm. This size was chosen so that most of the major
subsystems fit in one single block. But if necessary, larger
subsystems such as fuel tanks can occupy double blocks as
well. Each block houses one major subsystem like reaction
wheels and can contain several minor subsystems such as
sun-sensors. Thus a satellite will consist on the order of 30
specialized blocks, forming a highly heterogeneous, modular,
and re-configurable robotic system in lattice structure (Fig.
1): each block has a dedicated functionality in the system
including, but not limited to, propulsion, altitude control,
data processing, telemetry, or providing energy. During the
project, concepts in four major fields of work have been
developed (they are elaborated on later in Chapter II):
a) Infrastructure: The infrastructure of the modules
consists mainly of the cube-shaped structure of the blocks
(edges and walls), the IT-infrastructure and the bus systems:
the data bus, the electrical bus and the thermal bus.
b) Interfaces: Each block is equipped with up to
six interfaces. The interface provides for the mechanical
coupling and a connection for each of the bus systems:
a thermal, an electrical and a data interface. As will be
explained later, the critical point on the interfaces is that
they have to be axial and rotational symmetric.
c) Control Architecture: As we have modular system
which can be re-configured at runtime, we need a control
architecture matching this dynamic and distributed approach.
d) Configuration of blocks: The concept of a satellite
construction kit consisting of building blocks with specified
requirements and constraints allows us to develop software
tools to facilitate a computer-aided satellite design process.
C. Current missions aiming at on-orbit servicing
Currently other well-known research groups are also work-
ing on the field of on-orbit satellite servicing. The three most
important projects are introduced here:
a) RRM: The NASA is working on an on-orbit ser-
vicing program, the Robotic Refueling Mission [7]. A set of
tools and a panel with a high number of valves and other
objects found on satellites are already on the international
space station where they run experiment with the DEXTRE
arm. They aim at refueling old satellites or performing repair
missions on satellites with conventional design (see Fig. 4).
b) Phoenix: The US-Government DARPA works on
the modularization of satellite systems. The available infor-
mation is limited as it has a military component. From [4]:
”The Phoenix program envisions developing a new class of
very small ’satlets’ similar to nano satellites, which could
be [...] attached to the antenna of a non-functional cooper-
ating satellite robotically, [...]”. ”Phoenix seeks to demon-
strate around-the-clock, globally persistent communication
capability for warfighters more economically, by robotically
removing and re-using GEO-based space apertures [...]”.
c) DEOS: The DEOS mission of the german space
agency (DLR) aims at capturing an uncooperative client
satellite with a servicer satellite, using a robotic arm. After
capturing, the servicer will dock to the client using a grapple
inserted into the main propulsion unit. Then the arm is
used to practice manipulation tasks like placing cameras and
inserting a refuelling adapter ([2], [10], see Fig. 4).
Fig. 4. On-Orbit Servicing: Left: Test-panel on the ISS of NASA’s RRM
[7]; Right: The DEOS mission of the German DLR ([2], [10]).
II. T HE BUILDING B LOCKS
This section describes the central element of the presented
concept: the building blocks (model and picture in Fig. 5).
The blocks are cube-shaped and have a size of 40x40x40
cm to be able to house most of the major subsystems
found in satellites. Examples for these major subsystems are
reaction wheels, chemical or electrical propulsion units, fuel
tanks, batteries, a variety of sensors for altitude control as
well as the main payload of the satellite i.e. in most cases
scientific instruments or telecommunication equipment. Few
large subsystems fill up a double or even a quadruple block.
The blocks are covered with reflecting insulation against
heat radiation. Each block is equipped with a number of
interfaces. These interfaces are used to connect adjacent
blocks to form a lattice pattern. Additionally, a servicer
satellite can grab the blocks by using a grapple interface
(Fig. 5) mounted on a robotic arm as was illustrated in
Fig. 1. The construction of the blocks is a highly complex
task as the space environment poses several requirements
for all incorporated components. The most prominent ones
are the resistance vs. cosmic radiation and the robustness
vs. high and low temperatures, especially the short and
intense heating phase as well as the lacking ability of heat
transmission. The vacuum itself changes the characteristic
of lubrication solvents and metals have a tendency to cold
welding. Consequently, the engineer is encouraged to keep
the mechanical complexity of the system as low as possible.
But as complex the design of a building block is, the
more complex is the design of a completely unique satellite
system. Once the building block is designed and qualified, it
can be incorporated in a large number of satellite systems,
reducing the effort to qualify the overall satellite system
significantly. The next two sections will discuss the two
main components of the blocks: the interfaces on, and the
infrastructure inside the blocks.
Fig. 5. Left: Model of a block housing a pair of star sensors as major
and two sun sensors as minor subsystems ([15]). Right: Test setup in our
lab with four connected blocks mounted on a pole. A fifth (sensor) block
is attached to a grapple interface with an umbral cord. This way a servicer
could bring the sensor block around the satellite to inspect specific sections.
A. Interfaces of the building blocks
We will start discussing the building blocks with the
interfaces as the interfaces are the most demanding part of the
system. They form a rigid connection of adjacent blocks and
transport electrical current and data as well as thermal energy.
Their requirements and their design influence the overall
design significantly. The most influencing requirements are
the need to be axial and rotational symmetric. The general
requirements are listed below:
• Symmetry: Axial and 90 degree rotational symmetry are
needed to enable connecting arbitrary blocks without
placing restrictions on the relative module orientation
• Low complexity: Mechanics in space have to be robust
and fail-save. Hence a low complexity of the design
significantly eases the qualification for utilization in
space and reduces the failure-rate of the components.
• Low mass: as the mass is a significant expense factor,
the total mass should be as low as possible
• Low volume: the interfaces shall occupy as little as
possible of the building blocks usable volume
• Sensors: The interface shall be able to detect when
another building block is being attached and it shall
be able to measure the rotational offset between the
interfaces.
In general, the requirement of symmetry is solved by
(a) using only androgynous components for the interfaces
and (b) incorporating all components four times, with all
four being placed on the same circumference around the
interface’s center. The electrical interface uses four times two
spring mounted contact pins including a control to prevents
short-circuits and surges. It shuts the interface off when
no other block is docked. The contact of two interfaces is
detected by contact switches embedded into the mechanical
interface and the relative orientation offset between two
interfaces is determined using one LED and three photo
transistors which are mounted in 90 degree steps on the
same circumference. A special focus of this work is on the
mechanical and the data interface, which are explained in
the next two sections. More details on the remaining parts of
the interfaces, including elaborations on the thermal interface
and bus concept, can be found in corresponding publications
by our partners: [14] (German) and [15].
1) Mechanical Interface: In the case of the mechanical
interface iBOSS has addressed two approaches which are
contrasted in Fig. 6: In approach (A), which can be seen in
more detail in Fig. 7, the coupling mechanism is placed in
the corners two enable optimal force introduction into the
block’s structure. Each corner houses a bolt with a notch as
well as a deepening which is used as guidance for the bolt
of the opposite interface while coupling. At the bottom of
the deepening a lifting solenoid is mounted which actuates a
pin which again locks the bolt in place. Alternatively, the
solenoid can be replace by linear drives or by one large
toothed ring encompassing the whole interface outfitted with
hooks for catching the bolt. We decided in favor of the
solenoid because of the low weight and the low mechanical
complexity - it has only one single moving part: the anchor
of the solenoid. Details on the control of the solenoid using
CPLDs can be found in [8]. Approach (B) uses a central
and circular bayonet connector which allows for a smaller
grasping mechanism for the robot arm ([15]).
2) Data Interface: The data interface connects the data-
bus systems of the individual building blocks. As the re-
quirements of the interfaces are more constraining than the
ones of the blocks in general, this interface defines the data
bus system. It is based on a single-wire fiber optic cable.

Fig. 6. Two approaches for the interfaces: Left (A): mechanical interface
based on bolts in the corners; Right (B): central mechanical bayonet and
electrical interface by our partners RWTH Aachen ilb and TU Berlin ilr
([15]). In both approaches the fiber-optic lens of the data interface is
mounted in the center. It is surrounded by the LED and the three photo
transistors for detecting the relative orientation.
Fig. 7. Approach (A) of the mechanical interface using a stem in each
corner which is fixed by a solenoid which again operates a catching bolt.
Left: Top view, Right: Bottom view
This way, the design of an androgynous and symmetric data
interface can be accomplished by fitting lenses on the cables
(see Fig. 8), allowing for bi-directional communication with
high data rates with a minimum of mass and complexity. In
contrast, a multi-wire solution would have to be implemented
four times to satisfy the symmetry requirement, including a
special control to merge the four signals afterwards. Table
I evaluates the alternative solutions and Fig. 6 shows the
plug embedded in the centre of each of the two mechanical
interfaces. The concept of the data interface does not restrict
the abilities of the data bus. It allows for high data rates from
100Mbit/s up to several Gbit/s, bi-directional communication
and multi-mode data-transfer, meaning that several networks
can be operated in parallel using only one fiber.
B. Infrastructure of the building blocks
As mentioned earlier, the Infrastructure of the modules
consists mainly of the cube-shaped structure of the blocks
(edges and walls), the IT-infrastructure and the bus systems:
the data bus, the electrical bus and the thermal bus. The
walls of the cubes are built as sandwiches made of carbon
and rigid foam. The corners house metallic load introduction
elements. This construction makes the blocks very stiff and
rigid while still being lightweight. To endure the extremely
high forces during launch, it is possible to use additional
structural enforced blocks. In this paper we will focus on
the IT-part of the infrastructure and therefore continue with
the data bus concept described in the next section. More
details on the remaining parts of the infrastructure can be
found in corresponding publications by our partners: [15] or
in german language in [14].
TABLE I
C OMPARING TWISTED PAIR (TP) AND FIBER OPTIC (FO) NETWORKS
Requirement TP FO
High data rate (>100Mbit/s) + ++
Rotational symmetry - ++
Axial symmetry 0 ++
Complexity of interface - ++
Data Bus: The data bus connects the individual com-
ponents inside each building block and connects to adjacent
blocks via the data interfaces. As defined by the data inter-
face, the bus is set up using fiber optics with one single
fiber and utilizing optical free space communication for
the connection between the blocks (see the section on the
interfaces for more information). The use of fiber optics
has several advantages: besides the high data rates which
reaches up to 10Gbit/s or even more, the cables are extremely
lightweight compared to ordinary cables. In a real satellite
system glass fiber optics would be used as they are more
lightweight and robust vs temperature and radiation, in our
test setups we use polymer optical fibers (POF) which
can be handled more easily. As protocol we user optical
ethernet, but Space Wire would be more appropriate for final
satellites. The block-based concept of the iBOSS approach
offers inherent redundancy for the bus system, which is
very valuable in space systems. As shown in Fig. 9, the
network data packets can travel several different paths on the
way between two blocks using different cables, routers and
interfaces. As result the IT-architecture becomes more robust
but also more complex and the routers in the individual
blocks need to support the Rapid Spanning Tree Protocol
(RSTP) to resolve cycles in the networks topology. They also
have to support the Simple Network Management Protocol
(SNMP) to allow gathering information on the network which
will be used in the management module (see Sec. III).
Fig. 8. Plug bearing the lens to Fig. 9. Redundancy: Packets can
enable optical freespace communica- travel different paths, reducing the
tion between building blocks impact of failures of cables, inter-
faces or routers.
III. T HE DYNAMIC SOFTWARE FRAMEWORK COSMA
As we have a modular system which can be re-configured
at runtime with many different specialized blocks, we need
a control architecture matching this dynamic and de-central
approach. The framework for controlling the individual
blocks uses a distributed, data-centric approach based on
Data Distribution Services (DDS) which enables the flexible
distribution and management of the software modules. There
are two types of software modules:
• Bound SW-modules: These are bound to one specific
building block. There are two candidates: (1) the ID-
 Module registers the building block when attached and
(2) the BC-Module controls the block’s hardware.
• Free SW-Modules: These perform the actual computa-
tion work like planning or data processing. The publish-
subscribe nature of the architecture makes it irrelevant
for the general modules on which computational unit in
which building block they are actually running.
Figure 10 shows a GUI provided by the management module
showing information on the attached blocks, the network
topology, and the geometrical structure. The information is
aggregated from the individual ID-Modules, the sensors of
the interfaces and the SNMP of the routers (see the data
bus section). For more details the reader is referred to the
publication [8] or in even more detail [12] (German).
Fig. 10. The GUI of the management module: Left: Network topology
and building block information; Right: Geometrical structure. The GUI
corresponds to the setup of the testbed shown in Fig. 5 (right).
IV. C OMPUTER - AIDED DESIGN OF MODULAR SATELLITES
As introduced earlier, the concept of a satellite construc-
tion kit consisting of building blocks, each with clearly speci-
fied requirements and constraints, facilitates the development
of software tools for a computer-aided satellite design pro-
cess. The semi-automatic design process takes place in three
major steps (as illustrated in Fig. 11): modeling, deducing
constraints and solving the resulting optimization problem,
where the last two steps are performed twice: for selecting
and for arranging the blocks.
Fig. 11. Computer-aided design in three steps: modelling, deducing
constraints, solving the optimization problems
a) Modeling: Initially the kit has to be modeled. This is
done in the ontology language OWL. The advantage in using
an ontology is that it is human readable and hence does not
require programming skills to be managed while likewise
enabling algorithmic processing. The modelling of the kit
has to be performed once only and provides the construction
kit ontology. The models of the blocks contain all known
information like size, weight, inertia, power consumption,
offered services, hardware components such as sensors and
processing units and so forth.
b) Selecting blocks: The design process of a satellite
starts with choosing a set of initial mission-specific rules
for the selection of building blocks. A greedy algorithm
then chooses the blocks needed to fulfill the given rules.
This selection-step is performed iteratively four times: for
the mission-specific blocks with rules given by the system
engineer, for the system-relevant blocks like navigation sys-
tems, for the scaleable blocks like batteries and finally for the
structural blocks. After each step the set of rules is extended
by the need of the latest chosen blocks. The resulting list of
blocks is called the satellite ontology.
c) Deducing constraints: In the next step a reasoner
(FACT++) processes the satellite ontology and induces rules
for the arrangement of the chosen blocks. These rules include
for example minimum or maximum distances to be kept
between specific blocks or the position and orientation of
blocks. This set of rules poses an optimization problem
which has to be solved in the final step.
d) Arranging blocks: The lists of rules and chosen
blocks are then given to an evolutionary algorithm, which
then solves the optimization problem. It starts initially with a
set of legal but otherwise random arrangements of the blocks
and then modifies and evaluates the current configuration
over many iterations. In consequence of the random-based
method of the evolutionary algorithm, a set of pareto-optimal
solutions is presented to the engineer. A satisfying configu-
ration is usually found after 500 iterations with a population
size of 200 for satellites with up to 30 blocks.
Details on the modeling, the deducing of rules and the
arrangement process can be found in [6] (German).
V. T HOUGHTS ON SERVICING A SATELLITE
When thinking about how to service a modular satellite
two major options come to the mind: obviously a servicer
satellite equipped with robot arms can perform the services.
But it would also be possible to install several more simple
active blocks with some inherent DOF on satellites, at least
on larger ones. These might be able to transport or replace
blocks without the need of a servicer. These could be used
for easier maintenance tasks or to support a servicer e.g.
by opening up a gap in which the servicer could work. In
addition to the manipulators, sensor systems similar to the
ones found in robotics are necessary to perform robotic tasks.
Concepts for both are sketched in Fig. 12 and 13. Details
on the various manipulation scenarios can be found in the
related publication [8].
Special challenges are posed when servicing in the earth
orbit. The manipulation has to be performed while floating
without any reaction forces. The servicer has a limited
supply of fuel itself which must be spent as economical as
possible. The task becomes even more challenging as satellite
operators are not willing to shut down a satellite while being
serviced as they have rented the transponder capacity and
have to pay high fees if the transponders are not available.
Consequently, satellites would have to be serviced while in

Fig. 12. Special active building Fig. 13. Exemplary sensor blocks
blocks with 3 DOF can transport with rotating laser range finder and
other blocks or open gaps in the camera mounted on miniature arm
lattice structure. for inspections.
operation (unless they are completely dead anyway). Even
more critical are legal, operational and insurance issues: Who
is responsible if the servicer is not able to repair a satellite
and instead damages it further and parts of the satellite hit
other satellite, or worse, the satellite crashes back to earth in
an habited area?
VI. I MPLEMENTATION AND ENVISIONING FUTURE
ORBITAL INFRASTRUCTURES
This concept could be implemented in four succeeding
steps. In the first step conventional satellites could be
equipped with an idle interface. In case of a damaged sub-
system a replacement subsystem could be delivered housed
in a building block which will be attached to the interface
(sketched in Fig. 14). In the second step, the subsystems with
the highest rate of failure would be housed in blocks while
the remaining satellite would be of conventional design. Step
three could be implemented once a sufficient number of
blocks is designed: the completely modular satellite. And
finally, step four envisions medium scale orbital platforms
which are hosted by satellite operators or agencies. On these
platforms docking ports are rented for telecommunication
companies (see Fig. 15). These would not have to launch
complete satellites including fuel and altitude control but
few transponder blocks only, lowering the costs significantly.
Replacement blocks could be launched into the orbit riding
along with supply flights to the ISS. The ISS itself, or
discarded ATVs, could be used as repository for replacement
blocks or fuel for the servicer satellites.
Fig. 14. Satellite with Fig. 15. Platform with local servicer and
additional solar array rented docking ports for commercial blocks.
VII. D ISCUSSION AND C ONCLUSION
In this paper we have introduced concepts for a visionary
future type of modular satellite system which is strongly
inspired by current earthbound modular robots. The concept
envisions satellites to be constructed out of a satellite con-
struction kit which consists of a set of cube-shaped building
blocks. The resulting satellite can accordingly be described
as heterogeneous modular robot in lattice structure. Along
infrastructure components we described the most crucial
component of the modules: the interfaces to connect adjacent
blocks. Additionally we presented a software framework for
controlling the system and software tools for a computer-
aided satellite design process.
Finishing the first phase of the project, the current tech-
nology readiness level (TRL) is three. Starting second phase,
the TRL shall be raised up to five. Besides raising the TRL,
the focus will shift to the robotic manipulation, designing
a service mission architecture and finally to an additional
economic point of view.
VIII. ACKNOWLEDGEMENTS
This work was supported by the Space Agency of the
German Aerospace Center (DLR), with funds provided by
the German Federal Ministry of Economics and Technology
(BMWi), following a resolution of the German Bundestag
under the promotional reference 50RA1007.
R EFERENCES
[1] B. K. A N : Em-cube: cube-shaped, self-reconfigurable robots sliding
on structure surfaces. Proc. of the IEEE International Conference on
Robotics and Automation (ICRA), Pasadena, California, USA, 2008.
[2] O NLINE : DLR W EBPAGE : ”DEOS”, visited July 2012
http://www.weblab.dlr.de/rbrt/OOS/DEOS/DEOS.html
[3] A. C ASTANO AND P. W ILL : Mechanical Design of a Module for
Autonomous Reconfigurable Robot. Proc. IEEE/RSJ Intl. Conf. In-
telligent Robots and Systems (IROS), Takamatsu, Japan, 2000
[4] O NLINE : DARPA: ”Phoenix Program”, July 2012, www.darpa.mil
[5] K. G ILPIN , A. K NAIAN , AND D. RUS : Robot pebbles: One centimeter
modules for programmable matter through self-disassembly. Proc.
of the IEEE Intl. Conference on Robotics and Automation (ICRA),
Anchorage, Alaska, 2010
[6] M. G ÖLLER ET. AL .: Modellierung und Konfigurationsgenerierung
für bausteinbasierte Satellitensysteme. Proc. of Deutscher Luft- und
Raumfahrtkongress (DLRK), Bremen, Germany, 2011
[7] NASA RRM FACTS S HEET: National Aeronautics and Space Admin-
istration, Goddard Space Flight Center, 2012
[8] J. O BERL ÄNDER ET. AL .: Management and Manipulation of Mod-
ular and Reconfigurable Satellites. Proc. of German Conference on
Robotics (ROBOTIK 2012), Munich, Germany, 2012
[9] L. P FOTZER ET. AL .: Biologically-Inspired Locomotion with the
Multi-Segmented Inspection Robot Kairo-II. Proc. of the International
Conference on Climbing and Walking Robots and the Support Tech-
nologies for Mobile Machines, France, 2011.
[10] P. R ANK , W. NAUMANN , ET. AL .: DEOS automation and Robotics
Payload. Proc. of the Symposium on Advanced Space Technologies
in Robotics and Automation (ASTRA), the Netherlands, 2011
[11] S. TANG , Y. Z HU , J. Z HAO AND X. C UI : The UBot modules for
self-reconfigurable robot. Proc. of the International Conference on
Reconfigurable Mechanisms and Robots (ReMAR), London, UK, 2009
[12] K. U HL ET. AL .: Ein Software-Framework für modulare, rekonfig-
urierbare Satelliten. Proc. of Deutscher Luft- und Raumfahrtkongress,
Bremen, Germany, 2011
[13] L. W INKLER , H. W ÖRN , AND A. F RIEBEL : A Distance and Diversity
Measure for Improving the Evolutionary Process of Modular Robot
Organisms. Proc. of the IEEE International Conference on Robotics
and Biomimetics (ROBIO), Thailand, 2011
[14] J. W EISE ET. AL .: Ein Bausteinkonzept für Wartungsfreundliche und
Rekonfigurierbare Satelliten. Proc. of Deutscher Luft- und Raum-
fahrtkongress (DLRK), Bremen, Germany, 2011
[15] J. W EISE ET. AL .: An Intelligent Building Blocks Concept for On-
Orbit-Satellite Servcing, in Proc. of the International Symposium on
Artificial Intelligence, Robotics and Automation in Space (i-SAIRAS),
Turin, Italy, September 2012
Vie