Concept of Operations and Preliminary Flight Model Design of a Modular Multi-Arm Robot using Standard Interconnects for On-Orbit Large Assembly

Full text

Page 1 of 15
Concept of Operations and Preliminary Design of a Modular Multi-Arm Robot using Standard
Interconnects for On-Orbit Large Assembly
Mathieu Deremetza*, Gerhard Grunwald b, Francesco Cavenago c, Máximo A. Roab, Marco De Stefanob,
Hrishik Mishrab, Matthias Reinerb, Shashank Govindaraja, Alexandru Buta, Irene Sanz Nietoa, Jeremi
Ganceta, Pierre Letiera, Michel Ilzkovitza, Levin Gerdes d, Martin Zwick d
a Space Applications Services NV/SA, Leuvensesteenweg 325, 1932 Sint-Stevens-Woluwe (Brussels Area), Belgium,
firstname.lastname@spaceapplications.com
b Institute of Robotics and Mechatronics, German Aerospace Center (DLR), 82234 Wessling, Germany,
firstname.lastname@dlr.de
c Leonardo S.p.A., Viale Europa, 20014 Nerviano (MI), Italy, firstname.lastname@leonardocompany.com
d Automation and Robotics Section, European Space Agency (ESA), Keplerlaan 1, 2201 AZ Noordwijk, The
Netherlands, firstname.lastname@esa.int
* Corresponding Author
Abstract
The capability of assembling large structures in space is essential to meet the requirements of the future space
exploitation and exploration missions. Whether for collecting solar power, or reflecting radio signals or light,
dimensions matter. In fact, large structure are continuously increasing in size to bring increased scientific (or
commercial) benefits. The studies conducted today foresee structures that will be too large to be launched into orbit
as a single self-deploying piece that can be contained in standard launcher fairings. While few concepts exist to
perform self-deployment of large structures in space, the approach taken here is based on standard modules that will
be assembled in space by a robotic system launched along with the modules. Furthermore, it is assumed that the
spacecraft structure and modules will be equipped with Standard Interconnects (SI) that will allow their mating to
each other and to the robot system for manipulation/transport, as well as allowing the robot system to move across
the structure.
This paper introduces the concept of operations and preliminary flight model design of a novel modular multi-
arm robot (MAR). The MAR is composed of three modules - a torso and two symmetrical 7-degree of freedom
(DOF) anthropomorphic arms with non-spherical wrists - that are functionally independent and can be connected by
the means of SIs to form the MAR. The torso is the main body of the robot. This mechanical hub can mate with three
other modules (arms and/or payloads). The torso can also be attached directly to the spacecraft structure. It provides
the required power, synchronizes and forwards high-level information to its connected modules and hosting
spacecraft. The torso is equipped with exteroceptive sensors for monitoring purposes. The two 7-DOF manipulators
are the limbs of the MAR: they serve as arms or legs depending on the desired configuration and are used to
manipulate payloads or to relocate the robot.
The MAR modular approach aims at reducing the burden of developing and launching a complex, large and
monolithic robotic system by splitting it into a smaller number of more manageable components. By taking
advantage of separating and recombining the manipulators in different configurations, this approach extends the
range of possible operations and provides an intrinsic system redundancy that reduces overall mission risks.
The MAR concept introduced in this paper is developed as part of the European Space Agency’s MIRROR
project.
Keywords: Space robotics, Relocatable robot, Modular robot, Mechanism Design of Manipulators, Standard
Interconnects
Acronyms/Abbreviations
European Space Agency (ESA), Energy Storage System
(ESS), Failure Detection Isolation and Recovery (FDIR),
Guidance Navigation and Control (GNC), Kinematic-
Dynamic-Graphic (KDG), Low Earth Orbit (LEO),
Monitoring and Control Center (MCC), On-board
computer (OBC), Orbital replacement unit (ORU),
Power distribution unit (PDU), Robot control unit
(RCU), Servo control unit (SCU), TC (Telecommand),
Telemetry (TM).
1. Introduction
In recent years, the space industry has undergone
profound changes. A larger offer in a growing new
space industry following the path of SpaceX resulted in
a continuous drop in launch costs. These new actors
participate in a transformation of the space industry

Page 2 of 15
similar to that which occurred previously in the aviation
industry.
Large structures in space are an essential and
recurring element for space exploitation and
exploration. Whether for collecting solar power, or
reflecting radio signals or light, dimensions matter.
In fact, large structures are continuously growing in
size with the aim to bring increased scientific and
possibly economic returns. We are already at the stage
in which next structures foreseen will be too large to
launch into orbit as single self-deploying pieces. The
“assemble, maintain and service” paradigm (already
applied with e.g. the ISS) may facilitate the design and
life extension of the most challenging missions. This
approach is consistent with a strategy favouring
multiple lighter launches instead of fewer heavier ones.
However, the formula assemble / maintain / service
in orbit is challenging to implement. In this context,
robotic technologies are instrumental to implement safe
and dependable assembly, maintenance and servicing
capabilities.
Inspired by these OSAM considerations, the work
reported in this paper describes a notional mission,
preliminary design and concept of operations of a multi-
arm installation robot for assembling large structure in-
orbit.
Fig. 1. Artist representation of the MAR concept.
This work, developed within the ESA MIRROR project,
leverages results, concepts or ideas from a number of
previous European projects: H2020 Space Robotics
projects (ESROCOS [1], SIROM [2], PULSAR [3] and
MOSAR [4-6]), ESA ISS EUROBOT project [7], ESA
TRP Dexterous Robot Arm (DEXARM) [8] and
standard interconnects (SIROM, ISSI [9] and
HOTDOCK[10]).
The structure of this paper is as follows: Sec. 2
details the mission scenario while Sec. 3 details the
preliminary design of the MAR (see Fig. 1). Then Sec. 4
details the concept of operations and Sec. 5 finally
provides a conclusion on the work achieved so far and
presents the perspectives on future activities.
2. Mission Scenario
2.1 Operational environment
In the frame of the MIRROR project, a robot is assumed
to provide self-assembly and self-maintenance
capabilities to large spacecrafts. The choice of the space
orbit in which the robot operates could be a key factor
for the definition of the operations concept. In
particular, the motion of the robotic arms can modify
the mass distribution of their host spacecraft and
consequently it could have an effect on the satellite
attitude and orbit states under the application of gravity
gradients. This effect must be logically compensated by
dedicated maneuvers operated by the spacecraft GNC.
According to this, since gravitational forces in Low
Earth Orbit (LEO) are only moderately lower than on
earth, an important set of GNC operations could be
necessary in LEO for compensating the effects of the
robot motion on the spacecraft. On the contrary, orbits
around Sun-Earth Lagrangian points at which the
gravitational field is null may not imply these issues.
Fig. 2. Sun-Earth Lagrangian points from [11].
Moreover, in LEO there are also atmospheric effects
that affect the pointing accuracy, and, more specifically
for telescopes, the orbits can be quite fast determining
different illumination conditions and limiting the
availability of the telescope to collect data. At the
contrary, orbits around Sun-Earth Lagrangian points
(See Fig. 2), at which the atmospheric effects are
negligible and the sun illumination is constant, could
not imply these issues.
Relying on these considerations as drivers, a feasible
assembly sequence for a space vehicle self-assembled in
orbit at the Sun-Earth L2 Lagrangian point, using small
robotic arms is assumed for a preliminary orbital
demonstration.
2.2 Spacecraft architecture at launch
MIRROR is a robotic system which provide self-
assembly and self-maintenance capabilities to a satellite.
In this scenario, a hosting spacecraft located in the Sun-
Earth Lagrangian point is assumed, acting also as a

Page 3 of 15
logistic node for additional servicing operations. As a
baseline, the hypothesis is to have a multi arm robot
stowed in the satellite at his home base attached to the
satellite primary structure by means of standard
interfaces. The spacecraft includes a service module, a
payload module and a dispenser storing the individual
mirror tiles. Fig. 3 shows the assumed multi arm robot
stowed configuration in the Ariane-6 satellite during the
launch phase:
Fig. 3. Launch configuration.
Once the spacecraft has reached the Sun-Earth L2 point,
the assembly sequence is initiated. The operation is
assumed to start with the deployment of a heat shield to
protect the temperature-sensitive electronics of the
telescope imager.
2.3 Reflector tile assembling methods
As previously stated, the multi arm robot system shall
be able to assemble reflectors in orbit. In the frame of
this project the simplest reflector assembly sequence has
been assumed based on the manipulation and
transportation of multiple hexagonal mirror tiles thanks
to dedicated standard interfaces. The robot is capable to
take tiles from the tile container and move them one by
one through the go/back path from the tiles container to
the primary mirror support. The robot operations are
assumed to be based on the following repeatable four
operational steps:
 Fetching the tile from the top of the tile
container at the robot home base.
 Transportation of the tiles one by one from
their container to the reflector primary support.
 Installation of the tiles on the reflector support
locations.
 Return of the robot to its home base.
Fig. 4 shows the assembly sequence of the first three
tiles.
Fig. 4. Start of mirror assembly installation of the first
three tiles on the reflector primary support.
The robot repeats these operations for all the tiles one
after the other in order to achieve the desired reflector
pattern. After having placed the first three tiles on the
primary support, the multi-arm robot is assumed to
continue the assembly with a second half-ring,
surrounding the three tiles placed in the previous step as
shown in the Fig. 5.
Fig. 5. Assembly of the outer half-rings of tiles.
After completing the second half-ring, another upper
half-ring is laid around and this operation is assumed
achievable by the robot by walking along the standard
interfaces placed on the back of each tile. This operation
is repeated until the desired mirror diameter is reached.
The assumed process to firstly complete the assembly of
the upper half rings of the reflector and secondary the
lower one, is applied because the spacecraft architecture
assumed to be characterized by the tile container placed

Page 4 of 15
sufficiently close to the primary mirror master tile to
minimize the dimension of the spacecraft itself. When
enough tiles are retrieved from the tile container, any
possible obstruction can be avoided and, consequently,
the assembly of the lower half ring can start. The
process continues with the assembly of tiles on the
bottom “sides” of the mirror as illustrated in Fig. 6.
Fig. 6. Placement of the side tiles.
Finally, the robot concludes the assembly with the tiles
located at the bottom of the structure, starting with the
inner ring tiles. Fig. 7 presents the final aspect of the
primary mirror. It should be noticed that the first ring of
tiles (six tiles) is directly attached to the central
component. All the other tiles are attached together to
obtain the desired pattern.
Fig. 7. Placement of the bottom tiles.
2.4 Docking configuration
In the case of the assembly of very large reflectors, a
single launch may not be able to lift all the required tiles
due to the limited dimensions of the container.
Therefore in order to have enough tiles for the assembly
of a very large structure, the telescope is assumed to
host a servicer module which can bring additional tiles
as well as ORUs for maintenance. In particular, the
telescope service module is assumed to be equipped
with a docking port. An illustration of the servicer
spacecraft docked with the telescope is shown in Fig. 8.
Fig.8. View of the servicer and telescope during
assembly.
Once the rendezvous is established, the required tiles
can be deployed by the multi-arm robot with its direct
access to the servicer. The robot can then unload the
tiles by applying the same operations as described
above.
This modular approach can also enable maintenance
and repair opportunities through the robotic
manipulation and transportation of dedicated
replacement units and/or new mirror tiles which could
eventually replace damaged reflector segments. In case
of damaged tiles, the robot is assumed to intervene to
replace the defective tile without disassembling the
whole structure. Therefore maintenance operations can
be accomplished when strictly necessary.
Moreover, once the rendezvous is established, the
required tiles and operational payloads can be installed
by the robot, before stowing the defective or obsolete
ones on-board the Servicer. The Servicer module finally
undocks and applies a suitable strategy to dispose the
defective/obsolete elements (de-orbiting or other)
2.5 Standard interconnects
As previously stated, the multi arm robot system
shall be able to relocate itself over a spacecraft and also
over the servicer and the already installed modules
allowing the transportation of reflector segments from
their storage area up to operational placement.
The process to permit the robot system locomotion
on the servicer, satellite and reflector structure, is based
on standard interfaces located on the satellite modules
(satellite and servicer) and placed on the back of each
tile. Such Standard Interconnect (SI) are assumed to
connect:
 modules to modules
 modules to spacecraft
 robot to module
 robot to spacecraft
The SI provides mechanical, data, and power
transfer capabilities.

Page 5 of 15
The number and location of standard interfaces is
assumed to be optimized such to facilitate all the
operations. This is the case for:
 each hexagonal mirror tile assumed to be
equipped with standard interfaces in its
boundaries and back side.
 the robot assumed to be equipped with standard
interfaces at both end-effector and legs levels.
 primary structure assumed to have a sufficient
number of standard interfaces such to avoid
misalignment issues.
3. MAR Preliminary Design
3.1 System overview
Since the MIRROR project adopts a modular
approach to the mission relying on SIs, we propose to
adopt the same philosophy for the MAR. A modular
design should reduce the overall complexity by splitting
the system into less complex subsystems [12]. This
approach should also bring a longer lifetime to the
device (maintenance-free design, built-in growth
potential and upgradeability, replaceable modules for
maintenance) and should reduce risks related to long
planning and development phases.
Thus, the MAR system, depicted in Fig. 9, is a
modular robot composed of three robotic subsystems: a
torso equipped with a 1-DOF leg and two 7-DOF,
human like, arms with non-spherical wrist robotic
manipulators
 The torso is the main body of the robot. This is
a mechanical hub that can equip three other
modules (limbs or payloads). The torso can be
attached directly to the spacecraft structure. This
central module will provide the required power and
synchronize or forward high-level information to its
connected modules. The torso is also equipped with
vision and perception devices on its “belly” surface,
and potentially with a solar panel on the “back”
surface.
 The robotic arms are comparable to the limbs
of the robot. These modules act as arms or legs
depending on the desired configuration of the robot.
They can be used to manipulate payloads or to
relocate the robot.
The different modules (torso and robotic
manipulators) are independent entities that can be
gathered by means of standard interconnects (SI).
The modularity concept informs the design of the
avionics for the MAR. The arms are designed to operate
as a unit with the Torso or independently from the
Torso. To manage this complexity, the Torso and arms
are each quipped with a Robot Control Unit (RCU)
tasked with controlling the joints. At any time, only one
RCU of the MAR will be commanding all the joints.
Each joint is equipped with a built-in, independent,
servo unit controller (SCU) to execute set points
originating from the active RCU.
Fig. 9. MAR system assembly: torso (grey) and robotic
manipulator (orange).
The following of this section describes the different
building blocks and subsystems involved in the MAR
concept.
3.2 HOTDOCK
Fig. 10. HOTDOCK robotic mating interconnects.
HOTDOCK shown in Fig 10. [1] is the selected
standard interconnects for the MAR. It is an
androgynous standard robotic mating interconnects,
developed by Space Applications Services NV
(Belgium), supporting mechanical, data, power and
thermal transfer. It is primarily designed to allow on-
orbit modular assembly and reconfiguration of
spacecraft elements.
HOTDOCK simplifies the replacement of failed
modules and allows for payloads swapping. At the same
time, HOTDOCK provides chainable data interfaces for
multiple module configurations.

Page 6 of 15
HOTDOCK features the following coupling
elements:
 A mechanical interface that provides:
- alignment;
- coupling/connection;
- mechanical load transfer capability.
It is composed of fixed elements (main body
structure and the form fit geometry) and a
movable locking ring to allow connection with
another device. Furthermore, the geometry of
HOTDOCK makes it androgynous and 90-
degree symmetrical.
 A central functional interface comprising a
contact plate with spring-loaded pins and pads
that enables:
- transfer of electrical power;
- transmission of data through CAN or
SpaceWire protocol;
HOTDOCK embeds its own controller for local
management (actuator, sensor, TM/TC communication)
and rear connectors harnessing giving access to the
power/data interface pins and the internal
controller/powering of the device.
3.3 Robotic manipulator
The robotic manipulators of the MAR, depicted in
Fig. 11, is a robotic device similar in to [6]. It comprises
the following elements:
 Structure (Limbs) – The manipulators is
composed by eight structural elements. The
overall configuration of the manipulator is
based on a human-like arm with asymmetric
joints. The arms are 1.8-meter long.
 Motorization (Robotic joints) – The walking
manipulator is equipped with seven revolute
joints according to the following symmetric
configuration R┴R┴R┴R┴R┴R┴R, where R
indicates a revolute joint and ┴ the
orthogonality between two successive joint
axes (see Fig. 6).
 End effectors (HOTDOCKs) – Each extremity
of the robotic manipulator is equipped with a
Standard Interconnect (SI), namely
HOTDOCK. These interfaces allow the robot
to relocate, since the arm can be attached to a
supporting structure on both sides.
Fig. 11. Overview of the robotic manipulators.
 Avionics – Fig. 12 represents the avionics
architecture of the robotic manipulators. The
RCU is physically located in the middle of the
arm, thus in the avionics architecture it is
connected to the closest SCUs over EtherCat.
Due to the flexible EtherCAT topology, the
master (RCU) can be located in the middle of
the slave (SCU) network. The RCU
implements a sense-plan-act control receiving
high level commands from the data channel in
the SI attached to the spacecraft network
though the CAN (CAN_A) data bus, sending
commands to the SCUs as well the two SIs of
the arm to execute the coordination motion.
The EtherCAT SI interface is used when the
Torso RCU takes over and the arm RCUs
becomes simple EtherCAT routers.
The two SIs at the arm’s extremities provides
sensing status and state of the environment
through the CAN data bus to the RCU thanks
to the sensor suite. It contains the proximity
sensors as well the docking confirmation.
For each of the joints constituting the arm,
there are SCUs associated. The Servo Control
Unit commands the joint motor by receiving
high level motion based on data received via
EtherCAT and powered via PDU. There are
brakes and sensors associated to it, which are
redundant, while the motors are not redundant.
The whole arm is powered via the PDU on a
48V power bus.
The system is hot redundant with cold
redundant in wiring. The SCUs, RCU and PDU
subsystems are hot redundant. Each subsystem
is connected to nominal and redundant power
and CAN data lines. For the PDUs, a single
output on each of the redundant PDUs is
providing power to one chain (nominal or
redundant).

Page 7 of 15
Fig. 12. Arm avionics preliminary architecture.
3.4 Torso
The torso of the MAR, illustrated in Fig. 13, is
composed as follows:
 Mechanical Structure – The torso is a truncated
tetrahedron. Since the configuration includes
two robotic arms for walking/manipulating and
one attachment point for ORUs, this structure
has an equilateral triangle baseline. To allow
serial or parallel manipulation and relocation
without restricting the workspace areas, the
sides of the torso are chamfered.
 Two fixed active HOTDOCKs - Two of the
three main corners of the torso are equipped
with static HOTDOCKs on which the two
“robotic manipulators” will be attached.
 One actuated active HOTDOCK - The leg (one
rotation around its main axis). The third point
of the torso is used for grasping payloads
(mirror tiles or ORUs) or to attach to the
spacecraft. This attachment point also uses a
HOTDOCK. The particularity of this third
attachment point is its mobility. Indeed it
allows either the torso to rotate the payload
when manipulating or to spin itself around if it
is attached to the spacecraft.
 Perception Sensors and Lighting Modules –
Due to the geometry of the torso, the belly can
be mostly protected from exterior illumination.
This surface is equipped with a camera, at the
center, and lighting modules to monitor the
assembly and manipulation tasks carried out by
the robot.
 Solar Array - Thanks to the geometry of the
torso, its wider surface (back) may be exposed
to light sources. Taking advantage of this, this
surface will be covered with a solar panel used
to recharge the internal battery and allow
limited operations/survival modes even if
sufficient power is unavailable.
Fig. 13. Overview of the MAR’s torso.

Page 8 of 15
 Avionics – The RCU and the SCU of the Torso
have the same functionalities as for the arms
and they control the robotic mechanisms.
The MAR shall be able to autonomously
move on the tile without direct power transfer
from the network through its SI. This is
achieved by the ESS (Energy Storage System).
The power is distributed via ESS and generated
from the batteries. The batteries charging will
be achieved via functional SI (from power
network through the SI) or home-base (from
the Solar Panel via MPPT line). The change
from powering from ESS is achieved by the
means of switching the power source in the
Power Distribution Unit.
The perception and lightning sensor is
powered directly from the PDU and provide the
telemetries to the MAR via a SpaceWire link to
the RCU.
There are three SIs connected to the Torso.
The two SIs, HOTDOCK A and HOTDOCK C
are the ones connecting to both arms. The third
SI, HOTDOCK B is connected at the end of the
1-DOF leg (revolute joint). The associated
SCU, motor, sensor and brake allow the Torso
to spin around when it is directly attached to
the spacecraft, as well to mount the title or
ORU by the means of the SI.
As for the arms, the Torso is powered via a
48V power bus.
The system is hot redundant and cold
redundant in wiring. The SCU for controlling
the 1-DOF leg, the RCU, the PDU and the ESS
subsystems are hot redundant. The detailed
avionics architecture of the Torso is presented
in Fig. 14.
3.5 Control
This paragraph describes the separation of on-ground
robot task generation and the on-board execution of the
MAR tasks. Based on the knowledge of the current state
of the telescope and the desired configuration, the
purpose of the task generation process is to create and
verify the step-by-step sequence of operations that can
be interpreted and executed by the space segment to
reach the final state.
The starting point is a planner to propose a set of
operation sequences. The plan can be developed at
different levels, from robot manipulator independent
description to robotics layer (that can be interpreted and
executed by the space segment), which means that all
the approach, pick, transfer and place operations are
defined with the respective values, e.g. the desired
Cartesian pose of approach phase. The planner can
consider known design constraints (e.g. availability of
Fig. 14. Torso avionics preliminary architecture.

Page 9 of 15
an active standard interface) in the preparation of the
task plan. Once a valid operation plan is available, a
Kinematic, Dynamic & Graphical (KDG) simulator will
verify the validity of the operation plan, ensuring that
the robot motions are feasible and collision free. If the
plan is verified, the step-by-step sequence of operations
can be uploaded to the central RCU controller of the
MAR for later execution.
It should be emphasized, that the plan verification
on-ground and the plan execution on-board have the
same core functionalities with the same interfaces to
mirror the behaviour of the system on-board on the
simulator on-ground.
The MAR can be seen as one robot system
consisting of a torso, two arms and a leg. In order to
increase the flexibility of the robot system, the MAR
can also be seen as a set of three independent robot
systems. This would allow to operate the single arms
and the torso including leg separated and independent
from each other. Thus, all three systems have to be
equipped with own RCUs. The main RCU is assigned to
the torso. Besides the control of the leg, it distributes the
commands/plans to the according arms. It acts as the
single point of contact for the communication from and
to the OBC. In case of connected systems i.e. the MAR,
one predetermined RCU may control the full set-up.
Independent of the specific configurations, all robot
operations lead to a restricted set of robot commands.
As we have a torque and position-controlled robot
system, the necessary robot motion commands are the
following ones:
 Move at Cartesian level
 Cartesian position controlled, requires
Inverse Kinematics
 Cartesian impedance controlled,
requires calculation of kinematics
parameters, e.g. the Jacobians
 Move at Joint level
 Joint position controlled
 Joint torque controlled
 Only a few additional configuration commands
are necessary
 to power on/off the robot
 to switch into the desired control
mode
 to parameterize the controller.
The current state of the execution is described by a
set of state variables which will be analyzed by the state
observer to feed back the current execution state to the
on-board task interpreter (to trigger the state machine)
as well as to the ground for further interpretation, for
example in case of failures or unexpected behaviour.
3.6 Software
3.6.1 Component and deployment diagram
The overall software architecture of the MIRROR
MAR system, depicted in Fig. 16, consists of software
components deployed on the core processing system -
RCU (Robot Control Unit) which are aimed at
managing the core functionalities of the MAR’s sub-
systems consisting of the following:
 MAR Manager - This software component is
the main orchestration and state management
module with FDIR capability. A set of commands
received from the ground segment via the
communications interface is interpreted into a set of
steps to be executed by dispatching or invoking the
functionalities provided for task or sub-system
specific software managers. This module sends
specific requests to the other modules in sequence
or in parallel and manages the response to achieve
the required behavior for a set of high-level
commands.
 Manipulation controller (Robot Motion
Controllers for two robotic manipulators and the
leg) - This software component is a high-level
controller which is an executor of a pre-planned
trajectory received from the ground segment. The
manipulation controller translates the joint and end
effector motion commands to the formats
interpreted by the low-level controllers via
EtherCAT with real time constraints. The joint state
feedback from the joint encoders, current and
torque sensors are sent back to the manipulation
controller via EtherCAT for a closed loop high-
level control of the manipulator motion to the
desired end effector position or pose. The feedback
of motion completion, start or errors is provided to
the MAR manager.
 HOTDOCK Manager - In the HOTDOCK
Manager the commands from the MAR Manager
and from the Manipulation Controller are checked
and piped to the HOTDOCK Driver. Information
related to the state of all the HOTDOCK devices of
the system is piped to both MAR Manager and
Manipulation Controller.
 Sensors & Data Fusion - This software module
implements the interface to command and receive
data from the camera(s) low-level drivers to
perform image processing for target pose
estimation using fiducial markers (Ex. Aruco). The
data fusion here is performed from the relative pose
estimation together with the joint states of the MAR

Page 10 of 15
and IMU data. This information is provided to the
MAR manager.
 Lighting Manager - This software component
is a basic high level controller for controlling the
lighting system on the MAR for actively
illuminating it’s workspace for the cameras to
function and to provide video telemetry for the
ground segment. The commands for controlling the
lighting comes from the ground segment via PUS
services to the MAR manager and this is dispatched
to the lighting controller for further sending device
driver specific commands.
 Ground Control Interface - This is a set of PUS
services to send goals and receive observations to
or from the ground segment via a wireless
communication link between MAR and the parent
spacecraft. This component also provides a
communication route Between the MAR and the
parent satellite for TM/TC data exchange with the
ground segment via the satellite’s main
communication sub-system.
3.6.2 RCU software stack
Fig. 15. shows the RCU software stack and its core
software components are described below:
 Application Layer: represents the software
specific to the MAR Implementation. The
middleware that handles the communication
between the different components is TASTE and
the data types exchanged are the ones defined in
ESROCOS. Each software component runs in a
separate taste function at a predefined rate and
communicates with the other components via
ASN.1 serialized objects.
All the components described in section “Software
Interfaces” are designed to be deployed in the
application layer. The TASTE development tool is
created for safety critical system development and
connects natively with the RTEMS operating
system designed to be installed on the RCU.
The components running on RTEMS on the flight
model are to be developed in C language and
respecting MISRA C:2012 standard. The FDIR and
OBDH will be deployed in the application layer
using the TASTE framework for modelling.
 Operating System Layer: makes use of RTEMS
OS build for LEON 4 processor. The OS includes
the timers, watchdogs and memory access
managers. The HAL layer used will be the one
provided by the RTEMS OS for LEON4.
 Redundancy: the available software stack is
bundled on the hardware in a duplicated way with a
redundant version accessible from the same
bootloader. Onboard bootloader can be configured
to attempt loading the nominal image and in case of
failure to fall back to the redundant one.
Fig.15. RCU software stack.
Fig.16. MAR’s Application Layer Deployment view.

Page 11 of 15
The boot up in the back-up image will attempt a repair
on the nominal system and will load the redundant
version upon the failure of the repair.
4. Concept of Operations
4.1 System identification
The operational concept of MIRROR addresses the
application of mirror tiles and ORU assembly
operations. As introduced and illustrated in Sec. 2, the
baseline scenario features a Telescope/Servicer
spacecraft transporting a set of mirror tiles, an ORU,
and a dedicated Multi Arm Relocatable Manipulator
(MAR). The MAR performs a number of operations,
transferring mirror tiles and ORUs from the servicer to
the telescope structure, with the purpose to assemble a
space reflector.
Fig.17. Operational Concept.
The main purpose of the MAR is to transfer the
mirror tiles between the storage area and the telescope
structure. In order to answer the problem of reachability,
the MIRROR project is based on the implementation of
a Multi-Arm Relocatable manipulator that ensures high
mobility along the structure. Equipped with Standard
Interconnects at both of its end-effectors and at the leg,
it can attach and manipulate the mirror tiles and ORUs,
and move along the structure by connecting to the SIs.
This connection may also be used to power the robotic
system and transfer the control commands coming from
the spacecraft computer.
The autonomous transfer and configuration of the
mirror tiles follows an execution plan prepared and
validated off-line in the Monitoring and Control Centre
(MCC), the ground segment. The valid execution plan is
finally uploaded to the MAR for execution. The MCC
supervises the execution of the plan in real-time via
monitoring and feedback information received from the
MAR. The MCC includes visualisation front-end tools
to support the design, verification and monitoring
activities during sequence execution.
The following subsections provide the list and short
description of the MAR operations including the basic,
reconfiguration, restricting, observation and charging
ones.
4.2 MAR basic operations
In the MIRROR operational concept, the MAR has an
active role, manipulating the mirror tiles and/or ORU
through interactions with the SIs, and relocating along
the structure. In this subsection, the basic and generic
operations are described and summarized in Table 1.
Table 1. MAR basic operations
 Walking operation
The MAR is equipped with seven active SIs (three on
the torso, and two per arm: one on the shoulder and the
other one on the arm tips) and each of these SIs can be
used for moving the robot according with the degree of
freedom of the robotic articulations. However, the
locomotion of the robot over the spacecraft is
accomplished by moving the arms from an initial pose
to a destination pose thanks to the SIs mounted to the
arm end-effectors which will engage the SI of the
structure (including the SI of servicing and installed
modules). It is assumed that the spacecraft structure is
equipped with passive (interfaces not actuated providing
only power and data connectivity) and mechanical
(interfaces not actuated and not providing power and
data connectivity) SIs. The locomotion is in particular
performed assuring the connection of at least one
MAR’s SI at any time.
Fig.18. Artist representations of the walking operation.

Page 12 of 15
 Transportation operation
The MAR transfers a mirror tile or ORU from a storage
position to a target position for assembly. This operation
is similar to the walking operation, except the MAR is
now transporting a mirror tile or ORU connected to the
SI of its Leg.
Fig.19. Artist representations of the transportation
operation.
 Manipulation operations
The set of operations for acting on tile and/or payloads
by using robotic arms or leg is defined as manipulation
operation.
Fig.20. Artist representations of picking a tile with the
torso leg.
In particular, two types of manipulation operations are
envisaged:
 the pick/place operations for moving or
transferring a tile and/or payload from an
arm/torso to the servicer, target satellite
and/or reflector structure (and vice-versa,
from the servicer, target satellite and/or
reflector structure to an arm/torso),
 the arm transferring operations for moving
or transferring a tile and/or payload from
one MAR’s SI to another one (arm or leg).
 Repositioning operation
The MAR must be able to reposition itself depending on
the selected configuration for achieving the
aforementioned operations. In particular the MAR must
be able to move from a configuration where its leg is
fixed to the telescope structure (or servicer or tile
reflector) and its arms SIs are open, to a reverse
configuration where its leg SI is open and its arms are
connected to SIs of the telescope structure (or servicer
or tile reflector). The repositioning of the MAR with its
torso leg fixed to the structure (or servicer or tile
reflector) is needed to pick and/or place operations with
arms. At the contrary, the repositioning of the MAR
with arms fixed to the structure (or servicer or tile
reflector) is needed to pick and/or place operations with
the torso leg and also for walking and transportation
operations. The storage and release operations of the
MAR to/from its home base are also included in the
repositioning operations.
Fig.21. Artist representations of the MAR attached to
the structure via its leg.
4.3 MAR reconfiguring operations
The MAR involves an increased modularity capability
in order to enable self-maintenance and auto-repairing
opportunities through its robotic manipulation.
Therefore, in case of damaged arms, the robot must
operate to detach or attach new arms from/to its torso.
This modularity capability can be also exploit for
achieving advanced configurations, like for instance the
implementation of additional arms in series to the
already installed ones and/or for instance the
reconfiguration of its arms from an extended
configuration to a shorter one. The MAR
reconfiguration operations are synthesized in Table 2.
Alternative operations to the proposed ones might be
envisaged depending of the MAR initial conditions and
operational complexity.
Table 2. MAR reconfiguring operations

Page 13 of 15
Fig. 22. Artist representations of reconfiguring
operations: arm detaching (left) and arm extending
(right).
4.4 MAR restricting operations
The MAR must be able to reposition and operate
also in restricted design conditions. In particular the
MAR must be able to move from one location to
another one having only one arm and the torso or in the
worst case, having just one arm. In the previous
paragraphs, basic operations for a multi-arm robot have
been described assuming two arms and one leg.
Logically the feasibility of these operations is strictly
dependent on the MAR design. Assuming restricted
configurations of the robot, some operations could not
be accomplished due to the lack of crucial elements.
This is the case for instance of the transportation
operation which is assumed to be performed with the
torso equipped with two arms. According to this, Table
3 shows the non-feasible operations according to the
MAR design restricted conditions considering the
following two possibilities:
 having 1 torso and 1 arm
 having only 1 arm
Table 3. MAR restricting operations (X=feasible)
Fig.23. Artist representations of restricting operations:
place with one isolated arm (left) pick with the torso and
one arm (right).
4.5 MAR observation operation
The MAR must be able to look at the surrounding
environment with its visual sensors to give a visual
feedback to Earth/ground segment. The environmental
observation operation of the MAR is assumed to be
performed during particular mission phases of the
satellite (e.g. during rendez-vous with servicer modules
or during orbit and attitude state changes of the
satellite). Therefore this operation is not related to the
classic "monitoring" operations of the MAR performed
during all the basic operations to provide feedback to
Earth/ground segment on the MAR motion state.
Moreover this operation is assumed to be performed in
stationary condition and at the MAR home base. At the
contrary classic "monitoring" operations of the MAR
are performed during the motion of the MAR assuring
for instance the avoidance of any possible obstacles.
4.6 MAR power supply and charging operations
All the MAR locomotion operations are in particular
performed with the connection of at least one MAR’s SI
at any time. On the other hand, the power supply can be
assured only when the MAR is connected to those
interfaces which can provide power. Otherwise the
exploitation of a battery is necessary. Also, if during
operations the power supplied by the arm or leg SIs is
not sufficient, an extra source of power could be
necessary. Consequently, assuming that the spacecraft
structure is equipped with both passive (interfaces not
actuated providing only power and data connectivity)
and mechanical (interfaces not actuated and not
providing power and data connectivity) SIs, dedicated
charging plan should be executed to address those
operations engaging limited power supply conditions.
According to the aforementioned considerations, a
complex mission of the MAR including operations over
both satellite and reflector tiles (like for instance for
tiles assembly mission) should include a dedicated
charging plan in order to provide sufficient power by
using also MAR battery. In conclusion, the battery

Page 14 of 15
subsystem is meant to provide the power needed for
motion over mechanical interfaces and operations
requiring extra power. The energy storage system is
meant to recharge while the manipulator is stationary (at
its home base or wherever a passive SI is available on
the spacecraft structure). The usage of solar panel can
also improve power autonomy during the restricted
operations.
4.7 MAR autonomy
The main purpose of the MAR is to transfer the
mirror tiles and/or ORUs between the storage area or
servicer to the telescope structure. In order to answer the
problem of reachability, for instance, the MIRROR
concept is based on the implementation of a walking
robot that ensures a high mobility along the structure.
The MAR should also be able to perform transportation,
manipulation and repositioning operations, as well as
self-reconfiguration motions, for instance to move from
a serial to a parallel configuration or vice versa. All of
these operations need a suitable reference motion, which
should be provided by a motion planner. Equipped with
Standard Interfaces at both of its end-effectors, it can
attach and manipulate the mirror tiles and/or ORUs, but
also move along the structure by connection to either
the mirror tiles and/or ORUs or the spacecraft SI. The
connection is also used to power the arm and transfer
the control commands coming from the spacecraft
computer.
The autonomous transfer of the mirror tiles and/or
ORUs follows an execution plan prepared and validated
off-line, in the Monitoring and Control Centre (MCC),
on the ground segment. The MCC includes a satellite
design, modelling and validation tool. It also allows the
automatic planning of the assembly that can be verified
with a multi-physics simulator. All these elements are
working iteratively together to prepare a valid execution
plan that is finally uploaded to the spacecraft for
execution. The MCC includes visualisation front-end to
support the design, verification and monitoring
activities during sequence execution.
The plan should provide a collision-free motion to
move from an initial to a final pose or configuration (i.e.
Cartesian poses for the end effector or Joint values for
each individual joint in the robot). The planner should
consider all the relevant constraints, including a model
of the environment, a model of the robot itself, and joint
and torque limits for the robot. Additional constraints
might come from specific restrictions for the desired
motion, e.g. maintaining a desired orientation on the
manipulated part, or moving through desired waypoints
during the motion. Particular operations, such as the
walking motion, imply multi-contact operations that
require considerations on the closed kinematic chain of
the robot, and motion of the robot within the self-motion
manifold (i.e. motions that change the configuration of
the robot without changing the position of the end
effectors). In cases where both arms should move at the
same time, for instance during a repositioning operation,
a suitable scheduling of the motions should be provided
in order to minimize the risks of self-collisions between
the two arms.
The starting point of the plan generation is a
predefined, valid, plan describing a set of operations.
The plan can be developed at different levels, from
robot manipulator independent descriptions (e.g. high
level description of motion and placement of modules)
to robot-specific joint set-points (that can be interpreted
and executed by the space segment). This results in a
plan in which all the approach, pick, transfer, place and
repositioning operations are well defined with regards to
their respective states.
5. Conclusion and Perspectives
This paper introduces the ESA MIRROR project and
the preliminary design of a MAR, a multi-arm modular
robot using Standard Interconnects for On-Orbit Large
Assembly.
Since future telescopes are assumed to be modular to
achieve large assembly in orbit, a modular robotic
system is also assumed to be relevant for the MAR
system. The modularity should:
 Allow to easily break down a complex
monolithic system into simpler independent
subsystems or modules and this is assumed to
be beneficial both for the space telescope
system and the robotic system. SIs are the
means to interface these modules.
 Provide a longer life time (independent
maintenance, upgrade or replacement of the
module).
 Reduce risks related to technology
obsolescence.
In the context of the MIRROR activity, the selected
level of modularity allows the MAR to adopt a minimal
modular configuration, suited for performing the
mission tasks. In the baseline configuration the robot
has two arms, each mounted on a different SI, and a leg.
As perspectives, such a concept could pave the way
to adaptive and reconfigurable robotic operations
involving multi-robot cooperation. Since all the module
are linkable together thanks to SIs, the robotic structure
can be adapted or reconfigured in real time to face
unexpected situations. Also, modular robots can be
linked to cooperate together for handling more complex
tasks that surpass the capabilities of a robot alone.
For instance, considering an inspection task: the
robot could inspect the opposite face of the telescope
with its camera. The reach of a single arm is not

Page 15 of 15
sufficient to position the torso in an acceptable viewing
position. However, by connecting two arms or more
end-to-end the robot can use them as a single longer arm
to position the torso for a better view.
In alternative use, two MARs may collaborate to
complete manipulation tasks that they would not be able
to complete alone. Leveraging their identical interfaces
they could navigate on the telescope structure to
position a larger tile assembly with higher precision
than they could alone. If an entire MAR is not needed,
one could leave an arm in position to help with the
placement task. The MAR may then be directed to use
its remaining arm to position the torso to image the
placement task as it occurs.
Finally, should the need arise, MARs may connect
to each other to form larger robots with a larger number
of limbs: for instance, two MARs connected by their
legs form a four-legged robot.
Fig.24. Artist representations of on-orbit modular multi-
robot cooperation.
Acknowledgements
This study is funded by ESA in the framework of the
Technology Research program (contract No.
4000132220/20/NL/RA) entitled “Multi-arm
Installation Robot for Readying ORUS and Reflectors
(MIRROR)”.
The authors would like to thank Thales Alenia Space
France, in particular Jurij D’Amico and Barthelemy
Attanasio for their technical contributions to this paper.
References
[1] MM. Arancón, et al. "ESROCOS: a robotic
operating system for space and terrestrial applications."
14th Symposium on Advanced Space Technologies in
Robotics and Automation (ASTRA). 2017.
[2] J. Vinals, J. Gala, and G. Guerra. "Standard Interface
for Robotic Manipulation (SIROM): SRC H2020 OG5
Final Results-Future Upgrades and Applications." i-
SAIRAS 2020.
[3] M.A. Roa, Towards In-Situ Assembly of a Large
Space Telescope, Robotics in-situ servicing, assembly
and manufacturing workshop at the IEEE/RSJ
International Conference on Intelligent Robots and
Systems (IROS), 2020.
https://wvrtc.com/iros2020/invited-speakers.shtml#
(accessed 09.07.2021)
[4] P. Letier, X. Yang, M. Deremetz et al., MOSAR:
Modular Spacecraft Assembly and Reconfiguration
Demonstrator, ASTRA, 15th Symposium on Advanced
Space Technologies in Robotics and Automation,
Noordwijk, Netherlands, 2019.
[5] M. Deremetz, Modular Robotic Assets and
Technologies for Future on-orbit Applications, Robotics
in-situ servicing, assembly and manufacturing workshop
at the IEEE/RSJ International Conference on Intelligent
Robots and Systems (IROS), 2020.
https://wvrtc.com/iros2020/invited-speakers.shtml#
(accessed 09.07.2021).
[6] M. Deremetz, P. Letier, G. Grunwald, M. A. Roa, B.
Brunner, B. Lietaer, M. Ilzkovitz. MOSAR-WM: A
relocatable robotic arm demonstrator for future on-orbit
applications. In 71th International Astronautical
Congress (IAC), The CyberSpace Edition, 2020.
[7] P. Schoonejans, et al. "Eurobot: EVA-assistant robot
for ISS, Moon and Mars." Proceedings of 8th ESA
Workshop on Advanced Space Technologies for
Robotics and Automation, ASTRA, Noordwijk. 2004.
[8] A. Rusconi, P. Magnani, P. Campo, et al. Dexarm
engineering model development and test. In 10th ESA
Workshop on Advanced Space Technologies for
Robotics and Automation-ASTRA, 2009.
[9] M. Kortmann, et al. "Design and qualification of a
multifunctional interface for modular satellite systems."
69th international astronautical congress, Bremen,
Germany. 2018.
[10] P. Letier, T. Siedel, M. Deremetz, E. Pavlovski, B.
Lietaer, K. Nottensteiner, M.A. Roa, J.S. Garcia-
Casarrubios, J.L.C. Romero, J. Gancet. HOTDOCK:
Design and Validation of a New Generation of Standard
Robotic Interface for On-Orbit Servicing. 71th
International Astronautical Congress (IAC), The
CyberSpace Edition, 2020.
[11] Lagrange points, 02 November 2017
https://www.esa.int/ESA_Multimedia/Images/2017/11/
Lagrange_points (accessed 09.07.2021).
[12] G. Visentin, (2006). Space Robotics. In Climbing
and Walking Robots, pp 27-37. Springer.